A website can look great and still provide a frustrating experience.

Maybe the main image takes too long to appear. Perhaps a visitor clicks a button and nothing seems to happen for a moment. Or the page shifts just as someone is about to tap a link.

These are the kinds of experiences Core Web Vitals are designed to measure.

Core Web Vitals are a set of user-focused metrics developed by Google to evaluate important aspects of website experience. The current set focuses on three things: loading performance, responsiveness, and visual stability. Those three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

If you’ve never worked with website performance before, the terminology can sound technical. It doesn’t have to be.

At a basic level, Core Web Vitals answer three practical questions:

Does the important content appear quickly?

Does the website respond when people interact with it?

Does the page stay where it is supposed to stay while loading?

Once you understand those three questions, the rest becomes much easier.

What are Core Web Vitals?

Core Web Vitals are standardized performance metrics that focus on real user experience.

Google currently uses three:

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

Google recommends evaluating these thresholds at the 75th percentile, with mobile and desktop experiences considered separately. In practical terms, this means you shouldn’t judge a website based only on the fastest or slowest visitor. You want the experience to be good for the large majority of users.

Each metric measures something different, so improving one doesn’t necessarily fix the others.

A website might have excellent LCP but poor INP because its JavaScript makes interactions sluggish. Another site might load quickly but have a poor CLS score because advertisements or images cause the page to jump around.

That’s why Core Web Vitals optimization needs to look at the whole experience.

Why do Core Web Vitals matter?

Website performance has always mattered to users.

People generally don’t want to wait for a page to load, stare at a frozen interface, or repeatedly reposition themselves because the content keeps moving.

Core Web Vitals give developers a practical way to identify some of these problems.

They are also relevant to Google Search. Google says its core ranking systems use Core Web Vitals as part of evaluating page experience. However, good Core Web Vitals scores do not guarantee high search rankings. Google also emphasizes that relevance and overall page experience matter, rather than treating Core Web Vitals as a single ranking shortcut.

That distinction is worth remembering.

You shouldn’t optimize a website simply because you want a perfect score in a testing tool.

You should optimize it because a faster, more responsive, more stable website is generally easier for people to use.

SEO is an additional reason to take performance seriously, not the only reason.

1. LCP: Largest Contentful Paint

Let’s start with LCP.

Largest Contentful Paint measures how quickly the largest visible content element is rendered after a visitor starts loading a page. That element is commonly an image, video poster, or large block of text.

Imagine someone opens an article page.

The browser displays the header, navigation, and some background elements. But the main article heading and featured image haven’t appeared yet.

From the visitor’s perspective, the page doesn’t really feel ready.

LCP attempts to measure the point when that important piece of content becomes visible.

What is a good LCP?

Google’s current recommendation is:

Good: 2.5 seconds or less
Needs improvement: More than 2.5 seconds and up to 4 seconds
Poor: More than 4 seconds

These thresholds are evaluated at the 75th percentile.

So if your site’s LCP is 2.2 seconds for most visitors but significantly slower for a smaller group, you need to look at the real-world data rather than relying on one test from your own computer.

What causes a poor LCP?

There isn’t one universal cause.

Common problems include:

Slow server response times
Large hero images
Unoptimized images
Render-blocking resources
Slow fonts
Too much JavaScript
Redirects
Poor caching
Slow network connections
Client-side rendering that delays important content

For example, suppose your homepage has a large banner image as its main visual element.

If that image is a 3 MB file, it needs to download before the browser can display it. Even with a good server, the visitor’s connection and device can make that process noticeably slower.

Compressing the image, serving an appropriately sized version, and making sure the browser can discover the resource quickly may improve LCP.

How to improve LCP

Start by identifying exactly what the LCP element is.

Chrome DevTools and performance tools can help identify whether it is an image, text element, or another resource.

Then investigate what is delaying it.

If the problem is server response time, look at hosting, caching, backend processing, and CDN configuration.

If it’s an image, optimize its size and format.

If CSS or JavaScript is delaying rendering, look at which resources are actually necessary before the main content can appear.

LCP optimization is much easier when you identify the specific bottleneck rather than applying random speed improvements.

