Checkout Purge Shield
When a customer places an order, WooCommerce writes several order notes: “Payment complete.”, “Stock levels reduced.”, one for each status change. WordPress stores order notes as comments. Many cache-purge plugins purge the cache whenever a comment is saved, and they don’t check what kind of comment it is. So every order note sets off a purge, for an “order page” that has no public URL and nothing cached behind it, while the customer waits for their order to go through.
The checkout purge shield stops that. It skips purges for order notes and for anything without a public URL, and it short-circuits the site’s own requests to URLs that provably have nothing cached. Placing an order then waits on nothing but the work the order genuinely needs.
Available since 6.28.
On a test store running Nginx Helper with its default settings, one checkout made 30 outbound purge requests. With the shield on, it made none. On superspeedyplugins.com, my own store, those purge requests were adding about 19 seconds to checkout. That was my store and my host’s purge set-up; what they cost yours depends on your purge plugin and cache server.
Where to find it
Scalability Pro > Miscellaneous > Checkout purge shield. It is on by default, and Enable good settings turns it on as well.
What sets off the purge requests
The best-known case is Nginx Helper. By default it purges on every saved comment without checking the comment type. With its AMP option on (the default), it also fetches an AMP version of the purged URL. For an order, that URL does not exist, so the site renders a full 404 page for itself, inline, inside the customer’s place-order request.
Under WooCommerce’s High-Performance Order Storage (HPOS), the “post” behind an order is a placeholder with no public permalink at all. Purging it can never clear anything, because nothing was ever cached for it.
A purge request is a real HTTP request from your server to itself. WordPress waits for each one to finish, or to time out, before it carries on. Several of them inside one checkout add up, and they all happen before the customer sees their order confirmation.
What the shield does
It works in two layers, both through WordPress filters:
- Order notes stop triggering purges. For Nginx Helper, the shield wraps its comment hooks and skips order notes, webhook delivery logs, action logs and comments on any content with no public URL. A real blog or product review comment still purges its post, the homepage, its archives and its feeds as normal.
- Pointless self-requests are answered instantly. Underneath that, any request from the site to itself for a URL that cannot have anything cached (an order placeholder, or an AMP URL on a site with no AMP plugin) gets an immediate empty “200 OK” instead of going out over the network. This catches other purge plugins too, including renamed or white-labelled copies of Nginx Helper that cannot be detected by name.
The shield only ever touches requests from your site to itself. Payment gateways, webhooks to other services and licence checks are never affected.
Nothing is written to your purge plugin’s settings. Switch the shield off and your purge plugin behaves exactly as it did before.
Cap the timeout on purge requests
A second, separate setting sits underneath the shield: Cap purge requests at 3 seconds. It is off by default.
Nothing reads the response to a purge request, so a purge that has not answered within a few seconds only costs your customer time. This setting caps the site’s own purge requests (the ones going to the purge path, /purge/ by default) at 3 seconds instead of the usual 5.
It is off by default because it is a different kind of change from the shield. The shield only skips requests that cannot do anything. The cap shortens the timeout on purges that are perfectly legitimate, so a slow cache server could occasionally leave a page uncleared.
- Stores where the shield is on but checkout profiling still shows purge requests waiting
- Hosts whose cache server answers purges slowly
Checking whether it helps your store
The shield makes no difference on a store with no cache-purge plugin, or one whose purge plugin ignores order notes. To see what your own checkout waits on, profile a real purchase with Super Speedy Performance Analysis. Its checkout flow analysis places one real order and shows the server time at each step, including outbound HTTP requests, split at the payment boundary.
If you use Query Monitor, the shield logs a debug message each time it skips a purge or short-circuits a self-request.
For developers
Four filters adjust the shield’s decisions:
spro_purge_shield_skip_comment_types– the comment types that never trigger a purge (defaultorder_note,webhook_delivery,action_log)spro_purge_shield_skip_url– override the decision for a single URL; returnfalseto let the request throughspro_purge_shield_amp_active– tell the shield your site serves AMP pages, so AMP URLs are never treated as phantomspro_purge_shield_purge_timeout– the timeout used by the cap, in seconds (default 3)
Comments