Core Web Vitals: What They Are and How to Fix Them

Core Web Vitals are the three metrics search engines use to measure how comfortable a site is to use. They affect rankings, but their effect on behavior matters far more: a page that lags and jumps loses visitors regardless of its positions.

LCP — when the user saw the main thing

Largest Contentful Paint shows how long it took to render the biggest element of the first screen: usually a banner, a headline or a product photo. The norm is under 2.5 seconds for 75% of users. Typical causes of poor LCP: a heavy unoptimized image, a slow server response (TTFB above 600 ms), blocking CSS and fonts. What to fix first: compress the hero image and convert it to WebP, add a preload for it, turn on server-side caching. On a typical site that takes off 1–2 seconds.

INP — how responsive the site is to actions

Interaction to Next Paint measures the delay between a click and a visible reaction. The norm is under 200 ms. Poor INP almost always means the main thread is busy with JavaScript: analytics, chat widgets, heavy handlers. The cure is deferring third-party scripts, breaking up long tasks and removing whatever nobody uses. A detailed explanation of the metric is on web.dev.

CLS — why the button runs away from your finger

Cumulative Layout Shift measures content shifting after rendering has begun. The norm is below 0.1. The causes are predictable: images and iframes without declared dimensions, banners inserted at the top after loading, fonts that change the line height. It is fixed with width and height attributes on all media, reserved space for dynamic blocks, and font-display: swap with a suitable fallback.

Lab versus field

• Lab tests (PageSpeed, Lighthouse) are for finding causes and testing hypotheses
• Field data (CrUX, Metrica) is for assessing the real situation and for ranking
• Look at the 75th percentile rather than the average: the average hides problems affecting half your audience
• Measure mobile and desktop separately — the difference is usually twofold

The order of work that pays off

We usually go like this: images and fonts first (a day of work, the biggest effect on LCP and CLS), then third-party scripts (half a day, effect on INP), then the server and caching, and only then bundle optimization and refactoring. The reverse order is a common mistake among teams that find code more interesting than pictures. The general prioritization logic is described in the piece on speed and sales.

What Core Web Vitals will not do

They will not lift a page into the top if it does not answer the query. This is a second-order factor: all else being equal a fast site beats a slow one, but relevance matters more. If you have no positions at all, look first at the causes in the breakdown of the Yandex top, and optimize the metrics in parallel.

How to keep the metrics healthy afterwards

• Check field data once a month — degradation creeps in unnoticed, along with a new widget
• Introduce a rule: every new image goes through compression before upload
• Require sign-off for adding any third-party script — each one costs tens of milliseconds of INP
• Measure the metrics before and after every release, not once every six months

If there is nobody to deal with the metrics, this is a routine task for ongoing maintenance — how we handle it is described in the support section, and you can measure the current state yourself in PageSpeed Insights.