WordPress CDN: how to choose the right one

There are two kinds of CDN for WordPress: an asset CDN, which a plugin wires up by rewriting the URLs of your images, CSS and JavaScript, and a full-site proxy, which sits in front of your whole domain and can also cache the HTML pages themselves. Which one is right depends on where your site loses time, who your visitors are and how much change to your DNS you are willing to make. This guide compares both types and gives you a checklist for picking a provider.

For the basics, see what a CDN is. If you don't know yet why your site is slow, find the cause first with the guide on why WordPress sites are slow.

The two kinds of WordPress CDN

Asset CDN (static files via plugin)

An asset CDN serves only static files. You create a pull zone at the provider and get a hostname such as cdn.example.com. A WordPress plugin then rewrites the URLs in your HTML so that files from wp-content and wp-includes load from that hostname. On the first request, the CDN pulls each file from your server and keeps a copy.

Your domain, your DNS and your HTML stay where they are. Every page view still goes to your hosting, which builds the HTML as before. Only the files the page references come from the CDN.

Full-site proxy (whole domain via nameservers or DNS)

A full-site proxy takes over the traffic for your entire domain. Depending on the provider, you either delegate your nameservers to it or point your domain's DNS at it. From then on, every request, HTML included, passes through the provider's edge servers first. The edge serves what it may cache and forwards the rest to your hosting.

Because all traffic flows through it, a full-site proxy can cache the HTML of public pages, terminate HTTPS and filter attacks before they reach your server. It is also the bigger change, since your whole site depends on the proxy being set up correctly.

What each type caches

The difference that matters most is the HTML. On a typical WordPress site, the slow part of a page view is the server building the page with PHP and the database. An asset CDN doesn't touch that step, so your time to first byte stays the same.

A full-site proxy can serve that HTML from the edge for anonymous visitors, without PHP or the database being involved at all. That is why this type helps most when TTFB is high or your server struggles in peak times.

Assets are cached by both types. If your pages are already generated quickly (for example thanks to a good page cache on the server) and visitors mainly wait for large files, an asset CDN may cover much of what you need.

Pros and cons in practice

When an asset CDN is enough

• Your server response is already fast, and heavy images or scripts are the bottleneck.
• You can't or don't want to change the nameservers or DNS of your domain.
• You want a change you can undo by switching off a plugin.

Watch out for the typical side effects. Files hardcoded in the theme, in page builder CSS or in inline styles are often not rewritten and keep loading from your origin. Web fonts loaded from a different hostname need a matching Access-Control-Allow-Origin header, or the browser refuses to use them. And WordPress adds a ?ver= query string to enqueued scripts and styles: the CDN must include query strings in its cache key, otherwise visitors keep getting the old file after an update.

When a full-site proxy pays off

• Your TTFB is high on public pages, or the server slows down during a newsletter send or a sale.
• Your visitors are spread across several countries or continents.
• You want DDoS filtering and HTTPS handled in front of your hosting.

The trade-offs are real, too. You have to get the bypass rules right so no personal page is ever cached for everyone. After you publish or edit a post, cached HTML must be refreshed. Your server now sees the proxy as the client, so your security or statistics plugins need to read the visitor's real IP from the header the provider passes along. And attackers who know your server's IP address can still bypass the edge, unless your host only accepts traffic from the proxy.

The selection checklist

Use these questions when you compare providers. They apply to any CDN, whatever its name.

HTML caching and bypass rules

Can it cache HTML, and how does it decide what to skip? For WordPress, these must always reach your server uncached:

• /wp-admin/, wp-login.php and admin-ajax.php
• Visitors with a wordpress_logged_in_ cookie (the WordPress cookie reference lists all cookies core sets)
• Commenters with a comment_author_ cookie, so they see their own comment awaiting moderation
• Password-protected posts, which use a wp-postpass_ cookie
• Post previews and anything personalized, such as carts and account pages in a shop

WordPress helps here: for logged-in users, password-protected posts and 404 pages it sends Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private. A proxy that respects Cache-Control headers will therefore bypass these responses. Plugins that personalize pages without sending such headers are the risk, so test them.

Purging after you publish

When you update a post, the post itself changes, and so do the homepage, category and tag archives and the feed. Ask how you clear the cache: per URL, for the whole domain, from a dashboard, via API? Automatic purging on publish depends on the provider and your setup. Without it, you need a short enough cache lifetime or a routine for purging after edits.

