Core Web Vitals are three measurements Google uses to describe how a web page feels to a real visitor: how quickly the main content appears, how quickly the page responds when someone taps or clicks, and whether things jump around while it loads. If your developer or SEO report has flagged “poor Core Web Vitals” and you are not sure whether to worry, this explainer covers what each metric means, the thresholds that count as good, and what you can ask for without needing to read code.
The three Core Web Vitals in plain English
Largest Contentful Paint (LCP): does the page show up quickly?
LCP measures how long it takes for the biggest visible element, usually a hero image or a large heading, to appear. Visitors judge a page by this moment. Google’s guidance is that a good LCP is 2.5 seconds or less, and anything above 4 seconds is poor.
Interaction to Next Paint (INP): does the page respond when I tap?
INP measures the delay between a visitor doing something, such as tapping a menu or pressing “Add to cart”, and the page visibly reacting. A good INP is 200 milliseconds or less, and above 500 milliseconds is poor. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, so older reports that mention FID are out of date.
Cumulative Layout Shift (CLS): does the page stay still?
CLS measures how much the layout moves unexpectedly while loading. You have seen this when you go to tap a button and an advert or image loads above it, pushing the button down. A good CLS score is 0.1 or less, and above 0.25 is poor.
These thresholds come from Google’s own write-up, How the Core Web Vitals metrics thresholds were defined. Google assesses them at the 75th percentile of page visits, which means at least three in four visits need to hit “good” for the page to pass. Thresholds have changed before, so check web.dev for the current figures.
Do Core Web Vitals affect Google rankings?
They play a part, and a modest one. Google’s Search Central page on Core Web Vitals says good scores align with what its core ranking systems seek to reward. It does not say good scores will lift a page to the top. In our view, relevance and content quality carry more weight. A fast page with thin content will not outrank a slower page that answers the question properly.
The stronger reason to care is your customers. In India and the UAE, much of your traffic is likely to be on mobile phones, often on patchy connections. A service page that takes six seconds to show anything, or a form that freezes when tapped, loses enquiries regardless of where it ranks.
How to check your own site
- Open PageSpeed Insights and enter your home page URL. Look first at the section showing what real users experienced. That is field data from Chrome users. The lab score below it is a simulation and useful for diagnosis.
- If you have Google Search Console set up, open the Core Web Vitals report. It groups your URLs into good, needs improvement and poor, for mobile and desktop separately.
- Check your most important pages, not only the home page: top service pages, the contact page, product pages if you sell online.
Small sites sometimes show “not enough data” for field results. That means too few Chrome users visited for Google to report figures. Use the lab data as a guide in that case.
Common causes and fixes
Slow LCP
- Huge hero images. A 4 MB photo straight from a camera is a common culprit. Ask for images to be resized and served in modern formats such as WebP or AVIF.
- Slow hosting or no caching. Cheap shared hosting can add a second or more before anything arrives.
- Fonts and scripts that block the page from drawing.
Poor INP
- Too much JavaScript, often from chat widgets, tracking tags, sliders and page builder add-ons all loading at once.
- Heavy third-party scripts. Each marketing tag you add costs a little responsiveness. Audit them once a quarter.
High CLS
- Images and embeds without set dimensions, so the browser does not reserve space for them.
- Cookie banners, pop-ups or promo bars that push content down after it has appeared.
- Web fonts that swap in late and change line lengths.
What to ask your developer or agency
- “What are our field LCP, INP and CLS on mobile for the top five pages?”
- “Which of these fail, and what is the cause for each?”
- “Which fixes are quick, and which need a bigger change such as new hosting or removing a plugin?”
- “How will we know it worked?” Field data in Search Console updates over a rolling 28-day window, so improvements take a few weeks to show.
If you are planning a new site, put performance targets in the brief from the start. It is far cheaper to build a fast site than to speed up a slow one later. Emberoot checks speed as part of every website build, and if your current site needs a wider look at hosting, plugins and scripts, that sits under our technology advice work.
Want someone to read your PageSpeed report with you? Book a free call.
Frequently asked questions
What is a good Core Web Vitals score?
Google treats a page as good when, at the 75th percentile of visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. There is no single combined score. Each metric passes or fails on its own, so check all three.
Why is my PageSpeed score different every time I test?
The 0 to 100 performance score comes from a lab test that simulates a device and network, and small differences in server response or third-party scripts change it between runs. The field data section, based on real Chrome users over the past 28 days, is steadier and closer to what Google uses for Core Web Vitals.
Do I need a perfect 100 PageSpeed score?
No. The lab score is a diagnostic tool, not a ranking factor in itself. What matters is that real visitors get a fast, stable, responsive page, which shows up as passing Core Web Vitals in the field data. Chasing 100 often means removing useful features for little gain. Fix what fails, then focus on content.