Core Web Vitals in 2026: A Practical Guide for Small Teams

Core Web Vitals are the three metrics Google uses to judge whether a page feels fast and stable to a real visitor. They matter for two reasons: they factor into search ranking, and they correlate strongly with whether people actually stick around and convert. You don't need a performance team to keep them healthy, but you do need to know what they measure and check them often enough to catch a regression before it costs you traffic.

The three metrics, in plain terms

Largest Contentful Paint (LCP)measures how long it takes the biggest visible element -- usually a hero image or heading -- to render. Good is under 2.5 seconds. It's the metric people mean when they say a page "feels slow to load."

Interaction to Next Paint (INP)measures how long the page takes to respond after someone clicks, taps, or types. Good is under 200 milliseconds. A page can load quickly and still feel broken if buttons take half a second to respond -- that's what INP catches.

Cumulative Layout Shift (CLS) measures how much visible content jumps around as the page loads. Good is under 0.1. This is the metric behind the classic complaint of trying to tap a button and hitting an ad that just loaded in above it instead.

Why these three and not page speed generally

Raw load time is easy to game and doesn't match what people actually experience. A page can report a fast "time to first byte" and still feel awful if the layout keeps shifting or the biggest image loads last. Core Web Vitals were chosen because each one maps to a specific, common source of frustration, and each is measurable from real user sessions, not just a lab test.

What usually causes a poor score

• Unoptimised or unsized images -- the most common cause of both poor LCP and poor CLS.
• Render-blocking JavaScript and CSS that delays everything below it.
• Third-party embeds (chat widgets, ad scripts, analytics tags) that load late and shift layout.
• Web fonts that swap in after a delay, causing a visible reflow.
• Heavy client-side JavaScript that keeps the main thread busy, delaying INP.

Lab data vs. field data

A Lighthouse score run once from your laptop is lab data-- useful for debugging, but it's one run, from one location, on one connection. What actually affects your search ranking is field data: real measurements from real visitors over time. That's why a monitoring setup that checks your live site on a schedule -- rather than a one-off audit -- catches the regressions a single Lighthouse run misses, like a new plugin that only slows things down for mobile visitors.

A practical checklist

1. Check both desktop and mobile -- mobile scores are almost always worse and matter more for ranking.
2. Re-check after every deploy that touches images, fonts, or third-party scripts.
3. Keep a screenshot alongside each check -- a number alone doesn't tell you what actually rendered.
4. Set a threshold you'll actually act on, and get alerted only when it's crossed for real, not on a single noisy sample.

SREmonitor runs this check automatically on a schedule, captures a screenshot alongside the score, and only alerts you after a real, sustained regression -- see our post on avoiding alert fatiguefor why that last part matters. If you're also thinking about whether your site is reachable in the first place, start with our uptime monitoring guide.