By Mehdi HassanWhat is a CDN, in plain terms?
A CDN, or content delivery network, is a set of servers spread across many cities that keep copies of your website's files and serve them from the location nearest each visitor. Instead of every request travelling to one origin server, most are answered by a nearby edge server. Less distance means less waiting.
Think of it like warehouses instead of a single factory. Your origin is where the site is built or stored. The CDN keeps stock in regional warehouses, so a visitor in Singapore isn't waiting on a round trip to Virginia for every image. The files are the same; only the delivery route changes.
For startups, a CDN is part of hosting rather than a separate purchase. Our guide to website hosting for startups explains where it sits next to the domain, DNS and the host itself.
When do you need a CDN for a website?
You need a CDN for a website whenever visitors are not all next to your server, which covers almost every marketing site. The good news is you probably already have one. Modern hosts put a CDN in front of your site by default, so the real question is whether it's caching the right things, not whether to buy one.
Where your site runs | CDN included? | What to check |
|---|---|---|
Vercel | Yes, built in | Static and cached pages served from the edge |
Netlify | Yes, built in | Cache headers on dynamic routes |
Cloudflare Workers or Pages | Yes, it is the CDN | Caching rules for HTML, not just assets |
Framer | Yes, managed for you | Image sizes and third-party embeds |
Webflow | Yes, managed for you | Image sizes and custom code |
WordPress on basic hosting | Often not | Add a CDN or a caching plugin with one |
The one setup that often lacks a CDN is a self-managed server, such as WordPress on shared hosting or a single virtual machine. There, adding Cloudflare in front of the origin is a common, low-effort fix. If you're comparing hosts for a new build, Vercel vs Netlify vs Cloudflare covers how each handles edge delivery and cost.
How does a CDN affect LCP and page speed?
A CDN improves page speed mainly by cutting the time to first byte, which is the start of every other timing, including Largest Contentful Paint (LCP). LCP measures when the biggest visible element, usually a hero image or headline, finishes rendering. The faster the HTML and that hero image arrive, the sooner LCP can happen.
Google's guidance on Largest Contentful Paint breaks the metric into four parts: time to first byte, resource load delay, resource load time and render delay. A CDN shrinks the first and third for visitors far from your origin. It does nothing for the second and fourth, which depend on how the page is built: whether the hero image is discoverable early, and whether scripts block rendering.
That's why a CDN is necessary but not sufficient. We regularly see sites on excellent edge networks with slow LCP because the hero is a large unoptimized image loaded by JavaScript. Interaction delay (INP) is also mostly about scripts running in the browser, and no edge server can fix that.
What is edge caching, and what should be cached?
Edge caching means the CDN stores a copy of a response at its edge servers and reuses it for later visitors until it expires or is cleared. Images, fonts, CSS and JavaScript are cached almost everywhere by default. The bigger gain comes from caching the HTML of each page too, because then the origin doesn't need to render it for each visit.
Marketing sites are good candidates for full-page edge caching, because most pages are the same for every visitor. Pricing, features, blog posts and landing pages rarely depend on who's looking. In Next.js, static generation and incremental revalidation produce pages that the host can cache at the edge and refresh in the background when content changes.
- Cache aggressively: images, fonts, CSS, JavaScript bundles with hashed file names.
- Cache with revalidation: marketing pages, blog posts, docs pages, rebuilt when the CMS publishes.
- Don't cache: form submission endpoints, preview and draft routes, anything showing personal data.
- Be careful with: pages that vary by country or language, which need the cache keyed correctly.
How cache invalidation works when you publish
When an editor publishes a change in the CMS, the cached copies at the edge are now out of date. Good setups handle this automatically: the CMS sends a webhook, the site regenerates the affected pages and tells the CDN to drop the old copies. On Framer and Webflow, publishing does this for you.
On a custom Next.js build, someone has to wire it up. If edits take minutes or hours to appear, or appear for some visitors but not others, the invalidation step is usually what's missing. It's one of the first things we check when a team says the site doesn't show their changes.
When does a global audience make a CDN matter more?
A CDN matters most when your visitors are spread across continents and your origin sits in one region. A US-hosted site viewed from Europe, India or Australia gains the most from edge delivery, because each uncached request crosses an ocean. If nearly all your traffic is in one region near your origin, the gain is smaller but still real for images.
For multilingual or multi-region sites, the CDN also needs to cache each language version separately. If your site redirects visitors by country or language, check that the cache doesn't serve one version to everyone. Information architecture decisions matter here too: subdirectories such as /de/ and /fr/ are simpler to cache correctly than versions switched by cookie. Our guide to website information architecture goes into URL structure.
What can't a CDN fix?
A CDN can't fix a page that is heavy by design. It moves bytes faster; it doesn't reduce how many there are. Oversized images, video backgrounds that autoplay at full resolution, several tag managers and chat widgets all still have to download and run in the visitor's browser.
It also doesn't fix rendering problems. A React app that builds the whole page in the browser shows a blank screen until JavaScript loads, wherever the files come from, and search and AI crawlers may see little content. That's a build issue, covered in our guide to moving a React SPA to an SEO-friendly website. Likewise, a CDN won't make inaccessible markup accessible.
How do you check whether your CDN is working?
You check a CDN by looking at the response headers on your pages and testing load time from the regions your visitors are in. Most CDNs add a header showing whether the request was a cache hit or miss, such as x-vercel-cache on Vercel or cf-cache-status on Cloudflare.
Open the network panel
In your browser's developer tools, load a page in a private window and select the main document request.
Read the cache header
Look for a hit or miss status. Reload once; a second visit should usually be a hit for cached pages.
Test from other regions
Use a speed testing tool that lets you pick a test location near your buyers, and compare time to first byte.
Check field data
Look at Core Web Vitals in Search Console or PageSpeed Insights, which reflect real visitors rather than one lab test.
If pages are always a miss, the host is rendering them on every request. That's fixable in configuration for most stacks. When we build a website on Next.js, we statically generate marketing pages and cache them at the edge by default; our own site runs on Next.js on Cloudflare Workers.
