Core Web Vitals Explained for Business Owners

LCP: when the main content appears

LCP is the metric people intuitively mean by speed. A visitor arrives from Google on a phone, and for a moment the screen is blank or shows a logo. LCP is the moment the big thing appears: the hero image on a homepage, the product photo on a product page, the headline on an article. What delays it is almost always a slow server response, an oversized image, or scripts and fonts the browser must download before it may draw. Our guide on why a website is slow shows how to tell which you have.

INP: how fast the page responds

INP measures the gap between a user's action and the screen changing in response. Tap a menu button and nothing happens for half a second; open a size selector and it lags. That is poor INP, caused by the browser being busy running JavaScript when the tap arrives. Typical culprits are heavy chat widgets, analytics and marketing tags, cookie banners with large scripts, and page builders that ship far more code than the page uses. INP replaced the older First Input Delay metric because it looks at every interaction during the visit, not only the first.

CLS: why things jump around

CLS is the metric behind the most irritating experience on the web: you go to tap a button and the page shifts, so you tap the wrong link instead. It happens when the browser draws content before it knows how much space something will need. Images without declared dimensions, fonts that swap in late, banners injected after load and embeds that resize themselves all push content around. CLS is usually the cheapest of the three to fix, because it is mostly about declaring sizes and reserving space.

• Give every image and video explicit width and height so the browser reserves the space early.
• Reserve room for cookie banners and notification bars instead of inserting them above existing content.
• Load web fonts without a visible swap, or use a system font for body text.
• Avoid late-loading hero sliders that appear above what the visitor is already reading.

Field data vs lab tests

There are two kinds of numbers and they often disagree. Lab tests, such as a PageSpeed Insights run or Lighthouse, load your page once on a simulated device and connection. Field data comes from the Chrome User Experience Report, collected from real visitors over the last 28 days, and it is what Google uses for ranking. A site can score well in the lab and poorly in the field if its real visitors are on older phones and mobile networks, common in Sweden outside the big cities. Judge by the field data; use lab tests only to diagnose why the field number is what it is.

Which metric to fix first

Open Search Console, choose mobile, and look at which page groups are marked Poor. Fix in this order: first the metric that is Poor on the page type with the most search traffic, usually the homepage or service pages; then LCP anywhere it is Poor, because it affects every visitor from the first second; then INP, which mostly hurts your most valuable visitors, the ones who interact; then CLS. Re-check after 28 days, because the field data needs that long to reflect a change. A performance and SEO optimisation follows exactly this sequence; the price is on our pricing page.

When you do not need this: if all three metrics show Good on mobile in Search Console, further speed work will not move your rankings and your money is better spent on content or conversion. If your site has too few visitors for Google to report field data at all, fix the obvious things a lab test shows and move on. If you are not sure how to read the report, book a short call and share your screen.

Frequently asked questions