先测量再优化：Paul Irish 的提速工作流程

为什么先优化通常在浪费时间

当你从修复入手时，性能工作会感觉很随机。今天你压缩文件，明天你调整缓存，然后又移除一个库。有时候有用，有时候完全没变化，而你无从得知原因。

最大的风险是优化了错误的方向。如果页面慢是因为主线程被 JavaScript 阻塞，那么花数小时压缩图片几乎不会有什么效果。或者你加速了用户并不在意的部分，而真正的延迟来自长时间的 API 调用、不断回流的布局，或一个阻塞线程的脚本。

按感觉判断也有陷阱。“感觉更快”可能是安慰剂（比如加了一个 spinner），或者因为在不同的网络、设备或时间测试得到的假象。“是真的更快”意味着在相同条件下做相同行为，得到更好的指标。

一个简单的承诺能修正大部分问题：在优化前先测量，然后再决定。当你把性能当作一个测量问题来看，就不再猜测，而是真正开始学习。

一个实用的循环看起来像这样：选一个需要改进的用户动作，在可重复的条件下记录基线，做一处可解释的改动，然后重新测量，只有当数字变好时才保留改动。

Paul Irish 与先测量的习惯

Paul Irish 是网页性能领域最知名的声音之一。他通过对浏览器工具和性能指导的工作，推广了一个直接的想法：你的第一件事不是猜哪儿慢，而是证明它。

这种心态会改变团队动态。与其基于“图片总是问题”或“肯定是框架”这样的习惯争论，你更从证据出发。当你能指向时间线、慢查询或长任务时，讨论就从相互指责转为解决方案。

“先测量再优化”还能冷却性能争论，因为它建立了共同规则：就要测什么达成一致、就什么叫“更好”达成一致，只有数字有变化才庆祝。

这在小站点和大型应用上都适用。一个单一基线能阻止市场页上随机的微优化；在大型产品上，一致的测量避免性能变成永无止境的待办事项。

把它具体化的一个简单办法是把性能当成 bug 报告：清晰的复现步骤、你看到的指标，以及一处改动绑定一处结果。如果两个人意见不合，就重新跑测量，让数据来决定。

把性能当作一个可观测的问题

首先把性能当作一个可观测的问题：增加观测手段来看到用户真实的体验。如果看不到，你就只能争论意见，而不是基于证据行动。这正是先测量的真正含义。

可观测不必很花哨。它是持续在固定地方收集少量信号，这样你能回答几个基本问题：

• 哪儿感觉慢？
• 时间都花到哪儿去了？
• 我们的改动有帮助吗？

通常你需要两类数据。

实验室数据是在受控设置中捕获：特定笔记本或测试设备、稳定的网络配置、每次相同步骤。它很适合调试，因为你可以按需复现慢点。

真实用户数据是用户在真实环境中体验到的：不同设备、地点和网络质量。它很适合优先级判断，因为它显示的是伤害真实用户的部分，而不是一次测试结果。

即便不是专家，你也能测量页面加载里程碑（比如首屏内容出现）、长任务与主线程阻塞、慢网络请求、昂贵的渲染工作（布局、样式、绘制）和服务器响应时间。

这些信号通常存在几个地方：浏览器开发者工具用于实验室剖析，服务器日志与追踪用于后端计时，分析或 RUM 仪表盘用于真实用户数据。例如，如果结账感觉慢，DevTools 可能显示浏览器在渲染一个庞大的购物车 UI 时很忙，而服务器日志显示 API 很快。没有可观测手段，你可能会去优化后端却始终解决不了真正问题。

第 1 步：建立可重复的基线

要在优化前测量，你需要一个可信的起点。基线是相同动作、以相同方式和在相同条件下测量的结果。

从一个真实的用户旅程开始，而不是“整个网站”。选一句能描述清楚的动作，例如“打开首页并滚动到第一个商品网格”或“登录并到达仪表盘”。把范围定窄能让数字更稳定，让接下来的步骤更清晰。

接着选 1 到 3 个匹配该旅程的指标。对于页面视图，一对常用指标是 LCP（主要内容出现速度）和 TTFB（服务器响应速度）。对于像结账这样的流程，你可能跟踪完成第一步的时间加上支付调用的 API 响应时间。太多指标会让人容易挑选有利数据。

