同一张页面，用命令行敲一条请求，看到 TTFB 只有 180 毫秒；换个浏览器审计面板跑一遍，性能分 92；可客服那边还在源源不断收到"打开很慢"的反馈——这种三方打架的场面，做过前端性能优化的同学大概都遇到过。问题其实不在工具本身，而在于我们手里这批网站访问速度测试工具，测的压根不是同一件事：有的在机房网络里发一次冷请求，有的在真实用户的手机上记录每一次卡顿，还有的把两类数据塞进同一张报表里让人对比。把 TTFB 这种单次请求的服务端响应时间，和 RUM 这种真实用户监测数据混为一谈，是性能排查里最容易走偏的起点。

这篇内容想做的事很具体：把常见的 13 个网站访问速度测试工具按"能回答什么问题"重新排一次队，讲清楚每个工具的适用边界和坑在哪；然后用一个首屏 4.8 秒的模拟案例，把从 TTFB 到 LCP 的链路切段定位走一遍；最后给出一套自建 RUM 的最小可行方案和三种团队规模的选型矩阵。不管你是刚接手一个老站点的前端，还是要把性能指标纳入日常巡检的运维，或者是被"页面慢"这三个字反复折磨的产品负责人，都能从里面直接抄到能用的东西。

1. 同一个站点测出三种分数：先把度量视角掰开

性能优化做到一定程度，你会发现真正难的不是"怎么优化"，而是"到底该信哪个数字"。同一张页面，在不同工具里呈现出的速度差异可能高达数倍，这不是工具在骗人，而是它们站在不同的观测点上。在挑工具之前，先把观测点分清楚，后面的选型会顺很多。

1.1 合成监测与真实用户监测，测的根本不是同一件事

合成监测（Synthetic Monitoring）是在受控环境里，用固定的设备、固定的网络条件、固定的地理位置，对页面发起一次或多次访问，记录下整个过程的时间数据。它的核心价值是可复现——今天测和下周测，条件一致，数据可对比，适合做回归验证和竞品对标。缺点是它只代表"某一个理想化用户"的体验，和真实用户的分布可能差很远。

真实用户监测（RUM，Real User Monitoring）则是在页面里埋一段脚本，把每个真实访客的加载数据采集回来。它反映的是分布——一线城市光纤用户和三四线城市中端安卓机用户，数据混在一起，你要看的是分位数而不是平均值。RUM 不可复现，今天采集到的样本和明天的不一样，但它才是用户真正感知到的东西。

我一般这么理解：合成监测像体检，固定项目、固定仪器、结果可比；RUM 像可穿戴设备，全天候记录，数据杂乱但真实。两者不是替代关系，缺一个都会瞎。

1.2 TTFB、FCP、LCP 这些指标各自卡在链路的哪一段

不把指标和链路阶段对应起来，讨论"慢"就是空谈。我习惯把一次页面访问拆成下面这几段，每个指标都对应其中某一段或某几段：

• DNS 解析：域名换成 IP。首次访问、DNS 缓存未命中时这一段能吃掉几十到几百毫秒。
• TCP 连接 + TLS 握手：建立连接，HTTPS 还要多一两个往返。移动网络下这段波动极大。
• TTFB（Time To First Byte）：从请求发出到收到第一个字节。它包含前面所有阶段，再加上服务端处理时间和网络回程。TTFB 高，八成是服务端或回源的问题；TTFB 低但页面还是慢，问题一定在后面的资源加载和渲染。
• FCP（First Contentful Paint）：首次有内容绘制出来，用户开始"看到东西"。
• LCP（Largest Contentful Paint）：最大内容元素绘制完成，通常对应首屏主体（大图、标题块）出现。
• INP（Interaction to Next Paint）：交互响应延迟，卡不卡手看它。
• CLS（Cumulative Layout Shift）：布局偏移，字体加载、图片没写尺寸都会踩。

一个很实用的判断口诀：TTFB 看后端，FCP 看关键渲染路径，LCP 看首屏资源优先级，INP 看主线程，CLS 看资源占位。拿着这条线索去对照工具输出，能省掉一大半无效排查。

1.3 "审计面板满分但用户喊慢"的三种典型成因

这个场景我见过太多次，背后通常是三类原因：

第一类，测试环境与用户环境错位。本地跑审计时用的是开发机的千兆网络和 M 系列芯片，用户用的是三年前的中端安卓机加地铁里的弱网。CPU 降速四倍、网络限速到"慢速 4G"，分数往往直接从 95 掉到 60 出头。做审计时不开节流，等于在温室里测抗寒能力。

