How Do You Test Website Response Time? What's a Normal Range?

When running website speed tests, many people come across the metric "response time," but once they actually get to the analysis stage, it's easy to confuse it with Ping latency, TTFB, and page load time. In reality, website response time is better suited to judging how fast a website is during the phase from receiving a visit request to starting to return content. It's affected both by server performance and by DNS, network routes, TCP connections, HTTPS handshakes, and CDN scheduling. If a website has clearly become slower to open, looking only at the final page load time often isn't enough. Breaking response time down first usually makes it easier to find exactly which part of the chain the problem lies in.

1. What does website response time mean?

Put simply, website response time is the time it takes from when a user initiates a request to when the website starts returning a response. That said, different speed testing tools don't all measure it the same way. Some tools include DNS, connection, and server processing in the calculation, while others focus more on the wait time before the server starts returning the first byte, so when actually troubleshooting, it's not advisable to look at just one total number.

A website visit roughly goes through the following stages:

• DNS resolution

• TCP connection establishment

• HTTPS/TLS handshake

• Server processing the request

• Returning the first byte

• Continued downloading of HTML, images, JS, CSS, and other resources

• Page rendering completion

Among these, Ping latency only reflects round-trip time at the network layer and can't directly represent real webpage response speed. If you want to know why a website "takes a while before content appears after you click it," you should generally pay more attention to HTTP response time and TTFB, that is, Time to First Byte. For example, if a website has a Ping of only 30ms but the server takes 800ms to process the request, it will still feel noticeably slow when actually visiting it.

2. How do you test website response time?

Testing website response time isn't complicated, and ordinary site owners can just use online speed testing tools. If you also want to break down DNS, connection, and TTFB further, combining browser developer tools or curl for analysis will be more accurate.

1. Test using an online website speed testing tool

If you want to quickly understand how a website responds across different regions and different carrier networks, you can use Chahu to run a website speed test.

After opening Chahu, enter the website address you need to test and start the check. The tool initiates requests from different regions and network environments across the country, so you don't need to manually select Telecom, Unicom, and Mobile nodes one by one.

After the test is complete, don't just look at a single fastest node. What's more worth paying attention to is:

• Whether response times across regions are close to each other

• Whether the differences between Telecom, Unicom, and Mobile are obvious

• Whether any nodes timed out

• Whether only a few regions are noticeably slower

• Whether the overall data is stable

If most nodes respond in around 100–200ms and only a few regions exceed 500ms, this situation usually can't be directly judged as insufficient server performance. It's more likely that there are differences in local routes, carrier interconnection, or CDN scheduling.

If all regions slow down at the same time, then it's more worth checking the origin server, program processing, and database.

2. Check using browser developer tools

If a website opens slowly on your own computer, you can check directly using Chrome developer tools.

After opening the target website, press F12, go to the Network panel, then refresh the page and click the topmost main document request to see the time consumed at each stage of the request process.

Common items include:

• DNS Lookup

• Initial connection

• SSL

• Waiting

• Content Download

Among these, the one more worth paying attention to is Waiting, that is, the time spent waiting for the server to return data.

If DNS, TCP connection, and SSL are all fast but Waiting is noticeably high, then the problem is usually no longer simple network latency, and more likely lies in the server program, database queries, dynamic page generation, or the CDN origin-pull stage.

Conversely, if Waiting isn't high but Initial connection is very long, then you should check the network route, packet loss, and server connection quality.

3. Use curl to check the time consumed at each stage

For operations staff or site owners with command-line experience, you can also test directly using curl.

curl -o /dev/null -s -w "DNS: %{time_namelookup}\nConnect: %{time_connect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n" https://www.example.com

After running it, you can see separately:

• time_namelookup: DNS resolution time

• time_connect: connection establishment time

• time_starttransfer: time when data starts being received from the server

• time_total: total time consumed by the entire request

The advantage of this approach is that it lets you break the visit process apart and look at it.

For example, if DNS only took 20ms and the connection took 50ms, but TTFB reaches 900ms, then you can basically determine that what's really slowing down the response isn't resolution and network connection, but backend processing or origin-pull.

3. What counts as normal website response time?

There's no absolute standard for website response time that applies to all scenarios, but under normal network conditions, you can refer to the following range.

