Understanding core web vitals

Overview

Website performance can be measured in many different ways, but some measurements are more useful than others. A page might load quickly according to one test while still feeling slow to use, or achieve an impressive performance score while frustrating visitors with content that moves around or buttons that take too long to respond.

Core Web Vitals are designed to measure some of these aspects of the experience. They focus on three things that can have a noticeable effect on how a website feels to use: how quickly important content appears, how responsive the page is when someone interacts with it, and whether the layout remains stable while it loads.

They are useful measurements, but they need context. Understanding what Core Web Vitals measure, what affects them and when they point to a genuine problem is more valuable than simply chasing better scores.

What are Core Web Vitals?

Core Web Vitals are a set of metrics introduced by Google to measure important aspects of the experience people have when using a web page.

The current Core Web Vitals are:

• Largest Contentful Paint (LCP)
  measures loading performance.
• Interaction to Next Paint (INP)
  measures how responsive a page is to user interactions.
• Cumulative Layout Shift (CLS)
  measures visual stability.

Each metric looks at a different part of the experience. Together, they can help identify pages that are slow to display their main content, interfaces that are sluggish to respond or layouts that unexpectedly move while someone is trying to use them.

Google defines thresholds for what it considers a good experience. To provide a good experience for most users, Google recommends assessing the 75th percentile of page loads across mobile and desktop devices.

Metric	What it measures	Good
LCP	Loading performance	2.5 seconds or less
INP	Responsiveness	200 milliseconds or less
CLS	Visual stability	0.1 or less

These thresholds give website owners a useful benchmark, but the numbers should not be considered in isolation. The important question is what they tell you about the experience people are actually having.

Why do Core Web Vitals matter?

People do not usually think about website performance in terms of milliseconds or performance scores. They notice the consequences.

A page might appear blank for too long before its main content arrives. Someone might click a menu or filter and wonder whether anything has happened. A button might move just as they are about to select it because another part of the page has loaded above it.

Core Web Vitals provide a way of measuring some of these experiences consistently. That makes them useful when identifying performance problems, comparing pages and monitoring how a website changes over time.

They also form part of Google’s page experience systems used in Search. However, passing Core Web Vitals does not guarantee higher rankings, just as failing them does not automatically mean a page cannot rank well. Google uses many signals when determining search results, and useful, relevant content remains important.

For website owners, the more immediate reason to pay attention to Core Web Vitals is simpler: poor results can point towards experiences that are making a website slower, less predictable or more frustrating to use.

What are the three Core Web Vitals?

Although Core Web Vitals are often presented together, each one measures something quite different.

• Largest Contentful Paint (LCP) asks how long it takes for the main piece of visible content to appear.
• Interaction to Next Paint (INP) looks at how quickly the page provides visual feedback after someone interacts with it.
• Cumulative Layout Shift (CLS) measures how much visible content unexpectedly moves as the page is being used.

It can be helpful to think about them as three questions:

How quickly can I see what I came for? → How quickly does the page react when I use it? → Does everything stay where I expect it to be?

A problem with any one of these can make a website feel slower or harder to use, even if the other measurements are good.

Largest Contentful Paint (LCP) explained

What does LCP measure?

Largest Contentful Paint measures how long it takes for the largest visible content element in the viewport to render.

Depending on the page, this might be a large image, a heading or another prominent block of content. On many websites, particularly visually led ones, the LCP element is often a hero image or another large piece of content near the top of the page.

Google considers an LCP of 2.5 seconds or less to be good.

LCP is useful because it focuses on when a substantial part of the page becomes visible rather than simply measuring when the browser first starts displaying something. A page can technically begin loading very quickly while leaving the visitor waiting for the content they actually need.

What causes a poor LCP?

There is rarely one universal cause. Common problems include:

• Slow server responses.
• Large or poorly optimised images.
• Images being discovered too late by the browser.
• Render-blocking CSS or JavaScript.
• Web fonts delaying the display of content.
• Too much work being performed before the browser can render the page.
• Important resources being loaded with the wrong priority.

