首页一直转圈，刷新一次又快了；文字已经出现，图片却迟迟不显示；办公室访问正常，客户用手机流量打开却要等很久。这些都叫“网站慢”，问题可能出在不同位置。

网站打开慢，应先检查DNS解析和连接建立，再看首字节等待，随后检查图片、脚本、接口与浏览器渲染。 找到耗时集中在哪一段，才能判断应该优化线路、源站、缓存还是前端代码。

CDN07建议先记录一次完整访问，再决定改什么配置。即使已经使用CDN，也需要按请求实际经过的路径排查。

网站慢在哪里，先用现象缩小范围

不要只记录“首页用了5秒”。相同的总耗时，背后可能是不同问题。

这张表用于确定检查入口，不能直接代替诊断。白屏可能发生在HTML返回之前，也可能发生在资源下载完成之后。

排查前，记下具体URL、发生时间、地区、运营商、设备和登录状态。对同一条件重复测试几次，保留失败和较慢的结果，避免只选最快的一次。

如果只有商品页慢，而首页和静态文件正常，检查范围就与“所有页面都慢”不同。先找到受影响的请求，后面的操作才有方向。

怎样记录DNS、连接和首字节耗时

浏览器开发者工具可以把一次请求拆成多个阶段。下面几个概念需要先分清：

这些阶段并不等于整页时间的简单相加。图片、脚本和接口可以并行请求，部分连接还会复用；页面何时显示取决于关键资源及其依赖关系。

以Chrome为例，可以按以下步骤记录：

1. 打开开发者工具，进入 Network（网络） 面板。
2. 确认选择 No throttling（不限速），避免意外保留模拟弱网设置。
3. 需要查看跳转链时，开启 Preserve log（保留日志），然后刷新页面。
4. 找到类型为 Document/Doc 的主文档，点击 Timing（时间）。
5. 记录DNS、连接、Waiting (TTFB)和Content Download，再检查影响首屏的其他请求。

如果要比较浏览器缓存的影响，可以勾选 Disable cache（停用缓存） 再测一轮。它不等于清空CDN缓存，也不代表DNS和连接状态全部重置。网站使用Service Worker时，还要检查响应是否由这一浏览器端程序提供。Chrome Network操作与阶段说明

DNS解析慢，应该检查哪些信息

DNS慢意味着客户端可能还没开始连接，就已经消耗了时间。先看慢的是主站域名，还是图片、字体、统计等资源使用的其他域名。

然后核对域名管理后台中的记录：网站是否刚迁移，CNAME是否指向当前接入目标，A和AAAA记录是否仍符合部署方案。A记录对应IPv4地址，AAAA记录对应IPv6地址，两者需要分别检查。

在装有nslookup的Windows、macOS或Linux环境中，可以查询示例域名的记录：

nslookup -type=A example.com
nslookup -type=AAAA example.com

将example.com替换为自己的域名。这些查询不会修改解析配置，但展示的是该命令所使用解析服务的结果，不一定与启用了安全DNS的浏览器完全相同。参数用法可参考BIND的nslookup说明。

结果中要分清DNS服务器自身的地址和域名查询结果。查到A或AAAA记录，只能说明这次查询返回了地址，不能单独证明网站已正确接入CDN。查询超时或返回不存在，也需要再核对域名拼写、解析服务和权威记录。

不同地区查询到不同IP并不一定异常，CDN调度本身就可能产生不同结果。相反，IP地址看起来相同，也不能证明所有用户走了同一条网络路径。

若只有某个网络反复解析慢，优先保留该环境的查询结果并做对照；多个网络都异常，再检查权威解析服务和记录链路。不要为了“少一次解析”直接删除服务商要求的CNAME。

浏览器里没有显示独立DNS时间，可能与缓存或连接复用有关，不代表首次访问也没有这部分成本。

连接建立慢，为什么不等于服务器配置差

域名解析完成后，客户端还需要建立连接。常见的新建HTTP/1.1或HTTP/2 HTTPS连接涉及TCP连接与TLS安全握手；HTTP/3使用QUIC，不能照搬相同的TCP拆分方法。

连接阶段偏长时，应记录远端地址、协议、用户网络和发生时段，再检查是否存在重试、丢包、拥堵、连接限制或TLS配置问题。

这里有三个容易忽略的区别。

浏览器到CDN节点的连接，不等于CDN到源站的连接。 源站是实际保存内容或运行应用的后端服务器。接入CDN后，浏览器记录通常只能直接展示到边缘节点的这一段，另一侧的回源连接需要结合服务端资料判断。

