Module 4 · 4.3

English

Nederlands English Deutsch Français Español Italiano Polski Čeština Magyar Slovenčina Hrvatski Slovenščina

Core Web Vitals: LCP, INP and CLS

Module 4: Speed, mobile and https · Reading time: 13 minutes

Learning objective: After this lesson you can explain the three Core Web Vitals and their thresholds, describe the difference between field data and lab data, read a PageSpeed Insights report, tackle the main causes of a poor score, and judge honestly how much speed counts in the search results.

Key concepts: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75th percentile, field data (CrUX), lab data (Lighthouse), PageSpeed Insights, Core Web Vitals report in Search Console, TTFB, compression, width and height on images, loading="lazy", page experience

Speed in three numbers

"Is my site fast?" is a vague question. Google and the makers of Chrome have turned it into three measurable questions, the Core Web Vitals:

Metric	Question	Good	Needs improvement	Poor
LCP, Largest Contentful Paint	How quickly does the largest piece of content appear on screen?	up to 2.5 s	2.5 to 4 s	over 4 s
INP, Interaction to Next Paint	How quickly does the page respond when you click, tap or type?	up to 200 ms	200 to 500 ms	over 500 ms
CLS, Cumulative Layout Shift	How much does the page jump around while loading?	up to 0.1	0.1 to 0.25	over 0.25

A few things worth understanding properly:

LCP measures the moment the largest visible element appears. That is usually a large photo at the top (the "hero") or a big block of text. For Bloemenatelier Lotte it is the photo of the flower arrangement on the homepage.
INP looks at all clicks, taps and key presses during the visit and reports (almost) the slowest response. On 12 March 2024 INP replaced the older metric FID (First Input Delay), which only looked at the first click and only at the wait before processing. If you come across FID in an old article, it is out of date.
CLS is not a time but a score without a unit. It goes up when things move while you are reading: you want to tap a button and at that moment a banner slides in above it, so you tap something else.

The 75th percentile

A page "passes" the Core Web Vitals when 75 per cent of visits score well on all three, measured separately for mobile and desktop. This is called the 75th percentile. It means that what counts is not your own fast computer on fibre, but the experience of most visitors, including those with an older phone on 4G.

Field data and lab data

There are two kinds of measurement, and they often give different numbers.

Field data comes from real visitors. Chrome collects anonymous data on how fast pages were (from users who allow it) in the Chrome User Experience Report (CrUX). PageSpeed Insights shows the field data from the past 28 days. The Core Web Vitals report in Search Console uses the same source. If your page has too few visitors, PageSpeed Insights shows the figures for your whole site (the "origin"), and if that also has too few, there is no field data.
Lab data comes from a simulated test with Lighthouse: a single load on an emulated mid-range phone and connection. Lighthouse cannot measure INP (nobody clicks), so it gives other figures, such as Total Blocking Time, which do give a hint about INP.

Field data is what counts for the assessment. Lab data is useful for finding causes and for seeing straight away whether an improvement helps, without waiting 28 days.

How much does it count?

This is often exaggerated. Here is what Google itself says in its documentation on page experience:

"Core Web Vitals are used by our ranking systems": so they do count.
There is no separate "page experience signal". According to Google, other parts of a good page experience (https, no intrusive pop-ups, mobile-friendly) do not directly help you rank higher, but they do make your site more pleasant to use.
"Google Search always seeks to show the most relevant content, even if the page experience is sub-par." So a slow page with the best answer can still be at the top.
According to Google, chasing a perfect score just for SEO "may not be the best use of your time".

Conclusion: make sure you are in the green, or at least the orange, zone, mainly because visitors give up on a slow or jumpy page. Chasing 90 to 100 points in Lighthouse gains you little in the search results.

Causes you can tackle yourself

A slow first response (TTFB)

Everything starts with the moment the first byte of the HTML arrives, the Time to First Byte. TTFB is not a Core Web Vital itself, but a slow TTFB makes a good LCP almost impossible. web.dev gives this guideline: good is 0.8 seconds or less, poor is more than 1.8 seconds. Causes according to web.dev: too little computing power at the hosting, no cache (every page is built from scratch, typical for WordPress without a cache plugin), redirects (lesson 4.1) and a distant server without a CDN.

