网站加载速度测试：从瀑布图找出真正拖慢的请求
瀑布图里耗时最长的请求未必拖慢首屏。沿 HTML、样式、脚本和图片的发现顺序，检查关键资源的排队、下载与依赖关系。
网站加载速度测试的瀑布图里，最长的一条请求不一定是首屏瓶颈。它可能是后台统计，也可能在主要内容出现之后才开始。真正要找的是：用户等待的内容，依赖哪些尚未完成的步骤。
先在图上找到主文档与主要内容
从主文档开始，确认跳转和响应；再结合画面或 LCP 元素找到首屏关键资源。它可能是一张图片，也可能是一段等待样式和字体的文字。不要先按资源体积排序，就把最大的文件定为根因。
Chrome Network 文档说明了请求发起者、瀑布图和计时信息。发起者有助于追踪资源是由 HTML、CSS 还是脚本引入，这比只看开始时间更能说明依赖。
把一条请求拆成可解释的等待
| 看到的阶段 | 要进一步确认的内容 |
|---|---|
| 排队或停滞 | 优先级、连接条件和浏览器调度 |
| 解析与连接 | 域名、远端地址和连接是否复用 |
| 等待响应 | 网络、缓存、服务端处理与后端依赖 |
| 内容下载 | 实际传输量、压缩、带宽和路径 |
Timing 的边界由工具定义。连接复用时，某个请求没有 DNS 或建连耗时，不代表互联网不需要这些步骤；它可能使用了已建立的连接。HTTP/2、HTTP/3 等协议还会影响并发方式，不能用“每个文件都单独排队建连”解释所有页面。
识别晚发现的关键资源
假设主图必须等脚本执行、接口返回之后才插入页面，即使图片本身下载很快，显示仍可能很晚。这是依赖链问题。反过来，图片很早就被请求，却下载很久，则应检查资源体积和传输。
处理方式需要匹配证据：能在文档中合理暴露的关键资源，不必无端延后发现；确认是首屏 LCP 图片后，再评估加载策略。不要把所有图片一律预加载，也不要把首屏关键图片机械地延迟加载。LCP 与资源的关系可参考 官方指标说明。
请求结束后还有渲染工作
浏览器还需要解析、执行脚本、计算样式、布局和绘制。瀑布图显示资源已完成，却不能解释主线程为什么忙；此时需要 Performance 记录。只减少请求数量，也不一定降低脚本执行和渲染成本。
每次修复后同时检查目标请求和画面。如果文件变小但首屏时间没变，继续查看是否还有更早的等待。想把请求与视觉时间结合起来，可参考从导航到首屏的记录方式；若涉及缓存，则看CDN 命中与回源检测。