CloudFront WordPress Setup (2026): A Cache Invalidation and Image Optimization Playbook

A single wildcard invalidation on a 40-page WordPress site costs the same as invalidating one object: nothing for your first 1,000 paths per month, then $0.005 per path after that. Yet most CloudFront WordPress setups still fire path-by-path invalidations on every deploy, burning through that free tier in a week and adding 200–800 ms of stale-content windows in the process. As of Q2 2026, CloudFront serves from over 600 edge locations and supports HTTP/3 by default on new distributions — but none of that matters if your invalidation strategy is wrong and your images ship as uncompressed PNGs. This article gives you three things: a battle-tested invalidation pattern that eliminates stale content without over-purging, an image optimization pipeline that pairs origin-side compression with edge delivery, and a cost model comparing CloudFront's per-request pricing against flat-rate alternatives so you can make an informed infrastructure decision.

Why Your CloudFront WordPress CDN Configuration Probably Leaks Stale Content

WordPress writes HTML dynamically. Every published post, updated plugin, or WooCommerce price change generates new markup, but CloudFront has no built-in hook into the WordPress lifecycle. The default TTL on a CloudFront distribution is 86,400 seconds. If your origin does not send explicit Cache-Control headers, CloudFront will hold onto a stale page for a full day. Most WordPress hosts ship with no cache-control headers on HTML responses at all.

The failure mode is predictable: editorial publishes a correction, the origin reflects it immediately, but edge locations continue serving the old version until TTL expiry or manual invalidation. For media and commerce sites, this is not an inconvenience. It is a revenue-impacting incident.

Cache Invalidation Patterns That Actually Work in 2026

Pattern 1: Versioned Asset Paths (Static Resources)

For CSS, JS, and image assets, append a content hash or build ID to the filename or query string. WordPress does this partially through wp_enqueue_style and wp_enqueue_script version parameters, but many themes and plugins hardcode asset URLs. Audit your rendered HTML. Every static asset URL should contain a unique version token. When it does, you never need to invalidate these objects — the new URL is a cache miss by definition, and CloudFront fetches the updated file on the first request.

Pattern 2: Short TTL + Stale-While-Revalidate (HTML)

Set Cache-Control on HTML responses to a short max-age (60–300 seconds) combined with stale-while-revalidate. This lets CloudFront serve a slightly stale page while fetching the fresh version in the background, keeping TTFB low without manual invalidation. As of 2026, CloudFront honors stale-while-revalidate when your origin sends it, which was not consistently the case before late 2024.

Pattern 3: Event-Driven Invalidation via Lambda or CI/CD

For sites where even 60 seconds of stale content is unacceptable — breaking-news publishers, flash-sale storefronts — trigger invalidation from the WordPress save_post hook. A lightweight Lambda function subscribed to an SNS topic or an EventBridge rule can call CreateInvalidation with only the changed URL paths. Keep invalidation batched: one API call can contain up to 3,000 paths, and it counts as a single invalidation request for billing purposes.

What Not to Do

