DNS、连接、TLS、TTFB和下载时间，网站速度应该先优化哪个？

网站测速报告里，DNS、连接、TLS、TTFB和下载时间都有数值。有人看到DNS用了100毫秒就去换DNS，有人看到TLS比连接时间高就准备换CDN，也有人只盯着TTFB，认为所有问题都在服务器。

这些判断都可能抓错重点。

真正的优化顺序不是固定的“先DNS、再连接、再TLS”，而应该看三个条件：

1. 哪个阶段明显偏离同地区、同运营商和历史基线；

2. 这个阶段影响多少真实用户和多少次请求；

3. 即使把它优化掉，对最终页面体验能改善多少。

对于普通网站，可以先记住一个大致优先级：

先处理失败、超时和明显异常，再检查主HTML的TTFB；如果问题集中在首次连接或某些地区，则优先检查DNS、TCP和TLS；如果首字节已经很快，但页面仍然加载很久，重点通常转向资源大小、下载吞吐和浏览器渲染。

TTFB经常是主文档最值得优先检查的指标，因为浏览器拿到HTML第一个字节前，后续页面解析、CSS、JavaScript和图片加载通常还不能完整展开。但这不是说TTFB永远排第一。DNS等待600毫秒、TCP跨洲绕行或一张首屏图片下载4秒时，继续压缩几十毫秒的服务器处理时间并不会解决主要问题。

先看完整请求链，不要孤立看五个数字

一次新的HTTPS请求大致经过：

输入域名
  ↓
DNS解析
  ↓
建立TCP连接或QUIC连接
  ↓
TLS握手
  ↓
发送HTTP请求并等待响应
  ↓
收到第一个字节，也就是TTFB结束
  ↓
下载剩余响应内容

五个阶段回答的问题不同：

这里有一个重要区别：不同工具的字段可能是“独立阶段”，也可能是“从请求开始累计到某个时间点”。

如果没有先确认指标口径，最容易出现重复计算。例如把curl的time_appconnect直接当成TLS阶段，又把DNS和TCP单独加一次，最终总时间就会被算大。

用curl正确拆分五个阶段

可以先对目标页面执行：

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_version=%{http_version}\ndns_done=%{time_namelookup}\nconnect_done=%{time_connect}\ntls_done=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\nspeed=%{speed_download}\n' \
  https://www.example.com/

输出可能类似：

remote_ip=203.0.113.10
http_version=2
dns_done=0.020
connect_done=0.075
tls_done=0.158
first_byte=0.380
total=0.430
size=42816
speed=151428

这些时间通常是从请求开始累计计算的，可以近似拆分为：

DNS时间     ≈ time_namelookup
TCP连接时间 ≈ time_connect - time_namelookup
TLS时间     ≈ time_appconnect - time_connect
握手后等待首字节 ≈ time_starttransfer - time_appconnect
下载时间    ≈ time_total - time_starttransfer

以上面的结果计算：

DNS约20ms
TCP连接约55ms
TLS约83ms
握手后等待首字节约222ms
下载约50ms

curl官方手册对time_namelookup、time_connect、time_appconnect和time_starttransfer采用的也是从传输开始到对应事件完成的累计计时。

需要注意：

• 使用-L跟随重定向时，部分计时可能累计多个请求；

• 经过HTTPS代理时，连接阶段可能包含代理建立过程；

• HTTP/3基于QUIC，TCP和TLS的阶段边界与HTTP/2不同；

• 请求很小的页面不适合评估下载吞吐；

• 一次curl调用通常是新连接，不能代表浏览器复用连接后的体验。

浏览器里的Timing为什么和curl不一样

Chrome开发者工具的Network面板会显示：

Queueing
Stalled
DNS Lookup
Initial connection
Proxy negotiation
SSL
Request sent
Waiting for server response
Content Download

其中Queueing和Stalled可能来自浏览器内部调度、连接槽位、代理或缓存处理，不属于服务器本身。

Chrome官方的网络请求Timing说明指出，Waiting（TTFB）包括一次网络往返以及服务端准备响应所用的时间。也就是说，浏览器里的TTFB同样不是“纯后端程序执行时间”。

浏览器还会复用连接。页面内多个资源使用同一HTTP/2或HTTP/3连接时，后续资源可能没有新的DNS、TCP和TLS阶段。此时不能因为某个资源的SSL显示为0，就认为TLS不需要时间。

排查时最好分别测试：

• 冷访问：新的DNS查询和新的网络连接；

• 暖访问：已有DNS缓存、连接和资源缓存；

• 正常缓存：接近重复访问用户；

• 禁用缓存：用于开发排查，但不代表真实用户日常状态。

先处理失败率，再优化毫秒数

如果某个地区出现以下问题，优先级应高于所有速度优化：

• DNS返回SERVFAIL；

