网站访问速度慢怎么排查：先看TTFB、LCP和瀑布流

遇到网站访问速度慢怎么排查的问题，第一步不是立即升级主机，也不是盲目开启缓存，而是确认“慢”发生在哪个阶段：域名解析、建立连接、服务器返回首字节、下载页面资源，还是浏览器完成渲染。不同阶段对应的处理方法完全不同。

例如，页面打开后很久才出现内容，可能与服务器响应有关；页面主体已经出现，但图片、字体或交互控件迟迟未完成，则更接近前端资源问题。先拆分耗时，才能避免把缓存、CDN或数据库优化用错地方。

先建立一组可比较的测速条件

网站访问速度慢怎么排查，必须先保证测试结果可比较。建议固定测试页面、测试浏览器、设备类型和网络环境，并分别记录首次访问与再次访问的结果。首次访问更能反映 DNS、连接和缓存未命中的情况，再次访问则有助于观察浏览器缓存和边缘缓存效果。

使用 Chrome DevTools 的 Network 面板，勾选 Disable cache，并记录请求总耗时、请求数量和最大资源。
在 Throttling 中分别选择 Fast 3G、4G 或自定义网络条件，观察移动端与桌面端差异。
使用 Lighthouse 检查性能，但不要只看总分，应保存 LCP、CLS、INP 等指标及诊断建议。
通过 curl 查看服务器响应，例如记录 DNS、TCP、TLS、首字节和总耗时；多次执行后看范围，不要依据单次结果下结论。

测试时还要区分首页、登录后页面、商品详情页、搜索页等不同类型。静态首页可能很快，但带查询参数的列表页可能因为数据库查询或接口串行调用而变慢。

进阶优化前优先看哪些指标

1. TTFB：服务器是否及时开始响应

TTFB 是从发起请求到收到首个字节的时间，通常包含解析、连接、TLS 握手和服务器处理。若同一页面在缓存命中时响应很快，未命中时明显变慢，应检查页面缓存、反向代理、应用进程和数据库查询。动态页面的 TTFB 会受登录状态、查询条件和后端负载影响，不能简单用一个固定阈值判断好坏。

如果静态文件的 TTFB 也持续偏高，可进一步检查服务器所在区域、网络路径、TLS 配置和边缘节点命中情况；如果只有某类接口变慢，则重点查看应用日志与数据库耗时。

2. LCP、CLS 与 INP：用户真正感受到的页面体验

LCP 反映主要内容出现的速度，常见对象包括首屏大图、标题或主要文本块。CLS 关注布局是否在加载过程中跳动，例如图片没有预留尺寸、广告位动态插入或字体切换造成页面位移。INP 则反映点击、输入等交互的响应情况，JavaScript 长任务过多时，即使页面已经显示，也可能操作迟钝。

这三个指标需要结合页面结构分析。LCP 高，先查最大内容元素和其依赖资源；CLS 高，先给图片、视频和嵌入内容设置宽高或比例；INP 高，则查看主线程长任务、事件处理函数和第三方脚本。

3. 瀑布流：判断等待发生在哪里

在 Chrome DevTools 中展开请求瀑布流，可以看出资源是在排队、连接、等待响应，还是下载阶段耗时。大量请求同时排队，可能是并发限制或主线程阻塞；某个接口完成后，下一批资源才开始加载，可能存在串行依赖；单个 JavaScript、字体或图片文件特别大，则应检查资源体积和加载优先级。

不要只关注文件大小。一个 500 KB 的脚本如果阻塞渲染，影响可能大于多个异步加载的图片；一张未压缩的首屏图片则可能直接推高 LCP。

按故障位置执行排查

域名与连接层

先检查 DNS 查询耗时、解析结果是否稳定，以及 IPv4 与 IPv6 是否表现不同。若只有部分网络环境变慢，应比较不同公共解析器和不同地区的结果，但不要仅凭一次解析测试认定 DNS 是根因。随后查看 TCP、TLS 握手时间；证书链过长、协议协商异常或连接复用不足，都可能增加首次访问等待。

服务器与应用层

检查 CPU、内存、磁盘 I/O、连接数、进程队列和数据库慢查询。若服务器资源并未饱和，但 TTFB 仍高，应查看应用日志中的接口耗时、外部服务调用和锁等待。接口调用应设置合理超时，避免一个失效依赖拖慢整页。

前端与资源层

优先处理首屏关键路径：压缩并转换大图，使用现代图片格式时保留兼容策略；非首屏图片采用懒加载；关键字体控制数量并避免阻塞文本显示；将非必要统计、聊天和营销脚本延后加载。CSS 与 JavaScript 是否合并，要根据 HTTP/2 或 HTTP/3、缓存命中和文件更新频率决定，不能机械追求文件越少越好。