WordPress Core Web Vitals: what LCP, INP and CLS measure and how to improve them

Core Web Vitals are three measurements Google defines for how a page feels to the person loading it: how soon the main content appears, how quickly the page reacts to a click or a tap, and whether things move about while it loads. They are taken from real visits in Chrome, not from a test.

This page is about those three figures. For the wider job of making a slow site faster, start with how to speed up WordPress.

The three metrics and their thresholds

Each figure is judged at the 75th percentile: three visits out of four must be at or under the threshold. Phones and desktops are judged separately. A page passes when all three are good. When there is too little data for INP, it passes on the other two.

INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. FID measured only the delay before the first interaction on a page. INP looks at every click, tap and key press of the visit, up to the moment the screen changes. Advice written about FID is out of date.

Field data and lab data

There are two ways to get these figures, and they answer different questions.

Field data comes from real visitors. Chrome collects it, and Google publishes it for pages and sites with enough visits. It covers the previous 28 days. This is the data the pass or fail is based on.

Lab data is a single load of the page under fixed conditions. It is there at once, it is the same test each time, and it comes with a list of what slowed the page. Use it to find causes and to check a change straight away.

The two often disagree. A lab test uses one device and one connection, where your visitors use many. It cannot measure INP, because nobody clicks anything during it. Total Blocking Time is its stand-in. It also sees only the layout shifts that happen during loading, so CLS can be lower in the lab than for real visitors, who scroll. When the two disagree, go by the field data.

Where to see each:

• PageSpeed Insights, at pagespeed.web.dev, shows both for one page. If the page has too few visits, it shows field data for the whole site. If the site has too few, it shows only lab data.
• The Core Web Vitals report in Search Console shows field data for the whole site, for mobile and desktop. It groups pages that behave alike and gives each group the status of its worst metric. Only indexed pages with enough data appear.

Start in Search Console if you have it. It tells you which metric fails and on which kind of page. Then put one page from that group through PageSpeed Insights to find the cause.

Improve LCP

LCP is the time until the largest image, block of text or video in the first screen has been drawn. Often that is a banner image, a featured image or a heading. The lab report in PageSpeed Insights names the element it measured, and you need to know which it is before changing anything.

The server answers slowly. LCP cannot be faster than the server's first answer. Time to First Byte is not a Core Web Vital, but it is the first part of this one, and 0.8 seconds or less counts as good. A page cache, a current PHP version and adequate hosting are the fixes. How to speed up WordPress and WordPress caching plugins compared cover them.

The main image starts loading late. The image that is the LCP element must never be lazy-loaded, and the browser should be told it is a priority. WordPress handles the common case by itself:

• Since version 5.5 it adds loading="lazy" to images that have a width and a height, in post content, excerpts, text widgets, avatars and images that themes print through WordPress's own image function.
• It leaves the attribute off the first images in the content, so they load at once: the first one since 5.9, the first three since 6.3.
• Since 6.3 it adds fetchpriority="high" to the image it judges most likely to be the LCP element. The image must cover at least 50,000 square pixels, and it is never lazy-loaded as well.
• It does not replace a loading or fetchpriority attribute that a theme or plugin has already set.

WordPress cannot see your layout, so this is a guess from the order of images in the page. It goes wrong in three usual ways.

• The banner is a background image set in CSS by the theme or a page builder. It is not an image tag, so none of the above applies, and the browser finds it only after reading the stylesheet. Use a real image there if the theme allows it.
• A slider or a script puts the image on the page after it loads. Replace it with a single still image.
• A plugin or theme with its own lazy-loading may apply it to every image, the first included. Look for its setting that leaves out the first images.

To check, view the source of the page and find the image. It should carry no loading="lazy", and ideally fetchpriority="high".

The image is too heavy. Upload it at the size it is shown, compressed, in a current format. See how to optimize WordPress images.

Styles and scripts hold up the first view. A large stylesheet, or a script loaded the ordinary way in the head of the page, must be fetched and processed before anything is drawn. Since 6.3, WordPress lets a theme or plugin mark a script as deferred, but it defers nothing by itself. Some caching plugins have settings that defer scripts for you. Switch on one setting at a time and check the menus, forms and sliders afterwards.

Visitors are far from the server. A CDN sends images and other files from a server near each visitor. See how to set up a CDN for WordPress.

Improve CLS

CLS scores how far visible content jumps without the visitor causing it. It is taken over the whole visit, not only during loading, and it counts the worst burst of shifts. A shift within half a second of a click or a tap is left out.

Images without dimensions. When an image tag has a width and a height, the browser keeps a space of the right shape before the file arrives. Since 5.5, WordPress adds missing dimensions to an image, but only when the image is in the media library and its tag carries the wp-image- class with the attachment's number. An image written into a theme template, pasted in as HTML or loaded from another site gets nothing. Add width and height to those by hand, and keep height: auto in the CSS so they still scale.

Embeds, ads and iframes. A video, a map or an ad that arrives late pushes down whatever is below it. Give its container the space in advance with a min-height or an aspect-ratio in CSS.

Content added above what is already there. A cookie notice, a sale banner or a sign-up bar that slides in at the top moves the whole page. Show it over the page instead, or keep its space reserved from the start.

Web fonts. Text is first drawn in a fallback font and redrawn when the web font arrives. If the two differ in size, the lines reflow. Preload the font used for the main text, and choose a fallback close to it in size.

To check, load the page on a phone and scroll slowly to the bottom. A lab test will not show you the shifts that happen there.

Improve INP

INP is the time from a click, a tap or a key press to the moment the screen shows a result. Scrolling and hovering are not counted. A page is slow to react when the browser is busy running JavaScript, and on a WordPress site that script comes from three places.

• Plugins. Many load their scripts on every page, including pages that make no use of them. Remove the plugins you can do without. The plugin section of how to speed up WordPress shows how to find the expensive ones.
• Scripts from other companies. Analytics, ad tags, chat widgets and social embeds all run in the visitor's browser. Keep the ones that earn their place and remove the others. Load a chat widget or a map only on the pages that need it.
• The page itself. A page with a very large number of elements takes longer to redraw after every interaction. A long page built from many nested sections and widgets is one. Fewer of both helps.

What is left after that is a developer's job: finding the slow interaction and splitting up the work it sets off.

A page that nobody interacts with has no INP. To test by hand, use the page as a visitor would while it is still loading, when the browser is at its busiest: open the menu, type in the search box, add a product to the cart.

After a change

Run the lab test again at once to see whether the cause has gone. Field data follows slowly: it covers the previous 28 days, so a fix takes about four weeks to show in full. In Search Console you can start tracking a fix from the issue's page, and it watches the affected pages for 28 days.

Our speed optimization service measures the pages you name before and after the work, and promises no score or pass, because Core Web Vitals depend on things outside one job, such as your hosting and scripts loaded from other companies.