性能预算与核心指标计算器

本地处理

打赏支持
分享链接
反馈建议

Google 按 75 分位评估真实用户数据（不是实验室跑分）。三项核心指标全部"好"才算通过，可回收的转化率损失不容小觑。

LCP 最大内容绘制（秒）

INP 交互到下次绘制（毫秒）

CLS 累积布局偏移

TTFB 首字节时间（毫秒）

FCP 首次内容绘制（秒）

页面总大小（MB，选填）

请求数（选填）

达标项数

需改进项数

较差项数

CWV 通过(1/0)

指标	当前值	好	需改进	较差	评级

阈值判定：LCP ≤2.5s 好 / ≤4.0s 需改进 / >4.0s 较差；INP ≤200ms / ≤500ms / >500ms；CLS ≤0.1 / ≤0.25 / >0.25；TTFB ≤800ms / ≤1800ms / >1800ms；FCP ≤1.8s / ≤3.0s / >3.0s。核心指标为 LCP、INP、CLS 三项。

三项核心指标各测什么

指标	测量内容	好	需改进	较差
LCP 最大内容绘制	首屏最大元素渲染完成的时间	≤2.5s	2.5–4.0s	>4.0s
INP 交互到下次绘制	用户交互到界面响应的延迟	≤200ms	200–500ms	>500ms
CLS 累积布局偏移	页面元素意外移动的程度	≤0.1	0.1–0.25	>0.25

两个辅助指标也常被一起看：TTFB（≤800ms 好）是 LCP 的前置条件，服务器慢则 LCP 不可能快；FCP（≤1.8s 好）反映首次内容出现的时间。它们不是核心指标，但常常是解释问题的关键线索。

为什么是 75 分位

Google 不使用平均值，而是看"至少 75% 的真实访问达到了「好」的水平"。这个选择很实际——平均值会被少数极快或极慢的样本拉偏，而 75 分位更接近大多数用户的真实体验。

这也意味着：一台高性能设备上的测试结果再好也没用，要按你的真实用户设备分布来优化。移动端用户占比高的站点，往往需要在低端安卓机上做验证。

各指标的优化抓手

指标不达标	优先检查
LCP 偏慢	① 首屏图片是否用 WebP/AVIF、是否设了 fetchpriority=high ② 是否误用了 loading=lazy ③ TTFB 是否过高 ④ 是否有渲染阻塞的 CSS/JS
INP 偏差	① 是否有超过 50ms 的长任务 ② 事件回调里是否做了重计算 ③ 是否在主线程做大量 DOM 操作 ④ 第三方脚本是否阻塞主线程
CLS 偏差	① 图片/iframe/广告位是否预留了固定尺寸 ② 字体加载是否导致文本重排（用 font-display:optional 或预加载字体）③ 是否有动态插入的内容把已有内容顶下去
TTFB 偏高	① 是否有 CDN ② 服务端是否有缓存 ③ 数据库慢查询是否在关键路径 ④ 是否启用了 HTTP/2 或 HTTP/3

三者的性能影响有多大

多项行业研究给出的量级参考：LCP 不达标通常伴随约 20% 的转化率下降，INP 约 17%，CLS 约 15%。虽然具体数字因行业而异，但方向是明确的——性能问题会直接体现为收入损失，而不只是"体验差一点"。

实用做法是给每个模板建立"性能预算"，在 CI 里跑 Lighthouse 并对关键指标设阈值，一旦超标就阻断发布。这比事后发现问题再返工要划算得多。

你可能还想问

性能预算怎么定？

先量化业务目标（如加载时间每快一秒带来的转化提升），再反推资源体积与关键指标上限；预算要能被流水线校验，否则容易流于口号。

核心指标看哪几个？

常见看加载性能、交互响应与视觉稳定性三类；只盯一个指标容易顾此失彼，例如为提速牺牲布局稳定反而更糟。

超预算了怎么办？

先定位是哪类资源超限（图片、脚本还是字体），再决定压缩、懒加载或延后加载；不要一刀切砍功能。