• IPv6连接超时；

• TLS握手失败；

• CDN节点偶发502、503或504；

• 下载中途断开；

• 某运营商P95出现数秒尖峰；

• 页面部分资源加载失败。

一个平均100毫秒但有5%连接失败的服务，通常比平均150毫秒且稳定成功的服务更需要处理。

因此，第一次排序应该是：

错误和超时
→ P95/P99异常
→ 大范围持续偏慢
→ P50可以进一步优化

只看平均值，可能把少量严重失败稀释掉。CDNChart在CDN测速方法论中也将DNS、TCP、TLS、TTFB、下载和总耗时分别记录，并结合P50、P95及可用性理解结果，而不是把所有请求压缩成一个平均分。

什么情况下应该先优化DNS

DNS值得优先处理的典型情况是：

• 首次访问经常在DNS阶段等待数百毫秒；

• 某个地区或运营商频繁解析超时；

• CNAME链存在异常或某一级权威DNS不稳定；

• 主页面引用大量不同域名，每个都产生新的解析等待；

• DNS返回了不合适的CDN入口，导致后续连接更慢；

• A记录正常，AAAA记录异常或解析到错误入口。

DNS慢主要影响首次解析。浏览器、操作系统和递归解析器缓存答案后，重复访问可能看不到明显DNS时间。

因此，假设DNS阶段为200毫秒，需要继续问：

这是冷查询还是缓存命中？
只发生在一次测试还是长期P95都高？
主域名慢还是第三方域名慢？
DNS虽然慢，但是否返回了更优节点？
降低DNS时间后，后面的连接是否反而更差？

不要为了降低DNS查询毫秒数，随意删除CDN需要的CNAME或把业务域名直接指向固定节点。DNS不仅负责查地址，也可能承担CDN节点调度。

DNS高时常见的优化方向包括：

• 检查权威DNS的地区覆盖和可用性；

• 减少不必要的CNAME链；

• 合理设置TTL；

• 减少页面中不必要的第三方域名；

• 对关键域名使用dns-prefetch或preconnect前先评估连接收益；

• 检查IPv4、IPv6和不同递归DNS返回结果；

• 确认CDN调度没有把用户送到远端节点。

更完整的检查步骤可参考DNS解析慢会拖慢CDN吗？域名解析耗时怎么排查。

什么情况下应该先优化连接时间

连接时间主要反映客户端到CDN节点或服务器建立TCP连接的成本。

如果DNS很快，但TCP阶段明显高，常见原因包括：

• 用户距离节点较远；

• CDN调度到了不合适的区域；

• 运营商之间路由绕行；

• IPv6线路质量差；

• 网络存在丢包和重传；

• 防火墙、代理或安全软件增加连接等待；

• CDN在目标地区缺少合适的网络入口。

可以分别测试IPv4和IPv6：

curl -4 -sS -o /dev/null \
  -w 'ip=%{remote_ip} connect=%{time_connect} total=%{time_total}\n' \
  https://www.example.com/

curl -6 -sS -o /dev/null \
  -w 'ip=%{remote_ip} connect=%{time_connect} total=%{time_total}\n' \
  https://www.example.com/

还可以使用：

mtr -rwzc 30 www.example.com

但中间路由器可能限制ICMP响应，某一跳显示丢包不代表业务流量一定在该处丢失。应结合最终目标、TCP连接时间和多地区数据判断。

连接阶段异常时，压缩页面代码或增加服务器CPU通常不会产生明显效果。更值得检查的是CDN节点、运营商线路、Anycast或DNS调度、IPv6以及网络路径。

什么情况下应该先优化TLS

TLS握手发生在建立加密连接时。如果TCP连接正常，TLS阶段却明显偏高，应继续检查：

• 是否启用TLS 1.3；

• 源站或CDN返回的证书链是否完整；

• SNI是否选择正确证书；

• 是否发送了不必要的证书；

• 某些客户端是否经过TLS检查代理；

• 握手阶段是否发生丢包或重传；

• IPv4与IPv6入口是否返回不同配置；

• 是否支持会话恢复；

• 边缘节点是否存在区域性性能问题。

TLS时间通常需要结合TCP时间看。假设：

TCP阶段：180ms
TLS阶段：190ms

更可能是节点距离和网络往返本身较高。

如果是：

TCP阶段：20ms
TLS阶段：600ms

才更值得重点检查证书、协议、中间设备和握手重传。

具体排查命令与判断边界，可以继续TLS握手时间很高，换CDN之前先检查什么？。

为什么主HTML的TTFB通常优先级较高

TTFB表示从导航或请求开始，到客户端收到响应第一个字节的时间。它包含DNS、连接、TLS、请求传输、网络往返以及服务端或CDN准备响应的时间。