2. INP: Interaction to Next Paint

The second Core Web Vital is Interaction to Next Paint, or INP.

INP measures how responsive a page is to user interactions. It looks at interactions such as clicks, taps, and keyboard input throughout the user’s visit and assesses how long it takes the page to provide visual feedback.

Think about clicking an “Add to Cart” button.

A visitor expects some immediate response: perhaps the cart count changes, a confirmation appears, or the button changes state.

If they click and the browser seems frozen for a noticeable amount of time, the site feels slow—even if the page initially loaded quickly.

That’s the kind of problem INP helps identify.

What is a good INP?

The current thresholds are:

Good: 200 milliseconds or less
Needs improvement: More than 200 milliseconds and up to 500 milliseconds
Poor: More than 500 milliseconds

Again, Google recommends looking at the 75th percentile when assessing performance.

What causes poor INP?

JavaScript is often a major factor.

A browser has to execute JavaScript on its main thread alongside other work required to update the page.

If a large JavaScript task occupies that thread, the browser may not be able to respond to a user’s interaction immediately.

For example, a visitor clicks a menu button just as a large script is processing.

The click happens, but the browser is busy.

The result is a delay between the user’s action and the visible response.

Other potential causes include:

Large JavaScript bundles
Long-running event handlers
Excessive DOM updates
Complex rendering work
Third-party scripts
Inefficient application code
Heavy client-side frameworks or components

How to improve INP

The first step is to reduce unnecessary JavaScript.

You don’t necessarily need to remove your framework. Instead, examine what the application is actually doing.

Break up long tasks where practical. Avoid doing expensive calculations inside interaction handlers. Delay non-essential work. Remove unnecessary third-party scripts.

If a button triggers a complicated operation, look at whether every part of that operation needs to happen before the interface responds.

The goal isn’t just to make the code execute faster.

It’s to make the interface feel responsive to the person using it.

3. CLS: Cumulative Layout Shift

The third metric is Cumulative Layout Shift, or CLS.

CLS measures unexpected movement of visible page content.

You’ve probably experienced this yourself.

You’re about to click a button. Suddenly an advertisement loads above it, pushing the button downward. You click—and end up opening something else.

Or you’re reading a paragraph when an image suddenly appears and moves the text several lines down.

That’s a layout shift.

CLS measures this kind of visual instability.

What is a good CLS score?

The current thresholds are:

Good: 0.1 or less
Needs improvement: More than 0.1 and up to 0.25
Poor: More than 0.25

The score is different from LCP and INP because CLS is unitless rather than being measured in milliseconds or seconds.

What causes CLS?

Common causes include:

Images without defined dimensions
Ads without reserved space
Embeds and iframes that change size
Dynamically injected content
Web fonts
Elements added above existing content

Google specifically identifies images, ads, embeds, dynamically inserted content, and fonts among common causes of layout shifts.

How to improve CLS

One of the simplest fixes is to reserve space for images.

Instead of allowing the browser to discover an image’s dimensions only after it starts loading, specify its width and height or use an appropriate aspect-ratio container.

For example:

<img
  src="product-image.webp"
  width="800"
  height="600"
  alt="Product image"
>

The browser can then allocate the appropriate space before the image arrives.

The same principle applies to advertisements and embedded content.

If you know that an ad slot will occupy a certain area, reserve that space instead of allowing the rest of the page to move when the ad eventually loads.

Core Web Vitals and page speed are not the same thing

This is an important distinction for beginners.

You may hear people use “page speed” and “Core Web Vitals” almost interchangeably, but they’re not identical.

Page speed is a broad concept describing how quickly a webpage loads and becomes usable.

Core Web Vitals are specific user-focused metrics that measure loading, responsiveness, and visual stability.

A website can have a relatively small page size and still have a poor INP because its JavaScript blocks interactions.

Likewise, a page might load quickly but suffer from CLS because content jumps around after loading.

That’s why simply reducing the number of kilobytes on a page isn’t the complete answer.

Good website performance means considering the whole user experience.

Core Web Vitals and Google Page Experience

Core Web Vitals are one part of Google’s broader Page Experience guidance.

