How to Run a Web Speed Test: A Complete Guide to Measuring Page Load Speed

Friends who run websites often ask me: "I clearly bought a high-spec server, and it opens lightning-fast locally, so why do so many users in other regions still complain that the site is slow?" Whenever I run into this question, I always tell them not to rush into paying for an upgrade. That's because whether a page opens and how fast it opens has nothing to do with how good your local internet connection is. A user's request has to travel across different carriers, backbone networks, and even international gateways. If there's a bottleneck at any single hop along the way, the experience takes a serious hit. In this article, we'll skip the complicated theory and jargon, and take a systematic look at how to actually run a WEB speed test, and how to analyze the data once you have it.

1. What Is a WEB Speed Test?

A WEB speed test is not the same thing as the broadband speed test you normally use. A regular speed test mainly checks your current network's download speed, upload speed, and latency — for example, whether your home broadband can reach 300Mbps or 500Mbps.

A WEB speed test, on the other hand, focuses on: how long it takes from the moment a user sends a request to the moment a specific website finishes loading.

Under normal circumstances, a single page visit roughly goes through the following steps:

Enter website address
      ↓
DNS resolution
      ↓
TCP connection
      ↓
TLS / HTTPS handshake
      ↓
Server processes request
      ↓
First byte returned (TTFB)
      ↓
Download HTML
      ↓
Load CSS / JS / images / fonts
      ↓
Page render complete

In other words, a slow page doesn't necessarily mean the server performance is poor. Sometimes DNS resolution alone already eats up a lot of time. Sometimes the server is too far from the user, so TCP and TLS connection times are high. And some sites have servers that respond quickly, but there are too many images, JavaScript files, and third-party scripts, so it still takes a few seconds before everything displays completely. When running a WEB speed test, breaking these stages apart and looking at them individually is usually more effective at spotting problems than just staring at the "total load time."

2. Which Metrics Matter Most in a WEB Speed Test?

Different speed testing platforms show slightly different data, but when you're actually troubleshooting page speed, the following metrics are the ones most worth paying attention to.

1. DNS Resolution Time

Before a browser can visit a website, it needs to use DNS to convert the domain name into a server IP address.

For example, when a user visits a website, the browser doesn't know which server that domain corresponds to, so it first needs to complete a process like this:

Domain name
↓
DNS query
↓
Server IP

If the DNS response is slow, then the page hasn't even started connecting to the server yet, and time has already been consumed.

Excessively long DNS times commonly come from a few situations:

• The DNS server itself responds slowly;

• The CNAME resolution chain is relatively long;

• DNS routing is not configured reasonably;

• Resolution is abnormal in certain regions;

• CDN DNS has scheduled traffic to an unsuitable node.

If only certain provinces or one particular carrier show DNS times noticeably higher than other nodes, you should focus on checking the resolution routing rather than immediately adjusting server configuration.

2. TCP Connection Time

Once DNS has resolved the server IP, the browser's next step is to establish a network connection with the server. TCP connection time is easily affected by the network distance between the user and the server. For example, if the server is deployed in Hong Kong, Singapore, or the United States, users in different regions may pass through different carrier backbone networks, international gateways, and routing nodes. So even when accessing the same website, different test nodes may see very different connection times. If the other page metrics are basically normal but TCP Connect Time stays consistently high, you usually need to further investigate the server's deployment location, carrier routing, and CDN node scheduling.

3. TLS Handshake Time

Most websites today already use HTTPS. After the TCP connection is established, the browser and server still need to perform a TLS handshake to negotiate the encryption protocol and connection parameters before HTTP content can actually be transmitted. This stage is also affected by network RTT. If the user is far from the server, or if the cross-carrier or cross-border route itself has high latency, the time required for the TLS handshake will also be amplified. So when analyzing the speed of an HTTPS website, you can't just look at server processing time — connection and handshake times deserve attention too.

4. TTFB

TTFB is one of the most important metrics in a WEB speed test.

