Core Web Vitals: what they mean and how to improve them
Core Web Vitals are Google’s three main metrics for the real-world experience of using a website: loading, responsiveness and visual stability. They are a ranking factor, but good scores alone will not put a website in first place. For businesses, the more important question is whether the website loads fast enough to avoid losing enquiries and orders.
Владислав БарковManaging Director
What do Core Web Vitals actually measure?
Core Web Vitals are metrics that describe three specific moments during a visit. LCP shows when the main content is rendered. INP shows how quickly the page responds to visitor actions. CLS shows whether elements stay in place or unexpectedly shift.
Google primarily uses data from real visits through the Chrome User Experience Report, known as CrUX. This is an important distinction. A website may look fast on your work laptop but be slow for someone using an older phone, a weak mobile connection or a different geographic region.
In Search Console and PageSpeed Insights, results are usually evaluated at the 75th percentile. This means you should think about the typical real visitor, not the best possible test result.
What are good LCP, INP and CLS scores?
| Metric | What it measures | Good result | Needs improvement | Poor result |
|---|---|---|---|---|
| LCP | Appearance of the largest visible element | up to 2,5 seconds | over 2,5 to 4 seconds | over 4 seconds |
| INP | Page response to interaction | up to 200 ms | over 200 to 500 ms | over 500 ms |
| CLS | Unexpected content shifts | up to 0,1 | over 0,1 to 0,25 | over 0,25 |
Thresholds are assessed separately for each metric. A page that loads quickly but has a shifted order button is not user-friendly. The same applies to a page that looks stable but does not respond when a visitor clicks a filter, menu or form.
What is LCP and why does the initial screen load slowly?
LCP, or Largest Contentful Paint, measures the time until the largest significant element in the visible part of the page is rendered. This is often the main image at the top, the heading block, a video or a large text container.
A slow LCP is usually not caused by just one issue. The server may respond slowly. The main image may be larger than necessary. JavaScript or CSS may block rendering. An external font, tracking code or banner may load before the content the visitor wants to see.
How do you improve LCP?
- Identify the specific LCP element in PageSpeed Insights or Chrome DevTools. It is not enough to know that the page is “slow”.
- Prepare images at the actual size at which they will be displayed. WebP or AVIF often reduce file size, but the format cannot compensate for incorrect dimensions.
- Prioritize the main image or text block. An image above the fold should not be loaded like an image that is far below it.
- Defer images below the fold using lazy loading. Do not apply lazy loading to the LCP element itself.
- Reduce time to first byte through caching, suitable hosting, a CDN and an optimized database query.
- Remove or defer JavaScript and third-party scripts that are not needed for the initial page render.
For a site with a catalog, filters, a calculator or personalized content, blindly “treating” LCP is not a sensible approach. Sometimes the cause is an API request that returns too much data. Other times, it is a component that loads an entire library to display one small function.
What is INP and why does the site respond slowly?
INP, or Interaction to Next Paint, replaced FID as an official Core Web Vital metric in March 2024. FID mainly focused on the first interaction. INP evaluates interaction responses throughout the entire visit-for example, clicking a menu, searching, applying a filter, adding to the cart or submitting a form.
With a high INP, a visitor clicks a button but does not receive timely visual feedback. They may click again, close the page or assume that the form is not working. The cause is often a long JavaScript task that blocks the browser’s main thread.
How do you improve INP?
- Check which interaction is slow. Chrome DevTools Performance and real-user data show long tasks and event handlers.
- Break heavy logic into smaller parts so the browser can update the interface between them.
- Load functions that are not needed immediately after the main content. This applies to chat, maps, complex calculators and some marketing scripts.
- Limit third-party scripts. Analytics tools, chats, advertising pixels and embedded content add up and are often the cause of blocking.
- For long lists, use pagination or virtualization instead of rendering hundreds of items at once.
- Provide visible feedback when an action is taken-for example, a button state or loading indicator-without blocking the entire page.
Not every slow action can be solved with more caching. If clicking “Calculate price” sends a request to the server, you also need to examine the API, the database and how the interface displays the result.
What is CLS and why do elements shift?
CLS, or Cumulative Layout Shift, measures unexpected layout changes. A typical example is an “Order” button that moves when an image, banner or cookie notice loads above it.
The most common causes are images and videos without defined dimensions, ads without reserved space, fonts that load late and content inserted above the visitor’s current viewport position.
How do you reduce CLS?
- Set width and height for images and videos or use CSS aspect-ratio to reserve space before they load.
- Set a minimum height for banners, notifications and other dynamic blocks.
- Do not insert content above text the visitor is already reading. If you need to show a notification, use suitable fixed positioning or a space reserved in advance.
- Check how fonts load. Changing the font can alter the height of headings and the entire block.
- Use CSS transform and opacity for animations when appropriate, instead of properties that trigger a new page layout.
How do you measure Core Web Vitals for a specific site?
- 01Check real-user data
Start with Google Search Console and CrUX if the site has enough visits. There you can see whether the problem affects a group of URLs and whether it occurs on mobile devices, desktop computers or both.
- 02Test important pages
Check the homepage, a key service page, a product page, the cart or an enquiry form. PageSpeed Insights shows a lab test and, when data is available, real-world field results.
- 03Find the cause in the code
Use Chrome DevTools Performance, Network and Lighthouse. Look for the specific LCP element, long JavaScript tasks, render-blocking resources and areas with layout shifts.
- 04Prioritize work by business impact
First fix the pages that generate organic traffic, enquiries or sales. Speeding up a page nobody visits is rarely more valuable than fixing a slow checkout.
- 05Measure again after the change
After every major change, compare the same URL, device and scenario. Real data in Search Console is updated with a delay, so do not treat an immediate lab result as final.
When is the problem with the site rather than the hosting?
Hosting is only one part of the picture. A more powerful server will not fix a huge image, poorly written JavaScript, or a form that makes ten requests to a slow database. The opposite is also true: a well-optimized interface cannot compensate for a slow server with a high TTFB.
With ready-made platforms and WordPress, the theme, plugins, images, caching, and external scripts are checked first. Removing a plugin without checking can break orders, tracking, or payments. For a custom-built site, the architecture, database queries, API integrations, and the way components are loaded are reviewed.
For a business website with forms and clearly defined services, the biggest impact usually comes from a combination of a good structure, optimized images, a reasonable amount of JavaScript, and stable hosting. This is part of technical SEO optimization, and for a new project it should be built in from the start during website development, rather than fixed after launch.
How much does it cost to improve Core Web Vitals?
The cost depends on whether you need an audit, specific fixes, or a redesign of part of the site. A small site with a few clear issues can usually be handled with a brief technical audit and targeted changes. An online store with filters, payments, external applications, and tracking requires more analysis because every change can affect sales.
| Scope | What it includes | What affects the price |
|---|---|---|
| Audit | Data from Search Console, PageSpeed Insights, DevTools, and a list of priorities | Number of templates, code access, and available real-world data |
| Targeted optimizations | Images, caching, scripts, element dimensions, and specific components | Platform, quality of the existing code, and external integrations |
| More extensive redevelopment | Changes to the architecture, API, database, or key pages | Catalog size, business logic, staging environment, and need for testing |
An accurate assessment comes after access to the site and a list of priority URLs. A promise that every site will achieve “100 out of 100” is not a reliable benchmark. The goal is a measurably better experience for real visitors without disrupting forms, orders, ad tracking, or the SEO structure.
Frequently asked questions
Do Core Web Vitals directly affect your position in Google?
Yes, they are part of the signals used to evaluate a page, but their impact is not independent and they do not override content, search intent, authority, or technical SEO. Meeting the thresholds does not guarantee the top position.
Why does PageSpeed Insights show a good result while Search Console reports an issue?
PageSpeed Insights may show a lab test in a specific environment, while Search Console uses aggregated data from real visits. The difference may be due to mobile devices, networks, countries, caching, or different page templates.
Should I use WebP or AVIF for all images?
Not automatically. What matters is the right size, compression, priority of the main image, and compatibility with your browsers and system. WebP and AVIF often help, but they will not fix a slow server or heavy JavaScript.
Can good hosting solve Core Web Vitals on its own?
Good hosting can improve time to first response and stability, but it does not solve problems with code, images, fonts, or external scripts. The entire path from the request to rendering and interaction needs to be checked.
Frequently asked questions
- What are Core Web Vitals?
- These are Google metrics for a website’s loading, responsiveness, and visual stability. The main ones are LCP, INP, and CLS.
- What are good values for LCP, INP, and CLS?
- A good result is an LCP of up to 2,5 seconds, an INP of up to 200 milliseconds, and a CLS of up to 0,1. Each of the three metrics is assessed separately, preferably using data from real visitors.
- How can I check my site’s Core Web Vitals?
- Use Google Search Console for real-world data and PageSpeed Insights for specific URLs. Chrome DevTools helps you identify the cause in images, CSS, JavaScript, or requests to the server.
- Do all Core Web Vitals have to be in the green?
- Green scores are a useful target, but they do not guarantee rankings or sales. Priority should be given to pages that bring traffic, enquiries, and orders, as well as issues that prevent visitors from taking action.
