React 性能优化

如何为 React 项目建立性能预算和回归门禁？

性能优化只有进入开发、构建、发布和线上监控流程，才能避免几周后再次退化。

适合阶段：资深前端 / 技术负责人核心能力：性能预算 · CI/CD · 回归治理

面试官想考什么

• 预算应该约束什么？ 考察指标设计。
• CI 性能测试如何避免误报？ 考察工程实践。
• 线上发现回归怎么办？ 考察发布治理。
• 如何平衡业务需求和性能？ 考察决策能力。

一句话回答

按页面类型和设备建立 JS、资源、LCP、INP、CLS、长任务和错误率预算，在 CI 做稳定基线、线上用 RUM 监控趋势，并通过灰度、feature flag 和回滚处理回归。

面试回答详解

1. 预算维度

• 构建：初始 JS、路由 chunk、依赖体积和重复包。
• 运行时：LCP、INP、CLS、长任务、内存和错误率。
• 业务：关键流程完成率、转化和页面可用时间。

2. 门禁分层

PR -> bundle diff / lint / unit
CI -> 固定环境 Lighthouse/Playwright
灰度 -> RUM / 错误 / 业务指标
发布 -> 告警 / kill switch / rollback

实验室测试要固定设备、网络、数据和预热策略，使用趋势和阈值而不是一次波动直接阻断所有提交。

3. 变更归因

每次构建记录 release、依赖变化、bundle 组成和性能基线。线上按版本、路由、设备、地区和登录态比较，快速定位回归来源。

4. 取舍

预算不是绝对禁止功能，而是要求团队显式说明成本和补偿方案，例如延迟加载、服务端计算或业务分层。

可直接背诵的 30 秒回答

我会把预算分成构建、运行时和业务三类：初始 JS、chunk、LCP、INP、CLS、长任务、错误率和关键流程成功率。PR 做 bundle diff，CI 在固定环境做实验室基线，灰度后用 RUM 按 release 和设备观察。发现回归先 feature flag 或回滚止损，再定位依赖、组件、网络和服务端变化。

扩展知识

性能治理闭环

预算 -> 基线 -> PR 检查 -> CI -> 灰度 -> RUM
-> 告警 -> 止损 -> 修复 -> 预算复盘

面试官追问链

追问一：Lighthouse 每次波动很大怎么办？

• 考察点：是否理解实验室噪声。
• 回答方向：固定环境、预热、重复运行、看中位数/分布，不能只凭单次结果阻断。

追问二：产品要求引入一个大编辑器怎么办？

• 考察点：是否会做业务取舍。
• 回答方向：评估使用概率和收益，按交互懒加载、预取、隔离依赖，并明确增加的预算和业务价值。

追问三：预算超了但业务指标变好，如何决策？

• 考察点：是否能综合决策。
• 回答方向：量化性能成本和业务收益，分人群和页面分析，寻找保留收益的替代实现，而不是只看单一指标。

推荐阅读

• web.dev Performance budgets
• web.dev Core Web Vitals
• React Profiler API
• React 性能优化