把测试设置写下来，这样别人以后能复现。小的差别会影响结果：

• 设备与浏览器（包括版本）
• 网络（wifi vs 4G，是否节流）
• 缓存状态（冷缓存 vs 热缓存）
• 地点和测试数据（区域、账号类型、购物车大小）
• 运行次数（例如跑 5 次取中位数）

最后，为你的受众定义“足够好”的标准。例如：“在中档手机、4G 下 LCP 小于 2.5 秒”。如果你使用 Koder.ai，在测试前拍个快照能把基线锁定到一个已知版本上。

第 2 步：刻意复现慢点

在剖析之前，先让问题可按需重现。如果你不能重复它，就不能信任结果。

从用户感受出发，而不是假设。是首屏渲染慢？某次点击卡住没有响应？提交表单后长时间等待？挑出用户抱怨的具体时刻并集中在那儿。

做一次快速运行确认慢点是真实且可重复的。尽量保持其他条件不变：相同页面、相同设备、相同网络（如果可能）。然后写下触发动作和确切感觉慢的时刻，例如“点击支付后按钮冻结一秒”或“产品列表出现时滚动卡顿”。

保持可重复的一个简单办法是写一个小脚本：从新标签页打开页面，执行导致卡顿的动作，记下准确的慢点，然后再重复一次确认。

只捕获一到两次基线录制，不需要几十次。你只需要足够的证据来判断“是的，慢点确实存在，且就发生在这里”。

第 3 步：剖析以找到主要瓶颈

一旦你能复现慢点，就别猜了。打开剖析器（大多数人用浏览器的 Performance 面板），录制一次慢交互。目标不是找出所有问题，而是弄清时间都花在哪儿。

从最大的时间块开始。微小的尖峰可能是真实存在的，但它们很少单独解释显著的延迟。

阅读录制的一种有用方式是把时间分到几个桶里：网络与加载（等待请求）、主线程脚本（长任务）、渲染与绘制（布局、样式、绘制）、空闲间隙（等待其他事情）、以及重复工作（同一昂贵步骤被反复执行）。

常见的错误是把慢服务器响应和慢客户端工作混淆。如果时间线上显示在请求进行中有长间隙，瓶颈可能是网络或后端。如果显示主线程长任务，那就是前端问题，即便网络很快。

在改动前，根据观察写一句简短、可测试的假设。例如：“页面慢是因为 API 返回后紧接着主线程被 JSON 解析阻塞。”这句话为下一步定下方向。

第 4 步：有目的地只改一件事

确定了可能瓶颈后，抵抗“把所有东西都修好”的冲动。改变一个变量，这样你能把因果联系起来。

保持改动小且易撤销。大规模重写会模糊结果：如果性能提升了，你不知道是为什么。如果更差，回滚就危险。

好的“一件事”改动是具体且可测试的。例子包括：延迟或移除一个阻塞渲染的第三方脚本、压缩慢页上的一张超大图片、为一个昂贵的数据库查询添加缓存、把一个沉重的 UI 组件拆分以减少首屏渲染工作，或减少剖析器中看到的一个热点循环的工作量。

在动手前写下你改了什么、为什么选它，以及你期望改善什么（比如“减少主线程时间”或“把 DB 时间减半”）。

如果团队使用支持快照和回滚的平台（比如 Koder.ai），在改动前拍快照能让“小且可撤销”不是空话。

第 5 步：验证影响并避免噪声结论

你改了一件事。现在证明它有用。

重新运行与基线相同的测试设置：相同设备、相同浏览器版本、相同路径和相同的运行次数。用相同的指标比较前后结果。不要在中途加入新的指标以迎合看起来更好的结果。

噪声是团队争论性能的常见原因。注意冷/热缓存、扩展或后台进程、不同网络条件或 VPN、服务器波动（安静时段 vs 忙时段），以及“刚发布后”和稳定状态的差异。

如果中位数改善但最差情况变差，那是个真实的权衡。决定对用户来说什么更重要，然后把决定记录下来：保留改动、回滚，或写一个新假设再测。

