How to Test Website Speed? Website Loading Speed Test and Result Analysis

A slow-loading website is often troublesome not because it's hard to confirm it's slow, but because it's hard to know where to start investigating. Changing servers, compressing images, tweaking CDN, or modifying DNS can all be effective, but only if you first identify the right problem. If the issue is actually an anomaly with a specific ISP's routing, spending hours optimizing front-end code won't yield noticeable improvements. Conversely, if the server responds fine but the real bottleneck is above-the-fold resources, adjusting network routes won't help either.

So before diving into optimization, it's more important to accurately measure your website's loading speed. Below, we'll follow a practical troubleshooting sequence, starting with multi-node speed tests, then examining response time, TTFB, and page load performance to determine whether the slowness lies in the network, server, or front-end resources.

1. What Exactly Are We Testing When We Test Website Speed?

When we casually say "this website opens in 1 second" or "this page takes 5 seconds to load," we're actually describing the combined result of multiple stages. A complete website visit roughly goes through the following process:

Enter website URL
      ↓
DNS resolution
      ↓
Establish TCP/QUIC connection
      ↓
TLS handshake
      ↓
Send HTTP request
      ↓
Server processes request
      ↓
Return first byte (TTFB)
      ↓
Download HTML
      ↓
Load CSS / JavaScript / images / fonts
      ↓
Browser renders page
      ↓
Main content displayed

If any step is slow, it extends the user's actual waiting time. For example, if DNS resolution takes 800ms, the browser waits nearly a second before even connecting to the server. If DNS and network are fine but the server takes 2 seconds to process a dynamic page, TTFB will be noticeably high. If the server returns HTML in 200ms but the above-the-fold includes an uncompressed 5MB image, users may still wait a long time to see the main content.

That's why when testing website speed, you shouldn't just ask "how many seconds did it take?" but also examine: Where exactly were those seconds spent?

2. How to Test Website Speed?

In practice, I don't rely on just one tool. Different tools offer different perspectives: some are better for checking network routes, others for page rendering, and others for pinpointing which specific resource is slowing down the page.

1. Start with Chahu for Multi-Node Website Speed Test

If you simply open the website from your own computer, you get a very localized result.

For example, if you're in Shanghai using China Telecom broadband and the site loads quickly, that only indicates good access from Shanghai Telecom to that website. It doesn't tell you whether users on Beijing Unicom, Guangzhou Mobile, or overseas users experience the same speed. A local browser test can't reveal that.

In such cases, it's better to run a multi-node speed test first.

Chahu's website speed test lets you simply enter a URL and initiate tests from various nodes across China Telecom, China Unicom, China Mobile, as well as Hong Kong, Macau, Taiwan, and overseas locations. The probe network covers multiple countries and regions, making it ideal for observing access differences to the same website across different network environments.

When testing, enter the full website address, for example:

https://www.example.com/

After starting the test, don't just look at the fastest node; compare results across different regions and ISPs horizontally.

Suppose the results are roughly:

If results from major regions are similar, it generally indicates no significant routing anomalies overall.

But if the results look like this:

In this case, you can't simply conclude "the server is slow."

Since other routes are normal and only Guangzhou Mobile is significantly higher, you should investigate the local Mobile routing, cross-ISP interconnection, DNS resolution results, or CDN node scheduling.

This is why multi-node speed tests are more valuable than "just opening it yourself": they help you first determine whether the problem is network-wide or isolated to specific regions and ISPs.

2. Then Use PageSpeed Insights to Assess Actual Page Load Experience

Multi-node speed tests answer "Is this website fast to access from different locations?" But to understand how the page itself loads, you need to examine page performance.

At this point, you can use Google PageSpeed Insights.

It focuses on a different aspect than Chahu.

Chahu is better for observing access routes and response differences across regions and ISPs; PageSpeed Insights leans more toward the webpage itself, especially user experience metrics like LCP, INP, and CLS.

For example, if the website isn't slow from anywhere in the country, but PageSpeed Insights shows a high LCP, the problem likely isn't the network route but rather above-the-fold images, CSS, JavaScript, or front-end rendering.

Conversely, if the page is lightweight and PageSpeed Insights performs well, but a specific ISP's actual access speed remains slow, you should shift your focus back to network routing, DNS, or CDN.

Combining both types of tools is more effective for identifying the real issue than relying on a single "performance score."

3. Use Chrome Network to Further Pinpoint Specific Requests

If previous tests confirm that the webpage itself has loading issues, you can proceed to open Chrome Developer Tools.

Press F12 on the webpage, go to the Network tab, and then refresh the page.

Here you can see every request made during page load, including HTML, CSS, JavaScript, images, fonts, APIs, and third-party resources.

