CDN Caching Settings That Improve WordPress Performance

A content delivery network (CDN) can make a WordPress site feel faster by serving cached files from locations closer to visitors instead of requesting every asset from the hosting server. The result depends less on switching on a single feature and more on choosing safe cache rules for HTML, CSS, JavaScript, images, fonts, and logged-in sessions.

This guide explains CDN caching settings that improve WordPress performance, how to apply them safely, and where CDN caching cannot solve an underlying hosting or application problem. The recommendations are suitable for shared hosting, managed WordPress hosting, VPS hosting, and cloud hosting, although the available controls differ between providers.

What CDN caching means for WordPress

A CDN is a distributed network of proxy servers. When a visitor requests a file, the CDN can fetch it from the WordPress origin server, store a copy at an edge location, and deliver that copy to later visitors. This reduces repeated origin requests and can lower network distance for static content.

CDN caching is the process of storing an HTTP response at the CDN edge for a defined period. The response is considered “fresh” until its time-to-live (TTL) expires, unless a purge or revalidation occurs. Static assets such as images, stylesheets, JavaScript files, and web fonts are usually good caching candidates. Personalized HTML, shopping carts, account pages, and administrator screens generally require more careful rules.

There are usually three separate caching layers:

• Browser cache: Stores resources on the visitor’s device according to HTTP headers.
• CDN edge cache: Stores responses on the CDN’s servers and serves them without contacting the origin for every request.
• Origin or WordPress cache: Stores generated pages or database results on the hosting server.

These layers can work together, but conflicting rules may produce stale pages or unexpected behavior. A CDN does not automatically replace good WordPress hosting optimization, efficient themes, updated plugins, database maintenance, or adequate server resources.

Why caching settings affect WordPress performance

WordPress commonly generates HTML with PHP and database queries. If the CDN serves a valid cached response, the request may not need to run through PHP at all. Static files also become more efficient to deliver when they have long-lived cache headers and versioned filenames.

Performance gains are most likely on pages that are public, requested often, and relatively stable. A news article, documentation page, or product landing page is easier to cache than a checkout page or a dashboard. The CDN may also improve resilience during short traffic increases, although it does not guarantee that the origin will remain available.

Recommended CDN caching settings

1. Cache static assets for a long period

Set a long browser and CDN TTL for files that do not change at the same URL, such as CSS, JavaScript, images, icons, and fonts. A common design is to use a versioned or fingerprinted filename, such as theme.4f2c1.css, and then permit long caching. When the file changes, the filename changes too, so visitors can receive the new version without waiting for the old TTL to end.

WordPress plugins and themes do not always use fingerprinted filenames. Many append a version query string, such as style.css?ver=6.5. Whether a CDN treats query strings as part of its cache key varies by provider. Confirm the behavior before relying on query-string versioning. If possible, use a cache-busting workflow that changes the asset URL when the content changes.

Do not apply a long TTL to every URL simply because the response is a static file. A file upload, API endpoint, or dynamically generated download may contain user-specific information.

2. Use sensible HTML edge caching

Caching public HTML at the CDN can reduce origin work substantially, but it requires exclusions. A basic rule can cache anonymous GET and HEAD requests for public pages while bypassing requests that indicate a logged-in or personalized session.

Typical bypass signals include:

• A WordPress login or session cookie, including cookies beginning with wordpress_logged_in_.
• WooCommerce cart, checkout, or customer cookies.
• An Authorization request header.
• POST, PUT, PATCH, and DELETE requests.
• Paths such as /wp-admin/, /wp-login.php, /cart/, /checkout/, and /my-account/, where applicable.

Public pages can often use a shorter HTML TTL than static assets, especially on sites that publish frequently. A “stale while revalidate” policy may allow the CDN to serve a recently cached response while it checks the origin for an updated copy. Support and behavior differ by CDN, so confirm how the provider handles stale content and errors.

Do not cache a response merely because it returns status 200. Inspect whether the response contains a private account name, cart contents, nonce, payment information, or other session data.

3. Respect origin cache-control headers