第二类，只测了首屏冷启动，没测二次访问和交互。有些站点首屏做得极快，但路由切换后组件懒加载没做好，点一个菜单转三秒。合成监测只跑首屏，自然发现不了。这类问题必须靠 RUM 里的交互指标来暴露。

第三类，样本偏差。审计工具默认从某几个节点发起请求，如果你的用户主要集中在某个区域，而那个区域的线路质量恰好很差，工具是看不见的。这种情况要么加多地拨测，要么直接看 RUM 的分地区数据。

提示：判断"分数和体感不一致"时，先问三个问题——开节流了吗？测的是首屏还是全流程？样本覆盖了真实用户的地区和机型分布吗？三个问题过一遍，基本能定位到偏差来源。

2. 13个工具的定位拆解：按"能回答什么问题"排队

工具列表本身没意义，有意义的是"我现在要回答什么问题，该拿哪个工具"。下面按四个层次展开，从最小的单次验证，到最重的真实用户数据体系。

2.1 单次请求的最小验证：curl 与浏览器开发者工具

工具 1：curl 计时。这是最轻量也最容易被低估的一个。一条命令就能把 DNS、连接、TLS、TTFB、总耗时全部打出来：

curl -o /dev/null -s \ -w "dns:%{time_namelookup} connect:%{time_connect} ssl:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" \ https://example.com/

它的价值在于排除浏览器干扰。当怀疑"到底是网络慢还是页面慢"时，先跑一条 curl。如果 TTFB 就已经 1.2 秒，那后面所有前端优化都是白费力气，得先去查服务端和回源链路。注意 curl 默认不执行 JS、不加载子资源，它只测文档本身——这是优点也是局限，别拿它当页面速度结论。

工具 2：浏览器开发者工具的 Network 面板。它是排查现场最有用的工具，没有之一。关键在于会用Timing标签页里的分解：Queued/Stalled、DNS Lookup、Initial Connection、SSL、Request Sent、Waiting(TTFB)、Content Download。这七段基本把一次请求的完整生命周期摊开了。瀑布图里如果看到大量请求是"排队"状态，那就是并发连接数被占满，通常和域名分片、HTTP/2 配置或者前置的大资源阻塞有关。

我常用的一个技巧：把 Network 面板的列自定义成TTFB、Content Download、Priority三列并排看。优先级低但体积大的资源排在关键请求前面，是首屏慢的高频原因。

2.2 实验室综合评估：四个"打分型"工具的差异

这一层工具会跑完整页面、执行 JS、给出综合评分，适合做上线前把关和版本对比。

工具 3：Lighthouse。浏览器内置，也可以命令行或 CI 里跑。它最大的优势是可编程——能写进流水线做性能预算卡点。核心用法是固定参数跑，别每次换配置：

lighthouse https://example.com/ \ --only-categories=performance \ --preset=desktop \ --throttling-method=simulate \ --output=json --output-path=./lh-report.json

要注意它的评分是加权计算出来的，单项指标改善不一定带来分数提升；而且不同大版本之间算法会调整，跨版本比分数没意义，比具体指标值才有意义。

工具 4：在线评分页（PageSpeed Insights 类）。它的独特价值是同时给出实验室数据和真实用户数据（来自公开的用户体验数据集），能直接看到"实验室 90 分、真实用户 LCP 4.2 秒"这种落差。做初次诊断时我一般先看它，因为它免费且能一次性暴露两个视角的矛盾。

工具 5：WebPageTest。这是实验室工具里功能最深的一个。多地点、多浏览器、多设备、连接方式可自定义，还能出视频胶片图和请求瀑布图。首屏视觉变化的时间点，靠胶片图一眼就能看出来。我一般在两个场景用它：一是需要复现特定地区、特定网络的问题；二是要给非技术同事解释"用户到底看到了什么"，胶片图比任何数字都直观。

工具 6：GTmetrix。定位和 WebPageTest 接近，界面更友好，历史趋势图做得不错，适合做版本迭代的横向对比。它的短板是免费额度有限，深度分析要靠付费档位。个人站点用免费额度做月度体检够用，团队高频使用就得算成本。

这四个工具的关系不是替代，而是颗粒度递进：在线评分页做初筛，Lighthouse 做工程卡点，WebPageTest 做深度复现，GTmetrix 做趋势跟踪。

