DNS, connection, TLS, TTFB, and download time: which should you optimize first for website speed?

In website speed test reports, DNS, connection, TLS, TTFB, and download time all have values. Some people see DNS took 100 ms and switch DNS providers; some see TLS higher than connection time and plan to change CDNs; others focus only on TTFB and assume all problems lie with the server.

These judgments may all miss the real issue.

The actual optimization order is not a fixed “DNS first, then connection, then TLS”; instead, consider three conditions:

1. Which stage deviates noticeably from the baseline for the same region, same ISP, and historical data;

2. How many real users and requests this stage affects;

3. How much the final page experience can improve even if you optimize it away.

For an ordinary website, you can start with a rough priority order:

Address failures, timeouts, and obvious anomalies first, then check the TTFB of the main HTML. If issues are concentrated in the initial connection or certain regions, check DNS, TCP, and TLS first. If the first byte is already fast but the page still takes a long time to load, focus usually shifts to resource size, download throughput, and browser rendering.

TTFB is often the metric most worth checking first for the main document, because before the browser receives the first byte of HTML, subsequent page parsing, CSS, JavaScript, and image loading generally cannot fully proceed. But that does not mean TTFB always ranks first. When DNS waits 600 ms, TCP routes across continents, or a hero image takes 4 seconds to download, further shaving tens of milliseconds off server processing time will not solve the main problem.

Look at the full request chain first, not five numbers in isolation

A new HTTPS request roughly goes through:

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

The five stages answer different questions:

There is an important distinction here: fields in different tools may be “independent stages” or “cumulative from request start to a certain point in time.”

If you do not first confirm how the metrics are defined, double counting is most likely. For example, treating curl’stime_appconnectdirectly as the TLS stage and then adding DNS and TCP separately again will inflate the total time.

Correctly split the five stages with curl

You can first run this against the target page:

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/

The output may look similar to:

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

These times are usually cumulative from request start and can be approximated as:

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

Using the above results:

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

The official curl manual also describestime_namelookup,time_connect,time_appconnectandtime_starttransferas cumulative timings from transfer start to completion of the corresponding event.

Note:

• When using-Lto follow redirects, some timings may accumulate across multiple requests;

• Through an HTTPS proxy, the connection stage may include proxy establishment;

• HTTP/3 is based on QUIC, so TCP and TLS stage boundaries differ from HTTP/2;

• Requests for very small pages are not suitable for evaluating download throughput;

• A single curl invocation usually creates a new connection and cannot represent the experience after the browser reuses connections.

Why browser Timing differs from curl

The Network panel in Chrome DevTools shows:

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

Queueing and Stalled may come from browser-internal scheduling, connection slots, proxy, or cache handling, not from the server itself.

Chrome’s officialnetwork request Timing documentationstates that Waiting (TTFB) includes one network round trip plus the time the server takes to prepare the response. In other words, TTFB in the browser is likewise not “pure backend program execution time.”

Browsers also reuse connections. When multiple resources on a page use the same HTTP/2 or HTTP/3 connection, subsequent resources may not have new DNS, TCP, and TLS stages. At that point, you cannot conclude that TLS takes no time just because SSL shows 0 for a resource.

During troubleshooting, it is best to test separately:

• Cold visit: new DNS lookup and new network connection;

• Warm visit: existing DNS cache, connection, and resource cache;

• Normal cache: close to a repeat visitor;

• Cache disabled: for development troubleshooting, but not representative of real users’ everyday state.

Handle failure rates first, then optimize milliseconds

If the following problems occur in a region, they should take priority over all speed optimizations:

• DNS returnsSERVFAIL;

• IPv6 connection timeout;

• TLS handshake failure;

• Occasional 502, 503, or 504 from CDN nodes;

• Download disconnects midway;

• A P95 spike of several seconds on a certain ISP;

• Some page resources fail to load.

A service averaging 100 ms but with a 5% connection failure rate usually needs attention more than one averaging 150 ms with consistent success.

Therefore, the first ranking should be:

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

