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 quick, so we went looking for a faster Plone site, half expecting to find one.

We tried the high-profile Plone sites, the community flagships, and the newer headless builds, measuring them on Google PageSpeed Insights. None scored higher.

On PageSpeed Insights, pretagov.com scores 91 on desktop and 94 on mobile for Performance, with a clean 100 for Accessibility, Best Practices, and SEO. Desktop is effectively instant with no layout shift; mobile, always the harder target, sits at 94. It also passes 2/2 on agentic browsing: the page is clean and structured enough for the AI agents that increasingly do the browsing, which, given what we do, we're happy to see.

So how did we do it? No tricks, just a few deliberate choices that add up.

Headless buys flexibility

The speed is real, but it's a by-product. What going headless actually buys you is flexibility: once the CMS stops rendering pages, you choose the frontend, the stack, and how it all ships. For pretagov.com that meant a ready-made design system, a Nuxt frontend, and static files on a CDN, which is where the speed came from. And because the frontend is ours to shape, we can point AI agents at it to tune performance for our real pages rather than a generic average.

Being headless also keeps the admin out of visitors' way. In principle the editing UI shouldn't be part of the public site at all, though not everything that calls itself headless manages it: a Volto SPA still ships its admin with the pages. A clean split leaves it out. That's better for security, since there's nothing there to attack, and for speed, since no one downloads code they'll never use.

After that it's about keeping the browser's workload down: error-only monitoring, analytics that waits for the visitor's first interaction rather than the first paint, and no hydration we don't need. The page shows up almost instantly and barely shifts as it loads.

Speed is just the first payoff

Speed is the one you can measure on day one. The rest show up over the life of the site:

• Security — the admin never ships to visitors; a smaller surface to attack.
• Your stack, your call — the right tool for each job, not one monolith.
• Your people — build with the developers, or AI, you choose.
• Less lock-in — swap the frontend without re-platforming; your content stays portable.
• Resilience — the static site stays up while the backend is upgraded or down.
• Reach — one source of content for the web, apps, and the AI agents that increasingly do the browsing.

Each of these is a post of its own. More soon.

The one catch, now gone

The usual catch with all this flexibility is editing. Build your own frontend and you tend to lose the friendly, in-context editing that makes a CMS worth having, which is exactly why many teams stay on a coupled stack.

That's where Hydra comes in. It gives editors a Medium-like editor right on the real page, needing only a thin layer of JavaScript to integrate: about 460 KB that loads only while editing and is split out of the public build. Editors get true WYSIWYG on the live page; visitors get plain static HTML. Building it, we improved on Volto in a few places. One of our favourites is shared, editable templates.

Shared, editable templates

The video above shows editing the site footer. It's a shared template: change it once, in place, and every page updates, with the layout locked so editors can't break it. The same thing works for reusable snippets anywhere on the site, like a call-to-action, a contact block, or a newsletter sign-up, all kept in sync automatically.

Templates are just one of the things we improved on Volto. A few others:

• A proper UI for editing nested containers.
• Editing on mobile, not just desktop.
• Converting a block from one type to another, in place.
• Wrapping blocks in a container, and unwrapping them again.
• Absorbing and expelling blocks, to move them in and out of containers.

And MCP is on the way, so agents can edit through the same interface a person uses.

So, is it the fastest Plone site?

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 oversell it. So here's an open question: if you know a Plone site that scores higher, tell us. We'd like to see it, and we'll probably learn something.

None of the pieces are unusual: headless, which keeps your frontend choices open and the admin out of the public build; an off-the-shelf design system; static hosting on a CDN; and Hydra, so we kept a good editing experience. A fast site and good editing usually feel like a trade-off. They needn't be.