Core Web Vitals in plain language

Core Web Vitals explained without the dashboard jargon: three measurements of a real visit. One tracks how long the main content takes to appear. One tracks how long the page takes to respond when someone taps or clicks. One tracks whether the layout jumps while it settles. Google uses them as signals of loading, responsiveness, and visual stability.

The targets are short enough to remember. Google Search Central says to aim for Largest Contentful Paint within 2.5 seconds of the page starting to load, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. web.dev states the same goals as a good experience: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. The examples below are what those numbers feel like on a company site.

Three facets, three metrics

web.dev describes Core Web Vitals as the subset of Web Vitals that apply to all pages, that every site owner should measure, and that show up across Google's tools. Each one is a field metric. It is meant to reflect a real visit, not only a simulation in a quiet office.

The set can change over time. The current three are stable: Largest Contentful Paint for loading, Interaction to Next Paint for interactivity, and Cumulative Layout Shift for visual stability. Interaction to Next Paint took the place of an older responsiveness metric, First Input Delay, because a single first tap was too narrow a picture of how a page behaves while someone uses it.

You do not need to collect these by hand to have the conversation. Search Console has a Core Web Vitals report. PageSpeed Insights and Chrome's user-experience data can show the same family of numbers. The point of knowing the names is so a report, or a studio, cannot wave at "performance" without saying which of the three is late.

Largest Contentful Paint

Largest Contentful Paint is the moment the largest visible element finishes painting. On a marketing homepage that element is often the hero photograph, or the headline block if the hero is small. The clock starts when the page starts loading. For a good experience, that paint happens within 2.5 seconds.

Picture a founder opening the homepage on a phone. The screen stays pale while a full-bleed photograph downloads. The headline is trapped inside the image, or it is waiting on a font and a script. The photograph arrives well after the page started. That late arrival is a weak Largest Contentful Paint, and it is the first impression.

The fixes are usually ordinary. Serve a photograph at the size it is displayed. Keep the headline in HTML so it is not trapped inside the image file. Be suspicious of a hero video that must download before the offer can be read. web.dev notes that related loading measures, such as server response and first content, help diagnose a slow largest paint. You can ask which of those is the bottleneck without running the test yourself.

Interaction to Next Paint

Interaction to Next Paint measures responsiveness. Someone taps, types, or clicks. The metric watches how long it takes before the next frame paints in response. web.dev's good line is 200 milliseconds or less. Google Search Central phrases the search recommendation as under 200 milliseconds. In practice, a tap should feel like it landed.

Picture the same homepage after it has painted. The visitor taps "Work" in the navigation. Nothing visible happens. A script is still busy with an animation library, an analytics tag, and a chat widget. The menu opens late. That delay is the experience Interaction to Next Paint is there to catch. The page looked ready. It was not ready for a person.

A laboratory tool such as Lighthouse cannot fully measure this, because a lab run has no visitor. web.dev is explicit: tools that load a page without a user cannot record Interaction to Next Paint, and Total Blocking Time is the lab stand-in teams use while building. A good lab score is encouraging. The field number, from real phones, is the one that matches the tap in the example.

Common causes on a marketing site are easy to describe even when the profiler is not. Too much JavaScript for a page that is mostly reading. A menu that waits on a framework to become interactive. Third-party widgets that run before the page has answered the first tap. The design can stay. The script diet is what changes the number.

Cumulative Layout Shift

Cumulative Layout Shift measures visual stability. A good page stays at 0.1 or less in web.dev's wording, and under 0.1 in Google Search Central's. Either way, the goal is a page that does not jump while someone is trying to use it.

Picture a "Book a call" button in the first screen. The visitor puts a thumb on it. A late-loading banner inserts itself above the button, the button drops, and the tap hits "Log in" or hits nothing. The page did not crash. It moved. That movement is layout shift, and it trains people not to trust the interface.

Shifts come from images without reserved space, fonts that swap and reflow the paragraph, ads or banners injected above content, and animations that start after the first paint and push sections down. The craft fix is to give media a width and a height, to keep late content from inserting above what is already readable, and to refuse motion that relocates the thing someone is about to tap.

A little shift is easy to miss in a screenshot taken on a fast laptop. Scroll the staging site on a phone while images load. If the button moves, the screenshot left the bug out.

How to read a report

One visit is an anecdote. web.dev recommends judging the metrics at the 75th percentile of page loads, separated for mobile and desktop. A page is in good shape when it meets the targets at that percentile for all three. The 75th percentile means you are looking at a visit that is slower than most, while still ignoring the worst tail. It stops a single office Wi-Fi test from declaring victory.

Mobile and desktop deserve separate lines. A desktop score can look calm while the phone, which is the founder's real preview and often the visitor's, is the one that fails. If you only have time to care about one segment, care about mobile.

Field data lags. A change you shipped this morning may not show in Search Console for a while. Use lab tools to catch a regression before release, then use the field report to see whether real visits agree. web.dev's distinction is the one to keep: lab measurement helps during development, and measurement from users is what tells you the page is actually fine.

What to ask for, and what to ignore

Ask which of the three is failing, on which template, on mobile or desktop. Ask what the largest element is on the homepage. Ask what happens when someone taps the primary action before every script has finished. Ask whether images reserve their space.

Ignore a single green badge with no URL and no device. Ignore a promise that a framework is "fast by default." The metrics are about the page you shipped: its images, its scripts, its fonts, and its habit of moving things. A calm stack helps. It does not score the vitals for you.

Hanabi treats these three as part of finishing a marketing site, alongside the writing and the layout. If you want that standard applied to a page you are about to build or replace, start from Hanabi's services and bring the report, or the complaint that the site feels slow. The names above are enough to make the conversation specific.

The order of operations, paint first and decorate second, is the companion piece: Why a marketing site should be fast before it is clever. Read that one when the scores are a symptom of an entrance that was designed to be admired on an empty screen.