Core Web Vitals Explained for Website Owners

Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: how quickly the main content appears, how quickly the page reacts when someone taps or clicks, and whether the layout jumps around while loading. They are part of Google's page experience signals, but the more important reason to care is simpler. Visitors leave slow, jumpy pages, and they rarely tell you why.

This guide explains the three metrics in plain language, the thresholds Google publishes, and how to decide what to fix first on a normal small business site.

The three metrics at a glance

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	Time until the biggest visible element has rendered	2.5 seconds or less	Over 4 seconds
INP (Interaction to Next Paint)	How long the page takes to respond visually after a tap, click or key press	200 milliseconds or less	Over 500 milliseconds
CLS (Cumulative Layout Shift)	How much visible content moves unexpectedly	0.1 or less	Over 0.25

Values between "good" and "poor" fall into a "needs improvement" band. Google assesses a page at the 75th percentile of real visits, which means that three quarters of your visitors should get an experience at or better than the threshold. One fast test on your own laptop does not prove the page passes.

Largest Contentful Paint: is the page showing up?

LCP looks at the largest image, video poster or block of text in the first screen and records when it finishes rendering. On most sites this is a hero image or a large headline. A slow LCP usually comes from one of four causes: a slow server response, a heavy or poorly formatted image, render-blocking CSS or JavaScript, or the browser discovering the key image too late.

Interaction to Next Paint: does the page respond?

INP replaced the older First Input Delay metric in March 2024. Where First Input Delay looked only at the first interaction and only at the delay before it started, INP considers interactions throughout the visit and reports one of the slowest, from input until the next frame is drawn. Pages that load quickly but feel sticky when you open a menu or press a button usually have a JavaScript problem: too much code running on the main thread at once.

Cumulative Layout Shift: does the page stay still?

CLS adds up unexpected movement of visible elements. You have felt this when you went to tap a link and a banner loaded above it, pushing the link down. Common triggers are images without width and height attributes, ads and embeds that load late, fonts that swap and change text size, and cookie banners injected at the top of the page.

Lab data versus field data

There are two kinds of measurement, and mixing them up causes confusion.

• Field data comes from real visitors using real devices and networks. Google collects it from Chrome users and shows it in PageSpeed Insights and Search Console when your site has enough traffic. This is what counts for assessment.
• Lab data comes from a simulated test, such as Lighthouse. It is reproducible, which makes it ideal for debugging, but it is one device on one connection.

A small site may have no field data at all. In that case use lab tests to find problems and treat the results as guidance, not as a verdict.

Where to start fixing

1. Measure the pages that matter. Test your home page, your most visited landing page and a typical article or product page on a mobile profile. Do not average the whole site.
2. Fix the slowest metric first. If LCP is poor and CLS is fine, work on LCP.
3. Start with the cheap wins. Compress and resize the hero image, set image dimensions, enable caching, consider a CDN, and remove plugins or scripts you no longer use.
4. Re-test after each change. Change one thing at a time so you know what helped.
5. Wait for field data to catch up. The real-world numbers are collected over a rolling period, so improvements take a few weeks to show fully.

What hosting has to do with it

Core Web Vitals are mostly about how a page is built, but hosting sets the floor. A slow server response delays everything that follows, which hurts LCP directly. Crowded servers, outdated PHP versions and missing server-side caching all add time before the browser receives the first byte. Good front-end work cannot fully compensate for a slow back end.

A realistic expectation

Passing all three metrics is a worthwhile goal, but it is not a magic ranking switch. Content relevance still matters far more. Think of Core Web Vitals as removing friction: they will not make a weak page rank, but a slow, jumpy page makes it harder to keep the visitors you already earned.

Common mistakes site owners make

• Chasing a perfect Lighthouse score. A score of 100 in a lab test is not the goal. Passing the three thresholds for real visitors is.
• Testing only on desktop. Most assessment is done on mobile, and mobile devices have slower processors and connections.
• Installing a speed plugin and stopping there. Plugins can help with caching and image handling, but they cannot remove a 3 MB hero image or a dozen marketing scripts.
• Ignoring templates. Pages built from the same template usually share the same problems, so fixing the template fixes many pages at once. Search Console groups similar URLs for exactly this reason.

Keep a simple log of what you changed and the score before and after. It saves guesswork when something regresses after a plugin update.

Fast pages start with the server

On Zebra Hosting Cloud, every plan includes the Plesk control panel, where you can choose current PHP versions, and Cloudflare CDN is available on hosted sites to serve static files closer to visitors. Together these cover the server side of the equation so you can concentrate on the page itself. See what each plan offers on the hosting overview.