WordPress Training
ElementorWordPress

Elementor and Core Web Vitals: What Actually Counts

“Elementor is slow” is one of the most persistent claims in the WordPress world. It is not entirely wrong and yet it is misleading. A page builder generates more markup than hand-written code — that costs something. But what actually makes Elementor sites slow in practice is almost always something else, and those things can be fixed.

The three values at stake

For some years now Google has measured three metrics that together form the Core Web Vitals.

LCP (Largest Contentful Paint) — when the largest visible element has loaded. Usually the hero image or the large heading. Target: under 2.5 seconds.

INP (Interaction to Next Paint) — how quickly the page responds to an input. It has replaced the earlier FID metric. Target: under 200 milliseconds.

CLS (Cumulative Layout Shift) — how much the content jumps while loading. Everyone knows the feeling: you go to tap a link and at the last moment an image pushes in. Target: under 0.1.

Important for context: Google judges on field data from real visitors, not on the test result of a single run. A good score in the testing tool alongside poor field data means your visitors are experiencing a different site than you are.

LCP: almost always the hero image

In nine out of ten Elementor projects I look at, the large image at the very top is the reason for a poor LCP.

The size. A photo straight from the camera is often 4000 pixels wide and several megabytes. It is displayed at 1600 pixels. Scale it to the size actually needed before uploading.

The format. WebP instead of JPEG typically saves a third at the same quality. There are plugins that handle this automatically.

No lazy loading for the hero image. This sounds counterintuitive but is decisive: deferred loading is meant for images that only become visible on scrolling. If you apply it to the topmost image, you delay precisely the element that determines the LCP. In Elementor you switch this off in the image widget.

Background images with care. An image used as a container background loads later than a real image widget. For the topmost element on the page, the image widget is the better choice.

CLS: reserve the space

Layout shifts occur when an element subsequently claims space that was not planned for. Three causes cover almost everything.

Images without fixed dimensions. The browser only learns how tall the image will be while loading, and pushes everything below it down. Give images a width and height, or a fixed aspect ratio.

Fonts that load late. The text first appears in a fallback font and jumps on the switch. Self-hosted fonts with a suitable loading strategy solve this — and are the better choice in data protection terms anyway, see Elementor and GDPR compliance.

Banners that appear from the top. A cookie banner or notice bar that pushes the content downwards is a guaranteed CLS hit. Lay it over the content rather than in front of it.

INP: less is more

The responsiveness metric suffers from too much JavaScript. On Elementor sites the usual suspects are: sliders and carousels, animated counters, motion effects on scroll, embedded videos and external scripts such as chat windows or tracking.

The most effective measure is also the least popular: use fewer of them. A slider with five images that hardly anyone looks at beyond the first costs loading time for no return.

For embedded videos the rule is: do not embed directly, show a preview image first and load the video on click. Elementor offers an option for this in the video widget.

What Elementor brings along itself

Under Elementor → Settings → Features you will find several switches that help noticeably:

Optimized CSS loading loads only the styles needed on the page instead of one large combined file. Improved asset loading and the option to leave out unused icon libraries go in the same direction.

Switch these options on one at a time and check the page afterwards. In rare cases a style is missing that came in via a third-party plugin.

How to clear out further is set out in removing Elementor bloat.

What Pro changes about this: nothing

So no false expectation arises here — the Pro version does not make your site faster. It brings features, not speed. Anyone who uses more widgets because of Pro tends to get slower.

Elementor Pro: worthwhile for the Theme Builder, forms and popups — not for loading time. That belongs to an honest assessment. View Elementor Pro

The order in which I work

Images first, then caching, then fonts, then scripts. In that order, because it is sorted by diminishing return. On most sites the first two steps alone move the score from red into green.

Measure before and after, otherwise you are optimising blind. And measure on mobile — that is where the values are worse and where the assessment is decided.

Further levers are collected in optimising Elementor performance. If you would rather go through this once on your own site, we do that in my Elementor training.

Tags

Core Web VitalsElementorPerformanceSEOWordPress