Shopify and Vercel are rebuilding Hydrogen as an open, runtime-agnostic foundation. Hydrogen now dep…
Live and Breaking Content Without Cache Chaos in a Headless Frontend
Live and Breaking Content Without Cache Chaos in a Headless Frontend
Live content and breaking news need data that is correct at the moment of the request, not data from the last build. In a composable frontend, that means block-level cache invalidation instead of global full rebuilds, and a clear split between content that stays stable for weeks and content that changes by the minute.
What Does Cache Chaos Look Like in a Headless Frontend?
Composable frontends cache aggressively, for good reason: statically generated or edge-cached pages are fast and cheap to serve. The problem starts when the same caching strategy gets applied to every content type. A product description that changes once a quarter and a live ticker that changes every minute end up in the same full-page cache with the same TTL. On top of that, you often get several cache layers at once: CDN edge cache, server-rendering cache, and browser cache, each with its own lifetime. When those layers aren't coordinated, different users see different versions of the same page at the same time, and nobody on the team can say with confidence which version is actually live.
The Problem: One Cache Layer Too Many, One Invalidation Strategy Too Few
In practice it usually plays out like this: an editor publishes an urgent update, but the homepage keeps showing the old version for several more minutes because the full-page cache only refreshes on the next scheduled rebuild or a manual purge. Purging the entire cache on every change isn't a real fix either, it wipes out the TTFB benefits the cache was giving you and creates short-lived load spikes on the origin during high traffic. Without granular invalidation per content block, you're left choosing between "stale for too long" or "rebuilt too often," and neither option works for breaking news and live content.
How Laioutr Delivers Live Content Without Cache Chaos
The more durable approach splits content by update frequency and invalidates precisely, instead of across the board. In Laioutr's composable frontend, every content block gets its own cache key. On publish, a webhook from the CMS triggers a tag-based purge of exactly the affected blocks, leaving the rest of the page untouched in cache. Content flagged as "live" or "breaking" automatically runs through stale-while-revalidate: users get an instant response while fresh data loads in the background, so the next request is already current. Category pages with stable content stay in the edge cache for a long time, while hero banners, live tickers, or availability indicators render as their own short-lived components. The result is a page where roughly 90 percent of content ships as fast as before, while the remaining 10 percent is genuinely live.
Naive Caching vs. Laioutr Composable Caching
| Aspect | Naive caching | Laioutr composable caching |
|---|---|---|
| Invalidation | Whole page or nothing | Tag-based, per content block |
| Breaking content | Waits for the next rebuild | Stale-while-revalidate, visible instantly |
| Cache layers | CDN, server, browser uncoordinated | Centrally managed via publish webhook |
| Load on updates | Spikes from full purges | Even, thanks to granular invalidation |
| Consistency | Users see different states | One defined, traceable live state |
What You Gain
With block-based cache invalidation, you ship breaking news and live updates without sacrificing the performance benefits your cache gives everything else. Your Core Web Vitals stay stable because stable content keeps getting cached aggressively, while only the genuinely live-relevant blocks keep refreshing. Your editorial team publishes directly, without waiting on a rebuild or pinging engineering for a manual purge.
If your homepage is stuck between "stale for too long" and "rebuilt too often," take a look at Performance and Core Web Vitals, or talk through how a composable visual page builder separates live blocks from stable content. As part of a composable headless frontend, this split can be introduced component by component, without ripping out your existing setup.
FAQ
Do I need to switch CDNs to get block-based invalidation? No. Tag-based purges work with most common CDNs; the lever is in the frontend architecture, not the CDN vendor.
How fast is breaking content visible after publishing? With stale-while-revalidate, typically within seconds, depending on webhook latency between the CMS and the frontend.
Does granular invalidation slow down the rest of the page? No, the opposite. Since only the affected blocks get invalidated, the rest of the page stays uninterrupted on the fast cache path.
More from the Laioutr Platform
About the author: Marcel Thiesies is Co-Founder of Laioutr. He works with editorial and engineering teams across the DACH region who need to ship live content and performance at the same time.
All data is based on publicly available information and our own platform experience. As of July 2026. Cache and CDN features may have evolved since. This article is not technical advice for your specific setup.