Measured in your browserWe advise on speed. We practice it.Loaded just now · real numbers from this visit, not a lab score.
Page loaded
First byte
DOM ready
First paint
Largest paint
DNS lookup
TLS handshake
Transferred
Saved by compression
Requests

WordPress is the web's most common origin and the source of its most repeatable CDN disasters — cached carts, leaked admin bars, logged-in pages served to strangers. All of them come from the same three misconfigurations, and all three are preventable in an afternoon. This is the safe path.

Decide the caching model first

Two legitimate models exist for WordPress delivery, and mixing them accidentally causes most incidents. Assets-only: the CDN serves uploads, theme and plugin files, while HTML comes from the origin every time — safe by construction, meaningful savings, the right default for shops, membership sites and anything heavily personalized. Full-page: the CDN caches HTML for anonymous visitors too — dramatically better performance and origin relief, in exchange for the exclusion discipline in the next section. Choose consciously based on how much of your traffic is anonymous: a blog with 98% anonymous readers should full-page cache; a store where every session carries a cart should think carefully and lean on the e-commerce guide's patterns instead.

The exclusions that prevent disasters

Every WordPress CDN disaster traces to one of three missing exclusions, so write these rules first. Paths: bypass cache entirely for /wp-admin/, /wp-login.php, /wp-json/ (unless you have deliberately decided your REST API is cacheable), /cart/, /checkout/, /my-account/ and any plugin-specific dynamic endpoints. Cookies: bypass whenever the request carries wordpress_logged_in_*, wp-settings-*, WooCommerce session or cart-content cookies — this single rule is what prevents a logged-in user's page being cached and served to the anonymous public. Methods and queries: never cache POST, and decide query-string policy explicitly (search and preview parameters must bypass; tracking parameters like utm_* should ideally be ignored in the cache key so they don't shred your hit ratio). Configure these at the CDN layer even if a caching plugin also sets headers — defense in depth, because plugins get deactivated.

Static assets: the easy 80 percent

Whatever the HTML decision, /wp-content/ and /wp-includes/ assets should cache aggressively: long TTLs (a week or more), because WordPress already versions most references with ?ver= parameters — which means your cache key must include that query string for these paths, the opposite of the tracking-parameter rule above. Confirm your origin (or caching plugin) sends immutable-friendly headers on uploads, let the CDN's image optimization work on the media library if the option exists (our image add-ons comparison maps who charges what), and the majority of your bytes are now edge-served regardless of the HTML model.

Purge on publish

Full-page caching is only livable if publishing purges. Wire your CDN's API into the publish flow — most providers have a maintained WordPress plugin; where none fits, a small hook on save_post and comment events calling the purge API does the job. Purge surgically: the changed post's URL, the front page, the relevant category and feed URLs — not the whole zone, which stampedes your origin for no reason. Set HTML TTLs modest anyway (five to fifteen minutes) so a missed purge self-heals quickly; the combination of event purge plus short TTL is what makes full-page WordPress caching boring, which is the goal. Tag-based purging, where your provider supports it, makes this cleaner still.

Verify before you trust

Before calling it done, run the four-browser test: anonymous visitor sees cached pages (cache-status header shows hits, Age climbs); logged-in user sees fresh pages with their admin bar, every request a bypass; one user's cart never appears in another browser; and a test post published right now appears on the front page within seconds. Then check the negative space in your analytics for a week — a sudden traffic-shape change (all sessions from one 'user', vanishing logged-in pageviews) is the signature of a cookie rule wrong in one direction or the other. Keep measuring hit ratio per content type, and expect: near-total on assets, high on anonymous HTML, zero on the excluded paths — by design.

Get the free assessmentMore analysis