Last updated 17 October 2026.
No affiliate links here. How this site makes money
If you run a business in one town, it’s fair to ask: “Why would I need a content delivery network? All my customers live within twenty minutes of the shop.”
It’s a good question, and the honest answer is “probably not for the reason you’ve been told”. A CDN’s headline benefit is serving files from a location near each visitor. If your visitors are already near your server, that benefit shrinks. But there are other reasons to put a local site behind a CDN, and some reasons not to bother. This article goes through both, and shows how to measure your own site rather than taking our word for it.
What a CDN does
A content delivery network keeps copies of your files on servers in many cities. When someone visits your site, they get those files from the nearest location instead of from your web host.
The bigger the network, the more likely there’s a copy close to each visitor. The principle holds for any CDN: the closer the copy, the shorter the trip.
Two things make a page slow: distance and server time
When someone loads your homepage, the wait before anything appears comes roughly from two places:
- Distance. Every request has to travel from the visitor to the server and back, and setting up a secure connection takes a few of those round trips before any content moves. The further away the server, the longer each trip takes.
- Server time. Once the request arrives, the server has to produce the page. On an uncached WordPress site, that means running PHP and querying the database for every visit.
A CDN mostly helps with the first. It does nothing for the second unless it’s caching the whole page, and many CDNs don’t cache HTML by default (see how to add a CDN to any WordPress site).
So for a local business whose server is in the same country as its customers, the distance part is usually already small. If the site feels slow, the cause is more likely to be server time, heavy images or too many scripts, and a CDN alone won’t fix those.
Why a local site might still want a CDN
Even with a nearby audience, there are good reasons to put a small-business site behind a CDN. They’re mostly not about distance.
Security
Many CDNs also filter traffic before it reaches your host; depending on the provider and plan, that can include DDoS protection and a web application firewall. For a small WordPress site, that means a lot of junk traffic (bots probing login pages, vulnerability scanners) can be stopped before it reaches your server. That’s less load on a cheap server and less risk. Check exactly what your chosen CDN includes.
A CDN also keeps your server’s IP address out of sight: when your website’s address points at the CDN, visitors and attackers see the CDN’s addresses, not your server’s.
HTTPS handled at the edge
A CDN normally issues the certificate for the visitor-facing connection and handles that part of the HTTPS work. You still want a valid certificate on your server too (our CDN guide explains why), but certificate problems at the visitor end become rare.
Static files off your server
Even without page caching, most CDNs cache images, CSS, JavaScript and fonts by default. On a typical brochure site those make up most of the bytes on a page. Serving them from the CDN takes that work off a small shared server.
Sudden spikes
Local businesses do get traffic spikes: a mention in the local paper, a post that does well on Facebook, a seasonal rush. Many CDNs also use “request collapsing”: when lots of visitors ask one location for the same uncached file at the same moment, it sends one request to your server and shares the answer with everyone waiting. Combined with cached static files, that makes a small server less likely to fall over when it matters.
Visitors who aren’t local
Your customers may be local; your visitors may not be. Holiday lets, wedding venues, estate agents selling to buyers abroad and anyone who appears in a travel guide all get visitors from far away. Check your analytics before deciding your audience is purely local.
When it’s not worth the fuss
There are good reasons to leave a CDN out:
- Your host already provides one. Some hosting plans include a CDN. Running a second CDN on top of the first adds complexity without much benefit. Pick one.
- Nobody will look after the DNS. Some CDNs ask you to move your domain’s nameservers to them; others, Cachper included, only need a few records added. Either way, someone has to change DNS safely. If the business’s DNS is managed by someone who won’t touch it, or email depends on records nobody fully understands, the move carries risk. A broken email setup costs a small business far more than a slightly slower page.
- The site is genuinely tiny and fast already. A one-page site on a good server with a few small images and a quick response time doesn’t gain much from extra layers.
- You’re hoping it’ll fix a slow server. It won’t, unless it caches whole pages, and even then every cache miss still waits for your server. Fix the server time first: better hosting, page caching on the server, and fewer heavy plugins.
A quick checklist
A CDN is probably worth setting up if two or more of these are true:
- [ ] Your analytics show a meaningful share of visitors from outside your region.
- [ ] Your site gets bot traffic or login attempts you’d like to block (most WordPress sites do).
- [ ] Your hosting is basic, shared hosting and you want to take load off it.
- [ ] You have, or can get, someone competent to manage the DNS.
- [ ] You occasionally get traffic spikes.
Probably not worth it (or not yet) if:
- [ ] Your host already includes a CDN that’s switched on.
- [ ] Nobody can safely manage the domain’s DNS and email records.
- [ ] Your real problem is a slow server response, which needs fixing first.
Measure it yourself
We won’t quote you a “X% faster” figure, because the only number that matters is the one for your site. Here’s how to get it.
1. Check your server response time
In Chrome or Firefox, open DevTools, go to the Network tab, reload the page and click the first request (the page itself). The Timing section shows how long the browser waited for the server’s first byte. Google’s web.dev guidance treats a time to first byte (TTFB) of 0.8 seconds or less as good and anything over 1.8 seconds as poor. It isn’t one of the Core Web Vitals, but a slow TTFB delays everything after it.
From a terminal, curl gives you a breakdown:
curl -o /dev/null -s -w "dns: %{time_namelookup}snconnect: %{time_connect}sntls: %{time_appconnect}snfirst byte: %{time_starttransfer}sntotal: %{time_total}sn" https://www.example.com/
Run it several times, because the first request can be slower. If “first byte” is much larger than “tls”, most of your wait is server time, not distance, and a CDN won’t change it much unless it caches the whole page.
2. Test from more than one place
Run the same test from somewhere far away. Free online testing tools let you choose a test location, or you can ask a friend abroad to run the curl command. Compare the numbers. If a distant location is much slower and you have visitors there, a CDN is likely to help them.
3. Check what’s being cached
Once a CDN is in place, look at the response headers. Most CDNs add a cache-status header (the name varies), and images, CSS and JavaScript should show as cached after the first load. HTML pages are only cached if your CDN does full-page caching: on Cachper, x-cachper: cache and an age header that rises on repeat requests show a page is being served from the edge. That tells you exactly which parts of the page come from the CDN and which still come from your server.
Our view
For most local businesses, a CDN is still worth having, but mainly for security, HTTPS and taking load off a modest server, not for raw speed. If you want whole pages cached at the edge too, Cachper is the option we recommend for WordPress; how to add a CDN to any WordPress site walks through it. If your customers really are all nearby and your host is quick, don’t expect a dramatic difference, and don’t let anyone sell you a paid CDN on the strength of distance alone.
If your measurements show the server itself is slow, start with caching at the server. We cover the layers in Why caching matters for WordPress.
If you’d rather have performance measured page by page over time, alongside search, trust and conversion, WebOptimizer does that. See WebOptimizer: measure your website, then fix it step by step.