The WordPress server can send headers such as Cache-Control, Expires, ETag, and Last-Modified. These headers communicate whether content may be stored and when it should be revalidated. A CDN rule that blindly overrides them can create stale or private-content problems.

For public static files, a policy similar to public, max-age=31536000, immutable can be appropriate when URLs are versioned. For public HTML, use a much shorter and site-specific policy. For private responses, use private or no-store where appropriate. The exact value should reflect how quickly content must change and whether the URL can safely be shared between visitors.

Use your browser’s developer tools or a command-line request to inspect response headers. Look for CDN-specific headers such as cache status indicators, but treat their names as provider-specific rather than as a universal standard.

4. Configure cache bypass rules before enabling broad caching

Create exclusions before creating a catch-all rule for WordPress HTML. The order of rules matters: a specific bypass rule must be evaluated before a broad “cache everything” rule. Review plugins that add custom endpoints, membership areas, search results, event booking, or account functionality.

WordPress’s /wp-json/ REST API often contains public and private endpoints. It should not be cached as a blanket category unless you understand the authentication and response behavior of each endpoint. Similarly, search URLs with query strings may generate many cache objects or expose results that should not be shared.

5. Choose a deliberate query-string policy

Query strings can represent either harmless asset versions or meaningful page state. For example, ?ver= may identify a stylesheet version, while tracking parameters may create unnecessary duplicate cache entries. An online store might use query parameters to change filters, currency, or availability.

Decide which parameters belong in the cache key and which can be ignored. Removing every query string is unsafe because it can make different responses appear identical. Keeping every query string can reduce cache reuse and increase storage. Use the CDN’s documented query-string controls, and test URLs that affect content before changing the policy.

6. Enable compression and modern protocols where supported

Brotli or gzip compression can reduce transfer size for text-based assets such as HTML, CSS, JavaScript, SVG, and JSON. The CDN should negotiate compression using the visitor’s Accept-Encoding header and should not compress already compressed formats such as JPEG, PNG, WebP, AVIF, ZIP, or most video files again.

HTTP/2 and HTTP/3 can improve connection behavior, but protocol support alone does not fix oversized images, slow database queries, or inefficient JavaScript. Enable them when offered, then verify that the site, origin, and TLS configuration operate correctly.

7. Cache images and fonts with care

Images often account for a large share of page weight. A CDN can cache them, but it does not automatically make an unnecessarily large image efficient. Use suitable dimensions and modern formats where compatible, provide responsive image variants through WordPress, and avoid stripping important image metadata without checking the result.

Fonts should be served with appropriate cache headers and limited to the weights and character sets that the site uses. Configure cross-origin access if fonts are served from a separate CDN hostname and the browser requires it. Do not use a wildcard access policy without considering the site’s security requirements.

8. Purge the right content after changes

A purge removes cached objects before their normal expiry. Full-site purges are simple but can send a large number of requests back to the origin when traffic returns. Prefer targeted purges for a changed post, stylesheet, script, image, or affected URL when the CDN and WordPress integration support them.

Publish workflows should account for related pages. Updating a post may require purging its permalink, the homepage, category archives, author archives, feeds, and cached API responses. A cache plugin or managed host may already perform some of these actions, so check for overlap before installing another automatic purge integration.

A practical setup process

1. Record a baseline. Test representative public pages, a logged-in page, a form, and any shopping or membership flow. Record response headers, page behavior, and origin response time before changing CDN rules.
2. Identify content types. Separate public HTML, static assets, private pages, API responses, downloads, and media. Treat each category differently.
3. Connect the domain securely. Follow the CDN provider’s DNS and TLS instructions. Confirm that the certificate covers the public hostname and that the origin connection uses the intended encryption mode.
4. Set static asset caching. Apply longer TTLs to versioned CSS, JavaScript, images, and fonts. Confirm that updated assets appear after a controlled change.
5. Add HTML bypass rules. Exclude administrators, login pages, sessions, carts, checkouts, account pages, and known private endpoints before enabling anonymous HTML caching.
6. Choose an HTML TTL. Start conservatively for public pages. Increase it only after confirming that publishing and editing workflows purge or revalidate content correctly.
7. Test cache hits and misses. Request the same URL more than once, inspect headers, and test from a clean session. Verify that a logged-in user cannot receive an anonymous cached response or vice versa.
8. Monitor after deployment. Review origin CPU, PHP workers, database load, error logs, cache status, and reports of stale content. Keep a record of each rule so it can be reversed.

