页面看起来“卡住”，不一定是文件太大，也可能是某个请求迟迟没有完成，导致后续资源排队。诊断时要看请求之间的先后关系，而不是只盯着单个耗时。下面这套网站核心页面加载链路的瓶颈诊断方法，适合从一张瀑布图开始逐步缩小范围。
先准备一份可比较的瀑布图
可使用浏览器自带的开发者工具，或 WebPageTest 一类的页面测试工具查看请求时间线。开始前固定页面地址、浏览器、网络条件和缓存状态，并记录测试是否为首次访问。建议在相同条件下测几次，观察中位表现；一次加载可能受网络波动、服务器负载或缓存影响。
瀑布图每一行通常代表一个请求，横向长度表示持续时间，所在位置显示它何时开始。不同工具对阶段名称的标注略有差异，但通常能看到排队、连接、等待响应和下载等阶段。
按顺序完成五步排查
- 确认问题出现在哪种加载情形。分别测试首次访问和再次访问，并确认页面是否完整加载。若只有首次访问慢，需留意缓存未命中、字体或图片首次下载；若两种情形都慢，继续检查服务端响应和请求依赖。测试前不要一边改变网络一边比较结果。
- 找出影响首屏的关键请求。先圈出显示首屏内容必需的文档、样式、脚本、接口和图片，再看它们的开始时间与结束时间。一个请求耗时很长，不代表它一定阻塞页面；如果它不在关键内容的依赖路径上，优先级可能低于一个耗时较短但必须等待的请求。
- 区分等待时间与传输时间。若连接建立后长时间没有响应数据，重点检查服务端处理、接口依赖或排队；若响应很快开始、下载阶段却很长，则检查资源体积、网络吞吐和传输效率。若连接阶段反复出现较长空档，还要核对域名连接、重定向次数及并发请求情况。时间线标签会因工具而异，应结合请求详情判断。
- 沿依赖链追到真正的阻塞点。看关键请求是否要等另一份脚本执行、样式表下载或接口返回。例如，目录页首屏需要列表数据，而列表接口又依赖较慢的服务端查询，那么图片压缩并不能消除这段等待。检查脚本是否阻止解析、资源优先级是否合理，以及关键内容是否能先于非必要模块出现。
- 一次只改一个因素，再复测。可根据证据尝试减少不必要的重定向、压缩过大的文件、延后非首屏脚本，或让首屏关键数据更早返回。每次修改后，在相同条件下重新记录瀑布图，并对比关键请求的开始时间、等待阶段和完成时间。若总耗时变化但关键链路没变，需继续确认改善是否来自网络波动。
读图时避免三个误判
- 把最长请求当成首要问题：它可能与首屏无关，先判断是否位于关键链路。
- 只看文件大小：小文件也可能因服务端等待或依赖顺序而拖慢页面。
- 把一次结果当结论：缓存、网络和服务负载都会改变瀑布图，复测才便于区分稳定问题与偶然波动。
实际排查可以先写下“哪个关键内容在等哪个请求”，再围绕这条依赖关系采取行动。网站核心页面加载链路的瓶颈诊断方法，重点不是把所有资源都优化一遍，而是用可重复的瀑布图确认阻塞点、验证改动，并确保首屏所需内容真正更早可用。
常见问题
瀑布图里最长的一行一定最重要吗？
不一定。只有影响首屏关键内容或后续请求的资源，才可能是优先排查对象。
缓存要开启还是关闭后测试？
两种状态回答的问题不同。首次访问可关注未缓存资源；再次访问用于观察缓存对回访加载的影响，比较时需记录状态。
多久的请求才算异常？
没有适用于所有页面的统一阈值。应结合资源类型、测试网络、服务端负载及同条件下的多次结果判断。
优化后页面更快，但瀑布图变化不大怎么办？
检查测量条件和实际展示时机，也可能是改动影响了脚本执行或渲染而非请求时长；应结合页面表现与时间线复核。