Third-party tools and scripts can also contribute to slower pages, particularly when several services need to load before important content can be displayed.

How can LCP be improved?

The right solution depends on what is causing the delay. Compressing an image will not solve a slow server, just as faster hosting will not fix a hero image that is unnecessarily several megabytes in size.

Improving LCP might involve optimising images, prioritising important resources, reducing render-blocking code, improving caching or reviewing how the page is delivered by the server.

The useful starting point is therefore not simply “How do we improve our LCP score?”, but “What is preventing this page’s important content from appearing sooner?”

Interaction to Next Paint (INP) explained

What does INP measure?

Interaction to Next Paint measures the responsiveness of a page throughout a user’s visit.

It observes interactions such as clicks, taps and keyboard input, measuring the time between the interaction and the browser displaying the next visual update. The final INP value is intended to represent the page’s overall responsiveness.

Google considers an INP of 200 milliseconds or less to be good.

This matters because loading a page is only the beginning of someone’s experience. A website can appear quickly but still feel slow if menus, forms, filters and other interactive features take too long to react.

What causes a poor INP?

JavaScript is often involved because browsers need to execute code in response to many interactions. If the browser’s main thread is already occupied with a large amount of work, the interaction may have to wait.

Common causes can include:

• Large amounts of JavaScript.
• Long-running JavaScript tasks.
• Complex page rendering.
• Expensive event handlers.
• Third-party scripts competing for browser resources.
• Interfaces doing more work than necessary after an interaction.

These problems can become more noticeable on less powerful devices. A page that feels responsive on a high-end development machine may behave differently on an older phone.

How can INP be improved?

Improving INP generally means reducing the amount of work that prevents the browser from responding promptly to an interaction.

That might mean breaking up long tasks, reducing unnecessary JavaScript, simplifying expensive interactions or reconsidering when particular scripts need to run.

It is also worth looking at the interface itself. Sometimes a performance problem is partly a design problem: an interaction has become unnecessarily complicated and requires the browser to do far more work than the user needs.

Cumulative Layout Shift (CLS) explained

What does CLS measure?

Cumulative Layout Shift measures unexpected movement of visible content.

You may have experienced this when reading an article and the paragraph suddenly moves because an image or advert appears above it, or when you are about to press a button and it shifts to another position.

Google considers a CLS score of 0.1 or less to be good.

Unlike LCP and INP, CLS is not measured in seconds. It is calculated from the size of unexpected layout shifts and how much of the viewport they affect.

What causes unexpected layout shifts?

Common causes include:

• Images without defined dimensions.
• Videos, embeds or iframes that do not have space reserved for them.
• Content being inserted above existing content.
• Cookie banners, adverts or notices changing the layout unexpectedly.
• Web fonts causing text to change size or position when they load.
• Components whose dimensions change after initial rendering.

Not every movement contributes to a poor CLS score. Movement that happens because someone deliberately interacts with the page can be expected. The problem is content moving without the user anticipating it.

How can CLS be improved?

A large part of preventing layout shift comes down to making the eventual layout predictable.

Images and embeds can have space reserved before they finish loading. Components can be designed with predictable dimensions, and dynamically inserted content can be handled without pushing existing content around unexpectedly.

These can sound like small technical details, but the result is straightforward: people can read and interact with the page without the interface moving underneath them.

Lab data and real-user data are not the same thing

One of the more confusing aspects of Core Web Vitals is that different performance tools can appear to give different answers.

You might run a page through Lighthouse and see a performance problem even though Google’s real-user data suggests the page is performing well. The opposite can happen too.

This is because performance can be measured in different ways.

Lab data is collected in a controlled test environment. Tools such as Lighthouse simulate particular device and network conditions so that tests can be repeated consistently.

Field data comes from real users and reflects how pages have actually performed across different devices, connections and circumstances over time.

Both are useful, but for different reasons.

Lab testing is particularly helpful when diagnosing a problem because you can make a change, run another test and compare the results. Field data gives you a better indication of what real visitors have experienced.

