Why Do Different Speed Test Platforms Show Such Different Results for the Same Website? How to Compare and Interpret Them

The same website takes only 600 milliseconds on Platform A but 2.8 seconds on Platform B, and PageSpeed Insights mobile scores still aren’t ideal. Run the test again, and the numbers may change again.

This gap does not necessarily mean one platform is “inaccurate.”

In many cases, platforms that all call themselves “website speed tests” are not measuring the same thing. One may request the homepage HTML from China Telecom in Beijing, another may run a full browser from a US cloud server, and another may show page experience for real Chrome users over the last 28 days. Their nodes, networks, devices, cache, and metric definitions all differ, so the results cannot be directly ranked or compared.

To judge which set of results is more useful, do not look only at the seconds or score displayed at the end. First confirm:where the test ran from, which IP was accessed, what content was requested, whether cache was hit, and which point in time the platform treats as the end of the test.

All three call themselves website speed tests, but they may measure three different things

Website speed testing platforms fall roughly into the following categories:

For example, a multi-node HTTP test may show the homepage request taking 800 milliseconds, while a full browser load takes 3 seconds. Both results can be correct at the same time.

The former may count only the time to complete the HTML request; the latter must also download CSS, JavaScript, images, fonts, and third-party APIs, then execute scripts, calculate layout, and render the page. If the HTML is small but the page references many resources, a large gap between the two is normal.

Reason 1: The test nodes are not in the same region at all

Website speed test results depend first on where the request originates.

Beijing Unicom, a Singapore cloud server, a German residential network, and a US West Coast data center all have different network distances and routes to the same website. Even without a CDN, geographic distance and carrier interconnection differences alone can make results differ severalfold.

If the website uses a CDN, the differences become even more obvious. Different test nodes may be scheduled to different edge nodes:

北京移动 → 北京或华北CDN节点
广州电信 → 华南CDN节点
东京节点 → 日本CDN节点
美国东部 → 弗吉尼亚或纽约附近节点

These requests connect to different targets, so the results will certainly not match.

Therefore, before comparing two website speed test platforms, confirm:

• 
  whether the test country, region, and city are the same;
  

• 
  whether they use the same carrier;
  

• 
  whether the node is a residential network or a data center;
  

• 
  whether IPv4 or IPv6 is used;
  

• 
  whether the node is accessing across carriers or across borders;
  

• 
  whether both platforms actually send requests from similar networks.
  

“Both are in China” or “both are US nodes” is not enough. Significant regional and carrier differences can exist within the same country.

Reason 2: DNS resolved to different IPs

Entering the same domain name does not mean the final request reaches the same server.

Smart DNS and CDNs return different results based on recursive DNS, client location, carrier, health status, and load. When two platforms use their own DNS resolvers, they may receive completely different response IPs.

For example:

平台A解析结果：203.0.113.10
平台B解析结果：203.0.113.20

If the two IPs belong to different CDN nodes, subsequent connection time, cache status, and origin fetch paths may all differ. Comparing “total time” here actually compares two targets, not just two speed test tools.

Even if the same Anycast IP is returned, requests may enter different edge nodes through different network entry points. The same IP does not guarantee the same actual network path.

Therefore, when a large speed test gap appears, the first cross-check is not average time but:

• 
  whether the response IPs match;
  

• 
  whether the networks or ASNs of the IPs match;
  

• 
  whether the CNAME chain matches;
  

• 
  whether IPv4 and IPv6 use different targets;
  

• 
  whether one platform hit an old DNS cache;
  

• 
  whether multi-CDN or failover is in use.
  

CdnChart'swebsite speed test toolshows response IP, IP location, HTTP status code, DNS resolution time, connection time, download time, total time, and redirects in the node details, helping determine whether the gap comes from DNS scheduling or node selection.

Reason 3: One test hit a warm cache, while the other triggered an origin fetch

This is a common reason for large CDN website speed test gaps.

Before Platform A requested a resource, the CDN edge node had already cached the content and could return it directly; the node hit by Platform B had no cache and needed to retrieve the data from the origin. Although the URL was the same, the actual paths differed:

热缓存：
测试节点 → CDN边缘节点 → 返回内容