Looking only at averages can dilute a small number of severe failures. CDNChart’sCDN speed testing methodologyalso records DNS, TCP, TLS, TTFB, download, and total time separately, and interprets results together with P50, P95, and availability, rather than compressing all requests into a single average score.

When should you optimize DNS first?

Typical cases where DNS deserves priority are:

• First visits often wait hundreds of milliseconds in the DNS stage;

• Frequent resolution timeouts in a certain region or ISP;

• An abnormal CNAME chain or an unstable authoritative DNS level;

• The main page references many different domains, each generating a new resolution wait;

• DNS returns an inappropriate CDN entry point, causing slower subsequent connections;

• A records are normal, but AAAA records are abnormal or resolve to the wrong entry point.

Slow DNS mainly affects first-time resolution. Once the browser, operating system, and recursive resolver cache the answer, repeat visits may show no noticeable DNS time.

Therefore, if the DNS stage is 200 ms, continue asking:

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

Do not arbitrarily delete CNAMEs required by the CDN or point business domains directly to fixed nodes just to reduce DNS query milliseconds. DNS not only resolves addresses; it may also handle CDN node scheduling.

Common optimization directions when DNS is high include:

• Check the regional coverage and availability of authoritative DNS;

• Reduce unnecessary CNAME chains;

• Set TTL appropriately;

• Reduce unnecessary third-party domains on the page;

• For critical domains, usedns-prefetchorpreconnectonly after evaluating the connection benefits;

• Check IPv4, IPv6, and results returned by different recursive DNS resolvers;

• Confirm that CDN scheduling is not sending users to distant nodes.

For more complete inspection steps, seeDoes slow DNS resolution slow down CDNs? How to troubleshoot domain resolution time.

When should you optimize connection time first?

Connection time mainly reflects the cost for the client to establish a TCP connection to a CDN node or server.

If DNS is fast but the TCP stage is noticeably high, common causes include:

• Users are far from the node;

• CDN scheduling sent them to an inappropriate region;

• Routing detours between ISPs;

• Poor IPv6 line quality;

• Packet loss and retransmission on the network;

• Firewalls, proxies, or security software add connection wait time;

• The CDN lacks suitable network entry points in the target region.

Test IPv4 and IPv6 separately:

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/

You can also use:

mtr -rwzc 30 www.example.com

However, intermediate routers may limit ICMP responses, and packet loss shown at one hop does not necessarily mean business traffic is lost there. Judge based on the final target, TCP connection time, and multi-region data.

When the connection stage is abnormal, compressing page code or adding server CPU usually has no noticeable effect. What is more worth checking is CDN nodes, ISP lines, Anycast or DNS scheduling, IPv6, and network paths.

When should you optimize TLS first?

The TLS handshake occurs when establishing an encrypted connection. If the TCP connection is normal but the TLS stage is noticeably high, continue checking:

• Whether TLS 1.3 is enabled;

• Whether the certificate chain returned by the origin or CDN is complete;

• Whether SNI selects the correct certificate;

• Whether unnecessary certificates are sent;

• Whether some clients go through a TLS inspection proxy;

• Whether packet loss or retransmission occurs during the handshake;

• Whether IPv4 and IPv6 entry points return different configurations;

• Whether session resumption is supported;

• Whether edge nodes have regional performance issues.

TLS time usually needs to be considered together with TCP time. Suppose:

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

It is more likely that node distance and network round trips themselves are high.

If it is:

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

then it is more worth focusing on certificates, protocols, middleboxes, and handshake retransmission.

For specific troubleshooting commands and judgment boundaries, continue with the pending review articleTLS handshake time is high—what should you check before switching CDNs?.

Why main HTML TTFB usually has higher priority

TTFB is the time from navigation or request start until the client receives the first byte of the response. It includes DNS, connection, TLS, request transmission, network round trips, and the time the server or CDN takes to prepare the response.

Google’sTTFB documentationcalls it a foundational metric for connection setup and server responsiveness. For HTML navigation requests, TTFB occurs before subsequent main page loading metrics.

This is why main HTML TTFB matters:

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

But high TTFB does not necessarily mean the origin application is slow. When going through a CDN, it may also include:

