Do Page Builders Hurt Core Web Vitals?

What does Google actually measure?

Core Web Vitals are three timing and stability scores that Google collects from real Chrome users visiting real pages, and in 2026 the thresholds are the same ones web.dev has published since Interaction to Next Paint replaced First Input Delay in March 2024:

• Largest Contentful Paint (LCP) is loading. How long until the biggest thing in view, usually a hero image or a headline block, has rendered. Good is 2.5 seconds or under. Poor is over 4 seconds.
• Interaction to Next Paint (INP) is responsiveness. When someone taps a menu, a button or a form field, how long before the screen visibly reacts. Good is 200 milliseconds or under. Poor is over 500.
• Cumulative Layout Shift (CLS) is visual stability. How much the page jumps about while it settles. Good is 0.1 or under. Poor is over 0.25.

There is a detail most summaries skip. A page does not pass by hitting those figures on average. Google looks at the 75th percentile of visits, split into mobile and desktop. So three visits in four have to be good on each metric, and the page has to clear all three to pass. The slower devices and patchier connections in your audience count in full.

You will see articles this year claiming the targets were cut to 2 seconds and 150 milliseconds. Google's own documentation doesn't say that. I work to the published figures, and I would treat anyone quoting tighter "official" numbers without a Google link with some suspicion.

Is the page builder really the problem?

Mostly, it is the way builders produce a page rather than the idea of dragging boxes about.

The HTTP Archive's 2025 Web Almanac is the best public data I know of on this. Its CMS chapter estimates that around 60% of WordPress sites use a page builder, with Elementor the most common, followed by WPBakery and Divi. It also says, plainly, that builders "often generate more complex DOM structures and larger CSS and JavaScript bundles", and that newer optimisation features help but "do not completely erase the performance gap" against more tightly controlled builds.

On mobile, 45% of WordPress sites passed all three Core Web Vitals in that dataset. Only 53% had a good LCP.

To be fair, and I want to be, the same chapter shows hosted builders doing better than you might expect. Wix passed 74% on mobile and Duda 85%, even though Wix pages carried a median of roughly 1.6 MB of JavaScript. That's more than double WordPress's median. The platform engineers tune delivery centrally, so each owner doesn't have to. That's a real point in their favour, but it's their engineering, not yours. You can't open the bonnet when a particular page fails.

So the honest answer is that builders don't guarantee a failing score. They make passing harder, and they make the fix less yours to control.

How does builder output drag down LCP?

LCP is mostly about how quickly the browser can find the main image or heading and paint it. Builders tend to get in the way in a few predictable places.

Render-blocking stylesheets. A typical builder page links a global framework stylesheet, a per-page stylesheet, an icon font or two, a theme stylesheet and whatever each add-on brings. The browser won't paint until it has fetched and parsed the CSS in the head. Every extra file in that queue is a round trip before anything appears.

Hero images the browser can't see coming. When the main image is a CSS background, or is injected by a slider script after the JavaScript runs, the browser's preload scanner doesn't find it early. web.dev's LCP guidance singles this out: the image request starts late, so the paint lands late.

Blanket lazy-loading. Some builders and optimisation plugins apply lazy-loading to every image on the page, including the one at the top. Lazy-loading the LCP image tells the browser to wait, which is the opposite of what you want.

Slow server responses. A page that has to be assembled from a database, a theme and a stack of plugins on every uncached request starts later. Time to First Byte isn't a Core Web Vital itself, but every millisecond of it comes straight off your LCP budget.

Why does INP suffer on builder sites?

INP is the newest of the three and, from what I see, the one owners understand least. It measures the gap between a tap and the next frame. That gap mostly depends on how busy the browser's main thread is when the tap arrives.

Builder pages keep that thread busy in a few ways. Animation-on-scroll libraries, sticky headers that recalculate on every scroll, mega-menu scripts, carousels and pop-up modules all queue up JavaScript. Add a tag manager, a chat widget, a review feed and a cookie tool, and a tap on the menu button has to wait its turn.

