What Are Core Web Vitals? Understanding LCP, INP and CLS

Core Web Vitals are the three core metrics Google uses to measure the user experience of a web page: how fast the page's main content loads (LCP), how quickly the page responds to clicks and taps (INP), and how much the content shifts while the page loads (CLS). Since 12 March 2024, INP has replaced FID as the interactivity metric.

What are Core Web Vitals, and why do they matter?

When visitors land on your site, they notice three things right away: How quickly did the page open? How fast did it respond when they tapped something? Did the content jump around while they were trying to read? Core Web Vitals turn these three experiences into numbers.

Google states clearly that its ranking systems use these metrics and recommends that site owners aim for good values. At the same time, Google stresses that it still tries to show the most relevant content even when the page experience is poor. So Core Web Vitals alone don't guarantee rankings. They are a factor that can make a difference between pieces of content of similar quality. We cover the overall SEO picture in our post What is SEO.

Rankings aside, speed and stability directly affect business results: a page that loads slowly, responds late to taps or makes people hit the wrong button drives visitors away before they fill in the form.

What do the three metrics measure? LCP, INP and CLS

For a page to be rated "good," all three values must meet the threshold at the 75th percentile of real visits. In other words, at least three out of four visits should have a good experience. Mobile and desktop are assessed separately. On most sites, mobile is where the real challenge lies.

LCP: When did the main content appear?

LCP (Largest Contentful Paint) measures the moment the browser renders the largest image or text block in the visible area. On corporate sites, this is usually the large image at the top (the hero image), a slider or the main heading.

The factors that hurt LCP most:

• Uncompressed, oversized images. For choosing the right format, see our post on lossy and lossless compression.
• Delaying the main image with lazy loading. You should not defer images at the top of the screen.
• A slow initial server response. We described the limits of a shared server in our hosting post.
• Large CSS and JavaScript files that block the page from rendering.

INP: How quickly did the page respond to a click?

INP (Interaction to Next Paint) measures how long it takes for visitors to see a change on screen after they click, tap or use the keyboard on the page. It doesn't look at a single interaction but at the interactions made throughout the visit, and it reports a latency that nearly all of them fall below. Hovering and scrolling on their own don't count.

In practice, INP problems look like this: you press the menu button but the menu opens a moment later, tabs switch late, the "Add to cart" button seems frozen. The cause is usually heavy JavaScript code keeping the browser's main thread busy: lots of plugin scripts, chat bubbles, tracking codes or large animation libraries.

CLS: Did the content shift?

CLS (Cumulative Layout Shift) measures how much the content moves unexpectedly while the page loads or while someone uses it. It's what happens when you are about to tap a news story and an ad suddenly appears at the top and pushes the text down.

The most common causes:

• Images and videos without width and height values.
• Web fonts that render at a different size from the fallback font.
• Ad, map or social media embeds that load later and expand.
• Banners added later on top of existing content (for example, a cookie notice or an announcement bar).

Why did INP replace FID?

In the original set of Core Web Vitals, the interactivity metric was FID (First Input Delay). FID looked only at the visitor's first interaction, and only at the waiting time before that interaction started to be processed. So even if a page was fast on the first click and slow afterward, FID could still look good.

INP, on the other hand, takes into account all interactions during the visit and the full time until the response is reflected on screen. The Chrome team introduced INP as an experimental metric in May 2022. On 12 March 2024, INP officially became a Core Web Vital, and Google removed FID from the program and deprecated it.

The practical consequence of this change for site owners: some sites that looked fine on FID may come out as "needs improvement" or "poor" on INP. Sites that use many plugins and third-party scripts in particular need to check INP separately.

How are Core Web Vitals measured?

There are two kinds of data, and it's important not to mix them up:

• Field data: The experience real users have on real devices. Google's assessment is based on this data.
• Lab data: A one-off test run in a controlled environment. You use it to find problems and try out fixes.

A common situation: the "no data" message in Search Console. This usually means your site or page doesn't get enough visits to produce a meaningful report in CrUX. The Search Console report also shows only indexed URLs and page groups with enough data. In that case, the lab results in PageSpeed Insights and the Chrome tools are your guide.

A word of caution: the 0–100 performance score in PageSpeed Insights is a lab score. The Core Web Vitals assessment, by contrast, is based on the field data at the top of the page. A score below 100 doesn't mean your site is "bad." What matters is whether real users meet the threshold on all three metrics.

How to improve Core Web Vitals

Every site is different, but these are the steps that work most often on corporate sites:

For LCP

• Serve the main image at the right size and in a modern format (WebP or AVIF).
• Don't lazy-load the image at the top of the screen.
• Speed up the server response: page caching, an up-to-date PHP version, sufficient server resources.
• Defer or combine non-critical CSS and JavaScript.

For INP

• Remove unused plugins and third-party scripts.
• Limit heavy animations and scroll effects.
• Load heavy embeds such as chat, maps or video only when needed.

For CLS

• Give every image and video a width and height.
• Serve web fonts from the site's own server, limited to the characters you need.
• Reserve space in advance for banners and embeds that load later.

Keep in mind that optimization has its limits. Some caching and speed settings can raise the score while breaking how the site works. After every change, you need to test menus, forms and the mobile view by hand.

Our experience

Our own site, artsution.com.tr, runs on WordPress, Hello Elementor and Elementor Pro, on a LiteSpeed server with the LiteSpeed Cache plugin. To improve our mobile PageSpeed results, we combined CSS files, served fonts from our own server instead of loading them from an external service, and prepared small font subsets that also cover Turkish characters. Animations that are off screen don't run until the visitor reaches that section.

In this process, we deliberately keep one setting turned off: the "guest optimization" feature in LiteSpeed Cache. This feature can delay JavaScript until the visitor's first interaction, and as a result we saw menus and forms not working on the first tap. An improvement you make for the lab score is not a real improvement if it breaks the experience of real users. That is exactly what INP tries to measure.

Frequently asked questions

Conclusion

Core Web Vitals break the question "Is the site fast?" into three concrete questions: Did the main content load quickly? Did the page respond to a tap right away? And did the content stay in place? These metrics are not the only factor in search visibility, but they directly affect whether visitors stay on your site.

If you'd like to improve your site's Core Web Vitals or build a new site around these criteria from the start, take a look at our web design and WordPress development services, or get in touch with us.