Content delivery networks sit near the top of every WordPress performance checklist. The pitch is simple: distribute static assets across edge servers, cut latency, serve files faster. For many solo operators, though, a CDN introduces more overhead than it solves—especially when you’re running a text-first site with minimal traffic.
The problem isn’t CDNs themselves. It’s the gap between what they’re built for and how most small operators deploy them.
When CDN cache misses cost more than direct origin requests
A CDN works by caching copies of your assets at edge locations close to visitors. When someone requests a file, the CDN checks its cache. If the file exists (a cache hit), the CDN serves it directly. If it doesn’t (a cache miss), the CDN pulls the file from your origin server, caches it, then serves it to the visitor.
That origin pull adds latency. For the first visitor after a cache expires, the request travels to the CDN, then to your origin, then back to the CDN, then to the visitor. That’s slower than a direct origin request—sometimes by 200–400 milliseconds.
If your site gets 500 visitors a day and your CDN cache expires every four hours, a meaningful percentage of requests trigger origin pulls. The benefit of edge caching evaporates when cache-hit ratios stay below 70%. Sites with low traffic or frequently changing content spend more time in cache-miss penalty than they gain from edge delivery.
Check your CDN dashboard’s cache-hit ratio. If it’s under 75%, you’re paying for infrastructure that slows more requests than it accelerates.
HTML caching at the edge breaks dynamic WordPress features
Most CDN providers let you cache HTML, not just static assets like images and CSS. The promise: serve entire pages from the edge without touching your origin server at all.
The catch: WordPress is dynamic. Comment counts update. Logged-in users see personalized navigation. Cart contents change. Caching full HTML breaks all of that unless you configure cache exceptions for every dynamic element.
Cloudflare’s default WordPress rules exclude logged-in users and query strings, but many operators enable aggressive HTML caching to chase Lighthouse scores. The result: broken checkout flows, stale post counts, and support requests from confused readers.
If you cache HTML, you need rules that exclude:
- Any page with cookies (wp-admin, cart, user sessions)
- URLs with query strings (?utm_source, ?add-to-cart)
- POST requests (forms, comments)
- Paths where content updates frequently (/feed, /comments)
Most small operators don’t have the traffic volume to justify the complexity. Caching assets only—images, CSS, JavaScript—delivers 80% of the performance gain with none of the breakage.
CDN costs scale faster than traffic for small sites
Free CDN tiers sound appealing, but bandwidth limits hit sooner than expected. Cloudflare’s free plan is genuinely unlimited for most use cases, but competitors like BunnyCDN, StackPath, and KeyCDN charge per gigabyte after you cross 100–500 GB per month.
A single viral post with embedded images can push a small site past free-tier limits. BunnyCDN charges $0.01–0.04 per GB depending on region. If a post with 2 MB of images gets 50,000 pageviews in a weekend, that’s 100 GB of bandwidth—$1 to $4 in CDN costs. Not catastrophic, but surprising if you budgeted for free infrastructure.
For most solo operators running text-heavy WordPress sites with under 10,000 monthly visitors, the marginal speed gain from a CDN doesn’t justify the configuration overhead or the risk of surprise bandwidth bills. A well-tuned origin server with image compression and browser caching delivers load times under two seconds—fast enough for retention and SEO.
When a CDN actually helps
CDNs make sense when:
You serve large files. Video embeds, downloadable PDFs, high-resolution images, or course assets benefit from edge delivery. A 50 MB video file served from a Singapore edge node loads faster for an Australian visitor than pulling from a US origin server.
Your traffic is geographically distributed. If your analytics show 30% of visitors from Europe, 30% from Asia, and 40% from North America, a CDN cuts cross-continent latency. If 90% of your traffic comes from one region, a well-located origin server is simpler.
You exceed 50,000 monthly pageviews. At that scale, cache-hit ratios stabilize above 80%, and the performance gain outweighs configuration complexity.
Before you add a CDN, run a baseline test. Use WebPageTest or GTmetrix to measure time to first byte (TTFB) and fully loaded time from multiple locations. Then enable the CDN, configure asset-only caching, and re-test. If TTFB improves by less than 150 milliseconds, the CDN isn’t doing much.
Want more operator-to-operator breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and infrastructure decisions that matter for small online businesses. No fluff, just the details that save you time and money.