Did we just make the fastest Plone site?

We rebuilt pretagov.com and went looking for a faster Plone site — and couldn't find one. Here's how headless, SSG on a CDN, a clean decoupling, and Hydra's in-page editing got us to 91/94 on PageSpeed Insights, plus an honest question.

We recently rebuilt pretagov.com. When it went live it felt fast — really fast. So we did what any engineer does with a suspicious result: we went looking for something faster to prove ourselves wrong.

We looked around — high-profile Plone sites, community flagships, the newer headless builds — and measured them on Google PageSpeed Insights. We couldn't find one that scored higher.

On PageSpeed Insights, pretagov.com scores 91 on desktop and 94 on mobile for Performance — with a clean 100 for Accessibility, 100 for Best Practices, and 100 for SEO. Desktop paints are effectively instant and there's essentially no layout shift; mobile — always the harder target — sits at 94. It also passes 2/2 on agentic browsing (the page is clean, structured, and legible to the AI agents that increasingly do the browsing) — which, given what we do, we rather like.

So how did we do it? None of it is magic. It's a handful of deliberate choices that compound.

Headless buys you flexibility, decoupling keeps it fast

The single biggest lever is going headless. Once the CMS stops rendering your pages, you get to pick the right frontend and the right deployment style — SSG, SSR, SPA, or a hybrid — for the job. For this site we took a ready-made design system, built the frontend in Nuxt, and shipped it as a static site served from a CDN.

The second lever pays off twice: visitors never load the CMS admin at all. A coupled CMS ships its admin with the frontend — whether server-rendered or a Volto SPA, the editing machinery rides along. A truly decoupled build keeps them apart, so the public site strips out any admin code. That's more secure — no admin surface to attack — and faster, because visitors never download code they'll never run.

The rest is discipline about what runs in the browser: monitoring trimmed to error-only, analytics deferred to the visitor's first interaction so it never competes with the initial paint, and no hydration we don't need. The result is a page that paints almost immediately, with essentially no layout shift.

…without giving up the editing experience

The usual catch with all this flexibility is the editing experience. Roll your own frontend and you often lose the friendly, in-context editing that makes a CMS worth having. That trade-off is exactly why many teams stay on a coupled stack.

This is where Hydra comes in. Hydra gives editors a Medium-like editor, right on the real page, while needing only a thin layer of JavaScript to integrate — around 460 KB that loads only while editing, split out of the public build entirely. Editors get true WYSIWYG on the live page; visitors get plain static HTML. And in building it, we improved on Volto in a number of places — one of our favourites is shared, editable templates.

Shared, editable templates

The video shows editing the site footer. It's a shared template: edit it once, in place, and the change propagates to every page — with the structure locked so editors can't accidentally break the layout. The same system drops reusable snippets anywhere across the site — a call-to-action, a contact block, a newsletter sign-up — that stay in sync automatically.

So — is it the fastest Plone site?

Honestly? We don't know. We went looking for a faster one and couldn't find it — but "we couldn't find one" isn't proof, and we'd rather be accurate than boastful. So here's an open question: if you know a Plone site that scores higher, tell us. We'd genuinely like to see it — and we'll almost certainly learn something.

What we are confident about is that none of the ingredients are exotic: headless for flexibility, an off-the-shelf design system for a polished start, SSG on a CDN for raw speed, a clean decoupling that keeps the admin out of the public bundle, and Hydra so we didn't have to trade away the editing experience. Fast sites and a great editing experience are usually presented as a trade-off. They don't have to be.