Search Console has a report called Core Web Vitals, and every few months it emails a business owner to say some of their pages are “poor”. The owner pastes the URL into PageSpeed Insights, gets a score of 34 in red, and either panics or decides the whole thing is nonsense. Neither reaction is quite right. The three metrics behind the report measure things visitors notice, the score at the top mostly doesn’t, and a business site can usually get from red to green with a handful of specific changes, most of which have nothing to do with the hosting upgrade the host keeps suggesting.
Quick answer: Three numbers matter: LCP (how long until the main content shows, target under 2.5 seconds), INP (how quickly the page responds to a tap or click, under 200 milliseconds), and CLS (how much the layout jumps around, under 0.1). Use the field data in Search Console, not the lab score. On most WordPress and Elementor sites, LCP comes down to the hero image and render-blocking CSS, INP to third-party scripts, and CLS to fonts, embeds, and images without dimensions. Fix those and stop chasing 100.
What are the three metrics measuring?
Largest Contentful Paint is the time from the visitor requesting the page to the biggest thing in the viewport being drawn, which on a business site is nearly always the hero image or the heading over it. Interaction to Next Paint measures how long the page takes to visibly respond after someone taps a menu or clicks a button; it replaced First Input Delay in 2024 and is stricter, because it looks at every interaction on the page rather than only the first. Cumulative Layout Shift is a score for how much things move after they first appear, the effect where you go to tap a button and an image loads above it and pushes it down.
Google uses the numbers from real visitors’ browsers, collected over 28 days and reported at the 75th percentile. So the question is whether three quarters of your actual visitors, on their actual phones and connections, had a good experience. That’s different from the lab test PageSpeed Insights runs on a simulated slow phone, which is useful for diagnosis and misleading as a target.
Which numbers should you look at?
Search Console’s Core Web Vitals report, split by mobile and desktop, grouped by page type. That’s field data. If it says your product pages are poor on mobile for LCP, that’s a real problem for real visitors, and the report will tell you which metric and which group of URLs. The lab score in PageSpeed Insights is the one to ignore as a target: it compresses several metrics into a single number weighted for a slow device, and sites with a lab score in the 40s routinely pass the field assessment.
If Search Console shows no data, the site doesn’t have enough traffic for Google to report on it, and in that case the Vitals aren’t affecting your rankings in any measurable way; use the lab tool to fix the obvious things and move on.
What usually causes a poor LCP?
On WordPress sites, and Elementor sites in particular, the same few things. The hero image is a 3,000-pixel JPEG served at full size to a phone, so it’s the last thing to arrive. The page loads a lot of CSS before it draws anything, because the page builder ships styles for every widget whether the page uses them or not, and a couple of plugins add their own. Web fonts load late and the heading waits for them. And the server itself is slow to send the first byte, which is the one case where the host matters; anything over about 600 milliseconds to first byte is worth raising with them, and our post on why a WordPress site is slow goes through how to tell hosting problems from everything else.
The fixes, in the order we’d try them: serve the hero image at the size it’s displayed, in WebP or AVIF, and add a preload hint for it so the browser fetches it first. Turn on the page builder’s options for loading only used CSS and deferring the rest (Elementor has these under Performance in its settings). Self-host the fonts, limit them to the weights used, and set font-display to swap. Add caching and a CDN if the site doesn’t have them. That sequence gets most business sites under 2.5 seconds without touching the theme.
What causes a poor INP?
JavaScript, nearly always somebody else’s. Chat widgets, tag managers loaded with a dozen tags, heat-mapping tools, social embeds, and cookie banners all run code on the main thread, and when a visitor taps the menu while that code is running, the menu waits. The site’s own scripts rarely cause it on a brochure site; on a store, a badly written add-to-cart or filtering script can.
Open the site with a browser’s performance panel, or look at the Lighthouse “reduce JavaScript execution time” section, and the culprits are listed by domain. Then decide, for each third-party script, whether it’s earning its place. A chat widget nobody has answered in six months isn’t. For the ones that stay, load them after the page is interactive rather than in the head; most tag managers and chat tools support a delayed load, and a few seconds’ delay costs nothing.
What causes layout shift?
Images and embeds without width and height attributes, so the browser doesn’t reserve space for them. Fonts that swap in with different metrics and reflow the text. Banners, notices, and cookie bars injected at the top of the page after it’s drawn. Ads, if you run them. Most of this is fixed by making sure every image has dimensions (modern WordPress adds them if the theme cooperates), giving embeds a fixed-height container, and putting notices in space that’s reserved from the start rather than pushed in. CLS is the metric most often fixed in an afternoon.
What should you ignore?
Chasing a 100 lab score, which usually means stripping features the business needs. Minifying HTML, which saves almost nothing. Most “optimisation” plugins that promise a green score in one click; some help with caching and image conversion, and some break checkout, which our WooCommerce checkout post has a section on. Lab-only metrics like Total Blocking Time when the field INP is fine. And upgrading hosting before you’ve fixed the image and script problems, because a faster server delivers the same 3 MB hero image at the same size.
Core Web Vitals are a ranking signal, and a small one; content and links matter more. The reason to fix them is that the visitor experience is real, and a page that draws in a second and responds when tapped converts better than one that doesn’t. Once fixed, they tend to stay fixed if someone is watching, which is one of the things a maintenance arrangement should include, since a single new plugin can undo a good LCP.
If the site is an Elementor build with a poor LCP that the settings above didn’t fix, that’s a job we take on regularly under solutions and improvements. It’s usually a day or two, and most of it is images and scripts rather than anything structural.
Frequently asked questions
Does a poor Core Web Vitals score hurt my rankings?
A little, and much less than most people fear. It’s a tie-breaker among pages with similar content. Fixing it won’t lift a page from position 30 to 3; it might move you above a competitor with similar content and a slower site.
Why does PageSpeed Insights show a different result every time?
The lab test runs on a simulated device and network, and small variations in what loads when change the score. Use the field data at the top of the report if it’s there, and treat the lab score as a diagnostic that fluctuates.
My desktop scores are fine but mobile is poor. Why?
Mobile visitors have slower devices and connections, and the field data reflects that. Images sized for desktop and third-party scripts hit them much harder. Fix for mobile and desktop takes care of itself.
Will a caching plugin fix it?
It helps with time to first byte and repeat visits, which helps LCP. It does nothing for oversized images, third-party JavaScript, or layout shift. Caching is one of the steps, and on its own it rarely moves a page from poor to good.
Should I switch away from Elementor for performance?
Not for performance alone. Elementor sites can pass Core Web Vitals with the settings and image work described above. Rebuilding is justified when the site has other problems too; performance by itself is fixable in place.
How long until Search Console shows the improvement?
The report uses 28 days of field data, so expect up to a month after the fix for the status to change, and longer if the site has little traffic.