Do not use /* wildcard invalidations on every deploy. It forces CloudFront to re-validate every cached object across all edge locations, which spikes origin load and defeats the purpose of a CDN. Reserve wildcards for genuine site-wide changes like a theme swap or a global header update.

Image Optimization Pipeline for CloudFront WordPress Sites

Images account for 40–70% of total page weight on a typical WordPress site. Serving unoptimized originals through CloudFront just delivers large files faster — it does not solve the core performance problem.

Origin-Side: Compress Before It Hits the Edge

Use a build-time or upload-time pipeline that converts images to AVIF with a WebP fallback. As of 2026, AVIF support exceeds 93% of global browser traffic, making it the primary target format. WordPress 6.5+ supports AVIF uploads natively. For older installations, server-side tools like libvips or Imagick can handle the conversion at upload time via a mu-plugin or CLI script.

Set explicit dimensions on every image in your markup. Without width and height attributes, Cumulative Layout Shift (CLS) increases, and Core Web Vitals suffer regardless of how fast the image arrives.

Edge-Side: Cache-Control and Content Negotiation

Configure your CloudFront cache policy to include the Accept header in the cache key for image paths. This lets you serve AVIF to browsers that request it and fall back to WebP or JPEG for the rest, all from the same URL. Without Accept in the cache key, CloudFront will serve whichever format it cached first to all subsequent visitors.

Set long TTLs (31536000 seconds) on image assets with immutable directives. Combined with versioned filenames, this means each image is fetched from origin exactly once per edge location.

Responsive Images and Srcset

Generate multiple sizes at upload time — 480w, 768w, 1200w, 1920w at minimum — and use srcset in your markup. CloudFront caches each variant independently. The bandwidth savings at scale are significant: a mobile visitor on a 480px viewport should not be downloading a 1920px hero image, even if it arrives in under 100 ms.

CloudFront WordPress Setup: Step-by-Step Configuration (2026)

This assumes you have an existing WordPress installation and an AWS account. The sequence matters because misconfigured steps compound into hard-to-debug caching issues.

1. SSL certificate in ACM (us-east-1): CloudFront requires certificates in the us-east-1 region regardless of where your origin lives. Request a certificate covering your domain and www subdomain. DNS validation takes under five minutes if you control the zone.
2. Create the distribution: Set your origin to your WordPress host's domain. Enable Origin Shield in the region closest to your origin server — this collapses multiple edge requests into a single origin fetch. Select the recommended cache policy or create a custom one that keys on Host, Accept (for images), and Authorization (if you serve authenticated content).
3. Origin request policy: Forward the Host header so WordPress generates correct URLs in its markup. Forward cookies only for paths that require them (wp-admin, wp-login.php). For all public-facing paths, strip cookies entirely to maximize cache hit ratio.
4. Behaviors: Create separate cache behaviors for wp-admin/*, wp-login.php (set to no-cache, forward all headers and cookies), and everything else. Add a behavior for wp-content/uploads/* with long TTL and Accept in the cache key.
5. DNS cutover: Point your domain's A/AAAA records to the CloudFront distribution. If using Route 53, create an alias record. If using an external DNS provider, create a CNAME. TTL propagation varies, so monitor with dig or a global DNS checker.
6. Verify: Check response headers on your public pages. You should see X-Cache: Hit from cloudfront after the second request. Monitor the CloudFront console's cache statistics dashboard — target a cache hit ratio above 90% for static assets within the first 48 hours.

Cost Model: CloudFront vs. Flat-Rate CDN Alternatives

CloudFront pricing is usage-based: data transfer out starts at $0.085/GB in North America and drops with volume, plus $0.0075–$0.01 per 10,000 HTTPS requests. For a WordPress site serving 10 TB/month, the CloudFront bill lands in the $850–$1,000 range before considering invalidation costs and Lambda@Edge invocations.

Flat-rate CDN providers offer a different model that becomes compelling at scale. BlazingCDN delivers comparable stability and fault tolerance to CloudFront — trusted by enterprises including Sony — at a fraction of the cost. At 10 TB/month, BlazingCDN pricing sits at $100/month. At 100 TB, it is $350/month (versus roughly $5,500+ on CloudFront at standard rates). Even at the 500 TB tier, BlazingCDN costs $1,500/month with overage at $0.003/GB, scaling down to $0.002/GB at the 2 PB tier. For WordPress properties with heavy media delivery, this pricing asymmetry compounds monthly.

Diagnostics and Rollback: When CloudFront Caching Goes Wrong

This is the section most CloudFront WordPress guides skip. Here is how to diagnose and recover from the three most common failure modes.

Stale HTML After a Post Update

Symptoms: the origin shows updated content, but visitors see the old version. First, confirm the issue is CloudFront and not a WordPress object cache (Redis, Memcached) or a page-cache plugin (WP Super Cache, W3 Total Cache). Curl the origin directly, bypassing CloudFront, and compare. If the origin is correct, check the X-Cache and Age response headers from CloudFront. If Age is high and X-Cache shows Hit, the cached version has not expired. Issue a targeted invalidation for that path, wait 60–90 seconds, and verify.

Cache Hit Ratio Below 50%

This usually means cookies or query strings are fragmenting the cache key. WordPress plugins frequently inject tracking cookies or UTM parameters that create unique cache keys for the same content. Review your cache policy. Whitelist only the cookies and query strings your application actually needs for rendering. Everything else should be stripped.

Rollback Procedure

If a misconfigured distribution is serving errors or broken content, the fastest rollback is to update the DNS record to point directly to your origin, bypassing CloudFront entirely. Keep the CloudFront distribution active but unused while you debug. Do not delete the distribution — recreating it means losing your edge-cached content and starting cold across all locations.

FAQ

How do I invalidate CloudFront cache after WordPress updates?

The most reliable method is event-driven invalidation triggered by WordPress hooks (save_post, switch_theme) routed through SNS or EventBridge to a Lambda function that calls CreateInvalidation. Avoid full wildcard invalidations unless the change is site-wide. Batch changed paths into a single API call to stay within the free 1,000-path monthly tier.

What are the best CloudFront cache settings for WordPress in 2026?

For HTML, use a short max-age (60–300 seconds) with stale-while-revalidate. For static assets (CSS, JS, fonts, images), use max-age=31536000 with immutable, and version your filenames. Create separate CloudFront behaviors for wp-admin (no cache), uploads (long TTL, Accept in cache key), and public HTML (short TTL).

How do I optimize WordPress images with CloudFront?

Compress and convert images to AVIF (with WebP fallback) at upload time using server-side tooling. Generate responsive variants at 480w, 768w, 1200w, and 1920w. Include the Accept header in your CloudFront cache key to enable content negotiation. Set immutable cache headers on versioned image filenames.

Is there a CloudFront WordPress cache invalidation plugin worth using?

The C3 CloudFront Cache Controller plugin remains actively maintained as of 2026 and hooks into post save and update events. For more control, WP Offload Media can manage the full static asset pipeline. Both are worth evaluating, but neither replaces understanding your cache policy configuration. The plugin handles the trigger; the cache policy determines what gets cached and for how long.

How much does CloudFront cost for a WordPress site?

Costs depend on traffic volume, geographic distribution, and request count. A WordPress site serving 10 TB/month in North America will pay roughly $850/month on CloudFront at standard rates (as of Q2 2026). Flat-rate alternatives can reduce this significantly — BlazingCDN covers the same 10 TB for $100/month with comparable edge delivery performance.

Your Move: Measure, Then Decide

Before you commit to any changes, instrument what you have. Pull your CloudFront cache hit ratio from the last 30 days. Run a WebPageTest comparison from three geographically distinct locations with CloudFront enabled and with a direct-to-origin bypass. Measure the actual TTFB delta and the total page weight with and without your current image pipeline. If your cache hit ratio is below 85% or your median image payload exceeds 200 KB per page, the patterns in this article will produce measurable results within a week. If you are already above those thresholds, the cost model section might be where your next win lives. Either way, measure first.