How to Read Website Speed Test Results: Response Time, Connection Time, and Download Time Explained

Running a website speed test isn't complicated. What actually confuses people is usually the row of numbers that appears after the test finishes. For the same website, one node might resolve DNS in a very short time, another node might be noticeably slow during the connection phase, and yet another might look perfectly normal until it gets stuck on download. Staring only at a single "total response time" makes it very hard to tell whether the problem lies in domain resolution, network routing, the server, or content delivery.

So when reading website speed test results, the point isn't simply to compare which number is bigger or smaller, but to figure out which step the time is being spent on. This article approaches it from a site owner's practical troubleshooting perspective, explaining DNS, connection time, response time, download time, and total response time one by one, and analyzing what to check next based on common speed test results.

1. What Is a Website Speed Test Actually Measuring?

When a browser visits a website, it doesn't just download the page directly from the server after you type in the URL. A normal website request roughly goes through this process:

Enter website address → DNS resolution → Establish TCP/QUIC connection → TLS handshake for HTTPS sites → Send HTTP request → Server processing → Return data → Download content

If you look further into the full page loading stage, after the HTML is returned, the browser still needs to load CSS, JavaScript, images, fonts, and other resources before the page can finish rendering.

What we usually see as "the website took a few seconds to open" is actually the combined result of multiple stages stacked together.

If DNS resolution itself is slow, the browser hasn't even started connecting to the server yet, and time has already been wasted upfront. If DNS and the network are both fine, but the server is slow at processing dynamic pages, users still have to wait. If the server returns content quickly but the download phase takes a long time, then attention should shift to file size, bandwidth, and transmission routing.

Chahu's current website speed test results display DNS, connection, download, and total response time separately. These metrics are exactly what you need to break down the different stages of a single website request.

For a quick understanding, here's a table to keep in mind:

Different website speed test tools may define "response time" differently: some platforms call the time needed to complete a single HTTP request "response time," some provide TTFB (Time to First Byte) separately, and others offer fields like DNS, Connect, Download, and Total. So when reading a speed test report, it's not advisable to interpret "response time" on every platform as TTFB. If a tool provides TTFB separately, it's better suited for observing how long it takes from the start of the request to receiving the first byte.

2. How to Read DNS Resolution Time

After a user types www.example.com, the browser first needs to know which IP address this domain corresponds to. This step is DNS resolution.

The DNS time in the speed test results reflects how long this process took.

If the DNS stage is noticeably higher than other nodes, the problem usually hasn't reached the server processing stage yet, because at this point the client hasn't even truly connected to the website server.

What Does High DNS Time Usually Indicate?

Common causes include slow DNS service response, long resolution path distance, abnormal recursive DNS status in certain regions, or differences in DNS scheduling results across regions when using a CDN.

However, a single node occasionally showing high DNS time doesn't immediately mean there's a problem with the DNS service.

DNS itself has caching, and different test nodes may use different recursive DNS servers. So rather than fixating on one node, it's better to observe multiple regions horizontally.

For example:

If the vast majority of nodes are in a similar range and only one node is noticeably higher, you can continue testing first to see if it's temporary network fluctuation. But if a certain region or ISP is consistently high over the long term, it's worth further checking DNS routing and resolution strategy.

Why Is DNS Fast in Some Regions but Slow in Others?

After a website uses public DNS, intelligent DNS, or a CDN, users in different regions may actually experience different resolution paths. For example, Shanghai Telecom and Guangzhou Mobile use different recursive DNS servers, and the network paths to authoritative DNS servers are also different, so some variation in resolution time is normal. What's truly worth paying attention to is persistent, concentrated abnormalities. If multiple Mobile regions have DNS noticeably slower than Telecom and Unicom, then when troubleshooting, you shouldn't just look at one node—you should check whether the problem is concentrated on the Mobile network.

What to Check First When DNS Is Abnormal?