Ping测的是另一类交互。 它不能覆盖HTTPS握手、应用排队、数据库查询、资源下载和脚本执行，所以低Ping不能保证页面快。

入口跳转也会消耗时间。 从HTTP跳到HTTPS，再从裸域跳到www，最后跳到语言页面，可能在最终HTML返回前产生多次响应。检查每次跳转是否必要，并让站内链接直接指向正确目标。

对于部分运营商或晚高峰明显变慢的情况，要在相近时段比较相同URL，而不是拿白天的宽带结果对比晚上的手机流量。跨地域业务可以结合面向大陆用户的海外网站访问优化思路，进一步安排不同网络的对照测试。

TTFB高，怎么区分网络问题和源站问题

TTFB指首字节时间，即响应开始到达前的等待指标。但不同工具的计时起点可能不同。

页面导航口径的TTFB会包含首字节之前的解析、连接等阶段；Chrome Network中的 Waiting (TTFB) 是请求发送后的等待部分，也包含网络往返。比较两个数字之前，先确认它们是否采用同一口径。web.dev的TTFB定义

因此，看到TTFB为1秒，不能直接认定服务器执行代码花了1秒。对于经过CDN的请求，这段时间还可能涉及边缘处理、回源及中间代理。

对比公共静态文件和动态请求

在同一时段，对比业务页面与一个小型公共静态文件。

如果静态文件很快，某个接口却反复等待较久，优先检查该接口的应用处理、数据库查询、外部服务调用和排队情况。但两类请求可能采用不同缓存或后端，仍需用日志确认。

如果多个不同类型的请求都慢，再检查共同经过的网络、代理和源站资源。不要只测试首页就判断整个系统。

接入CDN后，核对请求是否命中缓存

CDN可以将适合缓存的响应保存在分发节点上。缓存命中时，部分请求无需再次访问源站；缓存未命中或需要验证时，则可能继续回源。基础工作方式可以参考CDN缓存与分发原理。

检查慢请求的路径、缓存规则、响应头和日志。不同产品的缓存状态字段不同，具体含义以对应厂商文档为准；没有看到某个常见响应头，不能直接认定没有缓存。

公共资源与个人数据需要分别处理。登录状态、购物车和账户资料不能为了降低TTFB就直接开启整站共享缓存，缓存规则应符合认证与响应内容的边界。HTTP缓存与共享缓存说明

用请求ID把浏览器和服务端记录对应起来

尽量通过请求ID关联边缘、Web服务器和应用日志；缺少统一ID时，至少对齐时间、路径和状态码。

浏览器等待很长，而应用处理较短，说明还有应用日志之外的环节需要检查。应用记录本身就很慢，则继续定位数据库、外部接口或计算任务。

如果源站负载异常，还要检查业务请求是否绕过预期的CDN入口。已接入CDN却仍存在其他直连路径时，可以进一步阅读源站IP暴露与访问保护的排查方向。不要仅凭负载升高就断言发生攻击。

HTML很快，为什么图片和页面仍然慢

HTML返回快，只说明主文档这一条请求表现较好。首屏可能还在等待图片、CSS、JavaScript或业务接口。

检查关键资源时，先看两个时间：什么时候开始请求，以及开始后用了多久。

如果一张首屏图片很晚才开始下载，问题可能在资源发现或依赖关系。例如图片要等JavaScript运行后才插入页面，那么缩小图片只能改善下载部分，不能消除前面的等待。

若首屏主要内容是一张大图，应检查浏览器是否能及时发现它，不要直接套用屏幕外图片的懒加载策略。LCP（最大内容绘制）可用于观察视口内主要内容何时呈现，但它也不等于所有功能已经可用。首屏资源与LCP优化说明

如果资源开始下载及时，却持续下载很久，再检查：

• 图片分辨率和格式是否适合实际显示尺寸；
• 文本资源是否使用合适的压缩方式；
• 是否一次加载了大量首屏暂不需要的文件；
• 资源域名是否采用了预期的CDN与缓存配置。

资源下载结束后，页面仍卡顿，应转到Performance面板查看脚本和渲染。JavaScript长时间占用浏览器主线程时，即使文件传输更快，用户仍可能无法及时看到内容或操作页面。

还要单独查看第三方字体、统计和客服脚本。主站接入CDN，不意味着这些独立域名也同步得到优化。

用curl复核，同一个请求到底耗时在哪

浏览器适合观察整页依赖，curl适合复核指定URL。下面的命令适用于Linux或macOS中的常见Shell，测试一个普通GET请求：