This table can only serve as a reference and can't be applied mechanically. Website response speed itself is affected by many factors, such as server deployment location, the visitor's region, carrier network, page type, and whether a CDN is used.

For example, for a website deployed in Shanghai, the normal response range will definitely differ between a Shanghai user and a US user visiting it. Likewise, a purely static page and a dynamic page that requires real-time database queries and calls to multiple APIs can't simply be judged by exactly the same response standard. So the truly meaningful approach isn't just asking "how many milliseconds counts as normal," but looking at it in combination with the website's business and user distribution.

4. Don't mix up response time and page load time

Website response time and full webpage load time are often lumped together. Suppose a website: the server starts returning HTML at 150ms, but the page still has a large number of images, JavaScript, CSS, and third-party scripts, and loading everything takes 2.8 seconds in total. The 150ms here can be understood as the early-stage response speed, while 2.8 seconds is closer to the entire page load time. The two reflect completely different problems.

If the server response is only a little over 100 milliseconds but the full page is still slow, the optimization focus should be on images, frontend resources, and third-party scripts. If the page itself has very few resources but after visiting it you need to wait one or two seconds before the server starts returning content, then you should focus on checking the backend, database, or origin server. Therefore, when doing website speed tests, you can't just see "loading took 3 seconds" and directly conclude the server is slow. Judging which stage is slow first is more important than simply staring at the total time.

5. Why does website response time become slow?

When website response time suddenly stretches out, it's rarely caused by a single factor, and troubleshooting usually has to be worked through layer by layer. Based on daily operations and tuning experience, it mainly comes from the following areas:

1. Server compute can't keep up or code stalls

When CPU usage keeps spiking, memory is tight, or the backend application logic becomes blocked, requests can only queue up once they reach the server.

• Typical scenarios: WordPress with a pile of plugins installed, PHP processes maxed out, a Java API locked up, or slow SQL in the database without indexes.

• Performance characteristics: Network Ping values and connection establishment are all normal, but the HTTP response header (TTFB) takes a long time to come out.

2. Physical distance and cross-network link latency

Data transmission is limited by physical limits. If the origin server is deployed overseas (such as the US West) while the main traffic comes from within the country, even if the server configuration is top-tier, just the cross-border RTT (round-trip time) will introduce a noise floor of over a hundred milliseconds.

• Compounding effects: Congestion on international egress bandwidth, detours at carrier interconnection nodes, and so on.

• Performance characteristics: Testing from the same data center as the server is extremely fast, but users in other locations or on specific carriers report obvious lag.

3. DNS resolution stuck at the first step

A browser must look up the IP before establishing a connection. If the DNS authoritative server responds slowly, the route resolution configuration is improper, or the TTL setting is unreasonable and causes frequent cross-region recursive queries, domain resolution alone can swallow hundreds of milliseconds.

• Troubleshooting suggestion: Prioritize using dig or network diagnostic tools to separately measure the time consumed at the DNS stage, to avoid blindly refactoring backend code.

4. Excessive TCP and TLS handshake overhead

After getting the IP, the client needs to perform the TCP three-way handshake; if it's an HTTPS website, a TLS handshake is layered on top as well.

• Where the bottleneck is: Once there's packet loss, high latency, or route detours on the intermediate link, the time consumed by TCP retransmission and TLS key exchange gets multiplied.

• Performance characteristics: The server's own CPU is very idle, but the client spends an extremely long time on connection establishment (Connect Time).

5. Low CDN hit rate or abnormal origin-pull

After integrating a CDN, requests first land on edge nodes. If a node doesn't have a cache (Miss), it needs to pull data from the origin server.

• Common pitfalls:

  • Poor origin-pull link: Network fluctuations between the edge node and the origin server, or the origin server itself responding slowly, causing overall time consumption to stack up.

  • Node scheduling errors: For example, users in South China are incorrectly scheduled by DNS to nodes in North China or even overseas, causing abnormal access latency in a local area.​

6. How do you determine which segment is slow?

The purpose of testing website response time isn't to get a number, but to use that number to further narrow down the scope of the problem.

During actual troubleshooting, you can judge according to the following logic.

Ping is very high

If even Ping latency is noticeably high, check the network route first.

More common causes include:

• The user is too far from the server

• Cross-carrier access

• Cross-border networks

• Route detours

• Network congestion

In this situation, optimizing the server program first usually doesn't mean much.