First, confirm whether the domain can stably resolve to the expected IP, then compare whether there are obvious differences in resolution results across regions. If the website uses a CDN, also pay attention to whether different regions are being scheduled to reasonable nodes. If it should be accessing a domestic or nearby node but is being resolved to a server far away, the subsequent connection and access times will usually be stretched out as well. DNS time can't be viewed in complete isolation—it can also affect the connection results that follow.

3. How to Read Connection Time

After DNS finds the IP, the client still needs to establish a network connection with the target server. Traditional HTTP/1.1 and HTTP/2 typically require establishing a TCP connection, while HTTP/3 uses QUIC. For HTTPS websites, the connection also involves a TLS handshake and certificate negotiation.

So connection time more closely reflects: whether the test node can quickly and stably establish communication with the website server.

What Mainly Affects Connection Time?

Network distance is a fairly direct factor. The same server located in Hong Kong would naturally have different connection times for users in Shenzhen versus users in the United States. Beyond that, ISP interconnection, routing quality, network packet loss, and server-side connection handling also affect the final result.

So if you find: DNS is fast, but connection time is noticeably high

Then the problem shouldn't remain focused on DNS—it should be investigated in the direction of network routing.

Is It Normal for Ping to Be Fast but Connection Time to Be High?

Ping tests mainly reflect the basic network latency of ICMP packet round trips, while actually visiting a website requires establishing TCP, QUIC, or TLS connections. These two are not testing the same thing.

For example, a Ping of only 30ms doesn't guarantee that HTTP connection establishment will also be in the tens of milliseconds. If there's packet loss, retransmission, or abnormalities during the connection phase, you might see a situation where "Ping looks great, but the website connection is noticeably slow." Chahu's documentation on Ping and HTTP website speed tests also distinguishes between these two types of tests.

This is also why, when a website is slow, it's not advisable to only look at Ping.

Normal Ping can only rule out some basic network issues—it can't directly prove that the entire website access path is functioning properly.

How to Determine If Only Some ISPs Have Slow Connections?

Suppose the test results are:

DNS performance is similar, but the Mobile node suddenly becomes noticeably slower at the connection stage.

At this point, the problem looks more like: there are differences in the network routing between the test node and the server.

You can continue comparing other Mobile nodes. If multiple Mobile regions show similar behavior, you should prioritize checking the data center's Mobile routing, cross-network access, or the CDN's node scheduling for Mobile users—rather than changing DNS first.

4. How to Read Response Time: Slow Response Isn't Necessarily a Routing Problem

In many website speed test reports, "how long the server waited before starting to return data" is an important reference for judging backend performance. If the tool provides TTFB, this metric is especially worth paying attention to.

TTFB refers to the time between the client sending the request and receiving the first byte from the server. It's not just "server application execution time"—it also includes factors like establishing the connection, sending the request, and network round trips.

So to judge whether the server is slow, it's best to look at DNS, connection, and basic network status together.

Suppose:

Ping: 30ms
DNS: 25ms
Connection: 40ms
But the server takes a long time to start returning content

At this point, the basic network itself isn't showing particularly serious problems, so the troubleshooting focus can gradually shift toward the server.

1. Slow Backend Application Processing

WordPress, PHP, Java, Node.js, or other dynamic applications all need to execute code when generating pages.

If the server CPU is under long-term high load, PHP Workers are insufficient, or the application code is inefficient, the request may have already reached the server but the page takes a long time to return.

2. Slow Database Queries

Many dynamic websites' homepages, product pages, and search pages need to read from the database.

A single slow query might only add a few hundred milliseconds, but if a page needs to execute dozens of queries in sequence, the final wait time gets significantly amplified.

So when the network is fine but dynamic pages respond noticeably slowly, the database is well worth checking.

3. Long CDN Origin Pull Time

Using a CDN doesn't mean every request is returned directly from the edge node.

If the request doesn't hit the cache, the CDN still needs to pull from the origin to get the content.

Long distance from the edge node to the origin, slow origin processing, or poor origin pull routing quality can all cause MISS requests to be noticeably slower than cache-hit requests.

