If you have ever run your site through Google PageSpeed Insights and stared at a wall of acronyms, this post is for you. Core Web Vitals are the three measurements Google uses to judge how a page feels to a real person, and they are part of how Google ranks pages.
You do not need to become a performance engineer. You do need to know what the numbers mean, which ones matter for your site and what to ask your developer to fix.
The three metrics in plain English
- LCP (Largest Contentful Paint) measures how long the biggest visible thing on the page, usually a hero image or headline, takes to appear. Target: under 2.5 seconds.
- INP (Interaction to Next Paint) measures how quickly the page reacts when someone taps or clicks. Target: under 200 milliseconds.
- CLS (Cumulative Layout Shift) measures how much things jump around while the page loads, the classic case being a button that moves just as you tap it. Target: under 0.1.
Google reports these from real Chrome users where it has enough traffic (field data), and simulates them in a lab test otherwise. A site with little traffic will only see lab scores, which are stricter because they simulate a mid-range phone on a slow connection.
Why business owners should care
Three reasons. Google uses the metrics as a ranking signal, so a slow site competes with a handicap. Slow pages convert worse: every extra second of load time measurably reduces leads and sales. And for paid traffic, a slow landing page raises your cost per acquisition because you paid for clicks that bounced before the page appeared.
How to check your site
Run your homepage and your most important landing page through PageSpeed Insights on mobile. Look at the three Core Web Vitals first, then the Diagnostics list, which tells you what is causing the problem. Google Search Console also has a Core Web Vitals report that groups all your URLs by status.
The fixes that make the biggest difference
- Oversized images. The single most common issue. A logo exported at 1,000 pixels and shown at 60 pixels costs seconds on mobile. Resize, compress, and serve WebP or AVIF.
- Render-blocking fonts and scripts. Web fonts and JavaScript libraries loaded synchronously stop the page from painting. Load fonts asynchronously, defer scripts.
- Too much JavaScript. Page builders, chat widgets, trackers and animation libraries pile up. Remove what you do not use; defer the rest.
- Missing image dimensions. Images without width and height attributes cause layout shift as they load.
- No caching or CDN. A CDN and correct cache headers make repeat visits near-instant.
On a recent cleanup we took a site's home page from over 4 MB of images to under 100 KB without changing a single pixel of the design. That is typical: most performance problems are invisible to the eye and expensive on the network.
What to ask your developer
Ask for a performance budget written into the project: a maximum page weight and target Core Web Vitals on mobile before launch. Ask that it is checked on a real mid-range phone, not only a fast laptop. Performance is a build requirement, not a cleanup pass, and that is how we treat it in every build.
Lab data versus field data
PageSpeed Insights shows two kinds of results. Field data comes from real Chrome users visiting your site over the past 28 days and is what Google actually uses for ranking. Lab data is a single simulated run on a throttled device. When a site has little traffic, only lab data exists and the report says 'No Data' for real users. That is not a penalty; it just means Google does not yet have enough visits to measure.
Lab scores are stricter than most field results because the simulation assumes a slow phone on a slow connection. A lab score of 60 can coexist with perfectly good field metrics. Use lab data to find problems and field data to judge whether they matter.
A realistic improvement plan
Start with the home page and the two or three pages that drive the most leads. Fix images first, since they are usually the largest win for the least effort. Then address fonts and scripts. Then layout shift. Re-test after each change rather than all at once, so you know what worked. Most sites move from 'poor' to 'good' on mobile in one focused pass of a day or two, without any visible design change.
Frequently asked questions
Is a score of 100 necessary?
No. Aim for 'good' on all three Core Web Vitals on mobile. Chasing the last few points often costs more than it returns.
Why is my desktop score fine but mobile poor?
Mobile tests simulate a slower device and connection. The same page weight that is fine on fibre and a laptop hurts on 4G and a mid-range phone.
Will a faster site rank first?
Speed is one signal among many. It will not beat better content, but it removes a penalty and improves conversions on the traffic you already have.
Founder & CEO of Devontix Solutions. Absaar leads strategy, automation planning and product thinking across every build, from the first discovery call to the running system. More about Absaar