Google的TTFB说明将其称为连接建立和服务器响应能力的基础指标。对于HTML导航请求，TTFB发生在后续主要页面加载指标之前。

这就是为什么主HTML的TTFB很重要：

HTML第一个字节还没到
→ 浏览器无法完整解析页面
→ 关键CSS和JS发现得更晚
→ 首屏图片请求启动得更晚
→ FCP和LCP也容易向后推迟

但TTFB高不等于源站程序一定慢。经过CDN时，它还可能包含：

• CDN边缘排队；

• WAF或Bot规则处理；

• 缓存查询；

• 缓存MISS后的回源；

• CDN到源站的网络时间；

• 源站Web服务器排队；

• 应用程序执行；

• 数据库和第三方API；

• 源站返回首字节的传输时间。

排查时应对比：

web.dev给出的粗略参考是，TTFB在0.8秒以内通常被视为良好，超过1.8秒则较差。但这不是判断CDN是否合格的唯一标准，也不能代替按地区、设备和资源类型建立自己的基线。

TTFB高时应该先优化CDN还是源站

可以用缓存状态缩小范围。

连续请求同一个可缓存资源：

curl -sS -D - -o /dev/null https://www.example.com/static/app.js
curl -sS -D - -o /dev/null https://www.example.com/static/app.js

查看可能存在的：

Age
Via
X-Cache
CF-Cache-Status
其他厂商缓存响应头

不同CDN使用的字段不同，不能只根据某一个固定响应头判断所有厂商。

如果第二次命中缓存后TTFB明显下降，说明CDN边缘返回较快，主要延迟可能发生在MISS回源路径。

如果缓存HIT仍然很慢，应继续检查：

• 测试地区是否接入远端节点；

• 节点到用户的网络路径；

• TLS与TCP阶段；

• 边缘规则、WAF和计算逻辑；

• CDN节点负载；

• 测试工具是否把连接时间计入TTFB。

动态页面无法直接缓存时，可以优化：

• 应用查询和数据库；

• 页面片段或接口缓存；

• 源站连接池；

• CDN与源站间的长连接；

• 边缘计算；

• 第三方接口调用；

• 应用排队和并发限制；

• 不必要的重定向。

什么情况下应该先优化下载时间

如果TTFB已经较低，但页面仍然很慢，问题可能出现在响应体下载阶段或浏览器渲染阶段。

下载时间高通常与以下因素有关：

• 文件过大；

• 图片没有压缩或使用不合适格式；

• JavaScript包过大；

• 视频码率超出用户网络能力；

• 没有启用Gzip或Brotli；

• CDN节点吞吐不足；

• 用户网络带宽有限；

• 下载期间出现丢包；

• 单连接被限速；

• 静态资源没有正确缓存；

• 页面同时请求过多非关键资源。

对于一个只有30KB的HTML，下载时间占比通常不会太大。对于5MB首屏图片、软件安装包或视频分片，下载可能成为最主要阶段。

测试下载吞吐时，应使用自己管理的、大小固定且允许公开测试的文件：

curl -sS -o /dev/null \
  -w 'ip=%{remote_ip} size=%{size_download} speed=%{speed_download} total=%{time_total}\n' \
  https://static.example.com/test-file.bin

不要用几十字节的健康检查页面判断CDN下载速度。文件过小，连接、TLS和计时误差可能占据大部分结果。

下载阶段常见的优化方向包括：

• 减少首屏资源字节数；

• 图片转换为WebP或AVIF并按显示尺寸输出；

• 启用适合内容类型的压缩；

• 拆分和延迟加载非关键JavaScript；

• 为静态资源设置长期缓存和内容哈希；

• 使用CDN边缘缓存；

• 针对视频和大文件支持分片、Range和合理码率；

• 检查目标地区吞吐和单连接限速；

• 避免把大文件通过不适合的动态接口实时生成。

四种常见结果，先优化哪里

情况一：DNS占用了大部分首次等待

DNS：600ms
连接：40ms
TLS：70ms
握手后等待首字节：100ms
下载：30ms

优先检查DNS、CNAME、递归解析器和权威DNS。即使把TTFB减少50毫秒，用户首次访问仍然会在解析阶段等待。

情况二：连接和TLS只在部分地区高

DNS：20ms
连接：300ms
TLS：320ms
握手后等待首字节：80ms
下载：40ms

如果异常集中在某个地区或运营商，应优先检查CDN调度、节点覆盖、IPv4/IPv6和路由。源站应用可能并不是主要问题。

情况三：连接正常，但动态页面TTFB很高

DNS：20ms
连接：40ms
TLS：60ms
握手后等待首字节：1400ms
下载：30ms

优先检查缓存MISS、回源、应用、数据库和第三方接口。此时换DNS几乎不会改善主要等待。

情况四：首字节很快，下载和渲染很慢