冷缓存或MISS：
测试节点 → CDN边缘节点 → 回源网络 → 源站处理 → CDN节点 → 返回内容

If the origin is far away, slow to process, or the origin fetch route is congested, cold-cache results can be much slower than warm-cache results.

Suspect cache differences when the following occur:

• 
  the first test is slow, and the second is clearly faster;
  

• 
  connection times to different nodes in the same region are similar, but total times differ greatly;
  

• 
  static files fluctuate noticeably;
  

• 
  the CDN response header changes between HIT and MISS;
  

• 
  results suddenly become slower after adding a random query parameter;
  

• 
  some regions keep fetching from the origin while others hit cache directly.
  

For a fair comparison, clearly state whether the test is cold-cache or warm-cache. Do not directly compare a platform’s first-visit result with another platform’s result after the cache has been warmed.

If the business cares about repeat visits by ordinary users, record both first and repeat visits; if evaluating CDN origin-fetch capability, observe MISS requests separately, but do not create unnecessary origin load with large numbers of random parameters.

Reason 4: The tested URLs are not exactly the same

Some platforms request the homepage by default after accepting a domain, some require a full URL; some automatically complete HTTPS, and some may first access HTTP and then follow redirects.

The following addresses appear to point to the same website, but the actual test paths may differ:

http://example.com
https://example.com
https://www.example.com
https://www.example.com/
https://www.example.com/index.html

They may go through different redirects, cache rules, and security policies.

If Platform A tests:

https://www.example.com/

and Platform B tests:

http://example.com

Platform B may go through HTTP-to-HTTPS and bare-domain redirects,wwwtwo redirects in total, so the result is naturally slower.

When comparing, record the final URL, the number of redirects, and each redirect target. Pay particular attention to:

• 
  whether HTTP redirects to HTTPS;
  

• 
  whether the bare domain redirectswww;
  

• 
  whether it redirects to a language directory based on country;
  

• 
  whether mobile devices enter a separate site;
  

• 
  whether login status triggers other pages;
  

• 
  whether the test platform automatically follows redirects;
  

• 
  whether the final response is a normal page, a CAPTCHA, or an error page.
  

A 403 page of only a few KB may return faster than a normal homepage. Without checking status code and content size, it is easy to mistake “blocked” for “excellent performance.”

Reason 5: One tests only HTML, while the other runs a full browser

Multi-node HTTP tools are generally better for checking network and server responses; real-browser tools continue loading page resources and executing code.

A complete page may include:

• 
  the main HTML document;
  

• 
  multiple CSS files;
  

• 
  JavaScript bundles;
  

• 
  images and video;
  

• 
  web fonts;
  

• 
  API requests;
  

• 
  advertising, analytics, and customer service scripts;
  

• 
  maps, payment, or social components.
  

Therefore, “total homepage request time” and “the page has visually finished loading” are not the same point in time.

Google’s official documentation for PageSpeed Insights clearly distinguishes lab data from field data: lab data comes from a controlled environment and is suitable for debugging; field data comes from the Chrome User Experience Report and reflects how real users experience the page on different devices and networks. If a page or origin does not have enough field samples, PSI may show only lab results.

If one platform shows 800 milliseconds and another shows an LCP of 3 seconds, you cannot simply say the latter counted 2.2 extra seconds. Their end conditions differ:

• 
  800 milliseconds may mean the HTML download has completed;
  

• 
  LCP indicates when the main content element has finished rendering;
  

• 
  the Load event may wait for more resources;
  

• 
  fully loaded time may continue waiting for asynchronous requests;
  

• 
  time to interactive is also affected by JavaScript execution.
  

Before comparing results, confirm the metric name rather than comparing only the numeric units.

Reason 6: Mobile and desktop test conditions differ

A clear score difference for the same page on desktop and mobile does not necessarily indicate a platform problem.

Mobile lab tests may use lower CPU power and constrained network conditions. Desktop devices process JavaScript, image decoding, and layout calculations faster, so even when accessing the same server, page performance will differ.

Differences may also come from the website itself:

• 
  mobile loads different images;
  

• 
  responsive layouts run more scripts;
  

• 
  extra pop-ups or navigation appear on mobile;
  

• 
  the server returns different HTML based on User-Agent;
  

• 
  some ads are shown only to mobile devices;
  

• 
  third-party resources connect more slowly on mobile networks.
  

If Platform A uses a desktop browser and Platform B uses an emulated mobile device, their page load results should not be compared directly.

Reason 7: Protocols and connection reuse differ

A website may support HTTP/1.1, HTTP/2, and HTTP/3 at the same time. Different speed test platforms have different client capabilities and network environments, so the final negotiated protocol may also differ.

Conditions that may create gaps include:

• 
  one platform accesses over HTTP/2 while the other uses only HTTP/1.1;
  

• 
  one node supports UDP and successfully uses HTTP/3, while another network restricts UDP;
  

• 
  one test reuses an existing connection while the other creates a new connection each time;
  

• 
  one test resumes a TLS session while the other performs a full handshake;
  

• 
  the IPv6 path is better or worse than IPv4;
  

• 
  the test endpoint goes through an HTTP proxy;
  

• 
  the browser caches DNS, connections, or page resources.
  

HTTP/3 is not guaranteed to be faster on every network, and HTTP/2 will not automatically fix slow server processing. Protocol is only one test condition and must be recorded together with response IP, connection phases, and network path.

Reason 8: Request headers and User-Agent trigger different responses

Websites, CDNs, and WAFs may return different content based on request characteristics. If speed test platforms use different User-Agent, Accept-Encoding, Cookie, and regional request headers, the object being tested also changes.

Common differences include:

• 
  desktop and mobile page content differ;
  

• 
  clients that support Brotli receive smaller files;
  

• 
  first-time visitors without cookies receive a region selection page;
  

• 
  a Bot User-Agent triggers a CAPTCHA or rate limiting;
  

• 
  an error page is returned when a certain request header is missing;
  

• 
  logged-in and anonymous users receive different HTML;
  

• 
  different countries show different languages, prices, or compliance notices.
  

If one platform downloads a normal 500KB page and another downloads only a 20KB CAPTCHA page, the latter’s “faster download speed” has no business meaning.

When comparing results, check the status code, response size,Content-Encodingfinal URL, and key response headers, rather than only total time.

Reason 9: Platforms handle failures, timeouts, and averages differently

Statistical definitions directly change the final result.

Suppose the total times of five nodes are:

0.5秒、0.6秒、0.7秒、4秒、超时

Different platforms may use different methods:

• 
  count only the average of successful nodes;
  

• 
  count timeouts at a fixed upper limit;
  

• 
  remove the slowest and fastest results;
  

• 
  use the median;
  

• 
  show P75 or P95;
  

• 
  show only the “best single run”;
  

• 
  run multiple tests and select a middle one;
  

• 
  include DNS, connection, and download in total time;
  

• 
  exclude requests before redirects from the final time.
  

If a platform does not disclose its statistical method, comparing only the “average speed” shown at the top is of limited value.

A more transparent speed test result should at least let users see:

• 
  the number of nodes that actually participated in the test;
  

• 
  the number of successes and failures;
  

• 
  the raw results for each node;
  

• 
  the fastest and slowest results;
  

• 
  the average or median;
  

• 
  whether timeouts are excluded;
  

• 
  the test time;
  

• 
  response IP and status code.
  

A larger number of nodes does not automatically mean reliable results. For how to check nodes and metrics, refer to the published“How to Choose a CDN Speed Test Site? Check Nodes, Metrics, and Result Records First”.

Reason 10: The two platforms did not test at the same time at all

Website speed changes over time.

Carrier congestion may occur during evening peak hours, and origin CPU and database load may rise with business volume. CDN nodes perform load balancing, health checks, and failover, and network routes may also change temporarily.

Even with the same platform, two consecutive tests may differ due to:

• 
  changes in DNS cache status;
  

• 
  the first request triggering CDN warm-up;
  

• 
  changes in node load;
  

• 
  momentary origin pressure;
  

• 
  WAF rate limiting;
  

• 
  route convergence;
  

• 
  third-party API fluctuations;
  

• 
  content just published or cache just purged.
  

If Platform A tests in the morning and Platform B tests during evening peak, the difference may come from time, not the tool.

When the website itself fluctuates, refer to“Why Is a Website Sometimes Fast and Sometimes Slow? How Should CDN Speed Tests Be Run?”and record continuously at fixed time periods instead of keeping only one best result.

How to fairly compare two website speed test platforms

A truly effective comparison requires controlling variables as much as possible.

Use exactly the same test URL

Do not test the homepage on one platform and a static file on another. Copy the same full HTTPS address and confirm that the final redirect target is the same.

If a platform accepts only a domain, at least ensure the same hostname is entered, for example use:

www.example.com

Do not switch betweenexample.com,www.example.comand the origin IP.

Choose regions and networks that are as close as possible

If both platforms support Shanghai Telecom, compare Shanghai Telecom first; if only country can be selected, at least keep the country consistent.

Do not directly compare Beijing Unicom results with Singapore cloud nodes, and do not treat residential nodes and data center nodes as the same network environment.

Keep device and browser conditions consistent

Page performance tests also need to fix:

• 
  desktop or mobile;
  

• 
  browser type and version;
  

• 
  screen size;
  

• 
  CPU limits;
  

• 
  network throttling configuration;
  

• 
  whether browser cache is disabled;
  

• 
  first visit or repeat visit.
  

When these conditions cannot be unified, stop comparing final seconds directly and compare trends within each platform instead.

Record response IP, status code, and response size at the same time

At minimum record:

测试平台
测试时间
节点地区
网络类型
测试URL
最终URL
响应IP
HTTP状态码
响应大小
DNS耗时
连接耗时
首字节或等待时间
下载耗时
总耗时
是否命中缓存
是否发生重定向

If response IP, status code, or content size differ, explain those differences first, then compare performance.

Run multiple consecutive tests on each platform

A single result is easily affected by random fluctuation. Run at least 3 to 5 tests on the same platform, record the median, and retain the slowest result and failure count.

Do not pick only the best run. User experience is not just “how fast it can be occasionally,” but also “whether it is stable most of the time” and “whether the worst case is acceptable.”

Test at approximately the same time

It is best to run both platforms within the same time window, especially when investigating evening peak, campaign traffic, or sudden failures.

If website content is being published, the CDN is warming up, or DNS has just been migrated, wait until the state is relatively stable before comparing, or clearly record the change time.

Use CdnChart to determine where the gap comes from

When results from different speed test platforms differ greatly, first run a multi-region baseline test with CdnChart.

After entering the domain, do not look only at average time. Focus on checking:

1. 
   whether there are systematic differences among Telecom, Unicom, and Mobile;
   

2. 
   whether different regions return the same response IP;
   

3. 
   whether slow nodes are concentrated on a certain IP;
   

4. 
   whether all HTTP status codes are normal;
   

5. 
   whether the gap is larger in DNS resolution time or connection time;
   

6. 
   whether download time correlates with response IP;
   

7. 
   whether redirects and failed nodes appear;
   

8. 
   whether the same pattern still appears when retested under the same conditions.
   

If CdnChart shows large regional fluctuations for the same domain itself, it is not surprising that other platforms return different results. In this case, investigate CDN scheduling, node quality, and carrier routes, rather than arguing about which platform’s single number is correct.

If multi-region HTTP results are relatively stable but PageSpeed Insights or browser tests are still slow, the problem is more likely in page resources, JavaScript, third-party requests, or the rendering stage.

For more specific CdnChart instructions, refer to the written but unpublished “How to Run a CdnChart Domain Speed Test: Methods for Domain Access Speed and Network Latency Testing.”

Use curl to verify whether both platforms accessed the same content

You can run the following in your own network:

curl -L -o /dev/null -sS \
  -w '最终URL: %{url_effective}\n状态码: %{http_code}\n响应IP: %{remote_ip}\nHTTP版本: %{http_version}\nDNS: %{time_namelookup}s\n连接: %{time_connect}s\nTLS: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\n下载大小: %{size_download} bytes\n下载速度: %{speed_download} B/s\n重定向: %{num_redirects}\n' \
  https://www.example.com/

The official curl manual states:

• time_namelookupis the cumulative time from start to completion of domain resolution;
  

• time_connectis from start to completion of the TCP connection;
  

• time_appconnectis from start to completion of the application connection such as TLS;
  

• time_starttransferis from start to receipt of the first byte;
  

• time_totalis the total operation time.
  

Most of these fields are cumulative values and cannot simply be added together.

To verify the response IP shown by a speed test platform, you can use--resolvea fixed target while preserving Host and TLS SNI:

curl --resolve www.example.com:443:203.0.113.10 \
  -o /dev/null -sS \
  -w '状态码: %{http_code}\n响应IP: %{remote_ip}\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\n' \
  https://www.example.com/

Replace203.0.113.10with the node IP to be verified. If the speed gap disappears after fixing the IP, the original difference most likely came from DNS scheduling or different CDN nodes.

Use the browser Network panel to check what “total load time” actually includes

If both platforms claim to test the full page but the results still differ greatly, open Chrome DevTools:

1. 
   PressF12to open DevTools;
   

2. 
   open the Network panel;
   

3. 
   selectDisable cache;
   

4. 
   clear the records and refresh the page;
   

5. 
   view the main document and all resources;
   

6. 
   sort by Duration or Waterfall;
   

7. 
   check status, protocol, remote address, Timing, and response size.
   

Chrome’s official documentation states that the Network panel can show the status, size, total time, and waterfall for each request, and break down DNS, connection, waiting for first byte, and content download phases in Timing.

If a platform reports a page time of 3 seconds, while the browser waterfall shows the main document at 500 milliseconds and a third-party script waiting for 2.5 seconds, the reason for the platform gap becomes clear: one tested only the main document, while the other waited for page resources.

Which platform’s results should you trust?

A more accurate question is not “which platform should I trust?” but “which type of test is better suited to the current problem?”

If a platform does not disclose test nodes, status codes, response IPs, test objects, and statistical methods, its final score is hard to use for technical decisions.

If a platform can provide raw results, even if the numbers differ from another platform, the gap can be explained item by item through nodes, DNS, cache, and protocol. For network engineers, explainable results are more valuable than pretty-looking scores.

Frequently asked questions

Is it normal for the same website to differ by several seconds across speed test platforms?

It can be normal. If one platform requests only HTML while the other runs a full browser, or if the two use different countries, carriers, and CDN nodes, a difference of several seconds is not unusual. Unify the test conditions first, then determine whether the result is abnormal.

Why do consecutive tests on the same platform also differ?

It may be affected by DNS cache, CDN cold and warm cache, node load, origin pressure, network congestion, and route changes. Record response IP, cache status, and failures during consecutive tests.

Does a low PageSpeed Insights score mean the CDN is slow?

Not necessarily. PageSpeed Insights also analyzes images, JavaScript, the main thread, layout shifts, and interaction response. A CDN mainly affects resource delivery and cannot automatically solve front-end execution and page structure problems.

Both platforms show total time, so why can’t they still be compared directly?

The start and end points of “total time” may differ. One platform may measure a single HTTP request, while another may wait for the Load event or all page resources to complete. Check the metric definition.

If a speed test platform shows 200, does that mean it returned the normal homepage?

Not necessarily. WAF CAPTCHAs, regional notices, and custom error pages may also return 200. Also check the final URL, response size, page content, and key response headers.

Why does a cloud server test fast while real users say it is slow?

Cloud servers usually have sufficient bandwidth and may have good network interconnection with CDNs or cloud providers. Real users are also affected by home broadband, mobile networks, device performance, and local DNS.

When comparing CDNs, should you use the best result or the average result?

Do not use only the best result. Record the median, slow nodes, failure rate, and fluctuation range across multiple tests. The worst experience in core regions can sometimes matter more than the global average.

How can you tell whether a speed test gap comes from the platform or the website itself?

Use the same URL, similar nodes, and the same time window to run consecutive tests, then compare response IP, status code, response size, and cache status. If the same platform also fluctuates noticeably, the website, CDN, or network state is more likely unstable; if the gap disappears after fixing the target and conditions, the original difference mainly came from the platform’s test methodology.