2025年7月14日·1 分钟
先测量再优化：Paul Irish 的提速工作流程
把“先测量再优化”当成一个简单循环：建立基线、剖析、只改一件事、验证影响，从而养成更冷静的性能优化习惯。
把“先测量再优化”当成一个简单循环：建立基线、剖析、只改一件事、验证影响，从而养成更冷静的性能优化习惯。
当你从修复入手时，性能工作会感觉很随机。今天你压缩文件，明天你调整缓存，然后又移除一个库。有时候有用，有时候完全没变化，而你无从得知原因。
最大的风险是优化了错误的方向。如果页面慢是因为主线程被 JavaScript 阻塞，那么花数小时压缩图片几乎不会有什么效果。或者你加速了用户并不在意的部分，而真正的延迟来自长时间的 API 调用、不断回流的布局，或一个阻塞线程的脚本。
按感觉判断也有陷阱。“感觉更快”可能是安慰剂（比如加了一个 spinner），或者因为在不同的网络、设备或时间测试得到的假象。“是真的更快”意味着在相同条件下做相同行为，得到更好的指标。
一个简单的承诺能修正大部分问题：在优化前先测量，然后再决定。当你把性能当作一个测量问题来看，就不再猜测，而是真正开始学习。
一个实用的循环看起来像这样：选一个需要改进的用户动作，在可重复的条件下记录基线，做一处可解释的改动，然后重新测量，只有当数字变好时才保留改动。
Paul Irish 是网页性能领域最知名的声音之一。他通过对浏览器工具和性能指导的工作，推广了一个直接的想法：你的第一件事不是猜哪儿慢，而是证明它。
这种心态会改变团队动态。与其基于“图片总是问题”或“肯定是框架”这样的习惯争论，你更从证据出发。当你能指向时间线、慢查询或长任务时，讨论就从相互指责转为解决方案。
“先测量再优化”还能冷却性能争论，因为它建立了共同规则：就要测什么达成一致、就什么叫“更好”达成一致，只有数字有变化才庆祝。
这在小站点和大型应用上都适用。一个单一基线能阻止市场页上随机的微优化；在大型产品上，一致的测量避免性能变成永无止境的待办事项。
把它具体化的一个简单办法是把性能当成 bug 报告：清晰的复现步骤、你看到的指标，以及一处改动绑定一处结果。如果两个人意见不合，就重新跑测量，让数据来决定。
首先把性能当作一个可观测的问题：增加观测手段来看到用户真实的体验。如果看不到，你就只能争论意见，而不是基于证据行动。这正是先测量的真正含义。
可观测不必很花哨。它是持续在固定地方收集少量信号，这样你能回答几个基本问题：
通常你需要两类数据。
实验室数据是在受控设置中捕获：特定笔记本或测试设备、稳定的网络配置、每次相同步骤。它很适合调试，因为你可以按需复现慢点。
真实用户数据是用户在真实环境中体验到的：不同设备、地点和网络质量。它很适合优先级判断，因为它显示的是伤害真实用户的部分，而不是一次测试结果。
即便不是专家，你也能测量页面加载里程碑（比如首屏内容出现）、长任务与主线程阻塞、慢网络请求、昂贵的渲染工作（布局、样式、绘制）和服务器响应时间。
这些信号通常存在几个地方：浏览器开发者工具用于实验室剖析，服务器日志与追踪用于后端计时，分析或 RUM 仪表盘用于真实用户数据。例如，如果结账感觉慢，DevTools 可能显示浏览器在渲染一个庞大的购物车 UI 时很忙，而服务器日志显示 API 很快。没有可观测手段，你可能会去优化后端却始终解决不了真正问题。
要在优化前测量，你需要一个可信的起点。基线是相同动作、以相同方式和在相同条件下测量的结果。
从一个真实的用户旅程开始，而不是“整个网站”。选一句能描述清楚的动作，例如“打开首页并滚动到第一个商品网格”或“登录并到达仪表盘”。把范围定窄能让数字更稳定，让接下来的步骤更清晰。
接着选 1 到 3 个匹配该旅程的指标。对于页面视图，一对常用指标是 LCP（主要内容出现速度）和 TTFB（服务器响应速度）。对于像结账这样的流程，你可能跟踪完成第一步的时间加上支付调用的 API 响应时间。太多指标会让人容易挑选有利数据。
把测试设置写下来，这样别人以后能复现。小的差别会影响结果：
最后，为你的受众定义“足够好”的标准。例如：“在中档手机、4G 下 LCP 小于 2.5 秒”。如果你使用 Koder.ai，在测试前拍个快照能把基线锁定到一个已知版本上。
在剖析之前，先让问题可按需重现。如果你不能重复它，就不能信任结果。
从用户感受出发，而不是假设。是首屏渲染慢？某次点击卡住没有响应？提交表单后长时间等待？挑出用户抱怨的具体时刻并集中在那儿。
做一次快速运行确认慢点是真实且可重复的。尽量保持其他条件不变：相同页面、相同设备、相同网络（如果可能）。然后写下触发动作和确切感觉慢的时刻，例如“点击支付后按钮冻结一秒”或“产品列表出现时滚动卡顿”。
保持可重复的一个简单办法是写一个小脚本：从新标签页打开页面，执行导致卡顿的动作，记下准确的慢点，然后再重复一次确认。
只捕获一到两次基线录制，不需要几十次。你只需要足够的证据来判断“是的，慢点确实存在，且就发生在这里”。
一旦你能复现慢点，就别猜了。打开剖析器（大多数人用浏览器的 Performance 面板），录制一次慢交互。目标不是找出所有问题，而是弄清时间都花在哪儿。
从最大的时间块开始。微小的尖峰可能是真实存在的，但它们很少单独解释显著的延迟。
阅读录制的一种有用方式是把时间分到几个桶里：网络与加载（等待请求）、主线程脚本（长任务）、渲染与绘制（布局、样式、绘制）、空闲间隙（等待其他事情）、以及重复工作（同一昂贵步骤被反复执行）。
常见的错误是把慢服务器响应和慢客户端工作混淆。如果时间线上显示在请求进行中有长间隙，瓶颈可能是网络或后端。如果显示主线程长任务，那就是前端问题，即便网络很快。
在改动前，根据观察写一句简短、可测试的假设。例如：“页面慢是因为 API 返回后紧接着主线程被 JSON 解析阻塞。”这句话为下一步定下方向。
确定了可能瓶颈后，抵抗“把所有东西都修好”的冲动。改变一个变量，这样你能把因果联系起来。
保持改动小且易撤销。大规模重写会模糊结果：如果性能提升了，你不知道是为什么。如果更差，回滚就危险。
好的“一件事”改动是具体且可测试的。例子包括：延迟或移除一个阻塞渲染的第三方脚本、压缩慢页上的一张超大图片、为一个昂贵的数据库查询添加缓存、把一个沉重的 UI 组件拆分以减少首屏渲染工作，或减少剖析器中看到的一个热点循环的工作量。
在动手前写下你改了什么、为什么选它，以及你期望改善什么（比如“减少主线程时间”或“把 DB 时间减半”）。
如果团队使用支持快照和回滚的平台（比如 Koder.ai），在改动前拍快照能让“小且可撤销”不是空话。
你改了一件事。现在证明它有用。
重新运行与基线相同的测试设置：相同设备、相同浏览器版本、相同路径和相同的运行次数。用相同的指标比较前后结果。不要在中途加入新的指标以迎合看起来更好的结果。
噪声是团队争论性能的常见原因。注意冷/热缓存、扩展或后台进程、不同网络条件或 VPN、服务器波动（安静时段 vs 忙时段），以及“刚发布后”和稳定状态的差异。
如果中位数改善但最差情况变差，那是个真实的权衡。决定对用户来说什么更重要，然后把决定记录下来：保留改动、回滚，或写一个新假设再测。
当你测错对象或一次改动太多，性能工作就会变得混乱。即便应用在改进，你也可能浪费大量精力而看不到明确成效。
一个常见错误是把一个分数当成目标。分数有用，但用户感受到的不是“92 分”，而是“页面两秒就展示内容”或“点购买立刻有反应”。选择一个用户可见的结果并持续测量它。
另一个陷阱是只在高性能笔记本上测试。许多慢点只会在中档手机、差的网络或 CPU 忙时显现。只在最好设备上剖析，你会漏掉真正的瓶颈。
混乱通常来自这样的模式：优先改善最容易的事而非耗时最多的事、把多个改动合并成一次、每次换测试路径、因为“感觉更快”就跳过复测、或没有用相同基线重复验证就宣布胜利。
如果你用像 Koder.ai 这样的聊天驱动平台构建应用，同样的纪律依然适用：一次改动，然后在完全相同的流程上验证，这样你才能信任结果。
如果只养成一个习惯，就养这个：先测量再优化。目标不是无限制地收集数据，而是形成一个你能信任的可重复循环。
把确切的用户旅程命名清楚。“首页慢”太模糊。“从商品页点购买到看到确认页”给你一个可重复的点击路径。
使用这个清单：
冷静的性能工作很简单：一条路径、一套设置、一处改动、一个经验证的结果。
常见抱怨：用户点“Pay”后结账很慢。大家开始猜原因（图片、字体、按钮）。相反，把它当成一个可重复的测试。
建立可复测的基线。选一台设备和一条路径（cart -> checkout -> Pay -> confirmation）。开启网络节流（例如 Fast 3G），每次保持相同。测量一个简单的数值：从点击“Pay”到看到确认页的时间。
然后在同一时刻剖析，看看时间都花在哪儿。通常你在网络（长请求或过多请求）、服务器（支付调用慢，即使浏览器空闲）或主线程（浏览器忙于运行 JS 无法更新 UI）三类之间做判断。
想象剖析显示：点击“Pay”后浏览器先发了一个分析请求和一个反欺诈脚本调用，而支付请求被排在后面等待。这不是“把所有东西都加速”的问题，而是一个阻塞步骤。
有目的地改一件事。例如，让支付请求立即发出，把分析请求放到确认页展示后再发送。
用相同设置验证：相同节流、相同步骤、多次运行。如果确认时间下降且错误率没有上升，你就赢了。另外抽查一下没有破坏退款、重试或防止重复提交的机制。
当测量成为常态而不是救火行动时，性能才不会失控。把测量设为默认动作，即便一切看起来正常也要这样做。
挑一小组固定的指标供团队始终跟踪，保持一致性以便观察趋势：
围绕这些指标构建一个循环。每周一次基线检查通常足够。当某个指标漂移时，那就是触发器：去复现慢点、剖析、改一件事并验证影响。
在团队实际使用的任何格式里保留一个简单的性能日志。记录你测了什么（包括设备、网络和构建）、你改了什么，以及改动后数字的变化。
如果你用 Koder.ai 构建，Planning Mode 可以帮你在更改前写下用户旅程和关心的指标。然后用快照与回滚让实验更安全：拍快照、应用一处改动、重新测试，如结果嘈杂或更差就回滚。
在计划或复盘中，有一个问题能保持文化健康：“我们测了什么，它改变了什么？”
因为你很容易花数小时去优化并不是造成延迟的东西。先证明时间都花在哪儿（网络、服务器、主线程、渲染），再去针对最大的瓶颈处理。
把一个具体动作和精确条件写下来，然后重复执行：
如果不能复现，就不能信任结果。
为单一路径选 1–3 个与用户感受匹配的指标：
不要一次追踪太多指标，否则容易挑数据来证明先入为主的结论。
实验室数据在受控环境中采集（适合调试并能重复）。真实用户数据反映真实设备和网络情况（适合优先级判断）。
一个好策略是：用真实用户数据发现最糟糕的旅程，然后用实验室剖析原因并安全地测试修复。
把问题当成一个 bug 报告：
这会把讨论从“我觉得是图片”变成有证据的行动方案。
在剖析器中录制慢的交互，找最大的时间块：
然后写一句可测试的假设作为下一步。
它能让因果关系清晰。改一堆东西你就不知道到底哪一项起作用；改多了如果变慢，回滚也麻烦。
实用规则：一次只改一件、能解释清楚、并写下你期望移动的指标，然后重新测量。
使用与基线相同的测试设置进行比较：相同设备、相同浏览器版本、相同路径和相同次数的运行。
减少噪声的做法：
只有在相同条件下数字确实改善，才保留改动。
常见陷阱：
坚持一个旅程、一个设置、一个经验证的结果。
把它们用来让实验安全且可比：
工具有帮助，但真正的收益来自可重复的循环：基线 → 剖析 → 一次改动 → 验证。