4. Third-Party APIs Slowing Down Requests

Some websites also synchronously request payment, inventory, membership, advertising, or other APIs when generating pages.

As long as one of these APIs responds slowly, the entire page's backend processing can be held up.

So "slow server response" doesn't necessarily mean you must upgrade CPU and memory—the real problem might also exist in the application, database, cache, or external APIs.

5. How to Read Download Time

After the server starts returning data, the content still needs to be actually transferred to the client.

This stage corresponds to download.

If the earlier DNS, connection, and even server response are all fairly normal, but the download stage takes up most of the time, then the troubleshooting direction should usually shift from "when does the server start returning" to "why is the content transferring so slowly."

For example:

DNS: 20ms
Connection: 35ms
Earlier request process is normal
Download: 1.8s

At this point, continuing to optimize DNS doesn't make much sense.

1. The Returned Content Itself Is Large

If the test target is a large HTML file, image, installation package, or other file, download time will naturally increase.

So when comparing download times, it's best to confirm the test target is the same.

There's no meaningful comparison between the download time of a 20 KB page and a 5 MB file.

2. Insufficient Available Network Bandwidth

Network latency and network bandwidth are two different things.

A route with low Ping doesn't necessarily mean it's fast when transferring large amounts of data.

You might also see: connection establishes quickly, but the actual file download speed isn't ideal.

3. Cross-Region or Cross-Border Routing Impact

If the server and test node are far apart, or the path goes through unstable international or cross-border networks, actual transmission efficiency will be affected.

This situation is especially worth noting when overseas servers serve domestic users, or domestic servers serve overseas users.

4. Different CDN Nodes and Cache States

After using a CDN, different regions may access different edge nodes.

One node may have already cached the current content and can return it directly; another node needs to pull from origin, so the final time may naturally differ.

So when a CDN-enabled website shows regional speed test differences, besides looking at the server, you should also consider node scheduling and cache status together.

There's also a concept that needs special clarification here: "download time" in a website speed test doesn't necessarily equal the browser's full page load time.

After a single HTTP request download completes, the browser may still need to load a large number of CSS, JavaScript, images, fonts, and third-party resources.

So if the DNS, connection, and download in the speed test report are all normal but the actual page still opens slowly, you need to further check the frontend loading process rather than continuing to stare at this one download time metric.

6. How Should You Read Total Response Time? Don't Just Look at One Number

Total response time is the most intuitive, and also the most easily misinterpreted.

After a speed test finishes, many people's first glance is only:

0.8 seconds, should be pretty fast.
3 seconds, the website is too slow.

The problem is that the same total time can have completely different underlying causes.

For example, two nodes both end up at 1 second:

Node A:

DNS and connection are fast, but server processing took a long time.

Node B:

The server responded almost immediately, but the download stage took a long time.

The final total time displayed might be similar, but the optimization approaches are completely different.

The former should investigate the server, application, database, and cache; the latter should check content size, bandwidth, and transmission routing.

So total response time is good for quickly spotting "which node is clearly abnormal," but to truly pinpoint the problem, you still need to break it down further.

A practical approach is:

First find abnormal nodes horizontally, then look vertically at which stage the abnormal time is spent on.

For example, if most nodes nationwide are around 500ms and only Guangzhou Mobile reaches 2 seconds, then first open the detailed results for Guangzhou Mobile to see whether it's DNS, connection, or download that's high.

This is much more accurate than seeing "2 seconds" and immediately concluding the server is slow.

7. How to Read Chahu Website Speed Test Results

If you want to observe website access conditions from different regions and ISPs within China, you can directly use Chahu website speed test.

Currently, Chahu's website speed test can show DNS, connection, download, and total response time, and can observe website access performance from different probe nodes.

When actually reading the results, it's not advisable to fixate on a single millisecond number right away. You can follow the order below.

Step 1: Enter the Website Address to Test

After entering the website speed test, enter the full URL, for example:

https://www.example.com/

Then start the test.

