Yes, and it is built for it. The end is written into the page as one exact moment, and the script counts to it from the visitor's own clock — so a page cached an hour ago still shows the right countdown rather than the one that was true when it was cached.
A per-visitor countdown works from a cached page too. The page says how long the countdown is, and the script works out each visitor's own end from when they first saw it, and remembers it — so nobody is handed the deadline of whoever happened to load the page first.
It also leaves the page cacheable. The server no longer sends a cookie with a visitor's first view, which is what stopped caches such as Nimble Cache from keeping — or preloading — any page with a per-visitor bar on it.
A daily or weekly cut-off carries the next fortnight of cut-offs in the page, with your days off already left out, so a cached copy moves on to tomorrow's by itself. A heading that names the day with {day} changes "tomorrow" to "today" at midnight on a cached copy too, by your site's clock.
A campaign that opens or closes sales empties the page caches at that moment, so the cached product page gains or loses its button. A countdown to a scheduled sale's start empties them when the sale starts, once more a minute later, and again when WooCommerce moves the product's price to the sale price, which its own job can do after the start. WordPress does it on the next visit that reaches the site rather than the cache, so on a quiet site it can be a little late; the shop refuses the sale on time whatever the cached page shows.
The cart timer is the exception, as any cart is: it is per shopper, so the cart and checkout pages should be excluded from caching, which WooCommerce already asks of every caching plugin.
Still stuck? Ask the developers who wrote it. We aim to reply within one business day.
Countdown Timer
Countdown timers that run to your real sale dates, on a product, across the shop, or as a cart timer at the checkout.
From $19 a year · every feature · 30-day refund
