The site opens, but the main image lags. You tap a button and nothing happens. You start reading and the text suddenly jumps down. Each of these annoyances has a name and a measurement at Google — Core Web Vitals.
These metrics affect both user experience and conversion: few people complete a form on a slow, "jumpy" page. Google also considers them as part of its page experience signals.
In this guide we explain all three metrics in plain words, show how to measure them and list the most common issues we see, with fixes. There are technical details you can hand to a developer too.
Short answer: Core Web Vitals are Google's three user-experience metrics: LCP (how fast the main content loads), INP (how fast the page responds to interaction) and CLS (how visually stable the page is).
Core Web Vitals at a glance
The thresholds are defined in Google's web.dev documentation and assessed at the 75th percentile of real users — at least 75% of page visits should be in the "good" range.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | Load time of the largest visible element | ≤ 2.5 s | > 4 s |
| INP — Interaction to Next Paint | Time to visual response after a click or tap | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Unexpected movement of page elements | ≤ 0.1 | > 0.25 |
Values between the two thresholds fall into "needs improvement". In March 2024 INP replaced the old FID metric, so if older articles mention FID, it is no longer current.
Why it matters
Google says Core Web Vitals are among the page experience signals its ranking systems use, but relevance and content quality come first. See Google's Core Web Vitals documentation. In practice the bigger effect is on conversion: users drop off less on fast, stable pages.
LCP: how fast the main content appears
LCP is the time until the largest element in the visible part of the screen — usually a hero image, banner or large heading — is fully rendered. For the user it is the "page has loaded" moment.
What makes LCP worse
- The hero image is too large or in an old format (e.g. a 3 MB PNG).
- The hero image is marked for lazy loading — it is the first visible element and should not wait.
- Heavy render-blocking CSS and JavaScript in the head.
- Slow server response (high TTFB): cheap hosting, no caching.
- Fonts load late and text stays invisible.
Fixes
- Convert the hero image to WebP/AVIF and serve size-appropriate versions (srcset).
- Add fetchpriority="high" to the hero image; keep loading="lazy" for images further down.
- Keep critical CSS at the top and load the rest of the scripts with defer.
- Cache static pages and use a CDN where possible.
- Use font-display: swap and load only the font weights you need.
INP: how fast the page responds
INP measures how long the browser takes to visually respond to the user's clicks, taps and key presses across the visit, and reports one of the worst. The "I pressed the button and nothing happened" feeling is poor INP.
What makes INP worse
- Many plugins, widgets and third-party scripts (chat, heatmaps, ad pixels) fill the main thread.
- A long JavaScript task runs after a click and the screen does not update.
- A very large DOM — thousands of elements and frequent re-renders.
- No visual feedback (loader, button state) after a click.
Fixes
- Remove unnecessary plugins and scripts; load the rest after the user starts interacting.
- Break long tasks into smaller chunks so the browser can update the screen in between.
- Give visual feedback immediately after a click and do heavy work afterwards.
- Review Tag Manager tags regularly: unused tags add load too. We describe how we keep GTM and GA4 clean on our GA4 service page.
CLS: why the screen moves
CLS sums up unexpected shifts of elements while the page loads and during use. The familiar example: you go to tap a button, a banner loads above it and you tap the wrong thing.
What makes CLS worse
- Images and videos have no dimensions (width/height or aspect-ratio).
- No space is reserved for ads, embeds or iframes.
- A cookie notice or promo banner pushes content down.
- Text changes size when the web font swaps in.
Fixes
- Give every image and video dimensions or use CSS aspect-ratio.
- Reserve space for dynamic blocks with min-height.
- Show notices as overlays instead of pushing content.
- Choose a fallback font close in size to the main font.
Which tools to measure with
There are two kinds of data: real-user data (field data) and lab tests (lab data). Google's assessment uses real-user data.
| Tool | Data type | Use |
|---|---|---|
| Search Console — Core Web Vitals report | Real users (CrUX) | Overall site status, problematic URL groups |
| PageSpeed Insights | Real + lab | Diagnosis and recommendations for a specific page |
| Lighthouse (Chrome DevTools) | Lab | Checking a change immediately |
| Chrome DevTools — Performance panel | Lab | Analysing INP and long tasks |
Small sites may have no real-user data because traffic is too low. Lab tests then give direction, but remember to test on mobile and on an average connection. Check the device split in GA4: on most B2C sites the mobile share is high.
Core Web Vitals are only one part of technical SEO. The full checklist with indexing, hreflang and schema is in our technical SEO article.
Practical tips by CMS and a 30-minute plan
WordPress
Most problems come from heavy themes, page builders and many plugins. A caching plugin, image optimisation and removing unused plugins usually make the first big difference.
Shopify and other SaaS platforms
The server side is controlled by the platform, so the main work is reducing the number of apps, serving images at the right size and keeping the theme light.
Modern frameworks like Next.js
Static generation or server rendering gives a good base for speed, but large client JavaScript bundles can hurt INP. Load components when needed and control third-party scripts.
A 30-minute start
- Open the Core Web Vitals report in Search Console and note the "poor" URL groups.
- Test your highest-traffic page in PageSpeed Insights in mobile mode.
- Identify the LCP element and optimise its image.
- Find images without dimensions and add them.
- Identify the heaviest third-party script and check whether you need it.
Frequently asked questions
What are Core Web Vitals?
Google's three user-experience metrics: LCP (how fast the main content loads), INP (how fast the page responds to interaction) and CLS (how visually stable the page is).
What are good LCP, INP and CLS values?
LCP of 2.5 seconds or less, INP of 200 milliseconds or less, CLS of 0.1 or less. They are assessed at the 75th percentile of real users.
What happened to FID?
FID (First Input Delay) was removed from Core Web Vitals in March 2024 and replaced by the more comprehensive INP metric.
How much do Core Web Vitals affect rankings?
Google uses them as one of the page experience signals, but relevance and content quality matter more. Speed mostly makes a difference between pages of similar quality and in conversion.
Does my PageSpeed score need to be 100?
No. The Lighthouse score is a lab test; what matters is that real users' Core Web Vitals are in the "good" range.
Why is there no data in Search Console?
Real-user data is collected only for URLs with enough traffic. On small sites you work with PageSpeed Insights lab results instead.
Conclusion
Core Web Vitals measure three problems users feel: slow loading, slow response and a moving screen. Fixing them helps both SEO and the conversion of ad traffic — the same page also affects landing page experience in Google Ads. For the other pillars of SEO, see our what is SEO guide.
The quickest wins usually come from images, third-party scripts and elements without dimensions. Start there and track the results with real-user data. If you run an online store, we cover the impact of speed on sales in our e-commerce SEO guide, and landing page experience in Google Ads in our Quality Score article.
Shall we audit your website's speed and technical SEO?
SEO service