A website was essentially a digital document, the web a library, and the internet the mechanism of delivery. Updating a document meant editing HTML on your computer and uploading it to a server by hand, usually over FTP. In 1995 PHP arrived and changed that, generating the HTML on the server from content held in a database. Paired with MySQL it became the standard way to build a site, and still underpins WordPress, a popular CMS.
As the web grew into more than a delivery system for documents, the technologies evolved with it. React and Next.js let us build static sites in JavaScript and lift them with rich interaction and animation. But fresh content and the performance of a static build pulled in opposite directions.
Pulling content from a CMS like Storyblok, Next.js does much the same job as PHP, combining it with HTML and CSS and delivering a page to the browser. Run dynamically, this happens on every request, so a CMS edit is live the moment it’s made. The cost is latency, heavy API usage and a larger bill for the client. Run statically, the work happens in the background on a regeneration schedule. Performance improves, costs and latency fall, but content lags behind.
It’s now 2026, and Next.js 16 has cracked it. What if we could have the best of both, heavy caching for performance with content updates that still land instantly? Better still, what if different parts of a page could refresh at different speeds, depending on what they are for?
Cache Components is the new Next.js caching model that does exactly this. Caching becomes something a developer declares in a single line, around one piece of data or an entire component. Every part of a site carries its own strategy, regenerating from fresh content precisely when it needs to.
Every part of GFSmith’s page carries its own cache tag: commerce revalidates on price and stock (Saleor), editorial on publish (Storyblok). Learn more about our work with GFSmith
As part of our relationship with GFSmith, we’ve been tasked with building out their e-commerce presence to reflect the exciting new brand. The intersection of editorial content and e-commerce is the perfect use case for these behaviours. Data updates to the catalog within the Saleor platform trigger a flush of the cache of the relevant pages of the site: consequently, a pricing update will show almost instantly. The editorial elements of these pages are left untouched, updating independently.
Anything we do leave uncached doesn’t hold up the page. Next.js sends the cached shell straight away, with a placeholder where the live part will sit, then streams it in behind. The visitor gets the page immediately, and the live data is accurate to the second. The approach is called partial prerendering. The framework gives us the mechanism; the judgement is in what we choose to cache.
The cached areas still need to update when someone edits them, so we add a webhook to the CMS. Cached content carries tags, and an edit in a CMS like Storyblok expires only the tags it affects. The change surfaces almost at once, and nothing untouched is rebuilt.
Granular caching of this kind isn’t unique to Next.js, and other platforms arrive there by their own routes. What has changed is the arithmetic. When we reach for React and Next.js it is for the fluidity they give users, through considered animation, richer state and frictionless movement between pages. This used to result in trade-offs over efficiency & performance. Now we’re able to more confidently deliver these features as part of highly performant and efficient builds which always deliver content fresh.
