页面慢，不一定是服务器扛不住：DNS 查询、首字节等待、图片下载或脚本执行，都可能拖长用户看到内容的时间。诊断网站核心页面加载链路的瓶颈诊断方法，重点不是先换配置，而是把加载过程拆开测量，再找出最值得处理的一段。
1. 用瀑布图找出耗时集中在哪一步
先打开 Firefox 开发者工具的网络面板，清空记录后重新加载目标页面。选择一条代表性页面，观察文档及主要资源的请求顺序和耗时；再分别测试首次访问与再次访问，避免把缓存效果误认为网络改善。
- 先看主文档请求，再检查字体、图片、样式表和脚本等关键资源。
- 观察 DNS、连接、等待响应和接收数据等阶段；具体字段名称会随工具界面略有不同。
- 记录是否有请求排队、长时间等待，或关键资源要等其他请求完成后才开始。
瀑布图适合快速定位“慢在哪里”，但单次测试受网络、缓存和服务端负载影响，不能直接作为结论。
2. 用 TTFB 区分服务器等待与前端下载
TTFB（首字节时间）反映从发出请求到收到响应首字节所经历的时间，其中既有网络往返，也包含服务端处理。若它明显偏高，而后续内容下载很快，应继续检查应用处理、数据库访问、缓存命中情况和服务器日志；若首字节较早、主体下载拖得久，更该核对响应体大小和用户网络。
实操时，从同一网络重复访问几次，并对比匿名访问、登录访问或不同地区的结果。Google 对 Core Web Vitals 的建议中，LCP 在真实用户第 75 百分位不超过 2.5 秒属于良好；它衡量主要内容何时呈现，不等同于 TTFB，也不能单凭一个指标判断服务器性能。
3. 用 Lighthouse 找渲染和脚本问题
Lighthouse 可在本地运行，也可通过 PageSpeed Insights 查看报告。它能指出可能影响加载体验的项目，例如阻塞渲染的资源、未使用的代码和图片优化机会。报告中的实验室分数来自特定设备与网络模拟，适合发现线索，不代表所有用户的实际体验。
- 对同一页面运行多次，先看重复出现的问题，不追逐一次分数波动。
- 检查关键内容是否被大型脚本、字体或样式表延后显示。
- 每次只改一类问题，随后重新测试，确认对应指标和瀑布图确实变化。
4. 核对资源体积、缓存与请求数量
在网络面板按传输体积排序，优先查看首屏图片、字体和较大的脚本文件。图片可按显示尺寸选择合适格式与压缩程度；脚本可检查是否加载了当前页面不需要的模块。静态资源的浏览器缓存能减少回访下载，但首次访问仍需传输，因此缓存不能替代体积治理。
请求数量多不一定就是瓶颈：若资源很小、并行加载顺畅，合并文件未必有收益；若关键资源互相等待，调整加载顺序可能更重要。用相同页面、相同测试条件对比改动前后，才能判断取舍是否有效。
5. 用真实用户数据确认问题是否普遍
实验室测试便于复现，真实用户监测（RUM）则能呈现不同设备、网络和地区的差异。若已有分析平台或应用日志，可按页面类型、访问地区和时间段汇总 LCP、INP 等体验指标，并与服务器响应记录对照。没有监测系统时，先用少量人工复测和现有日志，不必为了诊断立即采购新工具。
把网站核心页面加载链路的瓶颈诊断方法落实为“复现—分段—验证”：瀑布图定位环节，指标缩小范围，改动后用同条件复测。先处理反复出现且影响关键内容的问题，通常比盲目增加带宽或重写页面更稳妥。
常见问题
只看 Lighthouse 分数够吗？
不够。它适合发现实验室环境下的优化线索，还应结合瀑布图和真实用户数据判断影响范围。
怎样判断慢在服务器还是用户网络？
对比 TTFB 与主体下载阶段，并在不同网络条件下重复测试；同时核对服务端日志，避免把网络往返误判为应用处理时间。
测试时需要清缓存吗？
首次访问和回访都应测。清缓存反映冷启动情形，保留缓存则能观察重复访问体验，两者回答的问题不同。
没有付费监测工具还能开始吗？
可以。浏览器网络面板、Lighthouse、PageSpeed Insights 和现有服务器日志已能覆盖不少基础排查场景。