Step 2: First Check Whether There Are Obvious Abnormalities Nationwide

After the test completes, don't start by studying whether DNS is 20ms or 30ms.

First observe the overall picture:

Whether Telecom, Unicom, and Mobile can all access normally, whether there are particularly prominent slow nodes between different regions, and whether there are timeouts or request failures.

If nationwide results are all fairly close, it means the problem is most likely not unique to a particular region.

If only a few nodes are particularly slow, then focus on those abnormal nodes going forward.

Step 3: Determine Whether It's Concentrated on a Particular ISP

For example:

Telecom nodes are generally normal, Unicom is also normal, but multiple Mobile nodes are consistently slow.

This kind of result is more valuable than "one node in Guangzhou is slow," because it indicates the problem may have obvious ISP characteristics.

At this point, you should continue checking Mobile routing, cross-network access, or CDN node scheduling.

Step 4: Break Down DNS, Connection, Download, and Total Response Time

After identifying abnormal nodes, observe which segment the time is concentrated in.

High DNS—check resolution first.

High connection—prioritize looking at the network and routing.

Earlier stages normal but server takes a long time to return—continue investigating the origin and backend.

Earlier stages normal, high download—focus on checking transmission and content size.

Only then does a single speed test truly serve its purpose of pinpointing issues.

8. What Do Several Common Speed Test Results Indicate?

In actual website maintenance, the following situations are fairly common:

1. DNS is slow, but the subsequent connection and download are normal

This result indicates that the real time waster is the domain resolution stage at the very beginning of the visit. Once resolution is complete, the subsequent server connection and content transfer show no obvious abnormalities. In this case, you should first check the DNS service, resolution performance across different regions, and the CDN's DNS scheduling—rather than prioritizing a server configuration upgrade.

2. DNS is normal, but connection time is high

DNS can quickly return the correct IP, but the test node and server take a long time to establish a stable connection. The problem is more likely concentrated in network routing, cross-ISP interconnection, network packet loss, the data center's routing where the server is located, or CDN nodes. If only a particular ISP has this issue long-term, the priority for investigating that ISP's routing would be higher.

3. Connection is fast, but the server takes a long time to respond

This situation usually indicates that the request can reach the server fairly smoothly, but the server takes a long time to process and return data. You can continue checking server load, backend applications, slow database queries, cache hit rates, and CDN origin pulls. At this point, you shouldn't just keep circling around network routing.

4. Everything earlier is fast, but download time is long

In this case, DNS, connection establishment, and even the start of content return all show no obvious problems. The time is mainly spent on content transfer. You can continue to confirm the test target size, server outbound bandwidth, cross-region routing, and CDN node status. If testing a large resource, download time should naturally be considered in relation to file size.

5. Only Mobile is slow; Telecom and Unicom are normal

If it's not just one node but multiple Mobile regions showing slow performance, then this result already has fairly obvious ISP characteristics. The troubleshooting focus should be on Mobile routing, cross-network interconnection, data center networking, and CDN scheduling for Mobile users. Conversely, if only Unicom is abnormal, then study Unicom-related paths first rather than assuming the entire website is slow.

6. All nodes are slow

If multiple regions and multiple ISPs nationwide all show similar high latency, the problem doesn't look like a single-region routing failure. At this point, you can further compare which stage the time is concentrated in. If everyone has slow connections, check the server network and data center routing. If connections are all normal but backend responses are generally slow, then the server, application, and database are worth prioritizing. If downloads are generally slow, continue checking bandwidth and content transfer. "Slow nationwide" only narrows the scope—it doesn't directly equal "insufficient server configuration."

7. Some regions time out directly

Timeouts are more noteworthy than simply slow responses. If only individual nodes occasionally time out, you can repeat the test first to rule out temporary network fluctuations and single-node abnormalities. If the same region or same ISP repeatedly times out, you need to continue checking regional routing, server firewalls, access controls, CDN nodes, and related network paths.