DNS：15ms
连接：35ms
TLS：50ms
握手后等待首字节：100ms
下载：3500ms

优先检查响应大小、压缩、图片、脚本、吞吐和前端加载顺序。继续优化几十毫秒TTFB的收益有限。

怎样计算“最值得优化”的阶段

可以为每个阶段记录三个维度：

异常程度 × 影响用户比例 × 可减少的实际时间

例如：

这比按照指标名称制定固定顺序更接近真实优化决策。

一套实际可执行的优化顺序

第一步：确定测试对象

不要把首页HTML、图片、API和大文件混在一起比较。

至少分成：

主HTML
可缓存静态资源
动态API
首屏关键图片
大文件或视频

第二步：区分冷连接和连接复用

分别观察：

• 第一次解析和新建连接；

• DNS缓存后的访问；

• TLS会话恢复；

• HTTP/2或HTTP/3连接复用；

• 浏览器资源缓存。

第三步：区分缓存HIT和MISS

CDN缓存命中与回源请求的TTFB差异可能很大。测试记录中必须保存缓存状态，否则不同样本无法直接比较。

第四步：覆盖真实用户地区

不要只使用服务器所在地或办公室网络。

至少按照实际用户比例覆盖主要城市、国家、运营商、IPv4和IPv6。

第五步：看P50、P95和失败率

P50反映常见体验，P95用于发现长尾问题，失败率用于识别可用性风险。只看一次最快结果没有意义。

第六步：一次只改变一个主要变量

例如：

先修复AAAA异常
→ 重新测试

再调整CDN节点或调度
→ 重新测试

再优化缓存和源站
→ 重新测试

如果同时更换DNS、CDN、证书和服务器，很难判断哪项改动真正有效。

五个阶段分别对应哪些优化手段

这些手段不能机械套用。例如DNS时间正常时，减少一层CNAME未必值得承担迁移风险；TTFB主要由跨洲网络往返造成时，单纯升级数据库也可能没有明显效果。

最容易出现的五种误判

把time_appconnect全部当成TLS时间

它通常是从请求开始到TLS完成的累计值，应结合time_connect计算TLS阶段。

用Ping代替连接和网站测速

Ping不执行正常的TCP、TLS、HTTP和页面下载。具体区别可以参考Ping很快，网站却很慢？别把延迟当成加载速度。

只测一次就确定优先级

网络抖动、DNS缓存、节点切换和源站负载都可能造成单次异常。至少要观察多次结果和P95。

用小文件判断下载速度

几十KB文件的总时间主要由连接和TTFB组成，无法充分反映持续吞吐。

把浏览器关闭缓存后的结果当成真实用户体验

禁用缓存适合发现完整请求成本，但真实用户可能使用DNS缓存、连接复用和资源缓存。冷访问与暖访问都要测，不能只保留其中一种。

常见问题

普通网站是不是应该先优化TTFB？

多数情况下，主HTML的TTFB值得优先检查，因为它会影响后续资源发现。但如果DNS、连接、TLS存在大范围异常，或页面主要问题是首屏资源过大，就不应机械地把TTFB排在第一位。

DNS只有100毫秒，需要优化吗？

要结合地区、缓存状态和整体占比判断。如果只在冷查询出现一次，而页面总加载需要数秒，收益可能有限；如果每个第三方域名都增加100毫秒，累计影响就可能很明显。

TLS时间高，换CDN一定有效吗？

不一定。TLS时间还受网络距离、丢包、证书链、客户端代理、TLS版本和IPv6线路影响。只有证据指向节点覆盖或CDN边缘性能时，更换CDN才更可能有效。

TTFB高就是服务器程序慢吗？

不是。TTFB包含DNS、连接、TLS、网络往返、CDN缓存、回源和服务器处理。应先拆分前置阶段，再对比缓存HIT与MISS。

下载时间高，增加服务器带宽就能解决吗？

不一定。如果资源由CDN缓存，瓶颈可能在边缘吞吐、用户网络、文件大小或单连接限制。应同时检查响应大小、压缩、缓存状态和目标地区带宽。

为什么浏览器显示DNS和TLS都是0？

浏览器可能使用了DNS缓存和已有连接，也可能从Service Worker或资源缓存取得内容。这不代表首次访问不需要DNS和TLS。

P50和P95哪个更值得看？

两个都需要。P50反映多数用户的常见体验，P95用于发现少量但严重的慢请求。优化平均体验时看P50，排查投诉和稳定性时更应关注P95及失败率。

五个阶段都不高，页面为什么仍然慢？

问题可能在浏览器渲染、JavaScript执行、CSS阻塞、字体、第三方脚本、主线程任务或资源加载顺序。网络阶段正常后，应继续检查FCP、LCP、INP和浏览器Performance面板。