第3章：性能测量工具 — 用数据说话，而不是靠直觉

做动态交付启动速度优化，最怕什么？我见过不少团队，上来就对着代码一顿猛改，改完自我感觉良好，结果线上还是慢。说白了，没有数据支撑的优化就是瞎忙活。这一章，我就带你搞懂两款最常用的性能测量工具：Lighthouse 和 WebPageTest。它们就像你的“体检报告”，能告诉你哪里虚、哪里堵。

3.1 工具全景图：你应该用哪个？

我先把这两个工具的核心关系画出来，你一看就明白。

3.2 Lighthouse：你的随身体检仪

Lighthouse 是 Google 出品的开源工具，内置在 Chrome DevTools 里，也可以命令行跑。我个人的第一道防线就是它。你想想看，一个报告同时覆盖性能、可访问性、SEO、最佳实践，多省事。

3.2.1 怎么用？

• Chrome 开发者工具： 打开要测的页面 → F12 → Lighthouse 标签页 → 勾选“Performance” → 点击“Generate report”。
• 命令行： 适合集成到 CI/CD。例如：

npx lighthouse https://example.com --view --output=json

加个 --preset=desktop 可以测桌面场景，默认是移动端模拟（Moto G4、3G 网络）。

3.2.2 关键指标解读

3.2.3 实战小案例

有一次，一个 React 动态交付页面的 LCP 高达 4.8s。我用 Lighthouse 报告往下翻，发现诊断建议里写“图片没有显式尺寸”。打开代码一看，果然一堆 <img> 没设置 width/height，导致布局偏移和图片加载占用大量时间。加上尺寸属性后，LCP 降到 2.1s。你看，工具直接告诉你答案，省得你瞎猜。

3.3 WebPageTest：把细节放大镜

如果说 Lighthouse 是体检仪，那么 WebPageTest 就是核磁共振。它给的信息更细、更真实。我尤其喜欢它的“瀑布图”和“多位置测试”功能。

3.3.1 核心操作

1. 打开 webpagetest.org（自建私有实例也行）。
2. 输入测试 URL，选择位置（比如 东京、弗吉尼亚、伦敦）和浏览器（Chrome / Firefox / 真实设备）。
3. 点击“Start Test”，等 1～3 分钟。

结果页会给你一串数字：First Byte、Start Render、Speed Index、Time to Interactive、Fully Loaded。每个都能点击展开瀑布图。

3.3.2 必看指标

• TTFB（首字节时间）： 超过 800ms 就说明后端或 CDN 太慢，要么升级服务器，要么加缓存。
• Start Render： 用户看到内容的时间，通常应小于 1.5s。
• Speed Index： 和 Lighthouse 的 SI 类似，但更精细。超过 5.0 就要折腾了。
• Fully Loaded： 所有资源加载完成的时间——注意，这个值可能被第三方脚本拖死。

3.3.3 对比测试技巧

WebPageTest 支持“对比模式”，最多输入 3 个 URL 并行测试。我经常用它来对比老版本和新版本的速度差异，或者“有 CDN”和“无 CDN”的效果。有一次，我把一个 SPA 页面的首屏 JS 从 800KB 拆成异步加载 + 关键 CSS 内联，用对比模式看到 Speed Index 从 12.3 降到 4.8，同事们当场闭嘴。

3.4 其他工具速览

除了这两大主力，还有几个我会备用的：

• PageSpeed Insights： 基于 Lighthouse，但多了“字段数据”（真实用户数据 CrUX）。适合快速评估线上真实体验。
• Chrome DevTools Performance 面板： 录制定制化的性能分析，比如查看具体函数的调用栈、内存泄漏。适合深入代码级调试。
• Sitespeed.io： 开源，可以持续集成测试，生成历史趋势图。我们团队用它来做性能监控 dashboard。

3.5 综合使用策略：一个简单的 SOP

1. 日常迭代： 本地用 Lighthouse 面板快速验证改动没有引入性能回退。
2. 预上线检查： 用 WebPageTest 跑一次“多位置 + 首次访问 + 重复访问”，记录下 TTFB、Start Render、LCP。
3. 线上监控： 接入真实用户监测（RUM）工具，比如 Google Analytics 的 Speed 报告或 Third party 工具。

这套流程我用了三年，基本没失手过。别追求一个工具解决所有问题，组合拳才是王道。