LCP 性能预算计算器

LCP（Largest Contentful Paint，最大内容绘制）是 Google 核心网页指标（Core Web Vitals）之首：视口内最大元素（通常是主图或标题块）渲染完成的时间。及格线 2.5 秒（P75 口径），超过 4 秒判「差」。它不是一个时间点的开销，而是流水线的总和：TTFB（服务器响应）→ 资源发现（HTML 解析到 <img>）→ 资源加载（图片下载）→ 渲染呈现（解码绘制）。每个环节都在花同一个 2.5 秒的预算。

性能预算（Performance Budget）的管理方法：先定总账（2.5s），再按阶段分账。推荐配比：TTFB ≤ 0.6s（服务器+网络）、渲染阻塞 ≤ 0.4s（关键 CSS/JS）、LCP 资源加载 ≤ 1.0s、渲染 ≤ 0.5s。优化手段与账目的对应关系：TTFB 超标查 CDN/缓存/服务端渲染；发现延迟查 preload/fetchpriority="high"；加载慢查图片格式（WebP/AVIF 省 30-50%）与响应式 srcset；渲染慢查 CSS 阻塞与字体 swap。本工具把 2.5 秒按你的实际数据分账，定位超支阶段并给出对应优化清单。

LCP 在核心网页指标中的位置：CWV 三件套分工明确——LCP 管「加载体验」（最大内容何时出现），INP 管「交互响应」（点击后多久有反馈，2024 年取代 FID），CLS 管「视觉稳定」（布局有没有乱跳）。三者都进 Google 排名信号，但只有 LCP 是纯加载指标：它衡量的是用户等待的「主观时长」——最大元素出现前，页面在用户眼里就是「还没加载完」。完整指标体见 网页性能指标计算器。

四段流水线的精确边界：TTFB 从导航发起到首字节到达（DNS+TCP+TLS+服务端处理全在里面）；资源发现是浏览器解析 HTML 直到定位 LCP 资源 URL 的时间（img 标签靠后发现、CSS 背景图更晚、preload 可以提前）；资源加载是字节传输时间（大小÷带宽+排队）；渲染延迟是字节到齐后到实际绘制的间隙（解码、阻塞的 JS/CSS、字体）。每段都有独立的优化武器库。

P75 口径与两种数据的差异：Google 判定用的是 CrUX 真实用户数据的第 75 分位——意味着每 4 个用户里可以有 1 个超过 2.5s。实验室数据（Lighthouse）是单次模拟（节流 CPU+网络），适合定位问题；真实用户数据（CrUX/RUM）适合判定达标。两者常差 50% 以上：实验室 1.8s 的页面，真实用户 P75 可能 2.8s（老旧手机+弱网）。优化要对真实数据负责。

图片型 LCP 的组合拳（它占 LCP 元素的大多数）：格式上 AVIF/WebP 比 JPEG 省 30–50% 体积（可用 图片压缩计算器 估算收益）；尺寸上 srcset 让手机不下载桌面级大图；优先级上 fetchpriority="high" 让 LCP 图插队，同时严禁对它懒加载（懒加载是 LCP 的头号自残行为）；发现上 preload 提前于解析。四招叠加通常能砍掉一半的加载时间。

把预算制度化：性能预算只有写进流程才不会腐化——CI 里跑 Lighthouse CI，LCP 预算超标直接打回合并；核心页面挂 RUM 监控（真实用户分位曲线），发版后对比 P75 漂移；把「LCP 分账表」贴在团队墙上，每次需求评审多问一句「这功能花哪段预算」。性能不是一次优化项目，而是一种持续的财政纪律。