Key takeaways
- Google measures three things: how fast the main content appears (LCP, under 2.5 seconds), how quickly the page reacts to a tap (INP, under 200 milliseconds), and how much it jumps around while loading (CLS, under 0.1).
- On most Elementor sites, five things decide the result: image sizes, fonts, the hero section, third-party scripts and caching. Plugins come sixth.
- Lab scores are a diagnosis. The field data in Search Console is the verdict, and it is what ranking uses.
What is measured
Core Web Vitals are Google's three measurements of how a page feels to a real visitor. They are collected from Chrome users and reported in Search Console, and they are one of the signals in ranking.
| Metric | Measures | Good |
|---|---|---|
| LCP, Largest Contentful Paint | when the biggest visible element has loaded, usually the hero image or headline | under 2.5 s |
| INP, Interaction to Next Paint | how long the page takes to respond to a tap or click | under 200 ms |
| CLS, Cumulative Layout Shift | how much content moves while the page loads | under 0.1 |
INP replaced the older First Input Delay in March 2024 and is stricter; it measures every interaction, not just the first.
The five things that move it
1. Images
The most common cause of a slow LCP is a 4'000-pixel photo displayed at 800 pixels. Every image on the site should be sized for where it appears, saved in a modern format (WebP, or AVIF where supported) and given explicit dimensions so the browser reserves the space. Elementor can serve responsive sizes; it cannot fix a 6 MB upload.
Lazy loading everything below the fold is right. Lazy loading the hero image is wrong; it delays the one image LCP measures.
2. Fonts
Web fonts loaded from Google's servers cost a connection and a round trip, and they are a privacy issue in Switzerland anyway. Host them locally, limit the weights to the two or three you use, and set them to display with a fallback until loaded. Unused icon fonts are a classic hidden cost; Elementor lets you switch them off.
3. The hero section
The first screen decides LCP. A hero with a background image, an overlay, a slider and an animation loads all of it before the visitor sees anything. The fix is a single optimised image, preloaded, with the headline as real text. Sliders in the hero are slow and almost nobody swipes them.
4. Third-party scripts
Chat widgets, embedded maps, video embeds, tracking pixels, social feeds. Each one loads code from another server and runs it on your page, and they are the main cause of a bad INP. Load them on interaction (the map when scrolled to, the video when clicked), or ask honestly whether the site needs them.
5. Caching and hosting
A page should be built once and served from cache, with the files compressed and delivered from a server near the visitor. A caching plugin plus a decent Swiss or European host does this. A cheap shared host with no caching layer loses a second before anything else is considered.
Elementor's own settings
Elementor has improved its output a lot in recent versions, and the settings are worth a pass:
- Flexbox containers instead of the old sections and columns, for less markup.
- Optimized markup and optimized CSS loading switched on.
- Icon and font libraries that the site does not use switched off.
- Google Fonts set to load locally.
- Widgets and add-on packs the site does not use deactivated. Every add-on pack loads its styles on every page.
Plugins
Plugins are blamed first and matter sixth. Forty plugins are a maintenance problem more than a speed problem, provided each one loads only where it is used. The ones that hurt are the few that load their scripts on every page: sliders, page builders' add-on packs, social sharing bars, some form plugins. Audit the ones that load on the home page and remove what is not needed.
How to check properly
Lab tools (PageSpeed Insights, Lighthouse) run the page once on a simulated device and are useful for finding what to fix. The field data at the top of PageSpeed Insights, and in Search Console under Core Web Vitals, is what real visitors experienced over the last 28 days. That is the number that counts for ranking and the one to report.
A site that scores 95 in the lab and fails in the field has a real-world problem, usually a slow host or a script that only misbehaves on older phones.
FAQ
What score should I aim for?
Green in the field data on mobile for all three metrics. The lab score is a guide; 90 and above is a good sign, but the field data decides.
Does Core Web Vitals really affect ranking?
Yes, as one signal among many. It will not lift a thin page above a good one, but between two comparable pages the faster one tends to win, and a failing page can be held back.
Is Elementor slower than other builders?
Built carelessly, all builders are slow. Built with the settings above, an Elementor site passes comfortably. The variable is the build, not the tool.
How often should speed be checked?
After every significant content change, and at least quarterly. Sites slow down as images and plugins accumulate, which is why my care plans include a speed check every quarter.
Twenty minutes on the phone, a written quote within two working days.