拨测显示 200 毫秒，用户说转圈五秒。两个都对，只是测的不是同一件事。

这个分歧解释了大部分「我这边很快啊」的扯皮。

拨测测到哪儿为止

拨测发一个 HTTP 请求，拿到 HTML 就结束。它不执行 JS，不加载图片、字体、样式表，也不渲染。

所以它回答的是：服务器响应快不快、线路通不通。

它不回答：用户看到第一屏要等多久。

先分锅

拨测快、用户慢，问题在前端资源和渲染。

拨测也慢，问题在网络或者服务端。

这一步分完，才好决定是找前端还是找运维。分不清就一起查，通常两边都查不明白。

前端三个大头

图片没压缩、没懒加载。 首屏一张 2MB 的图，什么优化都白搭。WebP 加尺寸适配，能省掉一大半。

同步 JS 阻塞渲染。 放在 head 里的大脚本，浏览器必须下载并执行完才继续。加 defer 或者挪到 body 末尾。

第三方脚本。 统计、客服、广告、字体，每个都几十毫秒，加起来就是一两秒。这些往往不在自己的监控里，但用户等的是总和。

怎么确认是哪一项

浏览器开发者工具的 Network 面板，按体积排序，最大的那一两个就是元凶。按时间排序，看是哪一段卡住。

Performance 面板录一次加载，能看出主线程被什么占住。这两步比看任何评分工具都直接。

一个常被忽略的点

服务端开了 gzip，但只对 HTML 开了，JS 和 CSS 没开。检查一下 Content-Encoding，很多配置只顾了主文档。

优化顺序

先解决最大的那个资源，再谈代码分割和预加载。顺序反了，做完一堆微优化，用户还是觉得慢。

判断该找谁，先用 网站测速 打一次底，确认服务端和网络没问题，再让前端接手。