Common mistakes and limitations

Caching everything: A global cache rule can expose personalized pages or break nonces and forms. Anonymous HTML caching must be limited to responses that are safe to share.

Using long TTLs without versioning: Visitors may continue receiving old CSS or JavaScript after a deployment. Version URLs or use controlled purges.

Assuming a CDN fixes slow WordPress code: A CDN does not remove the need to optimize database queries, reduce plugin overhead, use an appropriate PHP version, or allocate sufficient resources. Uncached requests still reach the origin.

Ignoring cache layers: A hosting cache, WordPress cache plugin, object cache, and CDN may each have different expiry rules. Conflicting settings can make troubleshooting difficult.

Failing to test cookies and headers: A cookie-based bypass may be incomplete, while a rule that ignores Set-Cookie can cache a response that should remain private. Review actual requests and responses rather than relying only on page speed scores.

Expecting global consistency: Different CDN edge locations may have different cache states while an object is being populated or revalidated. Purge propagation time also varies by provider. Time-sensitive content may need a shorter TTL or an explicit purge.

Overlooking origin capacity: A cold cache, purge event, or traffic spike can send many requests to shared hosting or a small VPS. Connection limits and PHP worker capacity still matter. Cloud hosting or managed hosting may offer easier scaling, but those options involve different operational trade-offs and costs.

Pros and cons of CDN caching for WordPress

• Pros: Lower repeat load on the origin, faster delivery of static assets, improved reach for geographically dispersed visitors, useful compression and protocol features, and a central place to manage cache policies.
• Cons: More configuration complexity, possible stale content, risk of exposing private responses, provider-specific behavior, extra DNS and TLS dependencies, and limited benefit for uncached dynamic requests.

The best configuration depends on the site’s audience, publishing frequency, personalization, ecommerce features, hosting plan, and tolerance for stale content. A small brochure site may need only static asset caching and carefully selected HTML caching. A membership site or store may use the CDN mainly for static files while leaving most HTML dynamic.

How to evaluate results

Use a repeatable comparison rather than relying on one score. Test the same URLs before and after the change, from similar network conditions, with both a warm cache and a cold cache. Include public and logged-in scenarios, mobile and desktop layouts, forms, search, media, and any transaction flow. Compare cache status, origin response time, page rendering behavior, error rates, and server resource use.

This methodology is consistent with the principles described in the Cloudflare Cache documentation, the MDN Web Docs HTTP caching guide, and WordPress guidance in the WordPress Developer Resources Transients Handbook. These sources explain cache headers, cache keys, revalidation, and application-level caching. They do not establish a universal setting or promise a particular speed improvement for every website.

Q&A

Should I cache WordPress HTML at the CDN?

Cache public, anonymous HTML only when you can exclude logged-in and personalized responses and reliably purge changed pages. Static asset caching is usually a safer first step.

What TTL should I use?

Use long TTLs for versioned static assets and a shorter, site-specific TTL for public HTML. The correct value depends on publishing frequency and how quickly changes must appear.

Can a CDN replace a WordPress caching plugin?

No. A CDN and a WordPress or server-side cache operate at different layers. They can complement each other, but duplicate or conflicting features should be reviewed.

Why does a page still seem slow after enabling a CDN?

The request may be a cache miss, the HTML may be personalized, or the bottleneck may be database work, PHP execution, JavaScript, images, hosting capacity, or third-party services. Inspect the waterfall and response headers before changing more CDN rules.

Is CDN caching safe for an online store?

It can be, but carts, checkout, customer accounts, payment steps, and other private responses must bypass shared caching. Follow the store platform and CDN documentation, and test with separate anonymous and authenticated sessions.

Informational note: CDN settings can affect availability, privacy, and hosting resource use. Apply changes gradually, keep backups of configuration, and consult the CDN, hosting, and ecommerce documentation before using broad cache rules on a production site.