curl -sS -o /dev/null \
  --connect-timeout 10 --max-time 30 \
  -w 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nready=%{time_pretransfer}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://www.example.com/'

把地址替换为自己的页面。-o /dev/null丢弃下载内容；-sS隐藏进度但保留错误信息；两个超时参数分别限制连接阶段和整个操作的等待时间。Windows需要使用相应的curl.exe、输出目标和Shell换行语法，不能直接照搬这段多行命令。

输出时间单位是秒。这里的dns、connect、tls等名称是便于阅读的标签，对应花括号里的curl字段。它们大多是从操作开始计算的累计时间，不能相互相加。curl官方计时字段说明

下面是一组教学示例，不是CDN07客户实测：

假设没有103等临时响应，对于新建、无代理、无重定向的普通HTTP/1.1或HTTP/2 HTTPS请求，可通过相邻时间点辅助判断：TCP连接约0.08秒，TLS握手约0.13秒，传输准备完成到首字节之间约1.20秒，首字节之后约0.08秒。

这组数据说明，下一步应优先检查请求发送后的网络、代理、回源和应用处理。1.20秒仍然不是单独的服务器执行时间。

状态码也必须一起看。200不保证返回内容就是预期页面；301或302表示需要检查跳转，本命令不会自动跟随；403、502、504则应先处理对应访问或上游异常。失败、超时情况下，不要把不完整的计时当作正常样本。

curl不会继续下载页面里的图片，也不会执行JavaScript。它测得快，不能证明整页已经快。

怎样验证优化有效，而不是测试条件变了

改完配置后，用相同URL、登录状态和相近网络条件复测，明确浏览器缓存是否启用，同时保留响应状态和内容检查。

重点比较原先偏慢的阶段：DNS是否缩短，首字节等待是否改善，关键图片是否更早开始加载。不要只看总时间下降，因为变化可能来自浏览器缓存或临时网络波动。

对于有明显地区差异的网站，至少覆盖主要用户所在网络；对于移动端问题，使用实际手机复现。桌面浏览器模拟弱网有助于控制变量，但不能完全代表某个运营商的真实路径或手机性能。

要把问题交给技术支持时，准备URL、发生时间、地区运营商、浏览器与设备信息、Timing截图和请求ID。导出HAR或日志后，仍需检查并去除令牌、个人资料等敏感信息，不要只依赖工具的默认脱敏。

常见问题FAQ

网站第一次打开慢、第二次快，是什么原因？

可能与浏览器缓存、CDN缓存、DNS缓存、连接复用或应用预热有关。比较两次请求是否真正发送、响应来自哪里，以及哪些阶段缩短，才能区分原因。不能仅凭重复访问变快就认定CDN配置正确。

TTFB超过1秒，是不是服务器性能不够？

不一定。先确认计时口径，再看网络、代理、回源和应用日志。如果应用处理很短，升级服务器可能无法改善主要瓶颈；若慢查询或队列耗时明显，就应针对后端处理。

Ping很低，但网页打开慢正常吗？

这种组合可能出现，因为两者测量对象不同。继续检查HTTPS请求、首字节、资源体积和脚本执行；低Ping不能排除这些环节的问题。

用了CDN网站还是慢，要换服务商吗？

先确认慢请求是否经过CDN、是否适合缓存、回源是否偏慢，以及页面是否被前端任务阻塞。只有问题持续集中在相应分发节点或链路，并有同条件对照证据时，才适合进一步比较方案。

网站只有部分地区访问慢，怎么确认原因？

在相近时段用相同URL对比不同网络，记录解析结果、远端地址、状态码和阶段耗时。还要确认是否使用IPv4或IPv6。一次外地测速不足以确定长期原因，也不能凭地区差异就直接认定被屏蔽。

清理缓存能让网站一直变快吗？

不能。清理浏览器缓存可能让下一次访问重新下载文件；清理CDN缓存还可能增加回源。只有怀疑缓存内容或状态异常时，才针对必要范围处理，并验证结果。

网站提速从哪一步开始

排查时记住四点：

• 先定位具体请求和耗时阶段，再决定修改对象。
• 首字节慢需要结合网络与服务端证据，不能直接归因于服务器。
• HTML返回快之后，还要检查关键资源和浏览器渲染。
• 接入CDN后的效果，应在相同条件下验证，不能只看一次测速。

下一步可以先打开Network面板，保留一条慢请求的Timing记录，再用curl复核该URL。问题集中在源站处理时，继续查应用日志；集中在内容分发或跨地域访问时，可结合CDN07高防CDN服务的接入方案，按实际业务路径评估配置与优化方向。