Ping is normal, but the TCP connection is very slow

If the underlying network latency isn't high, but establishing a TCP connection takes a long time, focus on checking:

• Whether there is packet loss

• Whether the network path is stable

• Whether a firewall is affecting the connection

• Whether the server's connection count is too high

• Whether a CDN node is behaving abnormally

TCP is fine, but TTFB is very high

This is a fairly typical backend problem.

The connection to the server is fast, but after connecting, data doesn't come back for a long time. This usually means the server is waiting on some processing step.

Key areas to look at: the backend application; the database; APIs; caching; origin server performance; CDN origin fetch

TTFB is fine, but the page is still slow

In this case, the problem is generally no longer the response time itself.

If the server returns the HTML quickly, but the full page still takes several seconds to open, keep checking: whether image files are too large; whether there is too much JS; whether CSS is blocking; whether third-party analytics scripts are slow; whether font files are too large; whether caching is enabled for static assets, and so on. This is also why, when testing website speed, it's best to judge response time and page load time separately.

7. How should you optimize a slow website response time?

Once you've identified which stage is slow, the optimization direction actually becomes much clearer:

• If server processing is slow, check program execution efficiency, database queries, and server CPU and memory resources;

• If users are too far from the server, consider adjusting the server deployment location, or use a CDN to shorten the distance between users and access nodes;

• If DNS resolution is slow, check whether the current DNS service and resolution routes are reasonable;

• If TCP or TLS connection establishment is slow, focus more on network routes, packet loss, server connection capacity, and HTTPS configuration;

• If only certain regions or a specific ISP are slow, focus on checking CDN scheduling, node quality, and ISP interconnection;

• If TTFB is already normal but the page still loads slowly in the end, shift your optimization focus to images, JavaScript, CSS, and third-party resources.

The biggest risk in website performance optimization is choosing the wrong direction. The server is already processing quickly, yet you keep upgrading the specs; the real problem is the cross-border route, and that kind of optimization usually won't produce noticeable results.

Conclusion

There is no fixed website response time standard that applies to every website. Under normal network conditions, 100–200ms is generally considered a fairly ideal response speed; once it exceeds 500ms, you can start paying attention, and if it stays above 1 second for a long time, it's worth investigating further.

But more important than the number itself is figuring out where the time is actually going. If Ping is high, look at the route first; if the connection is normal but TTFB is high, check the server and backend; if TTFB is very low but the page still loads slowly, focus on frontend resources such as images, JS, and CSS.

When testing website speed, don't rely only on a single result from your own location. Compare data from different regions, different ISPs, and different time periods together to more accurately determine whether the website is truly slow, or whether the problem only occurs on one particular network or in one particular region.

Related Q&A

1. Response time suddenly spikes, but the server CPU and memory are normal. Where should I look?

First check whether the database has slow queries, then check whether third-party interfaces are timing out. Abnormal DNS resolution, CDN origin fetch jitter, or even one external API getting stuck can all drive response time up. The server itself being fine doesn't mean the entire chain is fine.

2. Is there really a relationship between website response time and Google SEO rankings?

There is a relationship, but it's not a direct ranking factor. Google mainly looks at Core Web Vitals, and TTFB is one part of that. A response that's too slow affects crawl budget and also makes users impatient. It affects rankings indirectly, but don't expect that simply pushing response time down to 100ms will get you to the front page.

3. How often is it appropriate to test response time?

For normal times, a spot check once a week to establish a baseline is enough. After major sales, redesigns, or server changes, test more frequently. If problems appear, add temporary tests. Don't test every minute for no reason—it wastes resources and can easily be treated by the server as an attack.

4. The first visit is slow, but the second is fast. Does that count as a response time issue?

It counts, but you need to look at it separately. The first visit requires DNS resolution, connection establishment, and a TLS handshake, and may also have no cache. The second visit reuses many of those steps. When testing, you need to distinguish cold starts from warm requests. Don't mix the two results together, or your optimization direction can easily go off track.

5. If a 502 or 504 appears during testing, is that a response time issue or a server issue?

It's a server or gateway issue. A 504 is a gateway timeout, meaning the backend did not return within the specified time. In that case, check the backend and timeout configuration first, and don't stare at the response time number. A 502 is mostly the gateway being unable to connect to the backend, which has nothing to do with how fast or slow the response is.