TTFB stands for Time to First Byte, which is the time from when the request is sent to when the browser receives the first byte returned by the server.

Simply put, it's closer to: when the server actually starts returning content to the user.

If DNS, TCP, and TLS times are all fairly normal but TTFB is noticeably high, you need to keep investigating the backend.

Common causes include: the web server is overloaded; PHP, Java, Node.js, or other applications take too long to execute; database queries are slow; dynamic pages involve complex computation; the page doesn't use caching; the CDN misses the cache and has to frequently go back to origin; the link between the origin server and the CDN node is slow. To judge whether the server is slow, TTFB is usually a more meaningful reference than "how many seconds the page took to load in total."

5. Page Resource Load Time

After the server returns the HTML, the page hasn't actually finished loading. The browser will continue to request a large number of resources, such as: CSS; JavaScript; images; web fonts; video; ad code; analytics scripts; third-party APIs, and so on. This is also why some websites show a TTFB of only two or three hundred milliseconds, yet the page still takes three or four seconds to actually open.

The problem may not be with the server at all, but with frontend resources. For example, a single uncompressed homepage banner image could be several MB; a large number of JavaScript files also increases download, parsing, and execution time. If network connection and TTFB show no obvious abnormalities, then it's time to shift your attention to page resources.

6. Full Page Load Time

Full load time is fairly intuitive, and many people look at this number first when running a WEB speed test. However, this figure is better suited as an overall result rather than something you use directly to determine the source of a problem.

For example, two websites both take 4 seconds to fully load:

The first website might be:

TTFB: 2.5 seconds
Page resources: 1.5 seconds

The second website might be:

TTFB: 300ms
Page resources: 3.7 seconds

Although both end up at 4 seconds, the optimization direction is completely different: the first should prioritize checking the server and backend, while the second should focus more on images, JavaScript, CSS, and other frontend resources.

This is also why, when running a WEB speed test, it's best to observe the data for every stage at the same time.

3. How Do You Run a WEB Speed Test?

If you just want to quickly understand a website's current accessibility, you don't necessarily need to install professional performance analysis software. Using an online WEB speed testing platform is enough to complete a first round of assessment.

You can use Chahu to run a website speed check — just enter the website address and directly view accessibility across different regions.

For actual troubleshooting, you can follow this order:

Step 1: Enter the Website Address You Need to Test

Open the Chahu website speed test page, enter the URL you need to check, and start the test.

If you're checking an HTTPS page, it's best to enter the actual HTTPS address in use rather than just the bare domain.

This way, the test results are closer to what users experience when they actually visit the website.

Step 2: Observe Test Results from Different Regions

The fact that a website opens quickly locally only means that access from your current region and carrier is relatively normal.

But the website's real users may come from all over the country or even the world.

That's why the value of multi-node testing lies in observing different network environments at the same time.

For domestic websites, you can focus on comparing:

• Beijing;

• Shanghai;

• Guangdong;

• Jiangsu;

• Zhejiang;

• Sichuan, and other regions.

At the same time, observe:

• China Telecom;

• China Unicom;

• China Mobile.

If the website also serves overseas users, you can continue to check performance in the United States, Japan, Singapore, Europe, and other regions.

There's no need to obsess over whether a particular node is 42ms or 48ms.

What's more worth paying attention to is: whether there are obvious abnormalities between different regions.

If most nodes are within the normal range and only a few regions suddenly spike much higher, the problem often has clear regional or carrier characteristics.

Step 3: First Confirm Whether the Website Is Accessible

When actually troubleshooting website issues, it's not advisable to start by studying speed differences of a few dozen milliseconds.

First, you should confirm the most basic access status.

For example:

• Whether the request succeeded;

• Whether the HTTP status code is normal;

• Whether there are timeouts;

• Whether there are connection failures;

• Whether only certain regions are abnormal.

If most nodes return 200 normally but multiple nodes from one carrier keep timing out, then you should first check the routing, CDN nodes, or network scheduling.

