Build less page. What Elementor V4 asks of the plugins around it.

A shopper opens a product page on their phone. The photo appears, then the price, then the Add to basket button. Their thumb moves towards it. A reviews carousel finishes loading above the button and pushes everything down, and the tap lands on a size guide instead.

Nobody designed that moment. It was assembled: a builder, a theme, an add-on pack for the carousel, an animation library for the fade-in, a second icon font, a chat bubble. Each one made sense when it was added. Together, they decide what the shopper sees first and whether the button stays where it was.

That is why page speed belongs in a UX conversation, not just a developer one. And it is why Elementor V4, which Elementor itself presents as “the next era of website building”, is worth reading closely, especially if you build shops.

Speed is part of the interface

Google’s Web Vitals guidance describes three Core Web Vitals, each tied to something a person experiences. Largest Contentful Paint measures loading, and should happen within 2.5 seconds. Interaction to Next Paint measures how quickly the page responds, and should be 200 milliseconds or less. Cumulative Layout Shift measures visual stability, and should be 0.1 or less. The guidance suggests checking these at the 75th percentile of page loads, on mobile and desktop separately, so the target covers most visitors and not just the lucky ones.

Put those in shop terms. Is the product there? Does the button respond when I tap it? Does it stay where I’m aiming?

The web.dev guide to optimising CLS even uses the shop example. Layout shifts are “very common on the web, including when reading the news, or trying to click those ‘Search’ or ‘Add to Cart’ buttons”. It lists the usual causes: images without dimensions, ads, embeds and iframes without dimensions, content injected after the page loads, and web fonts. On a WordPress shop, many of those arrive through a plugin.

What Elementor V4 changes

Elementor’s version 4 FAQ describes the new editor as “an atomic, CSS-first, performance-optimized architecture”. Since April 2026, new Elementor sites run on version 4 by default. Existing sites can switch it on and adopt it gradually.

The central claim is about markup. In Elementor’s words, the Atomic Elements “are based on pure HTML tags that render without additional wrapper layers”, which “contributes to cleaner output and improved Core Web Vitals”. Styling moves to reusable classes and variables, so a heading style is defined once and applied everywhere, instead of being set element by element.

Why do wrappers matter? Chrome’s Lighthouse documentation on DOM size explains that a large DOM tree can slow a page in several ways. It can add nodes the visitor never sees on first load. It makes the browser “constantly recompute the position and styling of nodes” as people and scripts interact. Fewer layers, less work.

Elementor is careful about the limits. The same FAQ says that “when combining legacy v3 widgets with v4 Atomic Elements, performance gains may vary”, and that output gets leaner “as more Atomic Elements replace older widgets”. Its getting started guide adds that, in this hybrid set-up, the editor places a new V4 element inside a 3.x container when you drag it onto the canvas. The new core is lean. A page mixed with the old one is partly lean.

The other builders made the same bet

Elementor isn’t alone. Two rivals shipped rewrites within days of each other in February 2026.

Soflyy released Oxygen 6 on 24 February, a ground-up rewrite that promises “full control over semantic HTML and CSS”. Its launch post makes an argument worth borrowing whatever builder you use: “When you stack different components with their own markup and styling conventions, you lose consistency and control.”

Two days later, Elegant Themes took Divi 5 out of beta after more than a year of public testing. Its launch notes are the bluntest of the three about what holds a page back. Any page that contains a legacy Divi 4 module runs in “backward compatibility mode”, and on those pages you won’t “benefit from Divi 5’s performance improvements”. Its migrator converts Divi’s own modules across a site in one go, but third-party modules that haven’t been updated for Divi 5 stay in that mode until their developers catch up. That is honest of Elegant Themes. It also means that a Divi site built on years of add-on modules may see less of the new speed than the launch implies.

Read the three together and the message is consistent. Each new core is meant to be lighter, and the pieces you keep around it decide how much of that reaches the shopper. We’ll compare Elementor and Oxygen on the page each one actually ships in next week’s story.

The plugins around the builder

Elementor’s own help centre answers the question most builders eventually ask: do unused widgets slow a page down? For Elementor’s native widgets, it says no. Their assets load only where they’re used, apart from a small shared base. Then it adds: “Some third-party plugins may allow disabling of their widgets as they may require actively disabling to prevent them from loading assets even when not in use.”

That sentence is the whole problem in miniature. You can build a product page with lean atomic elements and still ship an add-on pack’s scripts and styles to every page on the site. You can also ship a slider library to a page with no slider, an animation script that delays the first view, or a reviews widget that injects itself above the fold after everything else has loaded.

None of these plugins is bad on its own. The question is whether each one earns its place on the pages where people make decisions.

An audit you can run this afternoon

1. Watch the first screen on a phone. Load your best-selling product page on a mid-range phone or a throttled browser. Note what arrives last, and whether anything moves the price, the delivery line or the button.
2. List what renders on product, cart and checkout pages. For each plugin, write down the decision it helps the shopper make. If the answer is “none”, take it off those pages.
3. Check what loads where it isn’t used. Use your browser’s network panel on a page without the add-on’s widget. If its files still load, use the add-on’s own setting to switch off unused widgets, or unload it on those pages.
4. Reserve space for anything that arrives late. Give images width and height. Give reviews, embeds and banners a minimum height, as the web.dev guidance recommends, so they fill a gap rather than push content.
5. Cut type and effects you can’t justify. Fewer font families and weights, a sensible fallback font, and entrance animations only where they explain something.
6. Build new sections from atomic elements. Where V4 is active, use atomic elements for new work rather than adding more legacy widgets, and accept that a mixed page is a transition, not the finish line.
7. Measure in the field, not just the lab. PageSpeed Insights and Search Console’s Core Web Vitals report show real-visitor data once a site has enough traffic. A better lab score after you remove a plugin is a good sign. The field data, at the 75th percentile, tells you whether shoppers felt it.

Build less, decide more

The pattern behind all of this is a design principle, not a speed trick. Every element on a product page should help someone decide: what it is, what it costs, when it arrives, whether to buy. Elements that don’t help add weight, wrappers, requests and movement, and the shopper pays for them in time and mis-taps.

Elementor V4, Oxygen 6 and Divi 5 are all built, by their makers’ accounts, to make the core of the page lighter. None of them can remove the plugin you added for a fade-in. That part is still a decision, and it’s yours.