Skip to content
McGinnPublishing
Performance

Publishing should invalidate, not deploy

The moment an editor waits on a build for a typo fix is the moment your CMS is not really a CMS. A five-line webhook fixes that permanently.

6 min readPriya Raghunathan, Senior Engineer

Time-to-publish is an editorial metric with an engineering cause. When a fix requires a rebuild, the editorial team's day is shaped by your deployment pipeline: they batch corrections, they hold copy until a release window, and they lose the ability to react to anything that happens in the next forty minutes.

With on-demand revalidation, publishing is a cache operation. It takes under a second and it does not touch the build.

The mechanism

Tag-based revalidation gives you exactly the invalidation granularity you want. Each cache entry knows which content it came from, and a publish tells the platform which tags changed.

// WordPress → app webhook
POST /api/revalidate
{
  "secret": "…",
  "tags": ["post:harrow-and-vine", "series:fiction"]
}

// App
await revalidateTag(tag)   // marks stale, serves
                         //   fresh-while-revalidating

Two details make this reliable rather than merely clever. First, the endpoint is authenticated with a shared secret compared in constant time — a webhook endpoint that accepts anonymous requests to invalidate your cache is a denial-of-service tool with a nice URL. Second, tags are derived from identity, not from the request: a post tag, a term tag, a global settings tag. A publish computes the affected set once and invalidates it.

Serve stale while you revalidate

Invalidation is not a hard cut. The first request after a publish is served from cache while the regeneration happens in the background. Your editor sees their change, the next visitor does not pay for it, and there is never a window where the page is missing.

Where content genuinely cannot be stale — a price, stock, a price of a ticket — the webhook revalidation is immediate and the stale window is irrelevant because it is measured in seconds.

The editorial argument

This is ultimately a workflow feature wearing a performance costume. The technical benefit is real and measurable. The reason clients mention it during a renewal conversation is that their editors stopped batching, and the difference in how the site feels day to day is not something a Lighthouse score captures.

Tagged

  • ISR
  • Webhooks
  • Caching
  • Editorial workflow