• CDN edge queuing;

• WAF or bot rule processing;

• Cache lookup;

• Origin fetch after a cache MISS;

• Network time from CDN to origin;

• Origin web server queuing;

• Application execution;

• Database and third-party APIs;

• Transmission time for the origin to return the first byte.

During troubleshooting, compare:

web.devgives a rough reference: TTFB within 0.8 seconds is generally considered good, while over 1.8 seconds is poor. But this is not the only standard for judging whether a CDN is qualified, nor can it replace establishing your own baseline by region, device, and resource type.

When TTFB is high, should you optimize the CDN or the origin first?

You can use cache status to narrow it down.

Request the same cacheable resource repeatedly:

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

Check for possible:

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

Different CDNs use different fields, so you cannot judge all vendors based only on one fixed response header.

If TTFB drops noticeably on the second request after hitting cache, the CDN edge is returning quickly, and the main delay may be on the MISS origin fetch path.

If cache HIT is still slow, continue checking:

• Whether the test region connects to a distant node;

• The network path from node to user;

• TLS and TCP stages;

• Edge rules, WAF, and compute logic;

• CDN node load;

• Whether the testing tool counts connection time in TTFB.

When dynamic pages cannot be cached directly, you can optimize:

• Application queries and database;

• Page fragment or API caching;

• Origin connection pools;

• Long-lived connections between CDN and origin;

• Edge computing;

• Third-party API calls;

• Application queuing and concurrency limits;

• Unnecessary redirects.

When should you optimize download time first?

If TTFB is already low but the page is still slow, the problem may be in the response body download stage or the browser rendering stage.

High download time is usually related to the following factors:

• Files are too large;

• Images are not compressed or use inappropriate formats;

• JavaScript bundles are too large;

• Video bitrate exceeds users’ network capacity;

• Gzip or Brotli is not enabled;

• CDN node throughput is insufficient;

• User network bandwidth is limited;

• Packet loss occurs during download;

• A single connection is rate-limited;

• Static resources are not cached correctly;

• The page requests too many non-critical resources at the same time.

For a 30 KB HTML file, download time usually does not account for much. For a 5 MB hero image, software installer, or video segment, download may become the dominant stage.

When testing download throughput, use a file you manage, with a fixed size and permitted for public testing:

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

Do not use a few-dozen-byte health check page to judge CDN download speed. If the file is too small, connection, TLS, and timing errors may account for most of the result.

Common optimization directions for the download stage include:

• Reduce bytes of above-the-fold resources;

• Convert images to WebP or AVIF and output at display size;

• Enable compression suitable for the content type;

• Split and lazy-load non-critical JavaScript;

• Set long-term caching and content hashes for static resources;

• Use CDN edge caching;

• Support segmentation, Range, and reasonable bitrates for video and large files;

• Check throughput and single-connection rate limits in the target region;

• Avoid generating large files in real time through unsuitable dynamic APIs.

Four common outcomes: what to optimize first

Case 1: DNS accounts for most of the first-visit wait

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

Check DNS, CNAME, recursive resolvers, and authoritative DNS first. Even if you reduce TTFB by 50 ms, users’ first visit will still wait during resolution.

Case 2: Connection and TLS are high only in some regions

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

If anomalies are concentrated in a certain region or ISP, check CDN scheduling, node coverage, IPv4/IPv6, and routing first. The origin application may not be the main problem.

Case 3: Connection is normal, but dynamic page TTFB is very high

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

Check cache MISS, origin fetch, application, database, and third-party APIs first. At this point, changing DNS will hardly improve the main wait.

Case 4: First byte is fast, but download and rendering are slow

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

Check response size, compression, images, scripts, throughput, and frontend loading order first. Continuing to optimize TTFB by tens of milliseconds yields limited benefit.

How to calculate the stage “most worth optimizing”

You can record three dimensions for each stage:

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

For example:

This is closer to real optimization decisions than setting a fixed order based on metric names.

A practical, executable optimization order

Step 1: Define what to test

Do not compare homepage HTML, images, APIs, and large files together.

At minimum, separate them into:

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

