Yes, and for most stores nothing needs configuring. There is one part that does not survive a page cache cleanly, and it is worth understanding rather than discovering from a customer.
Two caches, doing different jobs
| What it stores | Cleared by | |
|---|---|---|
| The plugin’s own cache | Each calculated date, for up to an hour. | Saving the settings screen, or wp edfw flush. |
| Your page cache | The finished HTML of a page. | Whatever your caching plugin does. |
They stack. A visitor can be served HTML that was generated an hour ago, from a date that was already up to an hour old when it was generated. For a delivery window measured in days that is almost always harmless — a 2–5 day estimate does not change hour to hour.
The exception: the countdown
The order within timer is the one element measured in minutes, and it is the one a page cache gets wrong.
It works like this: the server renders how many seconds remain until today’s cutoff into the page, and a small script counts down from that number. Doing it that way makes the timer immune to a visitor whose own clock is wrong — but it also means the starting value is baked into the HTML.
⚠ Warning
Cache that HTML for three hours and every visitor in those three hours starts their countdown from the number that was correct when the page was built. Late in the day the timer can promise time that has already gone, and tell someone they can still order for same-day dispatch when the cutoff has passed.
The date beside it is not wrong — that is a whole day, and the cutoff had not passed when the page was generated. It is specifically the minutes that go stale.
What to do about it
Pick the one that matches how much the countdown matters to you:
- Turn the countdown off. General → Show “order within” urgency countdown. If you are not leaning on urgency, this removes the problem entirely and everything else caches perfectly.
- Keep the cache short on product pages. A TTL well under an hour keeps the timer close enough to true. This is the usual compromise.
- Exclude product pages from the page cache. Accurate, and the most expensive — only worth it if the countdown is doing real work for your conversion rate.
Tip
Whichever you choose, check the storefront once shortly before your cutoff and once shortly after. Those two loads catch a stale countdown faster than any amount of reading settings.
What caches perfectly well
- The delivery date itself. Measured in days, and it only moves when the cutoff passes or your settings change.
- Cart and checkout. Excluded from page caching by every caching plugin worth using, because WooCommerce requires it.
- Order emails and My Account. The estimate is frozen onto the order at checkout, so it is a stored value, not a calculation.
When you change a setting and nothing moves
Saving the settings screen clears the plugin’s cache, so a stale storefront after a change is almost always the page cache in front of WordPress rather than this plugin.
✓ Note
The quickest way to tell them apart: load the page logged in. Caching plugins nearly always bypass the cache for logged-in users, so if the estimate is right for you and wrong in a private window, it is the page cache — purge it.
If the change came from somewhere that does not touch the settings screen — WP-CLI, an import, a migration — clear the plugin’s own cache too:
wp edfw flush