性能不是可选功能，而是基本要求。它会影响转换、保留和基础设施成本，因此属于产品对话，而不仅仅是工程。本指南从概念上阐述了在生产中支持快速 React 应用程序的策略。
衡量性能：Web Vitals
你无法优化你不衡量的东西。核心网络生命力是 Google 建立的一组作为用户体验参考的指标，并且可以作为指南针。
最大内容绘制 (LCP) 测量渲染最大内容元素之前的时间，它是“页面看起来准备就绪时”的代理。低于2.5秒被认为是好的； 2.5 到 4 秒之间需要改进；超过 4 秒就不好了。
首次输入延迟 (FID) 测量用户首次交互和浏览器响应之间的时间，即页面的响应速度。低于 100 毫秒即可； 100 到 300 毫秒之间需要改进；超过 300 毫秒就不好了。
累积布局偏移 (CLS) 衡量页面的视觉稳定性，即加载时内容“跳跃”的程度。低于0.1为好； 0.1到0.25之间需要改进；高于 0.25 是不好的。
支持持续改进的做法是在现场与真实用户一起收集这些指标（真实用户监控），并将其发送到分析工具。实验室测量有助于诊断，但只有现场数据才能揭示用户设备和网络上实际发生的体验。
代码分割和延迟加载
初始加载时间的最大敌人是单一的捆绑包，一次性交付用户稍后才需要或永远不需要的代码。拆分代码可以从三个方面解决这个问题。
按路线划分仅在用户导航到每个页面时加载该页面的代码，并在转换期间显示加载指示器。 按组件拆分对于重型组件也适用相同的原理，复杂的图表或海量数据表只有在实际发挥作用时才会下载。而动态导入将这个想法带到了交互层面：例如，Excel 的导出库仅在用户单击“导出”时才加载；大量地图库或条件填充遵循相同的逻辑。一种优雅的补充技术是根据意图预加载，当光标经过链接时开始下载产品的详细信息，预测导航而不影响初始加载。
React 中的渲染优化
即使使用精简包，不必要的重新渲染也会降低流动性。记忆是这里的核心工具。
昂贵的计算、过滤和排序大型列表、聚合统计数据都必须被记住，并且只有在它们的依赖关系发生变化时才重新计算。纯组件可以被记住，当它们的属性没有改变时不会重新渲染。并且传递给子组件的回调必须稳定，防止每次渲染的新函数触发级联重新渲染。注意不要通过条件反射来记忆：记忆的成本很高，在没有瓶颈的地方应用它只会增加复杂性。
对于很长的列表，虚拟化是决定性的。它不会渲染 DOM 中的数千个项目，而是仅渲染可见窗口，并在用户滚动时回收元素。内存和流动性的提升是巨大的，并且对于固定高度和可变高度列表都存在。
图像优化
图像通常是页面上最大的权重。三种做法占了大部分收益。
第一个是提供响应式图像：为设备和屏幕密度提供适当的尺寸，优先加载主图像（首屏）并延迟加载其余图像，理想情况下使用模糊的占位符以避免布局跳过。第二种是采用现代格式，例如 AVIF 和 WebP，在不支持它们的浏览器中回退到 JPEG，可以显着节省带宽，而不会造成明显的质量损失。第三种是视口之外的图像的延迟加载，这些图像只有在接近可见区域时才进入网络。
捆绑包大小优化
减少捆绑是一项持续的工作。捆绑包分析器揭示了是什么拖累了它，通常是在只需要一个功能时导入整个大型依赖项。 Tree Shaking 取决于仅导入您使用的内容：从库中引入单个函数，而不是整个包，或者用精简的替代方案和专有实用程序替换严重的依赖项。大型且特定的库、地图、电子表格处理器必须仅在资源被触发时动态加载，并且填充必须是有条件的，仅由实际需要它们的浏览器下载。
分析和调试
不进行测量而进行优化只是猜测。 React 的分析器允许您记录每个组件渲染所需的时间以及在哪个阶段（组装或更新），从而使真正的瓶颈可见。一种有用的启发式方法是将超过一帧预算（60 fps 时约 16 毫秒）的渲染视为可疑，并将其发送以进行监控，以便在用户抱怨之前在生产中出现性能回归。
网络优化
网络层提供的收益常常被低估。 资源提示指示浏览器预测工作：提前解析外部域的 DNS、预先建立与字体服务器或 API 的连接、预取稍后需要的低优先级资源，以及预加载关键资源（例如必要的 CSS 或主图像）。
在请求效率方面，批处理将多个单独的调用合并为一个请求，减少了往返开销，当许多组件几乎同时请求相似的数据时尤其有用。 缓存策略关闭了循环：服务工作人员可以提供来自缓存的响应并在后台更新它，而数据管理库控制在需要新的获取之前响应被视为新鲜的时间，从而避免冗余请求。
结论
Web 性能是一个连续的四步过程：测量（Web Vitals、分析、真实用户监控）、优化（代码分割、记忆、延迟加载）、验证（A/B 测试、现场监控）和迭代（性能预算和自动检查）。
值得正式制定性能预算、对脚本、样式表、图像和总页面重量的明确限制，并将其视为团队在没有有意识的决定的情况下不会超出的合同。逐步实施技术，始终衡量对用户重要的指标的真正影响，而不是孤立的实验室数字。
您如何监控和优化应用程序的性能？分享你的技巧！
另请阅读
- [Next.js 中的缓存和流式传输：性能成为架构决策0
- [2025 年 React 和 Next.js 的国际化最佳实践（i18n）1
- [什么是 React 服务器组件以及为什么逻辑要回到服务器2?
- [Alpine.js：2025 年简单交互式网站的终极解决方案3
- [GraphQL 应用程序：实施指南4
- [无头商务：解耦架构指南5