If all regions return 5xx, then you should focus more on the origin server or application service.

So the focus of the first round of testing is actually:

First confirm whether the website "can open normally," then investigate whether it "opens fast enough."

Step 4: Continue Looking at Response Time and TTFB

Once website access is normal, then start analyzing speed.

A more practical order is:

DNS
↓
TCP connection
↓
TLS handshake
↓
TTFB
↓
Content download

The advantage of looking at it this way is that you can gradually narrow down the scope of the problem.

For example, if DNS is fast and TCP is normal, but TTFB is noticeably high, then the problem has most likely moved into the server or application layer.

Conversely, if the server response isn't slow but TCP connection times vary dramatically across different regions, then you should focus your troubleshooting on routing and node scheduling.

Step 5: Check Page Resource Loading

If server response time is fine but users still feel the page loads slowly, you need to continue checking frontend resources.

You can focus on looking at:

• Whether homepage images are too large;

• Whether a large amount of JavaScript is being loaded;

• Whether CSS is blocking;

• Whether there are too many web fonts;

• Whether there are slow-responding third-party scripts;

• Whether static resources use caching;

• Whether CDN cache is hitting normally.

At this point, you've moved from "network access speed" into the "page performance optimization" stage.

You can also combine PageSpeed Insights or WebPageTest to further analyze page rendering, resource requests, and Core Web Vitals.

4. How Should You Interpret WEB Speed Test Results?

After you get the speed test results, you don't need to study every single data point one by one. During actual troubleshooting, you can first determine the general direction by identifying which stage the abnormality appears in.

For example, if a website shows TTFB of just a few hundred milliseconds across most nodes in Beijing, Shanghai, and Guangzhou, but suddenly hits two or three seconds in one particular region, there's no need to immediately rebuild the entire backend. First check whether the anomaly is concentrated in a specific region, a specific ISP, or a specific CDN node—that usually makes it much easier to find the real cause.

5. What's the difference between a web speed test and an internet speed test?

These two concepts are often lumped together, but in reality, they don't test the same thing.

For instance, if your home broadband speed test shows 500 Mbps, that only means your current network has high data transfer capacity. If the website's server is in a faraway region, or the server itself takes two seconds to start returning data, then even with gigabit broadband, the page may still load slowly. Conversely, if a webpage opens quickly, that only means the current access path and page performance are good—it doesn't prove your local broadband is problem-free. So when you encounter slow page loads, it's best to first determine whether it's "your local network that's slow" or "this particular website that's slow." The troubleshooting directions for these two are completely different.

6. What's the difference between a web speed test and PageSpeed Insights?

Web speed tests and Google PageSpeed Insights often appear together in website performance analysis, but they don't solve exactly the same problems.

Take Chahu's multi-node website speed test tool as an example—it's better suited for first observing:

• Whether the website is currently accessible;

• Whether access speeds differ across regions;

• Performance across different domestic ISPs;

• Network response time;

• TTFB;

• DNS, Ping, and other network-layer issues.

PageSpeed Insights, on the other hand, leans more toward analyzing the webpage itself, such as:

• LCP;

• INP;

• CLS;

• Image optimization;

• JavaScript execution;

• CSS blocking;

• Core Web Vitals.

Simply put: A web speed test is better for first determining "where it's slow," while PageSpeed Insights is better for further analyzing "why the page is slow."

For example, if Chahu's multi-node test shows that access speeds are normal across most of the country, but the page still feels laggy when actually opened, then using PageSpeed Insights to check LCP, JS execution, and image resources will be more targeted. If the multi-node speed test itself reveals abnormal TTFB or connection times in certain regions, then you should address the network or server-layer issues first.

7. Is one web speed test enough?

A single test can help determine whether a website is "currently" normal, but it can't reflect the site's stability over the past few hours or days.

This is also the biggest difference between instant speed tests and website monitoring.

Instant web speed test

Better suited for:

• The website suddenly won't open;

• Users temporarily reporting slow access;

• CDN just switched;

