هذا المقال غير متوفر بالعربية بعد. أنت تقرأ النسخة الإنجليزية.
Core Web Vitals: understand LCP, INP and CLS and finally fix them
Three metrics decide whether Google considers your site fast. What they really measure, the thresholds to aim for and the fixes that work most often.
فريق Codanalyst
قراءة في 4 دقائق
المحتويات
Since 2021, Google has used three user experience metrics in its rankings: the Core Web Vitals. They are far from the whole of SEO, but they have one rare quality: they measure what your visitors actually experience, on their phone, with their connection.
The problem is that their names don't help. LCP, INP, CLS: everyone knows they should be "in the green", few know why they aren't. Let's go through them one by one.
LCP: when the page finally looks loaded
Largest Contentful Paint measures how long it takes to display the largest visible element on screen. On a product page it's often the main photo; on an article, the title or the header image.
Google's thresholds:
- good: 2.5 seconds or less;
- needs improvement: between 2.5 and 4 seconds;
- poor: over 4 seconds.
In the vast majority of audits we see, a slow LCP comes down to one of three causes: a main image that is too heavy, an image the browser discovers too late, or a server that takes more than a second to respond.
The most effective fix often fits on one line. You tell the browser to load the main image first:
<img src="/hero.webp" alt="Trail running shoes on a mountain path" fetchpriority="high" width="1200" height="800">
INP: does the page respond when you click?
Interaction to Next Paint replaced FID in March 2024. It measures the delay between a user action (a click, a key press, a tap) and the visible update of the page. Where FID only looked at the first interaction, INP observes all of them and keeps one of the slowest.
The thresholds:
- good: 200 milliseconds or less;
- needs improvement: between 200 and 500 milliseconds;
- poor: over 500 milliseconds.
A high INP almost always means the browser's main thread is busy at the moment of the click: a tracking script running, a large component re-rendering, an event handler doing too much at once.
What works:
- trim third-party scripts: chat widgets, ad pixels and A/B testing tools are the usual suspects;
- break up long tasks: show the visual feedback of the click first, defer the rest of the work;
- defer what isn't urgent with the
deferattribute on non-essential scripts.
CLS: the page that moves on its own
Cumulative Layout Shift measures unexpected movements of content. You know the situation: you're about to tap a link, a banner loads above it, and you click something else.
No seconds here, but a score:
- good: 0.1 or less;
- needs improvement: between 0.1 and 0.25;
- poor: over 0.25.
The usual culprits are easy to spot: images without dimensions, ad slots without reserved space, web fonts that change the size of the text as they load. The simplest fix is to always set width and height on your images, or to reserve the space with the CSS aspect-ratio property.
Lab data or field data?
One point causes a lot of confusion. Google evaluates your Core Web Vitals using field data, collected from real Chrome users, based on the 75th percentile of visits. A test run from your computer, on a fast connection, can show excellent numbers while your mobile visitors have a very different experience.
Lab measurements remain essential to understand a problem and verify a fix. But it's the trend in real-world data, over several weeks, that tells you whether you've won.
Where to start
If you only did three things this week:
- identify the LCP element of your key pages and give it loading priority;
- add dimensions to every image;
- list your third-party scripts and remove the ones you no longer need.
That's exactly what Codanalyst checks in its performance analysis, page by page, with the right fix for each case. Run a free audit to see where your site stands.