第2章 启动速度优化核心指标：FCP、LCP、TTI
启动速度优化，第一步是搞清楚到底要优化什么。
很多人上来就搞代码压缩、图片优化，一顿操作猛如虎，用户还是抱怨慢。为什么呢？因为没对准真正的痛点。
我个人习惯，先盯住三个核心指标：FCP、LCP、TTI。这三个指标基本覆盖了用户从看到内容到可交互的完整链路。
2.1 FCP（First Contentful Paint）—— 首次内容绘制
FCP 就是浏览器渲染出第一个有意义内容的时间点。说白了，就是用户看到页面上出现了第一个文字、图片，或者非白色的背景。时间越短，用户感觉“页面加载了”越快。
我在项目中遇到过 FCP 优化得极好的页面，首屏几乎瞬间就有文字，但用户还是离场——因为虽然显示了内容，但页面无法操作。这说明 FCP 只是第一道门槛。
核心经验：FCP 的目标时间应在 < 1.8 秒。超过 3 秒，用户流失风险急剧上升。
优化 FCP 的核心思路：消除渲染阻塞。包括内联关键 CSS、异步加载 JS、压缩 HTML 初始体积。
2.2 LCP（Largest Contentful Paint）—— 最大内容绘制
LCP 衡量的是视口内最大可见元素（图片、视频、大块文本）完成渲染的时间。这个指标直接反映用户感受到的“主要内容加载完成”时刻。
为什么我建议重点盯 LCP？因为它和用户满意度高度相关。你想想看，一个页面 FCP 很快但 LCP 很慢，用户看到标题了却一直等不到核心图片，体验一样差。
我碰过一个案例：一个 Hero 图片 2MB 没压缩，LCP 达到 5 秒。压缩成 WebP 后只有 200KB，LCP 降到 1.5 秒。
优化 LCP 就是要优化首屏最大元素的加载。常见元素：Hero 图片、大标题、视频首帧。技术上优先做图片压缩、CDN 加速、preload 关键资源。
2.3 TTI（Time to Interactive）—— 可交互时间
TTI 是指页面变得完全可交互的时间点。注意是“完全”，不是部分按钮能用。页面可能看着渲染完了，但 JS 还在解析，点击没反应。
我见过一个案例：首屏渲染挺快，但用户点击按钮要等 3 秒才有反馈。这种“假快”比真慢更让人恼火。TTI 就是用来揪出这个问题的。
我个人习惯用 long tasks API 来识别哪些任务阻塞了交互。把超过 50ms 的长任务拆散或延迟执行。
千万不要只看 FCP 和 LCP 就以为优化到位了。如果一个页面 JS 执行时间过长，TTI 会严重滞后，造成用户流失。
2.4 三个指标的关系与优先级
| 指标 | 关注点 | 典型问题 | 优化重点 |
|---|---|---|---|
| FCP | 首次视觉反馈 | 白屏、首屏空 | 消除渲染阻塞资源、内联关键 CSS |
| LCP | 主要内容呈现 | 大图加载慢、字体延迟 | 图片优化、预加载关键资源、服务端渲染 |
| TTI | 交互可用性 | 长任务、JS 执行阻塞 | 代码分割、异步加载、长任务优化 |
我曾经在一个电商项目中，FCP 做到了 1.2 秒，LCP 2.8 秒，但 TTI 竟然到了 6 秒。用户以为页面卡死了，实际上只是第三方脚本没跑完。后来我们把非关键脚本延迟加载，TTI 降到了 2.5 秒。
2.5 如何测量这些指标？
实测有几种方式：
- Chrome DevTools：Performance 面板直接看 FCP、LCP、TTI 标记。
- Lighthouse：模拟打分，给出具体数值和优化建议。
- Web Vitals API：在 JavaScript 里跑
PerformanceObserver获取真实用户数据。
// 使用 PerformanceObserver 获取 LCP
const observer = new PerformanceObserver((list) => {
const entries = list.getEntries();
entries.forEach(entry => {
console.log('LCP:', entry.startTime);
});
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });2.6 核心指标与用户体验流程图
下面这张图展示了从加载到交互的过程中，三个指标各自覆盖的时间段。绿色代表基本可用，黄色代表主要内容到位，红色代表完全可交互。
你看，FCP 是最短的条，LCP 稍长，TTI 最长。优化目标就是让三条条尽可能向左缩短，尤其不能让 LCP 和 TTI 差距太大。
2.7 我的优化优先级建议
- 先保 FCP：如果首屏白屏，用户直接跑了。压缩 HTML、内联关键 CSS、用
loading="eager"保证首屏资源优先。 - 再攻 LCP：主要内容的加载速度。预加载首屏大图、压缩字体、使用
preload提示。 - 最后磨 TTI：干掉长任务、延迟加载非关键 JS、使用 Web Workers 分担主线程。
我个人习惯用 Web Vitals 数据做监控，设定阈值告警。比如 FCP > 2s 报警，LCP > 2.5s 报警，TTI > 3.8s 报警。这样能及时发现性能回归。
2.8 避坑指南
我曾经犯过一个错：只盯着 Lighthouse 模拟分数优化，忽略了真实用户环境。Lighthouse 模拟的网速和设备是固定的，但用户可能是千元机、弱网。结果模拟分数很高，上线后用户依然骂慢。后来我加上了真实用户监控（RUM），才真正看清问题。
所以，指标要结合模拟和真实数据一起看。模拟查瓶颈，真实查分布。
2.9 小结
记住三个核心指标：FCP、LCP、TTI。它们分别代表“看到”、“看到主要内容”、“可以操作”。优化时先保证 FCP，再提升 LCP，最后打磨 TTI。别跳步。