Every emDash page that is not already cached is assembled on request from the database. That makes the caching decision the single largest lever on speed, hosting cost and how quickly an edit appears to readers — and those three pull in different directions. This piece sets out the decision as we made it for this publication, with the numbers from the live site, so that an owner or agency can make the same call deliberately rather than by default.
The three options
There are, in practice, three positions an emDash site on Cloudflare can take. We ran the first two in production before settling.
| Option | What visitors get | What editors get | The cost |
|---|---|---|---|
| No edge cache | A full render on every visit | Every edit visible immediately | Slow pages and the highest database and compute load |
| Short cache plus purge on publish (our choice) | Cached pages almost all the time | Edits usually visible at once; worst case one page lifetime | A small, bounded staleness window |
| Long cache with serve-stale refresh | Cached pages, refreshed in the background; almost no visitor waits | Edits still visible at once after a purge | Stale pages can point at files a deploy has removed, unless the previous build’s files are kept |
What we measured
With no edge cache, every edit was live immediately, but every visit paid for a full render. On emDash 1.2, the median article took 1.29 seconds to start arriving, and one request in twenty took more than four. Moving to a five-minute cache with purge on publish changed the picture entirely. On emDash 1.3, on 18 October 2026, nineteen of twenty requests to each page were served from the edge.
The uncached cost matters less than it appears on a cached site, because most visitors never pay it. It falls on the first visitor after each expiry, on search crawlers, and on anything that cannot be cached. That is why the expiry interval is the real decision.
Our figures come from one location in the United States. The Weekly Dash has published a ten-day, six-country measurement of the same setup. Its numbers match ours closely: around 50 milliseconds from the cache, about a third of a second for a rebuild on a running Worker, and 1.5 to 2 seconds when the Worker has to start as well.
How freshness actually works
emDash tags every cached page with the content it shows. When something is published, unpublished, deleted or restored, emDash purges the pages carrying that content's tags, and site-wide elements such as menus, settings and widgets have their own tags. In practice an edit appears within seconds.
The tags are broader than they look. A page that shows a list of articles is tagged with the whole collection, not with each article in the list. Our article pages show related articles, so they carry that tag. Publishing one article therefore empties every article page, not just the one that changed. Correcting a typo in last month’s piece sends the next visitor to every article through a rebuild. On a site that edits often, it is worth batching corrections into one save, and showing article lists only where readers use them.
Three limits shape the worst case, and they are why the page lifetime still matters:
- Purges are rate-limited. Cloudflare applies its free-plan purge limits to this cache whatever plan you are on — five purge requests a minute, with a burst of twenty-five. A rate-limited purge fails silently, and the page waits for its lifetime to run out.
- A purge can arrive just after a visit. Occasionally the next visitor is served the previous copy while the purge is still completing. In our tests that happened once in five publish cycles, with the stale copy under ten seconds old.
- Some changes do not purge at all. Restoring an older revision, and changes to bylines, the media library and comments, leave cached pages as they are until they expire or the entry is saved again.
The trap we fell into
Cloudflare and emDash both support a setting that serves the stale page while fetching a fresh one in the background, and the documentation's own examples use it generously. For data it is excellent. For HTML it caught us out: immediately after a deploy, it kept serving pages that referenced the previous build's stylesheet, a file the new deployment no longer contained, and those pages rendered unstyled for minutes.
The cause was not serve-stale itself but what it served: pages pointing at a stylesheet the new deployment no longer contained. We fixed that cause directly. Each deploy now carries the previous build’s files forward for seven days, then checks that every file a live page references actually loads, failing the deploy if one does not. We also turned serve-stale refresh off for HTML, so the first request after expiry rebuilds the page in the foreground. With the files retained, that second change is no longer what keeps pages styled. It is a choice between a visitor occasionally waiting for a rebuild and a visitor occasionally seeing a page a few minutes older. The Weekly Dash measured the other side of that choice: with a week of serve-stale, 84 of 101 return visits were answered from the cache. We may revisit it.
What a deploy does
Cloudflare includes the Worker’s version in the cache key, so by default every deploy starts with an empty cache: the first visitor to each page after a release pays for its rebuild. A Wrangler setting, cache.cross_version_cache, lets versions share the cache. The price is that a layout change appears only as pages expire or are purged, so it suits sites that already keep old build files available. We deploy several times a week and do not set it yet; it is on our list.
Choosing your number
The right lifetime is the longest staleness the business can accept in the rare case that a purge fails. For this publication, whose content changes a few times a day, five minutes is comfortably inside that. A news desk running live updates would choose less; a brochure site that changes monthly could choose an hour or more.
| Type of site | Reasonable page lifetime | Why |
|---|---|---|
| Live news, prices, availability | 1 minute or no cache on those pages | A stale page is a factual error |
| Publication or blog | About 5 minutes | Edits appear at once; the worst case is brief |
| Marketing or brochure site | 30–60 minutes | Content rarely changes; speed and cost dominate |
Caching recommendations and decisions driven by it
- Running a WordPress site that works. The caching question is answered well on emDash, so it should not block a future decision; it is a configuration choice, not a risk.
- Commissioning a new site. Ask the builder for the page lifetime, the purge test on the live domain and the deploy-time asset check. Each is cheap to set up and expensive to discover missing.
- Running an agency. Standardise the policy: a lifetime per site type, the purge test and the asset check, applied to every client site. The build is described in what we learned running emDash in production.