DOM size makes it worse. Builders wrap each visible element in layers of containers: section, column, inner wrapper, widget, widget container. Lighthouse warns when a page's body has more than about 800 elements and flags an error above about 1,400. Builder pages often go well past that. A bigger tree means more work every time the browser recalculates styles and layout after an interaction, so each tap costs more.

One practical catch: Lighthouse, the lab tool behind PageSpeed Insights' score, can't measure INP at all because no one taps anything during the test. It reports Total Blocking Time as a stand-in. A page can look fine in the lab and still fail INP for real visitors.

What makes a builder page jump about?

CLS problems on builder sites usually come from content arriving in stages.

• Images and embeds without declared dimensions, so the space collapses and then springs open.
• Web fonts that swap in after a fallback, reflowing every heading.
• Sliders that render as a stack of images before the script tidies them into one.
• Cookie banners, promo bars and "book now" strips injected at the top after the page has painted.
• Sections that only appear once a script checks the screen width.

Each of these is fixable in a builder, usually with a setting, an extra plugin or custom code. That's the pattern I keep running into. The fix is another layer on top of the layer that caused the problem.

How do the metrics compare side by side?

How can you check your own site?

Start with PageSpeed Insights and read the top section, not the score. The part headed with real-user data shows your LCP, INP and CLS at the 75th percentile over the last 28 days. The coloured score further down is a single simulated lab run.

Here's the awkward bit for smaller UK businesses. Chrome only publishes field data for pages and sites with enough traffic. A lot of local business sites show "no data" for individual pages, and sometimes for the whole domain. In that case you are flying on lab numbers. That's fine for spotting render-blocking files, oversized DOMs and missing image dimensions, but it's not what Google's ranking systems see.

If you do have enough traffic, Search Console has a Core Web Vitals report. It groups similar URLs and labels each group by its worst metric, so one bad CLS figure turns the whole group red even if LCP and INP are fine.

That's also why I hand-code every site in plain PHP, HTML, CSS and JavaScript, with no WordPress, Elementor or theme underneath. After twelve years of building websites, I'd rather know what every file on a page is doing than inherit a builder's guess. The closest thing I have to a before-and-after is Beauty Within, a nurse-led beauty and wellbeing salon here in Kingswood. It used to sit on a BookSolo template, a shared platform address with a stock layout and booking bolted on. I rebuilt it as a hand-coded site on its own domain, with the booking journey (treatment, date, details and payment) built into the site itself. That project was about ownership and the booking journey rather than chasing a score, so I won't pretend I have a neat set of before-and-after speed numbers from it. What I can say is that nothing on the new site loads unless the page actually needs it.

Do Core Web Vitals decide rankings?

They are part of it, not all of it. Google says Core Web Vitals are used by its ranking systems, and also that good scores don't guarantee good rankings. Relevance and useful content still come first. A fast page about the wrong thing won't outrank a slower page that answers the question.

My reason for caring is simpler. The three metrics are a decent proxy for whether a visitor on a mid-range device gets a page that shows up, responds and stays still. That affects enquiries whether or not it moves a ranking.

So should you rebuild?

Not automatically. If your builder site passes all three in the field data, leave it alone and spend your energy elsewhere. If it's failing and you can't get it passing without a performance plugin, a caching plugin, an image plugin and a font plugin all fighting each other, a lean rebuild is often the cleaner route. You end up with fewer moving parts to go wrong later, too.

When I build, I write the HTML, CSS and JavaScript by hand, so every element on the page is one I chose. That doesn't make a site pass by magic. Heavy photos and a pile of third-party tags can still sink it. It does mean that when a number slips, I can find the cause in minutes rather than digging through someone else's framework.

If you'd like me to read your PageSpeed field data with you and give you a straight answer on whether it's a tweak or a rebuild, send the address through the quote form. You can also email info@shaunallen.co.uk or ring 07900 141 380 and I'll talk you through what the three numbers are saying.