Core Web Vitals explained in plain words: they are three measurements Google uses to judge how a page feels to a real visitor. The first measures how fast the main content appears. The second measures how quickly the page responds when someone taps or clicks. The third measures whether the layout stays still while it loads. If you run a small business website and someone has told you your site is slow, or you have seen poor URLs in Search Console, this guide shows you what each metric means, the scores that count as good, how to read your own report, which fix comes first, and when to ask a professional for help. You do not need to be a developer to follow it.
Core Web Vitals explained in plain words
Think of the three metrics as three questions a visitor’s browser is silently asking on every page. Did the main content appear quickly? Did the page respond quickly when I tapped something? Did things stop jumping around while I was reading? Google gives each question a metric and a name. Largest Contentful Paint, or LCP, answers the first question. Interaction to Next Paint, or INP, answers the second. Cumulative Layout Shift, or CLS, answers the third. Together they describe how a page feels to a real person, not how it looks in a design file and not how clever the copy is.
Google introduced Core Web Vitals as part of its page experience signals in 2021, and it has refined them since. One change matters for anyone reading an old report: Interaction to Next Paint replaced First Input Delay, or FID, as the responsiveness metric on 12 March 2024. FID only measured the delay before the browser could start on the first interaction. INP observes every click, tap and key press during the whole visit and reports close to the slowest one. If a report or an agency still talks about FID, that advice is out of date.
Each metric has three bands: good, needs improvement, and poor. A page passes the Core Web Vitals assessment when at least three in four real visits meet the good target on all three metrics. Google judges each metric at the 75th percentile of page loads, so the average is not what counts. Mobile and desktop are measured separately, and it is common for a site to pass on desktop and fail on mobile, because phones have slower processors and patchier connections.
The three metrics and the scores that count as good
The table below gives the bands Google publishes for each metric. Keep it beside you when you read your own report. The numbers are the same for every site, so a slow result means the same thing on a shop, a blog, or a service page.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: how long until the largest image or text block in view finishes rendering | 2.5 seconds or less | Over 2.5 up to 4 seconds | Over 4 seconds |
| Interaction to Next Paint (INP) | Responsiveness: how long from a click, tap or key press until the page shows the next frame | 200 milliseconds or less | Over 200 up to 500 milliseconds | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability: how much visible content moves without the visitor asking it to | 0.1 or less | Over 0.1 up to 0.25 | Over 0.25 |
Largest Contentful Paint (LCP): how fast the main content appears
LCP measures how long it takes for the largest visible element on the page to finish rendering. On most business sites that is the hero image or the main heading. It is the moment your visitor feels like the page has loaded. A slow LCP means visitors are staring at a blank or half loaded screen, and many leave before the site ever fully appears. Google splits LCP into four parts: the server response, the wait before the largest element starts loading, the time it takes to download, and the delay before it renders. The slow part tells you what to fix. If the server is slow, the image cannot save the result. If the hero image is heavy, the server cannot save it either. The fix depends on which part is slow, and PageSpeed Insights names the largest element for each page, which is where to start.
Interaction to Next Paint (INP): how quickly the page responds
INP measures how responsive a page is to the person using it. Every time a visitor clicks a button, taps a link, or types in a form field, the browser needs to process that interaction and update the display. INP captures the delay between the interaction and the next visual update, across all interactions during the visit. Scrolling and hovering are not counted. A poor INP feels like a stuck menu, a button that seems dead, or a form that ignores typing. The usual cause on a WordPress site is JavaScript: long tasks on the browser’s main thread, too many plugins loading scripts, and third party widgets such as chat tools, review widgets and tracking pixels all competing for the browser’s attention.
Cumulative Layout Shift (CLS): does the page stay still
CLS measures visual stability. It catches the button that moves just as someone goes to tap it, the banner that pushes the text down, and the headline that jumps when a font loads late. You have felt this yourself: you are about to tap a button on your phone and a late image loads above it, pushing everything down, so you tap the wrong thing. Most CLS problems have a small set of causes: images or videos without known dimensions, fonts that render larger or smaller than their fallback, ads or widgets that resize themselves, and content inserted above what is already on screen, such as a promo bar that appears after the page has loaded. The fix is to reserve the space before the content arrives, so the page does not move.
How much do Core Web Vitals affect Google rankings?
Some, but less than many sales pitches suggest. Google’s own wording is precise. Google says Core Web Vitals are used by its ranking systems. It also says it always seeks to show the most relevant content, even if the page experience is sub-par. Where many pages are equally helpful, great page experience can contribute to success in Search. And good results in Search Console or third party tools do not guarantee that your pages will rank at the top of Google Search results.
In practice, a fast page with thin content will not outrank a slower page that answers the question better. Treat Core Web Vitals as a tie-breaker and a matter of customer experience, not as a ranking shortcut. The stronger case for speed is what happens after the click. A visitor kept waiting, or one who taps the wrong button because the layout moved, is less likely to get in touch. That is the commercial reason to fix them, and it does not depend on any ranking promise. No speed fix can promise a top ranking, and this guide makes no such promise.
Field data and lab data: read the right number first
PageSpeed Insights shows two kinds of data, and they are easy to confuse. Field data comes from real visitors. It is collected through the Chrome User Experience Report, known as CrUX, which is Google’s public dataset of how real Chrome users experience popular sites over the previous 28 day collection period. Lab data comes from a single simulated test run on a mid tier phone on a mobile network. They measure different things, and Google says field data is what you should use to prioritise your efforts.
Read the field data section first when you open a report. If a page has too little field data, which is common on small or new sites, the tool falls back to data for the whole site, or shows none. That is normal, not a fault on your site. Rely on the lab test for now and recheck once traffic grows. The lab test cannot measure INP, because nobody is tapping anything in a lab test. Lighthouse uses Total Blocking Time as a stand-in. The 0 to 100 performance score is a lab diagnostic: 90 or above is good, 50 to 89 needs improvement, and below 50 is poor. It is useful for finding problems, but it is not the number Google uses in Search. A perfect lab score is not the goal. Passing the field data for all three Core Web Vitals on your key pages matters more.
Search Console has its own Core Web Vitals report, which uses the same real user data. It groups similar URLs together and gives each group the status of its worst metric, separately for mobile and desktop. Start with the mobile report, because Google mainly ranks your site using the mobile version, and mobile scores are almost always lower.
How to check your own Core Web Vitals in ten minutes
You need two free Google tools and one habit. No paid tool and no developer is needed for this check.
First, open Search Console and go to Core Web Vitals. Look at the mobile report first and note which URL groups are poor and for which metric. A group marked poor for LCP needs a different fix from a group marked poor for CLS, so write down the metric for each group.
Second, run PageSpeed Insights on the mobile setting for your home page and the two or three pages that bring in most enquiries. Paste the page address, run the test, and read the field data first, then the lab diagnostics. Write down the LCP element that PageSpeed Insights names for each page. That one item often explains most of a slow LCP. Test more than your home page. Run the test on a service page, a blog post, and your contact page too, because one heavy page can be slow while the rest of the site is fine. If you send ad traffic to a landing page, test that page as well. For a shop, test a product page and the checkout page. Our guide on a slow WooCommerce checkout shows how a checkout page can be slow while the rest of the store is fast.
Third, test on a real phone. Open your home page on mobile data, not office Wi-Fi, and note what appears late or jumps. Your own browser caches your site after the first visit, so your computer shows you a faster version than a new visitor sees. A real phone on a real connection shows you what a first time visitor experiences.
If there is no field data, do not panic. Small and new sites often have none, because Google needs enough real visits for a meaningful sample. Use the lab results to find the problems, fix them, and recheck once traffic grows. Search Console will show field data once your pages have enough visits.
What usually causes a bad score on a WordPress site
Most slow WordPress sites share the same few causes. Knowing them helps you read your report without guessing.
Oversized images are the most common cause of a poor LCP. Photos uploaded straight from a camera or a stock library are often far heavier than the screen needs. A phone does not need the large image a desktop monitor uses. Compressing images and serving them in a modern format such as WebP is usually the cheapest improvement available. A hero image that loads late is the next cause. The hero image should start downloading at the same time as the first resource on the page. If it is set as a background image or loaded by a script, it starts late. Put the hero image in the page content, mark it to load first, and never lazy load it. Lazy loading belongs below the first screen only.
Render blocking CSS and JavaScript delay everything. The browser cannot show the page until it has processed the stylesheets and any scripts placed in the page head. Heavy JavaScript also causes poor INP, because long tasks on the browser’s main thread delay the response to taps. Third party scripts make both worse. Chat widgets, booking tools, review widgets, ad pixels and analytics tags all load code from other companies’ servers. If a script does not add clear value to your site, remove it. Load the rest later, unless the page cannot render without it. A chat widget or a video embed can sit behind a lightweight image that loads the real widget only when someone clicks it.
Web fonts are a quiet cause of both LCP and CLS. Every font file is another download, and a late font can make text appear late or jump when it swaps in. Use fewer fonts, serve them in the WOFF2 format, and keep only the weights you actually use. A fallback font that takes up the same space stops the text from jumping when the real font arrives.
Layout shifts usually come from images and videos without known dimensions, fonts that swap late, ads or widgets that resize themselves, and content inserted above what is already on screen. Always set width and height on images and video, or reserve the space with an aspect ratio. Reserve space for embeds and late loading content. For cookie notices and promotional bars, reserve the space in advance or overlay the content, so the page is not pushed down.
Slow hosting and no CDN sit underneath all of it. Server response time is the first part of LCP. Google suggests most sites should aim for a time to first byte of 0.8 seconds or less as a rough guide. A content delivery network keeps copies of your pages and images close to your visitors, so a customer far from your server is not waiting on a server on another continent. Unnecessary redirects also slow the response, and they are worth removing. If the hosting itself is the bottleneck, no image fix will save the result.
In what order should you fix a slow site?
Work from the changes that are cheapest and most likely to help towards the most expensive. Each step says what to ask for, whether you do it yourself or hand it to a developer.
First, diagnose before spending. Ask for a one page written diagnosis covering each main template on mobile, listing the failing metric, the LCP element, and the three biggest causes, with screenshots from PageSpeed Insights and Search Console. Our guide on why a WordPress site is slow walks through the same diagnose first approach.
Second, fix the hero image. Ask for the hero served in a modern format, in responsive sizes, in the page content, marked to load first, with no lazy loading. Third, audit third party scripts. Ask for a list of every third party script and tag, what it does, who uses it, and what it costs in load time. Remove the unused ones, defer the rest, put chat and video behind a lightweight image, and clean out the tag manager. Fourth, stop layout shifts. Ask for width and height on every image and video, reserved space for embeds, and cookie or promotional banners that overlay rather than push content down.
Fifth, trim render blocking CSS, JavaScript and fonts. Ask for no synchronous scripts in the page head, smaller stylesheets, and fonts limited to the weights you actually use, with a matched fallback font. Sixth, optimise the remaining images. Ask for compression and modern formats site wide, with lazy loading for everything below the first screen. Seventh, review hosting and the CDN. Ask for server response times for your main pages, a CDN in front of the site, and redirect chains removed. If the hosting itself is the bottleneck, ask for a costed migration plan.
Finally, confirm with field data. Ask for Search Console’s Validate fix to be started once changes are live. Search Console then monitors the affected URLs for 28 days and marks the issue fixed only if it does not reappear. Meanwhile, the lab test shows whether each change worked. Do not judge a fix on the day it goes live. Field data needs real visits over time, so changes can take several weeks to show fully.
When to stop and ask a professional
Most of the easy fixes in this guide are safe jobs for a site owner: compressing images, removing unused plugins and scripts, and setting image sizes. But there is a point where doing it yourself stops helping. If the problems are built into your theme, if the hosting is the bottleneck, if the fixes need code changes you cannot make safely, or if the scores do not move after the easy fixes, that is the time to get a second pair of eyes. A professional check starts with a diagnosis, not with a rebuild, and it should tell you which metric is failing, what causes it, and what the fix will change before any work begins. If a fix needs a staging copy of your site, it should be tested there first, never on the live site.
A simple monthly routine
Core Web Vitals are not a one time job. A new banner, a new popup, a new hero video, or a plugin update can move the numbers, so a short monthly routine keeps them in view. Run PageSpeed Insights on your three most important pages. Check the Search Console Core Web Vitals report for new poor URLs. Review installed plugins, apps and scripts and remove any you do not need. Re-check after every big change. Our WordPress maintenance checklist covers the same routine as part of a regular maintenance habit, and a maintenance plan keeps the checks happening even when you are busy.
Frequently asked questions
Do I need a PageSpeed Insights score of 100?
No. The score is a lab diagnostic. What Google uses is the field data for LCP, INP and CLS, and even good results there do not guarantee top rankings. Aim for good on all three metrics on mobile, and treat the lab score as a tool for finding problems.
What if my site has no field data?
That is common on small or new sites. Google needs enough real visits for a meaningful sample before it shows field data. Use the lab test to find the problems, fix them, and recheck once traffic grows. Search Console will show field data once your pages have enough visits.
Is First Input Delay (FID) still used?
No. Interaction to Next Paint replaced First Input Delay as the responsiveness Core Web Vital on 12 March 2024. FID only measured the first interaction. INP measures every interaction during the visit. Any report, tool, or agency still quoting FID is working with out of date advice.
Why does my site fail on mobile but pass on desktop?
Mobile and desktop are measured separately, and phones have slower processors and patchier connections. The lab test also simulates a mid tier phone on a mobile network. A page that is fast on a desktop computer can still be slow on a phone, which is why you should always check the mobile result first.
Can I fix Core Web Vitals myself?
Often yes. Compressing images, removing unused plugins and scripts, and setting image sizes are safe jobs for most owners. Script and theme problems are harder, and that is where a developer can save you time. If the scores do not move after the easy fixes, ask for a diagnosis before spending more.
How long does it take for Search Console to show an improvement?
Search Console uses real visit data collected over a rolling period, so changes can take several weeks to show fully. After a fix, start Validate fix in Search Console and let it monitor the affected URLs for 28 days. Fix the problems, then keep checking the report rather than expecting an overnight change.
Conclusion
Core Web Vitals are three simple questions about how your site feels to a real visitor: does the main content appear quickly, does the page respond when tapped, and does the layout stay still. The scores that count as good are 2.5 seconds or less for LCP, 200 milliseconds or less for INP, and 0.1 or less for CLS, judged on three in four real visits. Read the field data first, fix the hero image and the unused scripts before anything expensive, and judge the result after real visits have had time to flow in. Speed is a tie-breaker for rankings and a real help for visitors, and the two reasons point to the same work: a lighter page, fewer scripts, and a layout that does not move. If you want the full diagnose first walkthrough, read our guide on why a WordPress site is slow. If the scores do not move after the easy fixes, our WordPress speed optimization service can check the site and tell you what is actually slowing it down. To talk about your site, message us on WhatsApp at +8801735127127, use the contact page, or email [email protected]. You can also see the full list on our services page.
