Core Web Vitals Explained for Non-Technical Founders
Executive TL;DR
- Three numbers, three questions. LCP: did the main content appear fast (good is 2.5 seconds or less). INP: did the page respond when tapped (200 milliseconds or less). CLS: did things stay still instead of jumping (0.1 or less). You need all three to pass.
- Google grades real visitors, not tests. Scores come from Chrome field data at the 75th percentile over a rolling 28-day window — so three of every four visits must hit the threshold, and a green lab score can sit next to a failing Search Console report without either being wrong.
- Fix by template, not by page. One product page template fixed well repairs thousands of URLs; chasing individual pages burns sprints. INP is where most sites fail and the hardest to fix; CLS is usually the cheapest win.
Someone sends you a screenshot. There’s a red circle on it, and the word “Performance.” The site is fine, your developer says. The site is failing, according to Search Console. Both are true, and the reason is the single most useful thing a founder can learn about this subject.
Core Web Vitals are three metrics that reflect a real visitor’s experience. Largest Contentful Paint asks how long it takes for the biggest content—usually your hero image or headline—to appear. 2.5 seconds or less is good. Interaction to Next Paint is how long it took for a page to respond after a tap or click. Good is 200 milliseconds or less; it replaced the older First Input Delay metric in March 2024, so any advice still mentioning FID is old news. Cumulative Layout Shift is how much the page jumps around as it loads, like when an ad loads in above the button you were trying to tap. Good is. 1 or less, and is the only one without a unit.
And here is the argument's ending part. Google doesn’t grade the test your dev ran on their laptop. It measures what really happened to real Chrome users on your site, at the 75th percentile—that is, three out of four visits must hit the threshold—averaged over a rolling 28-day window, scored separately for mobile and desktop. A fast office connection and a new laptop will get you a green lab score but a quarter of your actual visitors on mid-range Android phones will have a very different experience.
So the first decision is not what to fixscore,. It is which number you are going to run the company on.
Search Console field data, a lab test, your own real-user monitoring, or a plugin fix — which should you base decisions on?
| Search Console / CrUX | Lighthouse / PageSpeed | Your own real-user monitoring | Plugin, CDN or speed service | |
|---|---|---|---|---|
| Cost | Free | Free | Free to moderate — an open-source script plus wherever you store the data, or a paid tool | Monthly fee, often modest |
| What it actually measures | Real Chrome visitors — the exact data Google ranks on | One simulated visit on a throttled connection; a diagnosis, not a grade | Your real visitors, including browsers CrUX does not cover, broken down however you like | Usually nothing — it applies fixes and reports its own score |
| Feedback speed | Slow — a 28-day rolling window, so a fix takes weeks to show | Instant | Near real time, which is why it is the one you fix against | Instant claims, unverified reality |
| Who can act on it | Anyone can read it; engineers act on it | Engineers — it names the specific offending elements | Both: founders watch the trend, engineers use the attribution data | Nobody internally learns anything |
| Ops burden | None | None, until you wire it into CI | Low — a small script and an endpoint; moderate if you build dashboards | Low, but it becomes a dependency on someone else's black box |
| Lock-in | None | None | Low with the open-source library; higher with a proprietary vendor | High — removing it can undo the gains |
| Fails when | You need to know why, or you need results this week | Treated as the grade rather than the diagnosis | Traffic is too low for a stable 75th percentile | The bottleneck is your own code, which no CDN can fix |
When to pick each option
Search Console is the score board. You always start with that. It reports the same field data Google ranks on, grouped into sets of similar URLs, which tells you something a single-page test never will: which template is failing. If your product pages are red and your blog is green, then you have just scoped the work. Its weakness is the 28-day window—you won't see a fix land for weeks, so it is a terrible tool to iterate against.
Think of Lighthouse and PageSpeed Insights as diagnostic, not grade. Only a lab test will tell you that the hero image is 1.8MB or that a third-party script is blocking the main thread for 400 milliseconds. This is exactly what your engineers need. Teams end up optimizing a laptop simulation instead of the mid-range phone a real customer is holding by treating its score as the number to raise.
As you start working on performance, add your own real user monitoring. The official web-vitals library is a few kilobytes, reports the same three metrics from real sessions, and includes attribution data naming the element responsible. You get results in hours, not a month, broken down by page template, device, and country—plus you capture browsers CrUX does not. This is the best value addition on this list for most teams, and it is really cheap.
The legitimate easy wins—image compression, caching, edge delivery—use a plugin or a CDN service, but make it clear what it can’t do. And if the problem is a big JavaScript bundle, a slow API on your own page or 5 marketing tags added by your growth team, then no proxy will fix that. The honest test: ask the vendor to show improvements in your field data, not in their dashboard.
Rendering diagram…
// npm i web-vitals — Google's own library, a few KB.
// Add this once and you stop arguing about whose laptop is right.
import { onLCP, onINP, onCLS } from 'web-vitals/attribution';
function report(metric) {
const body = JSON.stringify({
name: metric.name, // LCP | INP | CLS
value: Math.round(metric.value),
rating: metric.rating, // good | needs-improvement | poor
// The attribution block is the part that saves engineering time:
// it names the element or interaction responsible, on a real visit.
culprit: metric.attribution?.element
?? metric.attribution?.interactionTarget
?? metric.attribution?.largestShiftTarget,
// Segment by what you can actually fix: the template, not the URL.
template: document.body.dataset.template, // 'product' | 'blog' | 'checkout'
path: location.pathname,
connection: navigator.connection?.effectiveType, // '4g' | '3g' | ...
});
// sendBeacon survives the page being closed — which is exactly when
// the slowest sessions end, and those are the ones you are missing.
navigator.sendBeacon('/api/vitals', body);
}
onLCP(report);
onINP(report);
onCLS(report);
// Then read the 75th percentile per template, not the average.
// Averages hide the quarter of visitors Google is actually grading you on.MVP development planner
Scope, budget, and launch plan
Choose the product, platforms, and modules. The range, phases, and team update as you go. It is a planning figure, not a quote.
Newsletter
One architecture teardown or evaluation, every other week
Practical write-ups on framework choices, migrations, and scaling decisions—written for people who have to defend the call in a meeting.
Newsletter
Get the 2026 Tech Stack Guide
Join the KarmaKoders newsletter for architecture notes, stack evaluations, and build playbooks.