★ FEATURED ARTICLE 同一张页面用命令行敲一条请求看到 TTFB 只有 180 毫秒换个浏览器审计面板跑一遍性能分 92可客服那边还在源源不断收到打开很慢的反馈——这种三方打架的场面做过前端性能优化的同学大概都遇到过。问题其实不在工具本身而在于我们手里这批网站访问速度测试工具测的压根不是同一件事有的在机房网络里发一次冷请求有的在真实用户的手机上记录每一次卡顿还有的把两类数据塞进同一张报表里让人对比。把 TTFB 这种单次请求的服务端响应时间和 RUM 这种真实用户监测数据混为一谈是性能排查里最容易走偏的起点。这篇内容想做的事很具体把常见的 13 个网站访问速度测试工具按能回答什么问题重新排一次队讲清楚每个工具的适用边界和坑在哪然后用一个首屏 4.8 秒的模拟案例把从 TTFB 到 LCP 的链路切段定位走一遍最后给出一套自建 RUM 的最小可行方案和三种团队规模的选型矩阵。不管你是刚接手一个老站点的前端还是要把性能指标纳入日常巡检的运维或者是被页面慢这三个字反复折磨的产品负责人都能从里面直接抄到能用的东西。1. 同一个站点测出三种分数先把度量视角掰开性能优化做到一定程度你会发现真正难的不是怎么优化而是到底该信哪个数字。同一张页面在不同工具里呈现出的速度差异可能高达数倍这不是工具在骗人而是它们站在不同的观测点上。在挑工具之前先把观测点分清楚后面的选型会顺很多。1.1 合成监测与真实用户监测测的根本不是同一件事合成监测Synthetic Monitoring是在受控环境里用固定的设备、固定的网络条件、固定的地理位置对页面发起一次或多次访问记录下整个过程的时间数据。它的核心价值是可复现——今天测和下周测条件一致数据可对比适合做回归验证和竞品对标。缺点是它只代表某一个理想化用户的体验和真实用户的分布可能差很远。真实用户监测RUMReal User Monitoring则是在页面里埋一段脚本把每个真实访客的加载数据采集回来。它反映的是分布——一线城市光纤用户和三四线城市中端安卓机用户数据混在一起你要看的是分位数而不是平均值。RUM 不可复现今天采集到的样本和明天的不一样但它才是用户真正感知到的东西。我一般这么理解合成监测像体检固定项目、固定仪器、结果可比RUM 像可穿戴设备全天候记录数据杂乱但真实。两者不是替代关系缺一个都会瞎。维度合成监测真实用户监测RUM数据来源受控环境发起的模拟请求真实访客浏览器上报可复现性高条件固定低样本随机覆盖网络有限节点全部真实网络环境适合场景上线前验证、回归对比、竞品对标线上体验监控、问题归因、SLA 统计主要短板与真实体验有偏差数据噪声大、需要采样与清洗1.2 TTFB、FCP、LCP 这些指标各自卡在链路的哪一段不把指标和链路阶段对应起来讨论慢就是空谈。我习惯把一次页面访问拆成下面这几段每个指标都对应其中某一段或某几段DNS 解析域名换成 IP。首次访问、DNS 缓存未命中时这一段能吃掉几十到几百毫秒。TCP 连接 TLS 握手建立连接HTTPS 还要多一两个往返。移动网络下这段波动极大。TTFBTime To First Byte从请求发出到收到第一个字节。它包含前面所有阶段再加上服务端处理时间和网络回程。TTFB 高八成是服务端或回源的问题TTFB 低但页面还是慢问题一定在后面的资源加载和渲染。FCPFirst Contentful Paint首次有内容绘制出来用户开始看到东西。LCPLargest Contentful Paint最大内容元素绘制完成通常对应首屏主体大图、标题块出现。INPInteraction to Next Paint交互响应延迟卡不卡手看它。CLSCumulative Layout Shift布局偏移字体加载、图片没写尺寸都会踩。一个很实用的判断口诀TTFB 看后端FCP 看关键渲染路径LCP 看首屏资源优先级INP 看主线程CLS 看资源占位。拿着这条线索去对照工具输出能省掉一大半无效排查。1.3 审计面板满分但用户喊慢的三种典型成因这个场景我见过太多次背后通常是三类原因第一类测试环境与用户环境错位。本地跑审计时用的是开发机的千兆网络和 M 系列芯片用户用的是三年前的中端安卓机加地铁里的弱网。CPU 降速四倍、网络限速到慢速 4G分数往往直接从 95 掉到 60 出头。做审计时不开节流等于在温室里测抗寒能力。第二类只测了首屏冷启动没测二次访问和交互。有些站点首屏做得极快但路由切换后组件懒加载没做好点一个菜单转三秒。合成监测只跑首屏自然发现不了。这类问题必须靠 RUM 里的交互指标来暴露。第三类样本偏差。审计工具默认从某几个节点发起请求如果你的用户主要集中在某个区域而那个区域的线路质量恰好很差工具是看不见的。这种情况要么加多地拨测要么直接看 RUM 的分地区数据。提示判断分数和体感不一致时先问三个问题——开节流了吗测的是首屏还是全流程样本覆盖了真实用户的地区和机型分布吗三个问题过一遍基本能定位到偏差来源。2. 13个工具的定位拆解按能回答什么问题排队工具列表本身没意义有意义的是我现在要回答什么问题该拿哪个工具。下面按四个层次展开从最小的单次验证到最重的真实用户数据体系。2.1 单次请求的最小验证curl 与浏览器开发者工具工具 1curl 计时。这是最轻量也最容易被低估的一个。一条命令就能把 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、给出综合评分适合做上线前把关和版本对比。工具 3Lighthouse。浏览器内置也可以命令行或 CI 里跑。它最大的优势是可编程——能写进流水线做性能预算卡点。核心用法是固定参数跑别每次换配置lighthouse https://example.com/ \ --only-categoriesperformance \ --presetdesktop \ --throttling-methodsimulate \ --outputjson --output-path./lh-report.json要注意它的评分是加权计算出来的单项指标改善不一定带来分数提升而且不同大版本之间算法会调整跨版本比分数没意义比具体指标值才有意义。工具 4在线评分页PageSpeed Insights 类。它的独特价值是同时给出实验室数据和真实用户数据来自公开的用户体验数据集能直接看到实验室 90 分、真实用户 LCP 4.2 秒这种落差。做初次诊断时我一般先看它因为它免费且能一次性暴露两个视角的矛盾。工具 5WebPageTest。这是实验室工具里功能最深的一个。多地点、多浏览器、多设备、连接方式可自定义还能出视频胶片图和请求瀑布图。首屏视觉变化的时间点靠胶片图一眼就能看出来。我一般在两个场景用它一是需要复现特定地区、特定网络的问题二是要给非技术同事解释用户到底看到了什么胶片图比任何数字都直观。工具 6GTmetrix。定位和 WebPageTest 接近界面更友好历史趋势图做得不错适合做版本迭代的横向对比。它的短板是免费额度有限深度分析要靠付费档位。个人站点用免费额度做月度体检够用团队高频使用就得算成本。这四个工具的关系不是替代而是颗粒度递进在线评分页做初筛Lighthouse 做工程卡点WebPageTest 做深度复现GTmetrix 做趋势跟踪。2.3 持续合成监测与多地拨测从测一次到一直测工具 7Pingdom 类合成监测平台。核心能力是定时定点每隔几分钟从若干节点发起请求记录可用性和响应时间异常时告警。它解决的问题是我不知道它什么时候开始慢的。性能问题往往有明确的时间点某次发布、某个配置变更、某个第三方服务抖动没有持续监测就只能靠用户投诉来发现。工具 8云厂商的多地拨测服务。国内做业务基本绕不开这一层因为节点分布直接决定你看到的数据是否有代表性。选这类服务时重点看三件事节点覆盖的城市和运营商是否匹配你的用户分布、是否支持自定义请求头和鉴权、是否能把结果推回你自己的监控系统。我踩过的坑是只看节点数量不看节点质量某些节点长期网络抖动天天误告警最后只能全部屏蔽等于白买。工具 9自建 headless 巡检。用无头浏览器加定时任务把 Lighthouse 或自定义脚本跑在自家机器上结果落到自己的时序库里。成本低、完全可控、能内网访问缺点是节点覆盖有限、维护要人力。适合有明确内网或预发环境验证需求的团队我一般用它来做发布后的自动回归每次上线后自动跑三个核心页LCP 超过基线的 15% 就报警。2.4 真实用户侧四种采集路径的取舍工具 10Navigation 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, };适合需要精细控制、或者只关心少数几个自定义节点的场景。缺点是它只覆盖文档本身核心指标的标准化要靠自己维护各浏览器行为差异需要额外处理。工具 11web-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 的波动范围。这一步的产出是一张基线表指标基线值备注DNS42ms第二次访问命中缓存后降到 3msTCP TLS310ms移动网络下握手开销明显TTFB980ms波动区间 7601300msFCP2.3s首屏骨架出现LCP4.8s首屏主图渲染完成页面总请求数87其中第三方 31 个TTFB 接近 1 秒这在内容型站点里已经偏高了。但先别急着下结论因为 TTFB 高有两种可能服务端处理慢或者网络回程慢。需要切开来看。3.2 从瀑布图切段DNS、连接、TTFB、内容下载、资源与渲染打开瀑布图逐段核对很快就看清了结构第一段TTFB 的构成。在服务端的访问日志里对照同一时刻的请求服务端实际处理时间是 120ms。也就是说 980ms 里有 860ms 花在了网络回程和排队上。这个结论很关键——它把优化方向从改代码直接转向了改链路。进一步查发现这个地区的用户在高峰期会被调度到较远的节点回源路径长这是 TTFB 高的主因。第二段内容下载。文档本身只有 38KB下载耗时 90ms正常。问题不在这里。第三段关键资源。瀑布图显示首屏主图LCP 元素的请求是在 CSS 和两个字体文件之后才发出的。这就是典型的资源优先级问题主图被排在后面LCP 自然被推后。检查 HTML 发现主图既没写fetchpriorityhigh也没有 preload浏览器按默认顺序发现它。第四段渲染阻塞。有两个同步脚本在 head 里加起来阻塞了约 400ms 的解析。其中一个还是第三方统计脚本。第五段第三方资源的隐形开销。31 个第三方请求里有一个广告位的脚本连续发起了 9 个串行请求链式依赖。这段在瀑布图里表现为一条长长的瀑布把主线程占住了近 600ms。把这些切段数据整理成表问题就一目了然环节耗时判定DNS 连接 TLS352ms正常范围可优化空间小等待响应TTFB 扣除服务端860ms主要瓶颈链路调度问题文档下载90ms正常阻塞脚本400ms可消除第三方串行链600ms可优化LCP 元素延后加载约 1.1s优先级配置缺失针对性处理调整该地区的节点调度策略、给首屏主图加fetchpriorityhigh和 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 用来看长尾。建表时我建议至少包含这些字段字段类型用途metric_name字符串LCP/INP/CLS/TTFB/FCPmetric_value数值毫秒或无量纲page_path字符串按页面聚合device_type枚举桌面/移动connection枚举4g/3g/wifiregion字符串地区由服务端按 IP 粗略推断release字符串前端版本号用于对比发布前后sample_rate数值采样率用于还原真实量级分位数统计在多数时序数据库里都有现成函数。用 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知道影响了多少人。具体配置我建议这样能力工具选择频率输出可用性监控多地拨测服务1 分钟告警 可用率性能巡检自建 headless Lighthouse每次发布 每小时版本对比报表真实用户指标web-vitals 自建上报实时分页面分位数看板深度复现WebPageTest按需瀑布图 胶片图趋势对标公开用户体验数据集月度行业分位对比关键在于把合成数据和 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 个工具才真正开始为你所用。
阅读完成 · 觉得有帮助？
