Core Web Vitals for a company website: what actually moves the numbers

Most company websites fail Core Web Vitals for three or four reasons, and they are the same three or four reasons every time. This article names them, in the order they cost you the most.

Written from sites we build and sites we are asked to rescue. The fixes are ranked by what actually changes the number, not by what is easiest to write in a report.

The three numbers, in plain terms

LCP — how long until the biggest thing on screen has drawn. Usually your hero image or headline. Target: under 2.5 seconds.

CLS — how much the page jumps around while it loads. Every time something arrives late and pushes the content down, this goes up. Target: under 0.1.

INP — how long the page takes to respond when someone taps or clicks. Target: under 200 milliseconds.

Google measures these from real visitors, not from a test run on a fast laptop. Your own machine on office wifi is the least representative device your site will ever load on.

What actually moves LCP

In order of impact, from what we see repeatedly:

1. The hero image
   • Wrong format. A 2 MB JPEG where a 180 KB WebP would look identical.
   • Wrong size. A 4000px-wide file rendered at 1400px.
   • Loaded lazily. The one image that must never be lazy is the one at the top.
2. Fonts
   • A custom font that blocks rendering until it downloads.
   • Fix: font-display: swap, preload the one weight above the fold, and subset it to the characters you use — including Romanian diacritics, which get dropped by careless subsetting.
3. Render-blocking scripts
   • Analytics, chat widgets and tag managers in the <head>, loaded synchronously.
   • Almost all of them can be deferred. The chat widget does not need to load before the headline.
4. The server
   • Time to first byte above 600ms means nothing downstream will save you.

The two that trip most sites

CLS is almost always images without dimensions. The browser does not know how tall an image will be until it arrives, so it reserves nothing and everything below jumps. Put width and height on every image, or an aspect-ratio in CSS. This is a one-line fix per image and it removes most layout shift on a typical site.

The other common cause is a cookie banner or notification bar that injects itself at the top after the page has drawn. If it must exist, reserve its space from the first paint.

INP is usually one heavy script. A slider library, a scroll-animation library, or an analytics bundle doing work on every scroll event. The symptom is a page that looks finished but ignores the first tap. Profile it, find the long task, and either defer it or replace it.

Animation libraries deserve special mention. They are the reason many otherwise well-built sites feel sticky on a mid-range Android phone — the exact device most of your visitors are holding.

Why fixing it after launch costs more

Performance is a structural property, not a setting. If the site was built on a page builder that ships 400 KB of JavaScript to render a text block, no amount of image optimisation gets you into the green. The honest answer at that point is a rebuild, which is why we put this in the structure from the first commit rather than treating it as a pass before launch.

Concretely, that means: images in modern formats with explicit dimensions from the start, fonts subset and preloaded, no library added without asking what it costs in kilobytes, and a build that ships static HTML where static HTML is enough.

What good looks like

Measured on a mid-range Android phone over a normal mobile connection, not on your desktop:

• LCP under 2.0s — comfortably inside the 2.5s threshold, with room for a slow day.
• CLS under 0.05 — half the threshold. Achievable on any site where every image has dimensions.
• INP under 200ms — reachable on a content site unless a heavy script is doing work on scroll.

Check with real-visitor data, not a single lab run. A lab test tells you what is possible; the field data tells you what your visitors actually get.

The order to work in

If you are rescuing an existing site, do it in this order — it front-loads the impact:

1. Fix the hero image: correct format, correct size, not lazy.
2. Add dimensions to every image on the page.
3. Defer every third-party script that is not needed for first paint.
4. Subset and preload the fonts.
5. Only then start profiling JavaScript.

Steps one and two take an afternoon and typically move a failing site to a passing one. Everything after that is refinement.