Your site loads quickly from the office. A customer on another continent sees a blank screen. Both observations can be correct: a local check tells you how the site behaves on one network path, not how it behaves for everyone. Before changing infrastructure, make that difference measurable.
Start with a question you can test
“Is the site slow globally?” is too broad. A useful question is: does the same product page take longer to show its main image in Singapore than in London under the same mobile connection profile? Pick a page that represents real traffic, rather than an empty health endpoint.
Use a repeatable browser test from each region. Hold the browser, viewport, connection profile, and page version constant. Run at least five repetitions per setup and save the individual results. A median summarizes the typical run; the slow runs still deserve investigation.
Find the delay in the request path
Open the waterfall and inspect the HTML request first. A long connection phase suggests a network path or connection setup issue. A long wait after the request is sent may include network travel, cache lookup, an origin fetch, or application work. TTFB alone does not identify which one.
Then inspect the largest visible element. If HTML arrives quickly but the hero image is discovered late, you have a resource discovery problem. If the page spends time executing scripts before it can paint, changing the CDN cannot remove that browser work.
Three places a page can spend your time
- 01ConnectionResolve the hostname and establish a secure connection.
- 02DeliveryReceive HTML and fetch the assets needed to render.
- 03RenderingRun scripts, lay out the page, and paint the main content.
Compare one change at a time
A CDN, a smaller image, and deferred video loading can all improve a page. If you change all three at once, you can measure the combined result, but you cannot attribute the entire improvement to the CDN.
Start with the original page and a version delivered through the CDN with equivalent cache and content behavior. Then test image changes and loading priorities as separate steps. Record whether the edge was warm, whether the browser cache was cold, and whether the request reached the origin.
| Setup | What changes | What it tells you |
|---|---|---|
| Baseline | Existing delivery and assets | How the page performs today |
| Delivery test | CDN path; equivalent assets | Effect of the delivery configuration |
| Asset test | Smaller, correctly sized images | Effect of reducing transferred bytes |
| Loading test | Defer nonessential resources | Effect of prioritizing initial content |
Read regional results without hiding the outliers
Report each region independently before presenting a global average. A fast result close to the origin can hide a poor result in a distant market. Include the median, the number of runs, and a measure of variation. Keep failures visible rather than quietly removing them.
Use LCP to describe when the main visible content appears. Use TTFB to investigate the start of delivery. A page-load milestone is another useful diagnostic, but it is not interchangeable with LCP. For production validation, compare real-user results by region and device after the change.
Turn the finding into the next action
If only distant cache hits are slow, investigate routing, peering, and the serving location. If misses are slow in every region, examine origin response time and the path between the edge and origin. If hits are fast but LCP remains poor, inspect image discovery, render-blocking resources, and main-thread work.
Keep a short record of the change, the test conditions, and the remaining limitations. An honest conclusion might be “image loading improved in these three test regions.” It should not become “every customer is several times faster” without the evidence to support that claim.
- Save raw results and waterfalls alongside the summary.
- Recheck login, checkout, and personalized pages after changing cache rules.
- Repeat a small regional test after major releases, then monitor real-user behavior.
