Core Web Vitals

Core Web Vitals are three things Google measures about how a page behaves for the people using it. Not how it is built, and not how it scores in a test on a fast connection, but what actually happened on real visitors’ devices. The three cover how long the main content takes to appear, how quickly the page reacts when somebody taps, and whether things move about while loading.

In short

• Three measurements: loading, responsiveness and visual stability.
• They are taken from real visitors, not from a test you run.
• They are a genuine ranking signal and a light one.
• The reason to fix them is that people leave slow, jumpy pages.

The three, in plain terms

The official names are unhelpful and the ideas underneath are not, so they are worth translating once and then never thinking about again.

• Largest Contentful Paint. How long before the biggest item on the first screen has appeared. Usually a hero image or a headline. Good is under two and a half seconds.
• Interaction to Next Paint. How long between somebody tapping something and the page visibly responding. Good is under two hundred milliseconds.
• Cumulative Layout Shift. How much the page jumps around as it loads, scored rather than timed. Good is under nought point one.

Between them they describe the three ways a page can feel broken while technically working: it is slow to arrive, slow to answer, and it will not sit still.

Where the numbers come from

Google ranks on field data, collected from real Chrome users over a rolling twenty eight day window, and understanding that one fact settles most arguments about conflicting reports. Your score is not what a tool measured when you ran it. It is what your actual visitors experienced, on their actual phones, on their actual connections, aggregated.

That is why a site can score perfectly in a lab test and fail in Search Console. The lab test ran on a simulated device. The field data ran on a five-year-old handset on mobile data in a province. For most Philippine businesses the second group is the customer base, which makes the uncomfortable number the accurate one.

The seventy fifth percentile

Each measurement is judged at the seventy fifth percentile of page loads, which means three quarters of visits have to sit inside the threshold before you pass. It is the detail that decides most outcomes and the one most rarely explained, because it is not the average and it is not simply most of them.

The consequence is that a fast site with one slow segment can fail. If a quarter of your visitors are on older phones, their experience sets your score however good everybody else’s is. Averages hide that group. This measurement is designed not to.

What actually causes each one

The fixes cluster more tightly than the metrics suggest.

• Slow loading is usually one oversized image on the first screen, a font loading late, or a page waiting on a script before it can draw anything.
• Slow responses are almost always too much code running at once, most often third-party tags nobody has audited in two years.
• Layout shift is images and adverts with no dimensions set, so the browser does not reserve space and everything below jumps when they arrive.

Loading is decided entirely in that first screen, which is why it overlaps so heavily with the choices described under above the fold. Layout shift starts there and keeps accumulating as somebody scrolls, so a page can pass the first screen and still fail on something that loads late.

What they are worth in rankings

Worth saying plainly, because a lot of selling depends on the opposite.

They are a real signal and a light one. Their practical use is as a tie-breaker between pages that are otherwise comparable. A page that answers the question better will outrank a faster page that answers it worse, consistently, and no amount of optimisation reverses that.

Anybody presenting a performance score as the reason you are not ranking is describing the easiest thing to measure rather than the thing that is wrong. The honest version is that speed decides fewer contests than it is credited with, and that it costs you visitors regardless of what it decides.

The better reason to fix them

Take the ranking question out entirely and the case is still strong, because people leave pages that make them wait. People mistap buttons that move. Somebody who reaches for a booking link and hits an advert that loaded underneath their thumb has had a bad experience your analytics will record as a bounce and never explain. Each of the three metrics exists because it corresponds to a way people give up.

For a business whose customers are largely on phones and mobile data, that is not a technicality. It is the difference between an inquiry and a back button.

The order to fix them in

Most sites fail on loading first, and most of the work sits in four steps that have to happen in this order.

1. Find what the largest item on the first screen actually is. Search Console names it per page group, and it is usually a photograph nobody resized.
2. Resize and compress that one image, and give it explicit width and height attributes. This addresses loading and layout shift at the same time.
3. Audit the third-party scripts. Chat widgets, heat maps, pixels from a campaign that ended two years ago. Remove what nobody can account for and defer what remains.
4. Only then look at the server. If the first three are done and the numbers have not moved, the delay is upstream of anything on the page.

Doing these out of order is how businesses buy faster hosting to fix a four megabyte hero image.

Where to look at your own

Two places, answering two questions.

Search Console reports your field data, grouped into pages that behave similarly. That is the one that matches what Google uses, and the one to trust when reports disagree. PageSpeed Insights shows you both the field data and a lab test of the single page you entered, which is useful for checking whether a change worked before waiting a month to see it in the field.

Start with the mobile figures. If they pass and the desktop ones do not, that is a pleasant problem to have and rarely the one costing you customers.

If all three fail at once, stop reading reports and look at the server. Slow hosting produces every symptom on this page simultaneously, and no amount of image compression fixes it. That diagnosis belongs to technical SEO.