What will a CDN cache not fix on a slow page?

Why is your page still slow after you put it behind a CDN?

Because a cache changes how quickly bytes arrive, and a large part of what people experience as slowness happens after the bytes have already arrived. If the delay lives in the browser rather than on the wire, no amount of edge caching will touch it.

This is one of the most expensive misunderstandings in web performance, expensive because it sends people to buy infrastructure when the problem is in their own page. I have watched teams move hosting, add a CDN, and see almost no change in their field data.

The way out is to know which part of which metric you are actually trying to move. Google publishes that breakdown, and once you read it the arithmetic of what a CDN can and cannot recover becomes uncomfortably clear.

What does a CDN actually make faster?

The network portion of the trip. It shortens the physical distance between a visitor and a copy of your file, so the first byte comes back sooner and static assets download quicker. Those are real gains. They are also bounded, and the bound is knowable.

Google defines Time to First Byte as the time from when the user initiates loading the page until the browser receives the first byte of the HTML document response. That is the measurement a CDN most directly attacks, along with how long it takes to download the largest asset once the browser starts fetching it.

So a CDN is the right tool for a genuine distance problem. If your server is in one region and your buyers are in three others, edge caching is not optional, it is basic hygiene. If you want the mechanics of that first metric, I have written about Time to First Byte and what it means for SEO separately.

How much of your LCP is a CDN even able to touch?

Less than half, by Google's own accounting. Google breaks Largest Contentful Paint into four sub-parts: Time to First Byte, resource load delay, resource load duration, and element render delay. A CDN acts on the first and the third. It does nothing for the second or the fourth.

The recommended proportions make the ceiling explicit. Google's guidance suggests roughly 40% of your LCP budget should be Time to First Byte, under 10% resource load delay, roughly 40% resource load duration, and under 10% element render delay. Add up the two a CDN influences and you get about 80% in an already well-built page.

But read the middle two definitions carefully, because that is where wasted effort hides. Resource load delay is the time between TTFB and when the browser starts loading the LCP resource, and element render delay is the time between when that resource finishes loading and the element rendering fully. Both are consequences of how your page is written, not where it is served from. A hero image the browser cannot discover until it has parsed a stylesheet will be late from Tokyo and late from the next street.

Why does caching do nothing for INP?

Because Interaction to Next Paint is not about delivery at all. Google's documentation says INP observes the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. It measures what happens when someone presses something, long after your cache did its job.

The documentation is also specific about the boundary. The intent of INP is not to measure all the eventual effects of an interaction, such as network fetches and UI updates from other asynchronous operations. It is measuring the time the next paint is blocked, which is a browser problem, not a bandwidth problem.

What actually causes it is work on the main thread. Google's documentation points at long tasks on the main thread, along with large and complex layouts, style calculation complexity and DOM size. Every one of those is something in your own code. A faster copy of the same heavy JavaScript is still the same heavy JavaScript. If this is your situation, the fix lives in what INP measures and how to improve it.

What is the difference between delivery and execution?

Delivery is how long it takes to get the file to the browser. Execution is how long the browser then spends parsing, running and painting it. CDNs are a delivery technology, and most of the slowness people complain about on modern marketing sites is an execution problem.

The distinction has an obvious test. If your page is slow on a fast connection sitting next to your server, it is not a delivery problem. Nobody performs that test, because the instinct when a page is slow is to reach for infrastructure, which feels like doing something more than opening the page and profiling it does.

Third-party scripts are where execution costs usually come from, and they are cached beautifully by everyone and still ruinous. The tag manager, the chat widget, the analytics, the heatmap, the consent banner. All delivered instantly from an edge somewhere, all competing for the same single main thread. I have written about what happens when a third-party script breaks your page, and the performance version of that problem is quieter but more constant.

Does a CDN help a page that is slow for one user in one country?

Possibly, and that is the one case where reaching for it first is reasonable. Geographic variation in your field data is the signature of a distance problem, and distance is exactly what edge caching solves. The mistake is generalising from that case to every slow page.

So look at the shape of the problem before choosing the tool. If one region is markedly worse and the rest are fine, suspect the network. If every region is equally mediocre, the network is not your differentiator and you are looking at something in the page that is slow for everyone.

That distinction takes ten minutes of looking at data segmented by country, and it decides whether you spend money or spend engineering time. I would rather spend ten minutes on the diagnosis than a quarter on the wrong remedy, and the cost of guessing here is usually a quarter.

What should you measure before blaming the network?

Field data, at the percentile Google actually uses. For INP, its documentation says the 75th percentile of all page views is reported. For LCP, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits. Your median is not the number being judged.

That percentile matters more than people expect, because it is where the bad cases live. A page that is fine for most visitors and terrible for a quarter of them will read as a problem, correctly, and averaging that away is how teams convince themselves everything is fine while their field data says otherwise.

Then break the metric into its parts rather than staring at the total. Once you know whether your LCP is mostly TTFB or mostly render delay, you know whether to buy a CDN or to rewrite a template. A single number tells you that you have a problem. The sub-parts tell you whose problem it is.

When is a CDN genuinely the right fix?

When your Time to First Byte is eating most of your budget, when your audience is geographically spread, or when you serve large static assets to a lot of people. In those situations it is the correct and efficient answer, and I am not arguing against CDNs.

What I am arguing against is sequence. Adding a CDN to a page carrying six hundred kilobytes of blocking JavaScript is optimising the 40% you can reach while ignoring the part that is actually broken. Do the cheap diagnosis first, then buy the thing that addresses what you found.

There is also a reason to add one that has nothing to do with speed, and it is fine to say so out loud: resilience, security and traffic absorption are legitimate purchases on their own terms. Just do not expect them to show up in your Core Web Vitals, and do not promise anyone that they will.

What should you do next?

Open your field data, segment it by country, and break your LCP into its four sub-parts. If Time to First Byte dominates and one region is worse than the others, a CDN is your answer. If render delay dominates or every region is equally slow, close that tab and open your page's code.

Then check INP separately, because it will not follow LCP and it will not respond to any of this. If your interactions are above the thresholds Google publishes, the work is auditing what runs on the main thread, and that is usually a conversation about how many third-party scripts you have agreed to carry.

Across 70+ projects for 25+ clients, the pages I have made meaningfully faster got faster by removing things rather than by relocating them. If your site is slow and you are about to change hosting, reach out first and let's find out which 40% you are actually fighting.