This is also why a single performance test should not be treated as a definitive judgement on a website. We explore this in more detail in our Insight, How Much Can Website Performance Tools Really Tell You?

Why Core Web Vitals scores can change

Website performance is not fixed.

A page might perform differently depending on the visitor’s device, connection, location and browser. Even the same person loading the same page twice may not get exactly the same result because some resources could already be cached.

The website itself also changes. Performance can be affected by:

• New images and content.
• Additional plugins or functionality.
• Analytics and marketing scripts.
• Embedded videos and third-party services.
• Changes to fonts or styling.
• Hosting and server configuration.
• Updates to existing software.
• Changes to how pages and components are built.

This is why occasional testing can only tell you so much. A website that performs well at launch will not necessarily continue to do so indefinitely.

A good Core Web Vitals score does not mean a website is fast

Core Web Vitals measure specific aspects of performance. They do not measure everything that determines whether a website feels fast or provides a good experience.

A page could pass all three metrics and still contain unnecessarily large downloads, slow secondary content or frustrating interactions that are not adequately represented by those measurements.

The reverse is also worth considering. A small improvement to a Core Web Vitals number does not necessarily produce a meaningful difference for users.

This is where performance work can become too focused on scores. It is easy to spend time trying to move a metric from an already good result to an even better one simply because the number is visible and measurable.

The aim should be a faster, more responsive and more dependable website, not a perfect report.

How should you approach Core Web Vitals improvements?

Core Web Vitals are most useful when they help identify where investigation is needed.

A practical process might look like this:

Start by understanding which pages and metrics have problems. From there, investigate what is actually causing them rather than applying generic performance fixes.

Prioritisation matters too. A serious responsiveness problem affecting an important form or frequently used interface is likely to deserve more attention than a small improvement to an already fast page.

After making changes, test again and look for unintended consequences. Performance improvements can involve compromises, and making one number better should not come at the expense of usability, accessibility or maintainability.

This is also why website performance is best considered throughout design and development rather than being treated as something to fix shortly before launch. Decisions about imagery, fonts, components, scripts, integrations and content all contribute to the eventual experience.

Core Web Vitals should be monitored, not checked once

Websites rarely stay exactly as they were on launch day. Content teams add pages, developers introduce functionality, marketing platforms change and third-party services are added or updated.

Any of those changes can affect performance.

Regular monitoring makes it easier to spot deterioration before it becomes a larger problem. Instead of discovering months later that an important page has become considerably slower, teams can see how performance is changing and investigate when something unusual appears.

This does not mean somebody needs to watch a performance dashboard every day. The purpose of monitoring is to establish what normal performance looks like and make meaningful changes easier to identify.

It is an approach we use as part of ongoing website development: performance is something to maintain and improve over time rather than a task that can permanently be ticked off a list.

How we approach website performance at Feel Created

We treat performance as part of how a website is designed, built and maintained rather than as a separate optimisation exercise.

That can mean thinking about how images are handled, how components are built, what JavaScript is required, which third-party services are being loaded and how the website is hosted. It also means considering what happens after launch, when new content and functionality begin to change the site.

Our Website Performance Optimisation work can help identify the causes of existing performance problems and determine which improvements are likely to make a meaningful difference. Through Ongoing Development & Improvement, we can also continue monitoring and improving websites as they evolve.

Core Web Vitals can form part of that work, but they are not the only thing we look at. Performance needs to be considered alongside accessibility, usability, maintainability and what the website actually needs to do.

Core Web Vitals are useful, but they are only part of the picture

Core Web Vitals give us a useful way to measure loading performance, responsiveness and visual stability. They can highlight genuine problems and provide consistent benchmarks for tracking whether things are getting better or worse.

But a website is experienced by people, not performance tools.

The numbers become valuable when they help explain something about that experience: why important content is taking too long to appear, why an interface feels sluggish or why a page moves unexpectedly while someone is trying to use it.

That is a much more useful goal than chasing a perfect score. Core Web Vitals should help us make better decisions about website performance, not become the definition of good performance themselves.

How we can help