Elementor or the block editor: what rebuilding this site taught me

A site I rather enjoyed building

I’ll be honest about the first version of this site. I liked it. It had been put together with Elementor, and Elementor is a pleasant tool when you want to move quickly. You drag a block in, shift it about, and see the result on screen without going anywhere near a developer. Hundreds of ready-made widgets, a layout you adjust with the mouse. For someone with one foot in marketing, that’s very tempting.

The trouble comes from what gets added around Elementor. A page builder soon attracts add-ons, a bit like a new phone on which you install one app, then another, then ten. On this site, the builder came with four add-on plugins. Each one brought its own styles and its own scripts. And each one loaded them on every page, including the pages that never used them.

The day I counted the files

I had never properly measured what the home page was asking of the browser. When I did, it was a bit of a shock. To display that one page, the browser had to download 58 stylesheets and 38 scripts. Two different navigation menus were embedded on every page, though only one was ever shown. The fonts were fetched from external servers. And an old version of jQuery, a library that a great many plugins rely on, was loading twice because of a simple hover effect on a button.

None of this was serious on its own. Put together, it made for a site that was slow to open, especially on a phone, for a visual result that could have fitted in a tenth of the files. For a site whose whole purpose is to show what I can do, that wasn’t a great message.

Rebuilding without changing the face

I hesitated for a while. Redoing a site you’ve only just finished is never much fun. But I wanted to know what the same look would give without any builder at all. So I rebuilt the site with the Kadence theme and the block editor that ships with WordPress, the one people usually call Gutenberg. The aim was that nobody would notice the change on arrival. The large headings, the light background and the rounded white cards all stayed.

All the styling now lives in a single custom stylesheet. The fonts are hosted on the site itself rather than requested from Google on every visit. The builder-related plugins were uninstalled, since they no longer had any reason to exist. What surprised me most was how much the block editor covered on its own. The handful of slightly unusual layouts came from the theme’s blocks.

What the numbers came to

On the home page, stylesheets went from 58 to 7. Scripts, from 38 to 8. Requests to Google Fonts, from 5 to 0. Builder-related plugins, from 7 to 0. I did nothing cleverer than remove what wasn’t needed and let WordPress get on with its job.

Fewer files means faster rendering first of all, and better Core Web Vitals, the measures Google uses to judge how a page feels to a visitor. But the effect that matters most day to day is somewhere else. There are far fewer updates to keep an eye on, and far fewer doors for anyone looking for a way in. A site with seven fewer plugins is a site that wakes me up less often at night.

So should Elementor go in the bin?

No, and I want to say so clearly, because this kind of article tends to turn into a settling of scores. The right tool depends on the project, and above all on the team that will look after the site once it’s live.

When a marketing team has to push out landing pages every week, with very different layouts and short deadlines, Elementor still makes complete sense. It gives independence to people who don’t want to wait for a developer to move a button. I’ve seen that situation, and I wouldn’t take their tool away in the name of performance.

When loading speed and ease of maintenance matter more than layout freedom, the block editor is the better choice. That’s the case for a brochure site, a blog or a portfolio like this one. In both situations the rule I apply is the same. Keep plugins to a minimum, switch off what isn’t used, and measure regularly what each page actually loads, because that number tends to creep upwards without anyone noticing.

How I decide these days

Since the rebuild, I ask the same questions at the start of every project, before choosing a tool. They’re simple enough to put to a client who has never opened WordPress.

• What kinds of pages need producing, and who will create them day to day?
• Do the native blocks and the theme’s blocks already cover the need, before a single plugin is added?
• What performance budget are we setting, in number of requests, page weight and Core Web Vitals?
• After each plugin added, did we measure again, and remove whatever brought nothing?

The last question is the one most often forgotten. People measure at launch and then never again, and two years later the home page is loading twice as many files.

A trade-off, renegotiated each time

A page builder is neither good nor bad. It’s an exchange between layout freedom and lightness, and that exchange gets renegotiated on every project. Knowing how to work with both, and sensing the moment to move from one to the other, is part of the WordPress developer’s job as I practise it. Had I measured my own home page earlier, I’d probably have made this choice from the outset. That’s partly why I’m telling the story.