Start with a static pull CDN, not a reverse proxy. Before touching anything, take a full backup, record baseline TTFB and LCP figures, and run the change through staging first. That sequence protects you if a rewrite rule misfires or a purge rule fails, and it gives you the before-and-after numbers your client will actually ask about.
TL;DR:
- Using static pull CDN models simplifies setup, reduces risks, and supports most content-driven sites without altering core server behavior.
- Proper configuration, including cache purging and TLS mode full strict, is critical for effective CDN performance and avoiding redirect loops.
- Testing response headers, TTFB, and LCP measurements from multiple regions confirms the CDN is properly caching and delivering assets.
- Low cache hit ratios often stem from session cookies or improper invalidation, which should be tested and optimized through targeted purge rules.
- Agencies should prioritize static asset caching initially, reserving full HTML caching for high-traffic sites, to maximize performance gains safely.
Table of Contents
- Reverse proxy vs static pull: which CDN setup for WordPress suits you?
- How do you set up a CDN for WordPress step by step?
- How do you test and verify a CDN is actually working?
- Why does my CDN setup not improve WordPress speed?
- What does a CDN actually do for a WordPress site?
- Marcel’s take: why most agencies get CDN rollout backwards
- Let Wpcto handle your clients’ CDN setup and ongoing tuning
- Sources
Reverse proxy vs static pull: which CDN setup for WordPress suits you?
The reverse proxy (or DNS) model routes every request through the CDN before it reaches your origin server. You point your domain’s DNS at the provider, and the CDN sits in front of everything: HTML pages, admin logins, checkout flows, the lot. This unlocks a web application firewall, DDoS protection, and full-page edge caching for anonymous visitors. It also means a DNS misconfiguration can take the entire site offline, and cookie or session handling needs careful rules to avoid caching a logged-in dashboard for the next visitor.
The static pull (or push) model is narrower and far less risky. You keep your existing DNS and hosting exactly as they are, then use a plugin or a CNAME to have the CDN fetch and cache your images, CSS, and JavaScript from designated CDN plugins such as CDN Enabler or W3 Total Cache. Nothing about your server’s core behaviour changes, which is why WordPress’s own performance documentation treats this as the standard entry point for CDN integration.
For agencies managing several client sites, the choice comes down to how much operational overhead you can absorb:
- Static pull suits most brochure sites, blogs, and portfolios, where asset delivery is the bottleneck, not full-page latency.
- Reverse proxy suits high-traffic or security-sensitive sites (membership platforms, eCommerce) where WAF protection and HTML caching justify the added complexity.
- Multi-site agency accounts benefit from static pull first, because purge automation and SLA reporting are simpler to standardise across dozens of clients than a fleet of reverse-proxy configurations.
How do you set up a CDN for WordPress step by step?
Getting a CDN setup for WordPress right the first time means working through preflight checks before you touch a single setting. Skip this stage and you lose the ability to prove the CDN actually helped.
Preflight, before you connect anything:
- Take a full site backup (files and database) and confirm it restores cleanly.
- Record baseline metrics using WebPageTest and, where available, Chrome UX Report field data for TTFB and LCP.
- Clone the site to staging if your host supports it, and run the entire setup there first.
Connecting the CDN:
- Sign up with your chosen provider and generate an API key, or configure a pull zone that points at your origin.
- Install a CDN plugin (CDN Enabler and ShortPixel Adaptive Images are common choices) and enter your CDN base URL, or set a CNAME record if you’re using DNS-level integration.
- Set the TLS mode to Full or Full (Strict), never Flexible, since Imperva’s guidance on CDN SSL/TLS configuration is explicit that Flexible mode on an HTTPS origin routinely causes redirect loops.
- Add rewrite rules that exclude wp-admin, the login page, and cart or checkout URLs, so authenticated sessions are never served from the edge.
Locking down the origin:
- Restrict your origin server to accept traffic only from your CDN’s published IP ranges, and set CORS headers correctly for fonts and cross-origin assets.
Purge and warm:
- Configure purge-on-update so publishing or editing a post automatically clears the relevant edge objects, following the pattern Fastly describes for cache purging.
- Publish a test post, confirm the purge fires, then reload the page from a fresh location to check the edge has actually refreshed.
Pro Tip: Run the entire sequence on staging first, including a deliberate cache-busting test. If purge-on-update fails silently on staging, you’ve just saved yourself a client-facing incident on production.
How do you test and verify a CDN is actually working?
Checking response headers is the fastest way to confirm the CDN is doing anything at all. Look for x-cache, age, or via headers in your browser’s network tab; a hit will usually show a cache status and an age value greater than zero, while a miss confirms the request went back to origin.
From there, measure what actually matters:
- Compare TTFB and LCP before and after using WebPageTest, run from multiple regions if your CDN has multiple edge locations.
- Track your cache hit ratio over the first week; a low ratio despite correct setup usually points to a cookie problem, covered below.
- Test on a real phone over mobile data rather than only synthetic desktop runs, since WordPress’s own CDN lesson stresses that field conditions catch issues synthetic tests miss.
- Log into the site and confirm the dashboard and checkout pages bypass the cache entirely, and check for redirect loops on HTTPS.
A well-configured static pull setup typically shifts LCP more through image delivery than through raw network speed, because edge image resizing and modern format negotiation directly targets the resource that usually dominates LCP. If your before-and-after numbers barely move, the asset pipeline, not the CDN, is usually the problem.
Why does my CDN setup not improve WordPress speed?
Cookies are the single most common reason a CDN setup underperforms. Plugins that set session cookies on every page view, even for anonymous visitors, force the CDN to bypass its cache entirely, and performance engineers consistently flag this as the top cause of low hit rates. Audit your plugin list, disable unnecessary cookies, and re-test your hit ratio afterwards.
The second most common mistake is using Flexible TLS, which encrypts traffic between browser and CDN but leaves the CDN-to-origin leg unencrypted or mismatched, producing redirect loops that never resolve. Full (Strict) mode with a valid origin certificate avoids this entirely.
Third, site-wide purges on every update waste cache warmth unnecessarily. Targeted, tag-based invalidation clears only the objects that changed, keeping the rest of your cache warm.
- Audit cookies and disable any that aren’t functionally required.
- Switch from Flexible to Full (Strict) TLS and re-test for redirect loops.
- Replace blanket purges with targeted invalidation where your provider supports it.
- Enable Brotli compression, HTTP/3, and font preloading at the edge to push LCP further.
Pro Tip: If you manage several client sites, standardise your purge rules once and reuse the template. A single tag-based invalidation policy tested on one site saves hours across a client roster.
Full edge caching of HTML is worth considering once your traffic is high enough to justify the added complexity, but always exclude dynamic routes like cart, account, and checkout pages from that layer.
What does a CDN actually do for a WordPress site?
A CDN’s core job is distance reduction: instead of every visitor pulling images, CSS, and JavaScript from a single origin server, copies sit on servers physically closer to them. That’s static asset caching, and it’s what most WordPress CDN setups start with, because it requires no change to how WordPress generates pages.
HTML or edge caching goes further. Instead of just caching the assets on a page, the CDN caches the whole rendered page for anonymous visitors, meaning WordPress and its database aren’t queried at all for that request. This is where the bigger performance jump comes from, but it’s also where the risk concentrates: get the exclusion rules wrong and a logged-in admin sees a cached version meant for the public, or a cart page shows another shopper’s contents.
Most agencies underestimate how much of their site’s load time is genuinely resource delivery versus rendering. A WordPress performance audit run before rollout usually shows whether static asset caching alone will move the needle, or whether the site needs full HTML caching to hit meaningful LCP targets. Static caching is safer and covers most of the benefit for content-driven sites; HTML caching delivers more but demands the exclusion discipline covered above.
Marcel’s take: why most agencies get CDN rollout backwards
Most agencies I’ve watched implement CDN setup for WordPress start with the reverse proxy model because it sounds more impressive to pitch to a client. That’s backwards.
Agencies often seek specialist help for these decisions: not because the technical steps are secret, but because getting the sequencing wrong once, on a live client site, costs more in trust than the setup ever saved in load time. Our performance optimisation and hosting migration work exists precisely to take that sequencing risk off an agency’s plate.
If you’re weighing whether CDN work and ongoing maintenance is worth bringing in-house or handing off, the WordPress Profit Calculator shows what recurring care plans could be worth across your existing client base, in under 90 seconds.
— Marcel
Let Wpcto handle your clients’ CDN setup and ongoing tuning
Every agency reading the setup steps above already knows the real cost isn’t the initial configuration. It’s the purge failure six months later, the TLS redirect loop nobody catches until a client emails, the cookie audit that never happens because nobody has the hours. Wpcto exists so your team never has to be that hour.
Our WordPress support services cover performance optimisation, hosting and migration, and ongoing CDN tuning as part of standard maintenance retainers, so your agency keeps the client relationship while we handle the delivery behind it. For agencies that want the work fully white-labelled, our white-label WordPress support sits invisibly behind your brand; clients never know we exist. Before deciding how to structure that, run your client list through the WordPress Profit Calculator to see the recurring revenue currently sitting unclaimed in your existing WordPress base, then get in touch to talk through a retainer that fits your team.
Sources
For the official line on integration patterns, read WordPress’s performance optimisation documentation. On purge mechanics, Fastly’s explainer on cache purging is worth bookmarking, alongside Imperva’s TLS configuration guidance and this caching plugin compatibility breakdown for Elementor-built sites.