For example, if the homepage takes 4 seconds to fully load, you might find that the server returns HTML in just 300ms, but a certain banner image takes 2 seconds to load. Or you might discover that a third-party analytics script is hanging and blocking subsequent resources.

So these three testing methods can be summarized as:

Multi-node speed tests first determine "where it's slow," page performance tests determine "which stage is slow," and Network further identifies "which specific request is slow."

3. How to Interpret Website Loading Speed Test Results?

Once you have a speed test report, the real focus shouldn't be on an isolated "total time." DNS, network latency, TTFB, and page rendering represent completely different issues. If you lump them together, you might end up upgrading server specs when the server is fine, or optimizing images when the problem is actually the network route.

Here's how to understand some common metrics:

One metric that's often misunderstood is TTFB: TTFB stands for Time to First Byte, which is the time from when the browser sends a request to when it receives the first byte from the server.

If the website's base network latency is only a few tens of milliseconds, but TTFB reaches one or two seconds, it usually means the delay isn't on the network route but rather the server is slow to return content after receiving the request.

Common causes include slow backend processing (PHP, Java, Node.js), long database queries, high server load, pages that need to call third-party APIs, or slow origin fetch after a CDN MISS.

Google's web.dev provides a rough reference: TTFB under 0.8 seconds is considered good, 0.8–1.8 seconds needs improvement, and above 1.8 seconds is slow. However, TTFB is not a Core Web Vital, so it shouldn't be evaluated in isolation from how the website generates its content.

4. What Is a Normal Website Loading Speed?

How many seconds should a website take to open to be considered normal? This question is hard to answer with a single universal number. A corporate website with only text and a few small images shouldn't be held to the same "full load time" standard as an e-commerce page with numerous product images, videos, and third-party marketing scripts.

Instead of obsessing over whether a page should fully load in 1 or 2 seconds, focus on the stages that users actually perceive.

Google's current Core Web Vitals mainly include LCP, INP, and CLS.

Among them, LCP measures when the main content is displayed, with a recommended threshold of under 2.5 seconds; INP reflects the page's responsiveness to interactions, recommended to be under 200ms; CLS measures unexpected layout shifts, with a good score being 0.1 or less. Google also considers the 75th percentile when evaluating real user experience data.

For everyday website speed troubleshooting, you can simplify it as:

TTFB shows how quickly the server starts returning content, LCP shows how quickly users see the main content, INP shows whether the page feels responsive to clicks, and CLS shows whether the page jumps around during loading.

Compared to chasing a single "total load time," these metrics are more likely to tell you where your website actually needs optimization.

5. After Testing, How to Determine Where the Problem Lies?

The real value of speed testing is narrowing down the problem based on different results.

Even if the symptom is the same—"website is slow"—the underlying causes can be completely different.

1. Slow from All Regions

If Chahu multi-node tests show that responses from different regions and ISPs (Telecom, Unicom, Mobile) are all noticeably slow, and TTFB is consistently high, you should first check the origin server.

For example:

Shanghai Telecom TTFB: 1.8s
Beijing Unicom TTFB: 2.1s
Guangzhou Mobile TTFB: 2.0s
Chengdu Telecom TTFB: 1.9s

If all routes perform similarly, it's unlikely that a single ISP is at fault.

In this case, focus on the web server, backend application, database, server CPU and memory usage, disk I/O, origin bandwidth, and CDN origin fetch.

2. Only Certain Regions or ISPs Are Noticeably Slow

If Telecom and Unicom are normal but Mobile access is particularly slow, the problem is more likely related to routing.

For example:

Telecom: normal
Unicom: normal
Mobile: noticeably slow

In this case, check which IPs different ISPs resolve to, whether the CDN is directing to the correct nodes, and whether cross-network routing is taking unnecessary detours.

Chahu's multi-node tests are ideal for observing such regional and ISP differences.

Don't immediately upgrade your server just because the website is slow; server performance issues typically don't affect only one specific ISP.

3. TTFB Is Fast, but the Page Is Still Slow

Suppose the results are:

TTFB: 240ms
LCP: 4.6s

The server starts returning the page quickly, but users have to wait four or five seconds to see the main content.

In this case, the server is usually not the first thing to investigate.

Instead, open Network and PageSpeed Insights to check whether above-the-fold images are too large, CSS is blocking rendering, JavaScript execution is too long, fonts load slowly, or third-party ads, analytics, and support scripts are affecting page rendering.

Especially for image-heavy homepages, it's common to see "server fast, page slow."

4. Fast on Desktop, Noticeably Slow on Mobile

This situation can't be simply attributed to "poor phone performance."

Mobile devices might be on 4G, 5G, or unstable Wi-Fi, making network conditions more complex. Additionally, if the page loads many desktop-sized images and JavaScript, low-performance phones will take longer to parse and execute them.

