From WordPress to a modern stack (without throwing everything away)

Did you know a marketing site can change its engine without changing its bodywork?

For clients who need someone to work under the hood, it’s the first job on the list. Further down I’ll explain exactly what that job is, but first a more important question: why?

There are plenty of reasons, here’s an overview:

1. Speed. The image below is worth a thousand words. Do you know how rare an “all green” site on mobile is? There’s no precise number, but in my experience 5% is an optimistic estimate.
2. Control. With my architecture, every byte that reaches the browser is a deliberate choice, not a side effect of 30 plugins injecting stuff into the frontend.
3. Security. The less code is exposed to the public, the fewer locks there are to pick.

The typical case is the client on WordPress: they were sold the illusion of independence, but in reality the marketing manager can’t even change a price without breaking the layout. So they call me, and when I look under the hood I find a very heavy theme and two different plugins installed to do a 301 redirect (I’m not kidding).

After watching the same movie quite a few times, I decided to tackle the problem head on. I built a system that allows a progressive migration from any technology to my stack, without huge, expensive interventions. But what do I mean by progressive migration? Fasten your seatbelts, here comes the technical deep dive.

The heart of the system is a Node server, initially configured as a simple reverse proxy. With it I can rewrite the HTTP response, which gives me total control. That control is what makes the migration progressive: every time I work on a page, I move its response from the original application to the Node one. The result? Besides being able to use state-of-the-art web frameworks (I love SvelteKit), on every request we save:

• the WordPress bootstrap
• resolving the filesystem at runtime
• the hook system
• building the page in memory
• queries nobody asked for
• resolving script dependencies at runtime

The response time for a simple page easily improves tenfold. Of course each page takes time to do properly, especially for SEO, which is why the migration is progressive. Migrated and unmigrated routes live side by side, which guarantees continuity.

That coexistence comes at a price that’s convenient to forget, though: as long as the original instance stays on, its attack surface stays on too. On one of these projects I was reminded of it in the worst possible way, and I told the story in Hacked WordPress site: how I secured it and made it faster in a few hours.

As site management goes on, the improvement in the user experience is clear: every intervention moves another piece onto the new engine. The truth is that if whoever manages your site knows what they’re doing, you can have your cake and eat it too. You can have continuity: crucial, especially if your site is already indexed or you’ve invested a lot in it. At the same time you can make your main online growth platform more powerful, flexible and secure. If you’ve got a Fiat Panda engine in a Ferrari body, you’re out of excuses!

Tell me about your project: send me the domain and what bothers you about your current site. I’ll reply telling you which page I’d start from and what would change in response times.