让性能工作不会变得不可能的常见陷阱

当你测错对象或一次改动太多，性能工作就会变得混乱。即便应用在改进，你也可能浪费大量精力而看不到明确成效。

一个常见错误是把一个分数当成目标。分数有用，但用户感受到的不是“92 分”，而是“页面两秒就展示内容”或“点购买立刻有反应”。选择一个用户可见的结果并持续测量它。

另一个陷阱是只在高性能笔记本上测试。许多慢点只会在中档手机、差的网络或 CPU 忙时显现。只在最好设备上剖析，你会漏掉真正的瓶颈。

混乱通常来自这样的模式：优先改善最容易的事而非耗时最多的事、把多个改动合并成一次、每次换测试路径、因为“感觉更快”就跳过复测、或没有用相同基线重复验证就宣布胜利。

如果你用像 Koder.ai 这样的聊天驱动平台构建应用，同样的纪律依然适用：一次改动，然后在完全相同的流程上验证，这样你才能信任结果。

一个每次都能复用的快速清单

如果只养成一个习惯，就养这个：先测量再优化。目标不是无限制地收集数据，而是形成一个你能信任的可重复循环。

把确切的用户旅程命名清楚。“首页慢”太模糊。“从商品页点购买到看到确认页”给你一个可重复的点击路径。

使用这个清单：

• 把旅程写成简短脚本，任何人都能复现。
• 冻结设置（设备、浏览器、网络、地点如果可能）。
• 捕获基线数值并记录一段基线录制。
• 剖析，选出最大的瓶颈，只改一件事。
• 重新测试、记录新数值并写下决定。

冷静的性能工作很简单：一条路径、一套设置、一处改动、一个经验证的结果。

示例：不猜测地修复慢结账

常见抱怨：用户点“Pay”后结账很慢。大家开始猜原因（图片、字体、按钮）。相反，把它当成一个可重复的测试。

建立可复测的基线。选一台设备和一条路径（cart -> checkout -> Pay -> confirmation）。开启网络节流（例如 Fast 3G），每次保持相同。测量一个简单的数值：从点击“Pay”到看到确认页的时间。

然后在同一时刻剖析，看看时间都花在哪儿。通常你在网络（长请求或过多请求）、服务器（支付调用慢，即使浏览器空闲）或主线程（浏览器忙于运行 JS 无法更新 UI）三类之间做判断。

想象剖析显示：点击“Pay”后浏览器先发了一个分析请求和一个反欺诈脚本调用，而支付请求被排在后面等待。这不是“把所有东西都加速”的问题，而是一个阻塞步骤。

有目的地改一件事。例如，让支付请求立即发出，把分析请求放到确认页展示后再发送。

用相同设置验证：相同节流、相同步骤、多次运行。如果确认时间下降且错误率没有上升，你就赢了。另外抽查一下没有破坏退款、重试或防止重复提交的机制。

下一步：把这个流程变成团队习惯

当测量成为常态而不是救火行动时，性能才不会失控。把测量设为默认动作，即便一切看起来正常也要这样做。

挑一小组固定的指标供团队始终跟踪，保持一致性以便观察趋势：

• 页面加载：Largest Contentful Paint (LCP)
• 交互性：Interaction to Next Paint (INP)
• 稳定性：Cumulative Layout Shift (CLS)
• API 速度：关键端点的 p95 响应时间
• 错误：客户端与服务器错误率

围绕这些指标构建一个循环。每周一次基线检查通常足够。当某个指标漂移时，那就是触发器：去复现慢点、剖析、改一件事并验证影响。

在团队实际使用的任何格式里保留一个简单的性能日志。记录你测了什么（包括设备、网络和构建）、你改了什么，以及改动后数字的变化。

如果你用 Koder.ai 构建，Planning Mode 可以帮你在更改前写下用户旅程和关心的指标。然后用快照与回滚让实验更安全：拍快照、应用一处改动、重新测试，如结果嘈杂或更差就回滚。

在计划或复盘中，有一个问题能保持文化健康：“我们测了什么，它改变了什么？”