2.3 持续合成监测与多地拨测：从"测一次"到"一直测"

工具 7：Pingdom 类合成监测平台。核心能力是定时定点：每隔几分钟从若干节点发起请求，记录可用性和响应时间，异常时告警。它解决的问题是"我不知道它什么时候开始慢的"。性能问题往往有明确的时间点（某次发布、某个配置变更、某个第三方服务抖动），没有持续监测就只能靠用户投诉来发现。

工具 8：云厂商的多地拨测服务。国内做业务基本绕不开这一层，因为节点分布直接决定你看到的数据是否有代表性。选这类服务时重点看三件事：节点覆盖的城市和运营商是否匹配你的用户分布、是否支持自定义请求头和鉴权、是否能把结果推回你自己的监控系统。我踩过的坑是只看"节点数量"不看"节点质量"，某些节点长期网络抖动，天天误告警，最后只能全部屏蔽，等于白买。

工具 9：自建 headless 巡检。用无头浏览器加定时任务，把 Lighthouse 或自定义脚本跑在自家机器上，结果落到自己的时序库里。成本低、完全可控、能内网访问，缺点是节点覆盖有限、维护要人力。适合有明确内网或预发环境验证需求的团队，我一般用它来做发布后的自动回归：每次上线后自动跑三个核心页，LCP 超过基线的 15% 就报警。

2.4 真实用户侧：四种采集路径的取舍

工具 10：Navigation Timing / Resource Timing API 手工采集。浏览器原生 API，不依赖任何第三方库，几行代码就能拿到完整的分段耗时：

const nav = performance.getEntriesByType('navigation')[0]; const metrics = { dns: nav.domainLookupEnd - nav.domainLookupStart, tcp: nav.connectEnd - nav.connectStart, ttfb: nav.responseStart - nav.requestStart, domReady: nav.domContentLoadedEventEnd - nav.startTime, load: nav.loadEventEnd - nav.startTime, };

适合需要精细控制、或者只关心少数几个自定义节点的场景。缺点是它只覆盖文档本身，核心指标的标准化要靠自己维护，各浏览器行为差异需要额外处理。

工具 11：web-vitals 库 + 自建上报。目前主流做法，体积小、指标标准统一、能拿到 LCP、INP、CLS、TTFB、FCP。后面第 4 节会详细展开怎么落地。

工具 12：前端 APM 平台里的 RUM 模块。商业或开源的监控平台通常自带 RUM 能力，优势是开箱即用——错误监控、接口追踪、性能指标在一个界面里关联。适合不想自己维护上报链路的团队。代价是数据存在别人那里，自定义分析受限，成本随流量线性上升。

工具 13：公开的真实用户体验数据集。浏览器厂商会定期发布聚合后的真实用户指标（按域名、按地区、按设备类型），免费可查。它的价值是做行业对标：你的 LCP 2.8 秒到底是好是坏，要看同类站点在相同地区的分布才知道。局限也很明显——数据是聚合的，粒度粗，只能看月级别的趋势，不能用于日常排障。

注意：这 13 个工具没有一个是"必须全部用上"的。工具越多，口径越难统一。我见过团队同时用四套工具，四份报表三个结论，最后没人信数据。选型的核心是保证同一问题只用一套口径来回答。

3. TTFB 到 LCP 的分段定位：一个首屏 4.8 秒的站点怎么查

理论讲完，走一个完整的排查过程。这是一个模拟项目，某内容型站点，首屏 LCP 在部分用户群里达到 4.8 秒，其余用户正常。这种"一部分人慢"的问题最有代表性，因为它同时考验工具的覆盖能力和数据的切分能力。

3.1 先固定变量，做出可复现的基线

排查性能问题的第一原则是不要在不稳定的条件下比较数据。我做的第一件事是把所有测试条件固化下来：固定节点（选用户投诉最集中的地区）、固定设备档位（中端安卓机档）、固定网络（限速到下行 4Mbps、延迟 150ms）、固定页面和登录态。

然后用 WebPageTest 跑三次，取中位数作为基线。同时用 curl 打三次文档请求，记录 TTFB 的波动范围。这一步的产出是一张基线表：

TTFB 接近 1 秒，这在内容型站点里已经偏高了。但先别急着下结论，因为 TTFB 高有两种可能：服务端处理慢，或者网络回程慢。需要切开来看。

3.2 从瀑布图切段：DNS、连接、TTFB、内容下载、资源与渲染