Compression is part of this: the server should send HTML, CSS and JavaScript compressed with gzip or Brotli. You can see this in the header Content-Encoding: gzip or br. Almost every hosting does this by default, but a wrong setting or an old server can switch it off.

Images

Images are the most common cause of a poor LCP and CLS:

Too large. A photo 4,000 pixels wide and 5 MB in size for a box of 800 pixels. Resize before uploading and use a modern format such as WebP or AVIF.
No width and height. Without width and height the browser does not know how much space the image needs, so the text below it jumps as soon as the image arrives. web.dev recommends putting width and height on every <img>:
```
<img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">
```
Lazy loading the most important photo. loading="lazy" only loads an image once it comes into view. That is fine for photos further down, but web.dev is clear: do not lazy load images that are already in view when the page opens, and certainly not the LCP image. Otherwise the browser holds back the very photo that determines your LCP.

Shifting content and slow responses

Other causes of CLS according to web.dev: fonts that change size while loading, adverts and embedded widgets that resize themselves, and content inserted later above the existing content (such as a cookie banner that pushes the page down instead of sitting on top of it). A poor INP is almost always caused by too much JavaScript: heavy themes, sliders, chat widgets and third-party trackers. Take a critical look at every plugin or embedded service; less really is more here.

In practice: measuring with PageSpeed Insights

Go to pagespeed.web.dev, enter the address of your homepage and click Analyze. You get two tabs (Mobile and Desktop). At the top is the Core Web Vitals assessment based on field data, if there is any. Below that is the Lighthouse test with a score and a "Diagnostics" list of concrete points, for example about images that are larger than needed or an LCP image that is lazy loaded (the exact names change with new versions of Lighthouse). Start with Mobile: it is usually worse there, and Google looks at mobile first (lesson 4.2).

If your site is in Search Console (module 2), also look under Experience, Core Web Vitals. There you will see groups of similar pages with their status, including pages you had not tested yourself.

A site made with the AI Builder sets width and height on images whose size is known, loads the first photo on the page immediately and with priority (fetchpriority="high") and the rest lazily, and creates an 800-pixel-wide version of large photos when publishing. In WordPress, a cache plugin and resizing images help the most; the WordPress course goes into this in more depth in module 6. Other website builders and hosting companies work in a similar way: the buttons differ, the causes are the same.

Summary

The Core Web Vitals are LCP (good up to 2.5 s), INP (good up to 200 ms, replacing FID since March 2024) and CLS (good up to 0.1), measured at the 75th percentile per device type.
Field data (CrUX, 28 days) determines the assessment; lab data (Lighthouse) helps you find causes.
Google uses the Core Web Vitals in ranking, but relevance comes first: a perfect score is not a goal in itself.
Biggest gains: a fast server response with cache and compression, small images with width and height, not lazy loading the most important photo, and less third-party JavaScript.

Quiz

Exercise

Exercise A4.3: Fast response and light images. Enter the address of a page. The tool measures the time to first byte (TTFB) three times from our server and takes the middle value, checks whether the HTML is sent compressed (gzip, Brotli or zstd), counts the images without width and height, and checks that the main image at the top is not loaded with loading="lazy". Note: this is a measurement from one location, not a measurement of your visitors. No site of your own? Use www.wikipedia.org.

Exercise D4.3: Your Core Web Vitals. Run PageSpeed Insights on your homepage and on one other important page, starting with Mobile. For each page, note: whether there is field data (page or whole site), the LCP, INP and CLS from the field data, the Lighthouse score, and the element Lighthouse identifies as the LCP element. Choose the one improvement you think will gain the most, and explain why.

Exercise D4.3: Your Core Web Vitals

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

Ran PageSpeed Insights on your homepage (mobile)
And on one other important page
Noted whether there is field data (for the page or the whole site)
Noted LCP, INP and CLS from the field data
Noted the Lighthouse score and the LCP element
Checked the Core Web Vitals report in Search Console (if your site is in it)

Your table per page

Differences between field and lab? Why?

Which single improvement do you choose, and why?

Compared with desktop

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing