How Should You Test CDN Speed When a Website Is Sometimes Fast and Sometimes Slow?

This morning a page opened in half a second, but this afternoon the same page took three or four seconds. It loads quickly from your own office, yet a customer on a different carrier says it lags. A speed test looks fine the first time, but after a refresh the result drops sharply again.

Your website is already behind a CDN, so why is the speed still inconsistent?

Don't rush to switch CDNs.When the problem itself is 'sometimes fast, sometimes slow,' a single speed test is almost worthless as evidence.

The right approach is to fix the test target and conditions, sample repeatedly from multiple regions, carriers, and time periods, and separate first visits from cached visits. Don't just look at averages; also review P50, P95, success rate, responding node, and cache status.

A CDN speed test useful for troubleshooting must answer at least these five questions:

If you only record 'the website took 2 seconds to open,' you can't answer any of the five questions above.

Why do speed test results for the same website vary?

A website visit is not the user directly 'getting a speed number' from the CDN. It passes through DNS resolution, node scheduling, network connection, TLS handshake, CDN cache lookup, possible origin fetch, content transfer, and browser rendering.

If any part of that changes, the final time changes.

1. Each request may go to a different CDN node

A CDN directs users to different nodes based on DNS, Anycast routing, carrier networks, node health, and scheduling policies.

Even within the same city, two requests may not connect to the same IP; IPv4 and IPv6 may also enter different networks. If one node's route is clear and another is congested at that moment, users naturally experience different speeds.

Therefore, speed tests must record the responding IP or node identifier. Otherwise you only know that 'this request was slow,' not whether slow requests are concentrated on a particular node.

2. One request hits the cache, another goes to origin

If the same URL is already cached at a CDN node, it may be returned directly; if the cache is absent, expired, or bypassed, the CDN must fetch the content from upstream or the origin.

So you may see:

# 第一次请求
CF-Cache-Status: MISS

# 再次请求
CF-Cache-Status: HIT
Age: 12

It is not surprising that the second request is faster. Conversely, if you add a random query parameter to every test, you may keep creating new cache keys and make every result look like a first visit.

So separate cold-cache tests from warm-cache tests; never mix them into one data set and average them together.

3. Origin and application load changes

If HTML, APIs, or cache misses require origin fetches, origin CPU, database, disk, connection pools, third-party APIs, and cross-region origin routes all affect TTFB.

Access is normal during the day, but slows during peak business hours; static files are fast, while the homepage HTML is slow; the CDN showsMISSis slow, andHITis normal—these symptoms point more to origin or origin-fetch link issues than simply 'the CDN node is bad.'

4. The user's network itself changes

Wi-Fi signal, mobile network switching, carrier egress congestion, cross-network interconnection, packet loss, and route changes all make the same website perform differently at different times.

Testing only from your company broadband or your own cloud server represents at most that one location, not your target users.

5. Browser cache and connection reuse affect results

On a second refresh, the browser may use its local cache directly, or it may reuse an established TCP, TLS, or HTTP/2 connection. In that case, DNS lookup, handshake, and some resource downloads are reduced.

So 'first open' and 'open after refresh' are not the same scenario. The former is closer to a new visitor; the latter is closer to a returning user browsing continuously.

6. Third-party resources on the page are unstable

The main HTML and your own static resources may all be fast, but if ads, analytics scripts, support widgets, fonts, maps, or external APIs stall, the overall load time in the browser still slows down.

This is why single-file CDN speed tests and full-page speed tests cannot replace each other: the former is better for checking network and content delivery, while the latter exposes resource dependencies, JavaScript execution, and rendering issues.

Which metrics should a CDN speed test actually measure?

Don't stare at just one 'total time.' Break the total time down so you know who should fix it.

Chrome DevTools' network request timing explanation breaks a single request into stages such as DNS Lookup, Initial connection, Waiting (TTFB), and Content Download.

TTFB includes one network round trip plus the time the server takes to prepare the response. So a high TTFB does not automatically prove 'slow origin computation'; network distance, CDN edge processing, and the origin fetch path may also be involved.

Step 1: Fix the test targets first; don't mix everything together

It is recommended to prepare at least three types of URLs.

1. Main page HTML

For example:

https://www.example.com/

It reflects the page entry point, redirects, HTML caching, and origin response, but it is easily affected by login state, personalized content, and application logic.

2. Small static files

For example, a CSS, JavaScript, or logo file of a few dozen KB:

https://www.example.com/assets/app.css

The total time for small files is mainly affected by DNS, connection, TLS, and TTFB, making them suitable for observing node latency and whether caching is stable.

3. Large files of fixed size

For example, a public test file of 1MB, 5MB, or 10MB:

https://static.example.com/test/5mb.bin

Large files are better for observing sustained download speed and throughput. If the file is too small, it may finish before reaching stable transfer; if the file size differs each time, comparison is unfair.

Test files must be public, contain no sensitive information, have fixed content, and be cacheable. Do not use user files, signed private URLs, or backend APIs for public speed tests.

Step 2: Separate first visits from repeat visits

If you want to understand ordinary users' actual experience, keep at least two sets of results.

First-visit group

Simulate a user who has never visited the page before:

• No local browser cache;

• No reusable connection;

• The CDN edge cache may also be cold;

• A full DNS, TCP, and TLS process may be required.

First visits are more likely to expose cold cache, origin fetch, and connection establishment costs.

Repeat-visit group

Request again at the same node, same URL, and a similar time:

• The CDN cache may already be filled;

• The browser may use local cache;

• The network connection may be reused.

If first visits are slow and repeat visits become consistently faster, focus on cache status, TTL, and the initial origin fetch. If both first and repeat visits are slow, continue examining the network path, CDN node, origin, and file transfer.

Note that browser local cache and CDN cache are not the same thing.

To observe the CDN separately, use a command-line plain GET request and discard the response body instead of relying on browser refresh results.

Step 3: Use curl to break down a single request's timing

The following command quickly shows the main stage timings for a URL:

curl -sS -o /dev/null \
  -w 'status=%{http_code}\nip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\nspeed=%{speed_download}\n' \
  https://www.example.com/assets/app.css

Example output:

status=200
ip=203.0.113.20
dns=0.018532
connect=0.051437
tls=0.102219
ttfb=0.168604
total=0.221740
size=86324
speed=389302

The time unit here is seconds.

Pay special attention:time_connect,time_appconnectandtime_starttransferare all cumulative times from the start of the request, not independent stage durations.

You can roughly understand it as:

DNS阶段      = time_namelookup
TCP阶段      = time_connect - time_namelookup
TLS阶段      = time_appconnect - time_connect
首字节前等待 = time_starttransfer - time_appconnect
内容下载阶段 = time_total - time_starttransfer

If redirects, connection reuse, proxy forwarding, or non-HTTPS requests occur, some fields will differ. This breakdown is suitable for quick localization, but it should not replace browser waterfalls, CDN logs, and link monitoring.

Run ten tests in a row

for i in $(seq 1 10); do
  printf 'request=%s ' "$i"
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
    https://www.example.com/assets/app.css
  sleep 2
done

If you also want to observe cache status, you can check the response headers separately:

curl -sS -D - -o /dev/null https://www.example.com/assets/app.css \
  | grep -Ei '^(age|cache-control|cdn-cache-control|cf-cache-status|x-cache|via|server):'

Do not append a random parameter to every request by default just to 'avoid caching.' That changes the cache key, and the result may always be a cold request.

Only when specifically testing origin fetch or cold cache should you use controlled different URLs and group their results separately.

Step 4: Test separately across regions and carriers

Ten consecutive tests on your local computer can only answer 'how is it here.' Whether a CDN is stable must be observed from the networks where your target users are.

If users are mainly in mainland China, you should cover at least:

• China Telecom;

• China Unicom;

• China Mobile;

• Provinces where business users are concentrated;

• IPv4 and IPv6, if the website supports both.

For overseas business, choose regions based on the real user distribution, for example:

• Hong Kong, Singapore, Japan;

• US East and West;

• Major European regions such as Germany and the UK;

• Actual business markets such as India, Brazil, or the Middle East.

You can useCdnChart Website Speed Testto observe access results for the same website from different regions.

When testing, do not just screenshot the 'fastest node' or 'slowest node'; record each node's region, carrier, responding IP, status code, and each timing.

If different regions resolve to different vendors or networks, you can further useCdnChart CDN Checkto view CNAME, IP/ASN, and response header clues, so you do not mistake multi-CDN scheduling or vendor migration for single-node fluctuation.

Step 5: How many tests per node at minimum?

There is no fixed number that suits every scenario, but you can plan according to the severity of the problem.

Higher test frequency is not always better.

High-frequency, large-file tests against a production website generate bandwidth and request costs and may trigger protection rules. When testing your own website, control frequency based on file size, cost, and security policy; when testing third-party websites, you must not run high-concurrency stress tests.

Don't look only at averages; look at P50, P95, and failure rate

Suppose a node is tested 20 times: 18 times around 200 milliseconds, and 2 times over 3 seconds. The average may look acceptable, but those two slow requests are exactly the source of users' complaints about 'occasional lag.'

Therefore, you should record at least:

Below is a set of demo data, not representing any real website:

If you only look at the average of the four nodes, the problems with Guangzhou Mobile and Frankfurt are easily hidden.

CdnChart Testing MethodologyUse percentiles such as P50 and P95 to observe typical performance and tail experience. For 'the website is occasionally slow,' P95 is usually more diagnostically valuable than a single best result.

A speed testing plan you can execute directly

If someone now reports that the website is sometimes fast and sometimes slow, test according to the following process.

Round 1: Ten-minute quick reproduction

1. Fix one page HTML, one small static file, and one fixed large file;

2. Make 5–10 consecutive requests locally;

3. Record status code, responding IP, DNS, TCP, TLS, TTFB, and total time;

4. Check HIT, MISS, and Age for static files;

5. Determine whether slow requests are concentrated in first visits, cache MISS, or a particular responding IP.

Round 2: Cross-region validation

1. Select regions and carriers that match real users;

2. Test exactly the same URL from all nodes;

3. Run multiple rounds per node, not just one test;

4. Distinguish IPv4 from IPv6;

5. Summarize P50, P95, and success rate for each node.

Round 3: Observation over time

If the first two rounds do not reproduce the issue consistently, extend testing to 24 hours:

• Morning business off-peak;

• Noon;

• Evening traffic peak;

• Time periods when users complain most;

• Before and after releases, cache purges, or traffic switches.

Keep test conditions consistent each time, and record application releases, cache purges, DNS changes, and CDN rule changes.

Without a change timeline, when you see a slow data point the next day, it is hard to know what event it relates to.

Round 4: Use logs to confirm the responsible layer

Client-side speed tests can only observe the result of the request path. To confirm which layer the problem occurs in, you also need to compare:

• CDN access logs;

• Cache hit and origin fetch metrics;

• Origin access logs;

• Application and database monitoring;

• 5xx, timeouts, and connection errors;

• Node, region, and carrier dimensions.

Google Cloud CDN'scache log and monitoring documentationshows how to distinguish cache hits, validation, and misses from logs, and continuously observe CDN status through metrics such as regional traffic, cache hit ratio, error rate, and P95 TCP round-trip latency.

True stability assessment should come from monitoring over time, not a single manual refresh.

When looking at results, how do you locate where the slowness actually is?

You can use the following table for an initial assessment.

This table can only be used to narrow the scope.

For example, 'high TTFB and MISS' makes origin fetch more suspect, but you cannot conclude the origin is at fault without logs.

Why do speed test tools differ from real user feedback?

Speed test tools usually perform controlled synthetic tests: they actively visit pages from specified devices, networks, or nodes, and are suitable for reproducing problems and comparing before/after changes.

Real user data comes from different devices, networks, regions, and usage environments, and is better for judging what users actually experienced over a period.

In Google'sPageSpeed Insights documentationclearly distinguishes lab data and real user data:

• Lab data is suitable for debugging in a controlled environment, but may not cover real-world bottlenecks;

• Real user data reflects actual experience, but provides fewer diagnostic details;

• CrUX real user data in PageSpeed Insights represents samples from the past 28 days;

• A single Lighthouse test represents only one load under a specific simulated environment.

So when users say the website is slow but tools show it is fast, do not simply assume the user's network is bad, and do not immediately dismiss the speed test result.

A more reasonable approach is:

• Reproduce with multi-region synthetic tests;

• Confirm the scope of impact with real user monitoring;

• Then locate the cause using CDN, origin, and application logs.

The three types of evidence answer different questions and cannot replace one another.

Eight common mistakes in CDN speed testing

1. Testing only once

A single result may happen to hit cold cache, network jitter, or connection reuse; it represents neither daily speed nor stability.

2. Looking only at averages

Averages hide a small number of extremely slow requests. 'Sometimes slow' is itself a tail problem, so focus on P95, max, and failure rate.

3. Testing only on your own computer

Fast for you does not mean fast for customers. The value of a CDN is inherently related to region and carrier, and a single location cannot represent the whole country or the world.

4. Using a different URL every time

Random parameters, different protocols, different hostnames, and different file versions all change the request path or cache key, so you are not comparing the same object.

5. Mistaking browser cache for CDN cache

Becoming faster after refresh may only mean the browser already has the file locally; it does not prove a CDN edge cache hit.

6. Using small files to judge download bandwidth

Small files are suitable for observing response latency, not for accurately judging sustained throughput. To test download capability, use a public file of fixed and sufficiently large size.

7. Looking only at ping values

Ping tests ICMP round-trip time and cannot fully reflect DNS, TLS, HTTP processing, caching, origin fetch, and content download. Some nodes also limit or do not respond to ICMP.

8. Not recording status codes and cache results

A request returning403may look very 'fast,' and a CDN error page may also return quickly.

Recording only time without recording whether the response is correct can easily mistake failure for excellent performance.

Common questions

How many CDN speed tests are needed for accuracy?

For a quick check, test each node at least 5 times consecutively; when troubleshooting fluctuations, increase to 10 times and observe continuously across multiple time periods.

More important than the number of tests is keeping the URL, region, carrier, and test conditions consistent.

Why is the first speed test slow and the second fast?

It may be that the CDN cache has just finished filling, or that DNS, local cache, or the TCP/TLS connection is reused.

Check cache status, Age, responding IP, and whether the browser cache was cleared at the same time.

Why is local access fast, but users elsewhere slow?

Different regions and carriers may reach different CDN nodes and network paths.

Retest from the user's region, carrier, and IP protocol; local results cannot substitute for the other party's access conditions.

Should CDN speed tests look at latency or download speed?

Small files and web page entry points should focus more on connection time and TTFB; large-file downloads, video, and software distribution also need sustained throughput.

The two solve different problems, so you cannot choose just one number.

What does it mean when P50 is normal but P95 is very high?

It means most requests have normal speed, but a small subset is noticeably slower.

This is the typical pattern behind users saying 'mostly fast, occasionally very laggy.' Check whether slow samples are concentrated at specific nodes, times, carriers, or cache states.

Should random parameters be added to URLs during speed testing?

Do not add them casually in routine stability tests, because random parameters may create new cache keys.

If you need to test cold cache or force origin fetch, design a separate test group and clearly separate it from normal cache access.

How many milliseconds is considered fast for website speed test results?

There is no universal answer independent of user region, file size, business type, and cache status.

Rather than applying a fixed threshold, first establish a stable baseline for your own website, then watch whether P50, P95, success rate, and different regions show significant degradation.

How do you determine whether the CDN or the origin is slow?

First look at cache status and TTFB: if it is normal on cache HIT and noticeably slower on MISS, the problem is more likely related to origin fetch; if all requests are slow, continue checking nodes, network, and origin.

Ultimately, use CDN origin fetch logs and origin logs to confirm; do not draw conclusions from a single client-side speed test.

Summary: Measuring 'fast or not' is easy; measuring 'stable or not' is what matters

When a website is sometimes fast and sometimes slow, the biggest danger is not lacking a speed test tool, but using one result to explain all users.

A truly effective CDN speed test needs to:

1. Fix the page, small file, and large file to avoid mixing different test targets;

2. Distinguish first visits, repeat visits, cache HIT, and MISS;

3. Test separately by target users' regions, carriers, and IPv4/IPv6;

4. Run multiple sampling rounds per node and cover different time periods;

5. Look at DNS, TCP, TLS, TTFB, download time, P50, P95, and success rate at the same time;

6. Use CDN and origin logs to confirm which layer the slow requests ultimately occurred in.

If you just want to quickly confirm the problem distribution, you can first useCdnChart Website Speed Test, observe the same URL across multiple regions; if test results connect to different networks or show clues of multiple CDNs, then useCdnChart CDN Checkto review domain resolution, responding IP, and vendor characteristics.

Don't rush to pursue an all-green speed test screenshot. Being able to consistently reproduce occasional slow requests and identify which regions and stages they are concentrated in is what makes a CDN speed test truly useful.