Core Web Vitals explained: LCP, INP and CLS

Speed used to be measured with a single number, such as total load time. That told you little about what a person felt. A page can finish loading in four seconds yet show its main content in one and be usable immediately, or load in two seconds yet jump around and ignore taps. Core Web Vitals try to measure what matters to a person in three parts: did it appear quickly, does it respond, and does it stay still.

They are part of Google's page experience signals. Honest expectation matters here. Good vitals are not a magic ranking switch. Content relevance and quality remain far more important. But a slow, jumpy page loses visitors before they read anything, and between two otherwise equal pages, the better experience can help. The practical argument is for your visitors, with any ranking gain as a bonus.

The metrics have changed over time. Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric in March 2024, because it looks at all interactions during a visit, not just the first.

Field data comes from real visitors using real phones on real networks, collected from Chrome users and published in the Chrome User Experience Report. This is what Google uses for the assessment. Lab data comes from a test tool that loads your page once in a controlled simulation, which is useful for diagnosing problems because it is repeatable.

They often disagree. A lab test on a fast connection may look excellent while field data from visitors on older phones looks poor. And a new or low-traffic site may have no field data at all, because Google only reports it for pages with enough visits. Use lab tools to find and fix causes, and field data to confirm that real visitors benefit.

Remember that vitals are measured per page group and device. Your homepage may pass while a heavy product page fails, and mobile is usually the harder test. Our guide to testing website speed shows which tools to use.

Work from the server outwards. If the server takes a long time to answer, nothing else can be fast, so page caching comes first. Our plans use the LiteSpeed web server with caching and Redis object caching for dynamic sites, which cuts the time to the first byte on UK servers in London.

Next, look at the largest element on the page, often an image. Make it the right size for the screen, compress it, serve it in a modern format and make sure it is not lazy loaded, since it must appear straight away. Our guide on optimising images covers the details. Finally, reduce render-blocking CSS and JavaScript so the browser can paint sooner.

Phones have slower processors and often weaker connections than the computer you use to build the site. A script that runs in a blink on your laptop can keep a mid-range phone busy for a second, which is why INP and LCP problems show up on mobile first. Google reports phone and desktop separately, and most small business visitors arrive on a phone, so make that your main test.

If you only have time for one habit, open your own site on an older phone over mobile data once a month and tap around. What feels slow to you is slow to your customers, and no score replaces that.