Image optimization

Does the CDN convert images to WebP or AVIF, and does it still serve the original to browsers that don't support the new format? This can save you an image plugin that does the work on your server.

SSL between visitor, edge and server

With an asset CDN, the CDN hostname needs its own certificate. With a full-site proxy, the edge holds the certificate for your domain. Make sure the connection from the edge to your server uses HTTPS too. If the proxy talks plain HTTP to a WordPress site that forces HTTPS, you can end up in an infinite redirect loop, as the WordPress HTTPS documentation explains.

Security and DDoS protection

An asset CDN protects only the files it serves. Attacks on your pages, login or XML-RPC still hit your server directly. A full-site proxy can filter floods, block countries or IP ranges and rate-limit abusive clients at the edge. Check what is included in the plan you are considering and what costs extra.

Edge locations near your audience

A CDN only helps with distance if it has edge servers close to your visitors. Check where your visitors actually come from, then which regions the provider covers on your plan.

Setup effort and what happens to DNS and email

For an asset CDN, you enter a hostname in a plugin and perhaps add one CNAME record. For a full-site proxy, your DNS usually moves to the provider. That means every record must be present there before you switch, including the MX records for email and the TXT records for SPF, DKIM and domain verification. The checklist for changing nameservers without downtime walks through this step by step.

Visibility

Look for a response header that shows hit, miss or bypass on every request, and for statistics on cache hit ratio, traffic from edge versus origin and error rates. Without them, you can't tell whether the CDN does anything useful.

Measure before and after

Don't judge a CDN by how it feels. Before you switch, record a baseline:

1. Run your homepage, a post and an archive page through corewebvitals.page. Note the real-user data (if your site has enough traffic) and the Lighthouse results for mobile and desktop.
2. Measure the server response of the HTML from your own machine:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

3. After the switch, request the same page twice and look at the headers. The second request should show a cache hit.

curl -sI https://example.com/ | grep -i -E "cache|age"

4. Log in and check that wp-admin and your front end show a bypass, not a hit.
5. Compare the real-user data again once it has caught up, since it covers the last 28 days.

The guide on measuring website speed explains how to keep such a comparison fair.

How fast.site helps

fast.site is a full-site proxy. It sits in front of your existing WordPress hosting, so you keep your host and your site. You add your domain in the dashboard, point your nameservers to fast.site and verify. From then on fast.site manages your DNS, so all existing records, including MX records for email, must be in the fast.site DNS zone.

Fast Edge Cache™ serves public pages and assets from edge servers in the regions available on your plan. fast.site respects the Cache-Control headers your WordPress site sends, and the fs-cache response header shows HIT, MISS or BYPASS, so you can check wp-admin and logged-in sessions yourself. After publishing, you can purge single URLs or the whole domain in the dashboard, with a purge log, or via the API from your own scripts.

JPEG and PNG images are converted to WebP on the fly for browsers that support it, with AVIF depending on your plan. Every domain gets automatic Layer 7 DDoS detection and free, auto-renewed SSL certificates. Details are on the WordPress page and in the caching docs.

Measure your site before and after with the same pages and tools. You can test it with a free 7-day trial.

FAQ

Do I need a CDN plugin for WordPress?

Only for an asset CDN, because the plugin rewrites your file URLs to the CDN hostname. A full-site proxy works at the DNS level and needs no URL rewriting, since your domain stays the same. Some providers still offer a plugin for tasks such as purging.

Does a CDN replace my caching plugin?

Not necessarily. A page cache on your server speeds up every request that misses the CDN and all logged-in traffic, as the WordPress cache documentation describes. With a full-site proxy it matters less for anonymous visitors, but it rarely hurts to keep it.

Will a CDN break wp-admin or logins?

It shouldn't, as long as wp-admin, the login page and logged-in visitors bypass the cache. WordPress sends no-cache headers for logged-in users. Test it after setup: log in, edit a post and check the cache header on the admin pages.

Why don't my changes show up after I update a post?

The CDN still serves the cached copy. Purge the post URL and the pages that list it, such as the homepage and category archives. For CSS and JavaScript, check that the CDN keeps the ?ver= query string in its cache key.