Google’s current documentation encourages site owners to consider several aspects of the experience, including Core Web Vitals, secure delivery, mobile usability, intrusive interstitials, and whether the main content is easy to distinguish from other elements on the page.

There is no single “Page Experience score” that determines whether a page ranks.

Google explicitly says there is no single page-experience signal. Its ranking systems consider multiple signals, and good Core Web Vitals don’t guarantee top rankings.

This is useful context because it prevents a common SEO mistake: spending weeks chasing a perfect performance score while ignoring content quality or usability.

A page needs to be useful first.

Performance helps people consume that useful content.

Field data vs laboratory data

Another concept that can confuse beginners is the difference between field data and lab data.

Field data

Field data comes from real users.

It reflects the devices, networks, locations, and interactions that people actually experience.

Chrome’s User Experience Report, commonly known as CrUX, collects anonymized real-user measurement data and provides the underlying data used by tools such as PageSpeed Insights and Google Search Console’s Core Web Vitals reporting.

This makes field data extremely useful for understanding what your visitors actually experience.

Lab data

Lab data comes from a controlled testing environment.

Tools such as Lighthouse and Chrome DevTools can be useful during development because you can run tests before changes reach real users.

But lab and field results won’t always match.

A developer might test a page on a powerful laptop with a fast connection, while an actual visitor uses an older smartphone on a slower network.

The two environments are simply different.

Why both matter

Lab testing is useful for finding technical problems during development.

Field data is useful for understanding real-world performance.

A sensible workflow uses both.

Use lab tools while making changes, then monitor field data after deployment.

How to measure Core Web Vitals

You don’t need an expensive performance platform to get started.

Several tools can help.

Google PageSpeed Insights

PageSpeed Insights is one of the easiest starting points.

Enter a page URL and you’ll receive performance information along with available real-user data and diagnostic recommendations.

Where CrUX data is available, PageSpeed Insights uses real-world experience data over the previous 28 days and reports it at the 75th percentile.

This makes it useful for understanding both what a page looks like under controlled testing and how real users are experiencing it.

Google Search Console

Search Console includes a Core Web Vitals report that can help site owners identify groups of URLs with performance problems.

This is particularly useful for larger websites because you don’t necessarily need to test every URL manually.

If dozens of product pages share the same template, a common performance issue may affect many URLs.

Chrome DevTools

Chrome DevTools provides detailed performance information directly in the browser.

It’s particularly useful for developers investigating why a page is slow or why a particular interaction is taking too long.

Lighthouse

Lighthouse can perform automated audits covering performance and other aspects of a web page.

It’s useful during development and testing, but remember that a Lighthouse score is not the same thing as real-user performance.

A simple Core Web Vitals optimization process

If you’re new to performance work, don’t try to fix everything at once.

Use a simple process.

Step 1: Measure the current experience

Run PageSpeed Insights and check Search Console if your site has enough data.

Find out whether LCP, INP, or CLS is the main problem.

Step 2: Identify the cause

A poor LCP score doesn’t tell you exactly what to change.

Look deeper.

Is the server slow? Is the main image too large? Are CSS resources blocking rendering?

For INP, is a JavaScript task taking too long?

For CLS, is an image or advertisement causing content to move?

Step 3: Fix the biggest issue first

Don’t spend hours optimizing a small script if your homepage’s main image takes several seconds to load.

Prioritize changes based on their likely impact.

Step 4: Test again

After making a change, measure again.

A technical change that sounds useful isn’t automatically an improvement.

Step 5: Monitor real users

Performance can change after deployment.

New scripts, plugins, images, advertising, content, or application features can introduce problems.

Keep an eye on field data rather than treating optimization as a one-time project.

Common Core Web Vitals problems and fixes

Here’s a simple way to connect symptoms with possible causes:

Problem	Common causes	Possible solutions
Poor LCP	Slow server, large images, blocking resources	Optimize images, improve TTFB, caching, prioritize main content
Poor INP	Heavy JavaScript, long tasks, expensive event handlers	Reduce JS, split long tasks, optimize event handling
Poor CLS	Images without dimensions, ads, dynamic content, fonts	Reserve space, define dimensions, manage dynamic elements