• Server just finished migrating;

• DNS just modified;

• Temporary troubleshooting.

In these cases, running a multi-node test once can often quickly determine whether the problem exists.

Continuous website monitoring

If a website is already in official operation, relying solely on manual speed tests isn't very realistic.

For example, if a website experiences a ten-minute outage at 2 AM, by the next morning when you manually open the site it may have already recovered—a single test would hardly catch it.

Continuous monitoring automatically requests the website at set intervals to observe:

• Whether the website is online;

• Whether timeouts occur;

• Whether availability drops;

• Whether response times are abnormal;

• Whether there are frequent fluctuations during certain time periods.

For corporate websites, e-commerce, SaaS, APIs, or long-running websites, instant speed tests and continuous monitoring aren't an either-or choice. Use instant speed tests to pinpoint current failures when problems arise, and use monitoring to observe long-term stability during normal times—combining both approaches is more practical.

8. Troubleshooting order for slow web speed

If you have a lot of test results and don't know where to start, you can check in the following order:

Is the website accessible?
        ↓
Is the HTTP status normal?
        ↓
Is it slow only in certain regions?
        ↓
Is DNS resolution normal?
        ↓
Is the TCP / TLS connection taking too long?
        ↓
Is TTFB noticeably high?
        ↓
Are page images, JS, CSS too large?
        ↓
Are caching and CDN working properly?

The most important thing here is: don't start compressing images the moment you see a slow page, and don't assume the server configuration is insufficient just because TTFB is high. First determine which stage the problem occurs at, then adjust the corresponding part—troubleshooting efficiency is usually much higher that way. For example, if only one region has high connection times, optimizing frontend images won't help much; if network data is normal across all domestic nodes but page resources take four or five seconds to load, switching servers may not solve the problem either.

Conclusion

Website performance optimization is never a one-time task, and it's hard to solve with any single tool. When a webpage slows down, the worst thing you can do is compress images the moment you see slowness, or blindly switch servers the moment you see an error. Learn to use tools like Chahu to observe performance across different nodes nationwide and even globally, and break down DNS, TCP, TTFB, and resource loading times one by one—you'll find the problem is often quite clear. I hope the testing approach laid out in this article helps you build a clear performance troubleshooting framework and makes your website optimization more targeted.

FAQ

Q1: Does website loading speed actually affect Google search rankings? 

Yes, and it's a very clear ranking factor. Google has long incorporated page loading speed and Core Web Vitals into its search ranking algorithm. If two websites have comparable content quality and authority, the one that loads faster and offers a better user experience will gain a higher ranking advantage in search results.

Q2: Why does the first screen load quickly, but the PageSpeed Insights score is still low? 

PageSpeed Insights scores are based on a comprehensive evaluation of multiple dimensions, including full-page script parsing, unused CSS/JS, main thread blocking time, and simulated mobile performance. Sometimes a page looks visually rendered, but the background is still frantically loading third-party tracking code or unoptimized complex scripts, causing the main thread to be occupied for a long time—so the tool gives a lower score.

Q3: Mobile and PC speed test results differ greatly—which should I trust? 

It's recommended to prioritize mobile test results. Google currently uses mobile-first indexing across the board, and search engines mainly evaluate websites based on mobile page loading performance and experience. Additionally, mobile device CPU power and mobile network environments are more complex than PC, so if the mobile experience is well-optimized, the PC performance usually won't be bad either.

Q4: How do HTTP/2 and HTTP/3 substantively help website speed test metrics? 

Upgrading to HTTP/2 or HTTP/3 can significantly improve network blocking during multi-resource loading. Traditional HTTP/1.1 has head-of-line blocking issues, and browsers can only download a limited number of resources simultaneously; HTTP/2 supports multiplexing, allowing concurrent transmission of large amounts of CSS, JS, and images over a single connection. HTTP/3 is based on the QUIC protocol, further reducing TLS handshake overhead and packet loss retransmission latency—its speed improvements are especially noticeable in weak network environments.