打开瀑布图逐段核对，很快就看清了结构：

第一段，TTFB 的构成。在服务端的访问日志里对照同一时刻的请求，服务端实际处理时间是 120ms。也就是说 980ms 里有 860ms 花在了网络回程和排队上。这个结论很关键——它把优化方向从"改代码"直接转向了"改链路"。进一步查发现，这个地区的用户在高峰期会被调度到较远的节点，回源路径长，这是 TTFB 高的主因。

第二段，内容下载。文档本身只有 38KB，下载耗时 90ms，正常。问题不在这里。

第三段，关键资源。瀑布图显示，首屏主图（LCP 元素）的请求是在 CSS 和两个字体文件之后才发出的。这就是典型的资源优先级问题：主图被排在后面，LCP 自然被推后。检查 HTML 发现主图既没写fetchpriority="high"，也没有 preload，浏览器按默认顺序发现它。

第四段，渲染阻塞。有两个同步脚本在 head 里，加起来阻塞了约 400ms 的解析。其中一个还是第三方统计脚本。

第五段，第三方资源的隐形开销。31 个第三方请求里，有一个广告位的脚本连续发起了 9 个串行请求，链式依赖。这段在瀑布图里表现为一条长长的瀑布，把主线程占住了近 600ms。

把这些切段数据整理成表，问题就一目了然：

针对性处理：调整该地区的节点调度策略、给首屏主图加fetchpriority="high"和 preload、把同步脚本改成 defer、把第三方广告位改成异步加载并加超时兜底。改完之后同一条件复测，LCP 从 4.8 秒降到 2.6 秒，TTFB 从 980ms 降到 410ms。

3.3 三个高频误判：缓存命中、CDN 就近、第三方的"隐形账单"

这个案例里有几个细节值得单独拎出来说，因为它们太容易造成误判。

误判一：拿缓存命中后的数据当基线。第一次跑测试 DNS 是 42ms，第二次再跑变成 3ms，因为本地缓存了。如果不注意，很容易得出"DNS 没问题"的结论。做基线测试时要么清缓存，要么明确记录是冷启动还是热启动，两者混着比毫无意义。

误判二：以为"用了 CDN 就等于就近"。实际调度受节点负载、运营商线路、调度策略多重影响，高峰期完全可能调度到远端节点。验证方法很简单：在不同地区分别跑 TTFB，看数值是否随距离单调变化。如果某个地区明显偏离趋势，就是调度问题。这类问题只能靠多地拨测发现，单点测试永远看不出来。

误判三：低估第三方脚本的连锁成本。第三方脚本的问题不只是体积，更在于它自己会再发请求。一个统计脚本拉进来，它可能再串行加载配置、上报、实验分流三个资源，全在主线程上。我在做第三方治理时用的办法是给每个第三方设一个"预算"：脚本体积上限、最长执行时间、请求数上限，超了就找业务方重新评估。这个预算机制比单纯"减少第三方数量"更好落地，因为业务方听得懂。

提示：排查分段问题时，一定要把"服务端耗时"和"网络耗时"分开看。同一时刻对照服务端访问日志和客户端 Timing 数据，是区分这两者最快的方法。

4. 自建 RUM 的最小可行方案：埋点、上报、口径对齐

合成监测能告诉你"某个条件下慢"，但回答不了"到底多少用户受影响"。这就要靠 RUM。很多团队一听 RUM 就想到买商业平台，其实最小可行方案用几百行代码就能跑起来，而且数据完全在自己手里。

4.1 用 web-vitals 采集，用一个接口上报

核心原则是尽量少影响业务。采集脚本要做三件事：不在关键路径上执行、失败静默、不阻塞页面卸载。

