TL;DR: WP Engine caching runs in six layers—page (EverCache), CDN, Edge Full Page Cache, object cache, the NitroPack Add-On, and the browser—and most are automatic, including EFPC, on by default since April 2026. Purging isn’t uniform: The User Portal’s “Clear all caches” is the only one that reaches object cache, while the wp-admin button and API skip it, and the browser cache is always the visitor’s to clear. You don’t need a caching plugin, but a tool for front-end work: image compression, critical CSS, JS deferral, and minification. That’s what the NitroPack Add-On fills, free to test.
WP Engine runs one of the most capable caching setups in managed WordPress hosting, which is exactly why it can be confusing. What feels like a single on/off switch is really six layers working together, each storing something different, each with its own expiration window (cache-control headers can’t go below 600 seconds) and its own way of clearing.
It’s important you understand how they fit together, and this guide walks through all six—what each one caches by default, what WP Engine deliberately leaves out, and the front-end work that sits outside every caching layer.
What are the six layers of WP Engine caching?
Two of these layers run on WP Engine’s own servers, two more sit on Cloudflare’s edge network, one lives inside the NitroPack Add-On’s cloud, and the last one is on a machine you’ll never have access to—the visitor’s browser. Here’s where each lives and how long it holds onto your content.
| Layer | What it caches | Default TTL or constraint |
|---|---|---|
| Page cache (EverCache) | Rendered HTML, on WP Engine’s servers | 10-minute default expiration |
| Network cache (CDN) | Static assets—images, CSS, JS—on Cloudflare’s edge | 365 days |
| Edge Full Page Cache | Your HTML on Cloudflare’s edge | On by default since April 2026 for most accounts |
| Object cache | Database query results in an in-memory buffer | 1 MB buffer; on by default on new environments |
| NitroPack Add-On | Front-end optimizations in NitroPack’s own cloud | Optional layer with its own cache |
| Browser cache | Static assets stored on the visitor’s device | 365 days; can’t be purged remotely |
Okay, so how can you clear each one?
Everything on WP Engine or Cloudflare answers to a purge—clear your caches and the page cache, CDN, edge, and object cache all flush together. The browser cache is the holdout. Once an image or stylesheet lands on someone’s device, it can stay there for up to a year, and nothing you do on the server will move it. Only the visitor can by clearing their own browser.
So when a fix goes live for everyone except the one client swearing they still see the old logo, this is almost always why, and the answer is a hard refresh on their end, not another purge on yours.
Important note for object cache
It’s on by default for new environments and toggled per environment from the User Portal, so it’s probably already running on your site even if nobody switched it on deliberately. Keep that in mind for later, because it’s the one layer the wp-admin purge button doesn’t affect.
Test NitroPack yourself
By submitting, you agree to our Privacy Policy.
Edge Full Page Cache and the April 2026 rollout
Edge Full Page Cache (EFPC) is the layer that changed most in 2026. Normally your HTML is generated and served from WP Engine’s own servers, while Cloudflare only holds your static assets. EFPC caches the HTML on Cloudflare’s edge too, so the whole page is delivered from a data center near the visitor instead of from your origin. WP Engine’s launch data puts the typical gain at 60–90% faster Time to First Byte, with server response time improving 50–90%.
What matters for your site is that this is now mostly on by default. Since the end of April 2026, EFPC has been auto-enabled for accounts on Advanced Network and Global Edge Security, and switched on automatically for new sites. The two exceptions are NitroPack and Headless customers, who don’t get it auto-enabled and for the rest, you can still disable it per domain from the Domains page, or per environment from the Cache page.
It also doesn’t cache everything, and the carve-outs are worth knowing before you lean on it:
- Custom cookie exclusions are ignored. Path and query-argument exclusions still work, and the default exclusions like wp-admin, cart, and checkout are honored—but a custom cookie exclusion won’t be.
- PHP personalization breaks. A page that uses PHP to print “Welcome back, Sarah” caches the first visitor’s version and serves it to everyone after. Personalization rendered in JavaScript is fine.
- Device-type HTML variants, GeoTarget, and WPGraphQL Smart Cache Clear aren’t supported, because each depends on serving or clearing a page version that a single edge-cached copy can’t represent.
WP Engine’s own guidance is to prioritize NitroPack when both are available, since running EFPC alongside it adds nothing.
What does WP Engine exclude from caching by default?
Caching the wrong page is worse than not caching at all. A logged-in dashboard or a checkout served from someone else’s session is exactly the kind of thing you never want coming out of a cache, so WP Engine pulls a set of pages out automatically on every site.
On a standard install, that covers:
- The WP Admin area and wp-login.php
- Any page named cart, checkout, store, or check-out
- Any page where a wordpress_ cookie has a value set—which is how it keeps logged-in users out of the cache
If WP Engine detects WooCommerce, it adds more without you asking. That includes extra paths like /coupon, /my-account/lost-password, and the /wp-json/wc and /wc-api endpoints, the add-to-cart query argument, and the cookies that track an active cart, such as wp_woocommerce_session and woocommerce_cart_hash. The full list is in WP Engine’s docs if you need to confirm a specific path.
Anything past those defaults is a manual job. To exclude a custom path, argument, or cookie, you have to contact WP Engine Support, and paths have to be written in RegEx. One hard limit sits underneath all of it: you can’t switch caching off site-wide or on the homepage, and there’s no partial caching—a page is either served whole from cache or generated fresh every time.
Testing exclusions with curl
You don’t have to take an exclusion on faith. Run curl against the URL and read a single header:
Look for x-pass-why in the response. WP Engine returns one of three documented values—custom-path, custom-args, or custom-cookie—telling you exactly which rule pulled the page out of cache. To test a cookie-based exclusion, pass the cookie with -b:
If x-pass-why is missing, the page is still being cached, and the exclusion hasn’t taken. And once you know what’s cached, the next thing you’ll need is a reliable way to clear it.
Four ways to purge, and what each one clears
There are four places you can clear the cache from, but they don’t do the same thing. Two of them can be used for a wide purge, while the others will skip a layer.
Your options are the User Portal Cache page, the WP Engine menu inside wp-admin, the WP Engine API, and a PHP function in the platform’s MU plugin. Here’s what each one actually flushes:
| Purge surface | What it clears |
|---|---|
| User Portal → Clear all caches | Page (Varnish), network/CDN, object cache (if on), and NitroPack—everything except browser |
| wp-admin → WP Engine → Clear All Caches | Page and network/CDN—but not object cache |
| WP Engine API (purge_cache) | Same scope as the wp-admin button—not object cache |
| PHP (wpecommon::purge_varnish_cache) | Varnish for one URL, or the whole domain if no ID is passed |
⚠️ Important
The User Portal’s “Clear all caches” is the only option that reaches everything server-side in a single click, including object cache when it’s enabled. The wp-admin button and the API both leave object cache alone, which is the usual reason a query-driven change lingers after you’ve supposedly “cleared everything.” And none of them touch the browser cache—that part is always the visitor’s to clear.
When a page looks stale, and you’re not sure which layer is holding it, one quick check narrows it down.
- If it’s stale in incognito, it’s server-side.
- If it’s stale only in your own browser, it’s browser cache.
- If it’s stale in some regions but not others through a proxy, it’s the CDN.
Purging cache from a CI/CD pipeline
If you deploy through a pipeline, you don’t want to clear the cache by hand. The API handles it: send a POST to /installs/{install_id}/purge_cache as a build step. Just remember it carries the same scope as the wp-admin button, so it won’t clear object cache—if a deploy changes autoloaded data, clear that separately.
For invalidation triggered inside WordPress instead, the MU plugin function wpecommon::purge_varnish_cache() does it: pass a post ID to purge just that URL, or call it with no ID to purge Varnish across the whole domain.
Do you still need a caching plugin on WP Engine?
Short answer: not for caching. WP Engine already runs page, edge, object, and CDN caching on your behalf, so a plugin whose whole job is page caching has nothing left to do here.
The platform takes that seriously enough to enforce it. A number of caching plugins—W3 Total Cache, Hyper Cache, and WP File Cache among them—sit on WP Engine’s disallowed list and are removed automatically because they conflict with the caching the platform already provides.
Other third-party caching tools are technically allowed, but allowed isn’t the same as useful: stacking a second page cache on top of EverCache and Edge Full Page Cache just duplicates work that’s already done, and occasionally fights with it.
So if caching is covered, what’s actually left? The part no caching layer touches—front-end optimization. Caching stores your pages and serves them fast, but it doesn’t compress your images, generate critical CSS, defer non-essential JavaScript, or minify your code. Those are the jobs that move the Core Web Vitals Google actually scores, like LCP and INP, and they sit entirely outside what page, edge, or object caching does, on WP Engine or any other host.
That’s the real gap on a fast managed platform: not caching, which is handled, but everything that happens in the browser once the cached HTML arrives.
NitroPack Add-On for WP Engine
The NitroPack Add-On—formerly Page Speed Boost—is enabled straight from the WP Engine User Portal, and it brings NitroPack’s 60+ optimizations to your site: critical CSS generation, image optimization and compression, JavaScript deferral, code minification, and its own Cloudflare-backed CDN. The full feature list by plan is on NitroPack’s pricing page.
The results are why WP Engine built it in. On acquiring NitroPack, WP Engine reported average Lighthouse gains of 34% on desktop and 132% on mobile, and NitroPack consistently posts the highest Core Web Vitals pass rate among WordPress performance tools in HTTP Archive’s data.
“WP Engine’s architecture is built to deliver your site’s HTML to the browser as fast as physically possible. The NitroPack Add-On takes the baton from there. By automating the front-end execution—like critical CSS and JavaScript deferral—WP Engine customers access a complete, end-to-end performance stack that natively passes Core Web Vitals.“—Niko Kaleev, Product Marketing Manager at NitroPack.
It’s not a fix for everything, and it’s worth being clear where it stops. Per WP Engine’s docs, the add-on:
- Isn’t available for Headless, Multisite, or Sandbox sites.
- Doesn’t optimize pages for users logged in to wp-admin.
- Can’t speed up the first, uncached hit when your server is slow to generate the HTML
- Doesn’t touch the database—it’s front-end only.
Test your own site to see where the front-end gap is costing you—NitroPack’s Free plan needs no credit card and takes about three minutes to set up.
See NitroPack in action
By submitting, you agree to our Privacy Policy.
What WP Engine caching doesn’t fix for you
You now have the whole caching picture, which makes the common failure modes much easier to diagnose. Most of them trace back to a specific layer—or to the gap a layer leaves behind.
Which cache layer is the culprit?
The incognito, own-browser, and proxy checks from the purge section already tell you whether you’re dealing with a server-side, browser, or CDN problem. The one layer they don’t cover is NitroPack.
To check that, look for the x-nitro-cache: HIT response header, which confirms NitroPack served the page, and add ?nonitro to the URL to load it with NitroPack bypassed so you can compare the two.
502 errors after enabling object cache
Switch object cache on and start seeing intermittent 502s? The buffer is usually the cause. Object cache holds your autoloaded wp_options data in a 1 MB in-memory buffer, and when that overflows, WordPress retries in a loop that surfaces as 502 errors.
The fix is to disable object cache in the User Portal, audit your autoloaded data, then re-enable it. The NitroPack Add-On has nothing to do with this one—it’s front-end only and never touches the database.
ACF changes are not showing on the live site
When you update an ACF options page, the change won’t appear until the 10-minute page cache expires. Options-page values are sitewide settings, not post metadata, so no save event purges the cached HTML. Hook the purge to the action that actually fires:
add_action('acf/save_post', function () {
if (class_exists('wpecommon')) {
wpecommon::purge_varnish_cache(); // no post ID = purge the whole domain
}
});Use acf/save_post, not save_post—the latter never fires for an options page. For a regular post, pass its $post_id on save_post to purge just that URL instead of the whole domain.
WooCommerce currency and geolocation issues
Currency switchers and geolocation are a different problem: one URL needs to show different content to different visitors, and caching serves a single version to everyone.
WP Engine’s built-in WooCommerce exclusions handle the obvious cases—cart and checkout paths, plus cookies like woocommerce_items_in_cart and wp_woocommerce_session. For currency and geo personalization specifically, NitroPack’s Dynamic Content Cookies create a separate cached variant per cookie value, so each currency or region gets its own correct version. WP Engine’s docs include the GeoTarget cookie table if you’re wiring this up.
FAQs about WP Engine caching
When should I use the API purge versus the PHP function?
Use the WP Engine API purge_cache endpoint for automation that runs outside WordPress, like a CI/CD deploy step. Use wpecommon::purge_varnish_cache() when you want a purge triggered from inside WordPress itself—on a save, an update, or any hook—so invalidation happens the moment content changes.
Can I disable Edge Full Page Cache?
Yes. Turn it off per domain from the three-dot menu on the Domains page, or per environment from the Cache page in the User Portal. It stays off until you re-enable it.
Can I lower the cache TTL below 10 minutes?
No. Cache-control headers can’t go below 600 seconds. If you need fresher content than that, purge programmatically when the content changes, or ask WP Engine Support to set a full exclusion for the page.
How can I try the NitroPack Add-On without committing?
Start on NitroPack’s Free plan—no credit card, and setup takes about three minutes. It’s the low-risk way to see the front-end gains on your own site before enabling the paid add-on through the User Portal.