Step 2: Distinguish cold connections from connection reuse

Observe separately:

• First resolution and new connection;

• Visit after DNS caching;

• TLS session resumption;

• HTTP/2 or HTTP/3 connection reuse;

• Browser resource cache.

Step 3: Distinguish cache HIT and MISS

The TTFB difference between CDN cache hits and origin fetch requests can be large. Test records must save cache status; otherwise, different samples cannot be directly compared.

Step 4: Cover real user regions

Do not use only the server’s location or office network.

At minimum, cover major cities, countries, ISPs, IPv4, and IPv6 according to actual user proportions.

Step 5: Look at P50, P95, and failure rate

P50 reflects the common experience, P95 is used to find long-tail problems, and failure rate is used to identify availability risks. Looking at only one fastest result is meaningless.

Step 6: Change only one major variable at a time

For example:

先修复AAAA异常
→ 重新测试

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

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

If you change DNS, CDN, certificates, and servers at the same time, it is difficult to tell which change was actually effective.

What optimization measures correspond to each of the five stages?

These measures cannot be applied mechanically. For example, when DNS time is normal, reducing one CNAME layer may not be worth the migration risk; when TTFB is mainly caused by cross-continental network round trips, simply upgrading the database may have no noticeable effect.

Five most common misjudgments

Treating all of time_appconnect as TLS time

It is usually a cumulative value from request start to TLS completion, and should be combined withtime_connectto calculate the TLS stage.

Using Ping instead of connection and website speed tests

Ping does not perform normal TCP, TLS, HTTP, and page downloads. For specific differences, seePing is fast but the website is slow? Don’t mistake latency for loading speed.

Determining priority after only one test

Network jitter, DNS caching, node switching, and origin load can all cause a single anomaly. Observe at least multiple results and P95.

Judging download speed with a small file

The total time for a few-dozen-KB file is mainly made up of connection and TTFB and cannot fully reflect sustained throughput.

Treating results from a browser with caching disabled as the real user experience

Disabling cache is useful for discovering the full request cost, but real users may use DNS caching, connection reuse, and resource caching. Test both cold and warm visits; do not keep only one.

FAQ

Should ordinary websites optimize TTFB first?

In most cases, main HTML TTFB is worth checking first because it affects subsequent resource discovery. But if DNS, connection, or TLS have large-scale anomalies, or the page’s main problem is oversized above-the-fold resources, you should not mechanically put TTFB first.

DNS is only 100 ms; does it need optimization?

Judge based on region, cache status, and overall proportion. If it only occurs once in a cold query and the total page load takes several seconds, the benefit may be limited; if every third-party domain adds 100 ms, the cumulative impact may be significant.

If TLS time is high, will switching CDNs definitely help?

Not necessarily. TLS time is also affected by network distance, packet loss, certificate chain, client proxy, TLS version, and IPv6 lines. Only when evidence points to node coverage or CDN edge performance is switching CDNs more likely to help.

Does high TTFB mean the server application is slow?

No. TTFB includes DNS, connection, TLS, network round trips, CDN cache, origin fetch, and server processing. You should first split out the preceding stages, then compare cache HIT and MISS.

If download time is high, will increasing server bandwidth solve it?

Not necessarily. If resources are cached by the CDN, the bottleneck may be edge throughput, user network, file size, or single-connection limits. Check response size, compression, cache status, and target-region bandwidth at the same time.

Why does the browser show DNS and TLS as 0?

The browser may have used DNS cache and an existing connection, or may have retrieved content from a Service Worker or resource cache. This does not mean that first visits do not need DNS and TLS.

Which is more worth looking at, P50 or P95?

Both. P50 reflects the common experience of most users, while P95 is used to find a small number of severe slow requests. Look at P50 when optimizing average experience; when troubleshooting complaints and stability, pay more attention to P95 and failure rate.

If none of the five stages are high, why is the page still slow?

The problem may lie in browser rendering, JavaScript execution, CSS blocking, fonts, third-party scripts, main-thread tasks, or resource loading order. Once network stages are normal, continue checking FCP, LCP, INP, and the browser Performance panel.