9. The Correct Troubleshooting Order for Reading Website Speed Test Results

Website speed test reports contain a lot of data, but in actual troubleshooting you don't need to look at every item in no particular order.

You can follow this route:

First check whether the website can be accessed normally

↓

Check whether only some regions are abnormal

↓

Then check whether the abnormality is concentrated on a particular ISP

↓

Check DNS resolution time

↓

Check connection time

↓

Determine whether the server is too slow to start returning content

↓

Check download time

↓

No obvious abnormalities in the network request stage

↓

Continue checking images, JavaScript, CSS, and page rendering

This order narrows the scope with each step: if you discover from the start that only the Mobile network is abnormal, there's no need to compress homepage images first. If all network requests nationwide are normal but the page actually displays slowly, there's also no need to keep switching DNS for testing. Find which layer is slow first, then address the problem at that layer—troubleshooting efficiency will be much higher.

Conclusion

When actually troubleshooting website speed, I generally don't start by agonizing over whether a particular number counts as "standard." Instead, I first look at whether the abnormality has a pattern: is it slow nationwide, or only in some regions? Is a particular ISP noticeably higher, or is one specific stage among DNS, connection, and download particularly prominent? Once these questions are clarified, the subsequent troubleshooting direction usually won't go off track. Reading website speed test results doesn't require studying every metric in great complexity. Find the abnormality first, then determine which segment it's concentrated in, and finally address the corresponding part—this is often more meaningful than running the test a dozen times.

Related Q&A

1. What DNS time in milliseconds is considered acceptable?

For domestic nodes accessing domestic servers, keeping DNS resolution time within 20ms to 50ms is a fairly ideal state. For cross-border or international access, DNS time within 100ms is also considered normal. If DNS resolution in a specific region consistently exceeds 200ms over the long term, it usually means the recursive DNS in that region has cache failures, is experiencing DNS pollution, or the CDN's intelligent resolution strategy is assigning to an unreasonable authoritative server.

2. Server CPU and memory usage are both low, so why is response time (TTFB) still slow?

Sufficient hardware resources don't mean the application executes efficiently. Slow response could be due to slow queries caused by missing database indexes, synchronous blocking third-party external API calls in the application code, PHP-FPM/Nginx concurrent process pool configuration being too small, or the database connection pool being full and waiting for release. When troubleshooting, it's recommended to enable Slow Log and APM tracing to directly locate the bottleneck code segment.

3. All network metrics in the speed test report look great (small green numbers), but users still report slow page loading?

Speed test tools typically only initiate tests against a single document (such as the HTML homepage) by default. If the first HTTP request responds quickly, but the page itself references dozens of uncompressed large images, several-megabyte unbundled JavaScript files, or loads inaccessible third-party tracking scripts, the browser will get stuck during the rendering stage. This situation is a frontend loading and rendering performance issue, and needs to be investigated using Chrome DevTools' Network panel or PageSpeed Insights to examine the Waterfall.

4. Mobile network (China Mobile) speed test results are generally slower than Telecom and Unicom. How is this usually solved?

Due to historical network topology and cross-network interconnection node limitations, Mobile networks tend to experience higher latency and packet loss when accessing non-Mobile dual-line data centers. There are two main solutions: first, migrate the website origin to a high-quality data center with three-network direct connection (BGP) routing; second, use a CDN provider that covers independent Mobile nodes, ensuring Mobile users' DNS requests are precisely scheduled to Mobile dedicated line nodes, avoiding cross-network transmission.

5. After enabling HTTPS encryption, connection time has noticeably increased. How should this be optimized?

TLS handshake introduces additional network round-trip time (RTT). Optimizing TLS handshake performance can be approached from several aspects: enabling HTTP/2 or HTTP/3 (QUIC) protocols on the server side; enabling TLS Session Resumption and Session Tickets; configuring OCSP Stapling to avoid clients needing to verify status with the certificate authority in real time; and using SSL certificates that support ECC algorithms instead of traditional RSA certificates to reduce computational overhead.