前端性能预算：从 Lighthouse 分数到真实用户体验

性能不是“感觉快一点”，而是把页面体验拆成能诊断的预算，并在迭代中持续守住。Lighthouse 适合复现和定位实验室问题，真实用户监控更能反映设备、网络、缓存、地理区域和真实交互差异，两者不能互相替代。

指标与诊断顺序

• LCP 观察最大内容何时呈现；继续拆 TTFB、资源发现延迟、下载和渲染延迟。
• INP 评估用户交互到下一次绘制的响应；定位输入延迟、事件处理和后续渲染。
• CLS 关注会话中的意外布局移动；为图片、广告、字体和异步模块预留尺寸。
• TTFB 是重要诊断信号，但不是 Core Web Vitals；它帮助判断服务端与网络是否挤压渲染时间。

截至本指南核对的 web.dev 指标说明，良好体验通常以第 75 百分位衡量：LCP 不高于 2.5 秒、INP 不高于 200 毫秒、CLS 不高于 0.1。指标定义和阈值会演进，团队应链接到当前官方说明并记录核验日期，而不是把数字写死在多年不更新的规范里。

预算要落到页面和设备

预算按关键路由分别制定，至少包括首屏 JS/CSS、最大图片、字体数量、第三方脚本、长任务、API 等待、LCP/INP/CLS 和低端移动设备表现。先用当前实际数据建立基线，再为改进设置明确目标。不能把单一 gzip 包大小当成性能的全部：解析、执行、图片解码、布局和主线程竞争也会耗时。

预算阈值要设置软告警与发布门槛，超预算要附上原因、受影响页面、替代方案和到期责任人。按移动/桌面、冷/热缓存、登录/匿名和主要地区切片；百分位要有足够样本并报告置信度，避免小流量波动触发误判。

预算落地样例

先为首页、文章阅读、图书和后台等关键路径分别建表：记录当前基线、目标百分位、首屏资源体积、主线程长任务与实际用户指标。新功能在评审时声明新增 JS、CSS、媒体和第三方请求；CI 对构建体积做差异提示，超过门槛时要求说明而不是悄悄忽略。预算应结合站点用户设备和数据分布校准，不能照抄别家绝对数值。

当分数下降时先确认实验环境、缓存状态、测试版本与请求是否一致，再定位变化最大的资源或任务。只有相同条件下可复现的回归才适合作为自动阻断；生产用户体验看字段指标和真实业务路径，同时检查错误率、登录成功率等反向指标，避免为了更快而删掉必要功能。

从测量到优化

1. 在真实用户端用 PerformanceObserver/官方 web-vitals 库收集可支持的字段指标，并记录路由模板、release、设备档位与连接类型。
2. 只上报汇总值和必要诊断属性，不发送自由输入、完整 URL、DOM 或账号信息。
3. 对慢页面用 Chrome DevTools/Lighthouse 录制复现，再用网络瀑布和 Performance trace 区分网络、脚本、渲染与第三方影响。
4. 优先修复主要用户路径：压缩并正确选择图片、固定媒体宽高、拆分非首屏 JS、减少阻塞脚本、缓存有版本的静态资源。
5. 上线后在相同路由、版本和设备分层下比较字段数据，检查中位数之外的第 75/95 百分位与错误率。

实验室工具的模拟网络和脚本执行条件固定，不代表生产设备；INP 尤其需要真实交互观察。性能提升也不能以页面空白、减少必要提示或推迟关键内容为代价。

回归门禁和取舍

CI 选择少数核心页面、固定视口和网络配置执行基准测试；避免把噪声很大的绝对分数作为唯一阻断条件。可同时监测资源预算差异、布局变化和关键交互耗时，并保留可查看的报告。第三方脚本需要明确 owner、加载时机、隐私影响和移除条件。

实用检查表

• 首屏 LCP 资源是否能从 HTML 直接发现，是否被无关脚本阻塞。
• 图片是否有宽高、合适尺寸与格式，首屏和长列表的加载策略是否分开。
• 输入后的同步工作能否分片，昂贵计算是否需要 Worker 或缓存。
• 动态模块加载、字体替换和内容插入是否造成布局偏移。
• 真实用户数据是否按版本与路由观察，并排除隐私敏感参数。

参考：web.dev Web Vitals、测量 Web Vitals、LCP 优化指南、MDN PerformanceObserver。