These are starting points, not guaranteed fixes.

Performance problems are highly dependent on the site’s architecture.

What not to do when optimizing Core Web Vitals

There are a few traps worth avoiding.

Don’t chase a perfect score

A 100 on a laboratory performance report isn’t the same thing as a perfect user experience.

Real users have different devices, connections, and behaviors.

Focus on meaningful improvements.

Don’t optimize only for Google

Google itself says good Core Web Vitals do not guarantee high rankings.

If your site is fast but confusing, inaccessible, difficult to navigate, or filled with poor content, a performance score won’t solve the underlying problem.

Don’t rely only on one device

Desktop performance can hide mobile problems.

Check both.

Don’t assume every recommendation matters equally

Performance tools can identify many possible improvements.

Not every suggestion deserves the same amount of engineering time.

A change that saves a few kilobytes may be less valuable than fixing a five-second delay before the main content appears.

Do Core Web Vitals affect SEO?

Yes, Core Web Vitals are used by Google’s ranking systems as part of page experience evaluation.

But they aren’t a magic SEO lever.

Google explicitly states that meeting Core Web Vitals thresholds doesn’t guarantee that a page will rank at the top of search results. Its systems consider many signals, and relevant content remains important.

It’s better to think about performance this way:

Good content gets people interested.

Good usability helps them consume it.

Good performance removes unnecessary friction.

All three matter.

Why Core Web Vitals are useful beyond SEO

Even if search rankings weren’t a consideration, these metrics would still be useful.

LCP gives you a way to think about perceived loading speed.

INP gives you a way to investigate whether interactions feel responsive.

CLS gives you a way to identify visual instability.

Together, they turn vague complaints like “the website feels slow” into measurable problems.

That makes them useful to developers, designers, product teams, marketers, and business owners.

A business owner might not understand why a customer says the website feels unreliable.

A performance report might reveal that important pages are shifting while content loads or that mobile interactions are taking too long to respond.

Now there’s something concrete to investigate.

A beginner’s checklist for Core Web Vitals

If you’re responsible for a website and aren’t sure where to start, use this checklist:

For LCP:

Optimize the main image.
Reduce server response time.
Use effective caching.
Avoid unnecessary redirects.
Reduce render-blocking resources.
Prioritize important content.

For INP:

Reduce unnecessary JavaScript.
Break up long tasks.
Optimize event handlers.
Review third-party scripts.
Avoid expensive work during user interactions.

For CLS:

Specify image dimensions.
Reserve space for advertisements.
Give embeds predictable dimensions.
Avoid inserting content above existing content.
Check how fonts affect layout.

Then measure again.

The bigger picture: website performance is an ongoing process

Core Web Vitals give developers a useful framework for thinking about performance, but they aren’t the entire definition of a good website.

A fast website can still be difficult to use.

A technically excellent page can still fail if it doesn’t answer the visitor’s question.

And a site with good Core Web Vitals can still have accessibility, security, navigation, or content problems.

Google’s own Page Experience guidance makes this broader point: site owners should consider the overall experience rather than focusing on one or two signals.

That’s probably the most useful mindset for beginners.

Don’t optimize a website just to make a number turn green.

Optimize it so people can get what they came for without waiting, guessing, or fighting with the interface.

Final thoughts

Core Web Vitals can seem complicated when you first encounter terms such as LCP, INP, CLS, CrUX, field data, and the 75th percentile.

But the underlying ideas are straightforward.

LCP asks whether the main content appears quickly.

INP asks whether the page responds promptly when people interact with it.

CLS asks whether the page stays visually stable instead of jumping around.

The current “good” targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, evaluated at the 75th percentile.

Use tools such as PageSpeed Insights, Search Console, Lighthouse, and Chrome DevTools to understand where problems are coming from. More importantly, use real-user data when it is available, because controlled tests cannot reproduce every visitor’s device and network conditions.

And remember that Core Web Vitals optimization is not about chasing a perfect score.

It’s about building a website that loads its important content promptly, responds when users interact with it, and doesn’t make people chase content that keeps moving.

That’s good website performance—and it’s useful whether a visitor finds your site through Google, a social network, a referral, or a bookmark.