import { onLCP, onINP, onCLS, onTTFB, onFCP } from 'web-vitals'; const queue = []; let sent = false; function collect(metric) { queue.push({ name: metric.name, value: Math.round(metric.value), rating: metric.rating, id: metric.id, page: location.pathname, }); if (queue.length >= 5) flush(); } function flush() { if (!queue.length || sent) return; const payload = JSON.stringify({ ts: Date.now(), metrics: queue.splice(0) }); // 优先用 sendBeacon，页面卸载也能发出去 if (!navigator.sendBeacon('/api/perf', payload)) { fetch('/api/perf', { method: 'POST', body: payload, keepalive: true }).catch(() => {}); } } onLCP(collect); onINP(collect); onCLS(collect); onTTFB(collect); onFCP(collect); // 页面隐藏时兜底上报 document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') flush(); });

几个容易忽略的点：sendBeacon的 payload 有大小限制（一般 64KB），别塞太多；keepalive的 fetch 同样有总量限制；上报接口一定要做成幂等且轻量，几毫秒返回，别在里面做重查询。我见过上报接口自己慢到 800ms，反过来拖慢页面，非常讽刺。

4.2 上报字段设计与分位数统计

RUM 数据最容易犯的错是算平均值。性能数据的分布是长尾的，少数极慢的样本会把平均值拉得很难看，而且平均值掩盖了"到底多少人慢"。正确做法是看分位数：P50 看典型体验，P75 是行业通用的"良好"判定线，P95 用来看长尾。

建表时我建议至少包含这些字段：

分位数统计在多数时序数据库里都有现成函数。用 SQL 表达大概是这个样子：

SELECT page_path, metric_name, percentile_cont(0.50) WITHIN GROUP (ORDER BY metric_value) AS p50, percentile_cont(0.75) WITHIN GROUP (ORDER BY metric_value) AS p75, percentile_cont(0.95) WITHIN GROUP (ORDER BY metric_value) AS p95, count(*) AS samples FROM perf_metrics WHERE ts > now() - interval '1 day' GROUP BY page_path, metric_name ORDER BY p75 DESC;

release字段一定要加。没有版本维度，你就永远在回答"现在多慢"，而回答不了"这次发布让它慢了多少"。这个字段加不加，决定了 RUM 数据是报表还是诊断工具。

4.3 采样率、离线补报与数据噪声处理

三个实操层面的坑，每个都踩过。

采样率。全量上报在小流量站点没问题，日活上到一定量级后，上报请求本身会成为成本。我的经验是按 10%～20% 采样，同时对慢样本加权保留——超过阈值的样本全部上报，正常样本采样。这样既控制了总量，又不会丢掉长尾信息。采样率必须随数据一起上报，否则统计时无法还原真实量级。

离线补报。移动端网络不稳定，用户在地铁里打开页面，上报请求失败很正常。可以用 localStorage 暂存最近 N 条，下次访问时补发。但要注意加时间戳和会话标识，避免重复计算。补报数据的时间窗口我一般限制在 24 小时内，太旧的数据对排障没价值，反而污染趋势。

噪声清洗。原始 RUM 数据里一定混着奇怪的东西：机器人爬虫、预渲染、后台标签页、开发者自己的调试访问。CLS 尤其容易被异常值污染，一个离谱的布局偏移能把 P95 拉到几十。常见处理方式是按 UA 和指标值做上下限裁剪，同时把visibilityState不是 visible 期间的样本单独标记。这一步不做，你的报表永远在报警。

注意：RUM 的建设顺序建议是"先有 TTFB 和 LCP 两个指标 + 页面和版本两个维度"，跑通了再逐步加指标和维度。一上来就上十几个字段，最后大概率是字段填不满、报表没人看。

5. 选型矩阵：三种团队规模的工具组合与落地节奏

工具讲完了，案例走完了，最后落到"你该用哪几个"。我给三套组合，都是实际用过、能跑起来的配置。

5.1 个人站与小团队：零成本四件套

预算为零的情况下，下面四个够用：

• 开发者工具 Network 面板：日常排查的主力，几乎零学习成本。
• curl 计时脚本：写成一个 shell 脚本，每次改完服务端配置跑一遍，作为快速验证。
• Lighthouse（本地或 CI）：上线前跑一次，设一个分数下限做卡点。
• 在线评分页：每月一次，看真实用户数据和实验室数据的差距，做趋势记录。

这套组合的核心是"一次人工验证 + 一次自动卡点"。个人站点的流量特征简单，不需要复杂的 RUM 体系，但一定要养成记录的习惯——把每次的指标值存进一个表格，时间长了就能看出规律。我自己维护的几个小站，就是用一张表格记了两年，某次发现 LCP 缓慢爬升，回头看正好对应某次依赖升级，十分钟就定位了。

5.2 中型业务：合成监测 + 自建 RUM 的双轨

有稳定用户量之后，必须补两块能力：持续合成监测（知道什么时候出问题）和自建 RUM（知道影响了多少人）。

具体配置我建议这样：

关键在于把合成数据和 RUM 数据放在同一个看板上对照。合成监测报警而 RUM 平稳，说明是小范围网络问题；RUM 恶化而合成监测正常，说明问题只在特定用户群，需要按设备、地区、版本做切分。这两种情况的处理路径完全不同，分开看就很容易误判。

落地节奏上，我的建议是分三步：第一步只上拨测和版本对比，把"知道出问题"这件事解决；第二步上 RUM，先只采 LCP 和 TTFB，跑一个月看数据质量；第三步再补交互指标和分地区分析。急着一步到位，往往卡在数据口径对不齐上，最后工具成了摆设。

5.3 大型业务：口径治理比工具选型更重要

规模上去以后，真正的难题不再是"用哪个工具"，而是"十几个团队各用各的工具，报表对不上"。我经历过一次跨团队的性能评审，前端团队报 LCP 2.1 秒，运维团队报 3.4 秒，业务方拿着第三方平台的 4.1 秒来质问，会议开了两小时才搞清楚：一个是 P50、一个是 P75、一个是把预渲染样本也算进去了。

治理的做法是定一份指标口径规范，写清楚这几件事：

• 每个指标采集的是哪个阶段，用什么库、什么版本
• 统计用什么分位数，样本范围怎么界定（哪些页面、哪些用户、是否含预渲染）
• 采样策略和权重规则，怎么还原量级
• 数据保留周期，历史数据怎么对齐（库版本升级后老数据怎么处理）
• 谁负责维护、变更怎么评审

这份规范听起来很虚，但它是唯一能让十几个团队看同一张报表的办法。有了它，工具选型反而变成次要问题——因为无论用哪套工具，出来的数字含义是一致的。

还有一个实操建议：把性能指标和发布流程绑定。光有看板没人看，就设性能预算——LCP 的 P75 超过阈值时，发布流水线给出警告或阻断。这个机制真正起作用，是在它变成流程的一部分之后，而不是在它被写进文档之后。

提示：跨团队口径对齐时，最有效的做法不是开会讨论，而是让所有人用同一条测试命令、同一个测试页面、同一个时间窗口各跑一遍，把结果贴在一起看差异。差异本身就是最好的沟通材料。

6. 几个反复踩到的细节

最后补几个具体到操作层面的经验，都是文档里不会写、但实际做的时候会卡住的地方。

测试时间窗口的选择。性能数据有明显的时间特征，业务高峰期和非高峰期能差出 40%。做版本对比时，一定要选同一时段。我习惯固定在业务低峰期做基准测试，因为那时候变量最少；而分析真实用户体验时，必须看高峰期的数据，因为那才是用户真正难受的时候。这两类测试的目的不同，别混用。

节流配置要写进文档。Lighthouse 的simulate和devtools两种节流方式结果差异不小，devtools更接近真实但波动大，simulate稳定但偏理想化。团队里必须统一用一种，并写进测试文档。我见过同一个项目两拨人用不同节流方式测出 78 分和 91 分，争论了半天才发现配置不同。

首屏定义要和产品对齐。LCP 元素在不同页面可能完全不同，有的页面是主图，有的是标题，有的是一个大轮播。轮播图尤其麻烦，第一张图渲染完就算 LCP，但后面的图还在加载。这种情况要和产品确认"用户认为的首屏是什么"，再决定是否把轮播改成静态首图。技术指标和产品感知不一致时，永远优先看产品感知。

第三方脚本要建台账。每个第三方脚本记录：引入目的、负责方、体积、请求数、执行时长、可否异步、超时兜底策略。这份台账在排查"突然变慢"时价值极高，因为大部分突发性能问题都来自第三方变更。台账维护成本不高，但需要有人定期清理，否则半年后就没人认领了。

别忽略 TTFB 的"第二段"。很多人只看文档的 TTFB，但接口请求的 TTFB 同样重要。一个首屏渲染很快、但首屏数据接口要 1.5 秒才返回的页面，用户看到的依然是空白。排查时要把文档请求和关键接口请求分开看，接口慢就去查数据库和缓存，别在前端瞎折腾。

我个人在实际操作中的体会是，工具的数量和排查效率基本不成正比。真正决定排查速度的，是你对"这条链路上每一段大概该是多少毫秒"有没有一个基准印象。有了这个印象，任何一个工具给出的数字，你一眼就能看出哪里不对。基准印象怎么来？把一个典型页面从头到尾用 curl、开发者工具、瀑布图完整拆过三遍，心里就有数了。这件事没有任何工具能代劳，但做完之后，那 13 个工具才真正开始为你所用。