So when mobile is slow, besides checking the network route, you should also examine responsive images, above-the-fold resources, JavaScript execution time, and third-party scripts.

5. First Visit Is Slow, but Refresh Is Much Faster

If the same page takes 3 seconds on the first visit but only 1 second on the second, caching is likely involved.

On the first visit, the browser may need to perform DNS lookup, establish a new connection, complete TLS handshake, and download all static resources like images, CSS, and JavaScript.

On the second visit, some DNS, connections, and static resources can be reused or read from cache, so the speed naturally improves.

If you use a CDN, also consider that on the first request, the edge node may not have cached the content and needs to fetch from origin, while subsequent requests hit the edge cache directly.

Therefore, when testing website speed, don't conclude after just one refresh. It's worth observing both cold start and cache-hit speeds separately.

6. Complete Website Speed Testing and Troubleshooting Process

If you just want to quickly determine why a website is slow, there's no need to dive into dozens of performance metrics from the start.

In practice, you can follow this sequence:

Notice website is slow
        ↓
Use Chahu for multi-node website speed test
        ↓
Determine if only certain regions / ISPs are abnormal
        ↓
Check DNS, network latency, connection, and response
        ↓
If routing is normal but page is still slow
        ↓
Use PageSpeed Insights
        ↓
Check LCP, INP, CLS and other page metrics
        ↓
If further pinpointing is needed
        ↓
Open Chrome Network
        ↓
Inspect specific HTML / CSS / JS / image / API requests
        ↓
Finally determine if it's a
network / DNS / CDN / server / front-end resource issue
        ↓
Optimize the actual bottleneck

This sequence narrows down the problem scope step by step, rather than immediately compressing images, changing servers, or adjusting CDN when you see a slow page. For example, if multi-node tests already show that only one ISP is abnormal, there's no need to spend hours optimizing JavaScript. Conversely, if nationwide routing is fine and TTFB is only 200–300ms, but LCP exceeds 4 seconds, continuing to tweak network routes is pointless. The biggest fear in website performance troubleshooting isn't too many metrics, but optimizing in the wrong direction.

Conclusion

The real value of website speed testing isn't getting a number like "this page opens in X seconds," but knowing where those seconds are actually consumed. Multi-node speed tests help identify significant routing differences between regions and ISPs; DNS, Ping, and TTFB further narrow down network and server issues; while LCP, INP, CLS, and browser Network are better suited for analyzing actual page loading and interaction experience.

If your website has recently become noticeably slower, start by running a multi-node test with Chahu from different regions and ISPs to determine whether the problem is network-wide or concentrated on certain routes. If there's no obvious network anomaly, then proceed to PageSpeed Insights and browser requests. Separately examining the network, server, and page layers is often more effective than repeatedly refreshing the page or immediately upgrading your server.

FAQ

Q1: Why does the website feel fast when I open it on my computer, but users keep reporting slow loading?

This is because local testing has limitations. When you access locally, you might be in a region with good network nodes, and your browser may have cached the page's CSS, JS, and images. In contrast, network environments, ISPs (like Telecom, Unicom, Mobile), and user device performance vary greatly across regions. We recommend using Chahu's multi-node speed test tool to check first-visit times from different routes nationwide or globally to replicate real user loading experiences.

Q2: What is TTFB? What is a normal value?

TTFB (Time to First Byte) is the time from when the browser sends a request to when it receives the first byte from the server, reflecting the server's processing and response speed. According to Google web.dev, a TTFB under 800ms (0.8 seconds) is ideal; between 800ms and 1.8 seconds requires optimization; above 1.8 seconds indicates slow server response, requiring investigation into database queries, application code, or origin fetch speed.

Q3: Why do speeds vary so much between different ISPs (Telecom, Unicom, Mobile) during website speed tests?

Different ISPs have varying backbone network interconnections, DNS scheduling policies, and node infrastructure. For example, if your origin server is hosted in a Telecom data center, Unicom or Mobile users may experience additional routing detours and latency when accessing across networks. Alternatively, CDN misconfiguration might direct Mobile users to a high-latency node. When a specific ISP is slow, prioritize checking DNS resolution paths and CDN node allocation rather than optimizing front-end code.

Q4: The first visit to the page is slow, but pressing F12 to refresh or opening it a second time loads instantly. Is this normal?

Yes, this is perfectly normal. On the first visit (cold start), the browser needs to perform DNS resolution, establish a TCP connection, complete TLS handshake, and download all static resources. If you use a CDN, the edge node may also need to fetch content from origin. On the second visit, DNS and TCP connections are reused, and static images and style files are already in the browser's local cache or CDN edge cache, so the speed improves dramatically. When testing website speed, it's recommended to compare "first visit" and "cache-hit visit" separately.