Core Web Vitals

Core Web Vitals monitoring tracks how your website performs for real visitors — not in a lab, but out in the world on real devices and connections. It uses field data from Google's Chrome User Experience Report (CrUX), the same dataset Google uses as a ranking signal in Search.

How It Works

Once a day, Hoppla looks up your site's Core Web Vitals in the CrUX dataset and records the 75th percentile (p75) value for each metric. The p75 means three out of four of your visitors had an experience at least this good — it deliberately ignores the fastest outliers so the numbers reflect what most people actually see.

Because the data comes from real Chrome users, your site needs enough real-user traffic for Google to publish CrUX data for it. Low-traffic pages or brand-new sites may not have enough samples yet, in which case the check reports that field data isn't available rather than a score.

Core Web Vitals is an advisory check — it produces a warning status when metrics are poor, but it never creates incidents or appears as downtime on status pages. It's for tracking quality and search readiness, not outage detection.

Lab vs. Field Data

It's easy to confuse Core Web Vitals with the Lighthouse audit. They measure related things in very different ways:

	Lighthouse	Core Web Vitals
Source	Lab — a single synthetic load in a controlled browser	Field — aggregated from real Chrome visitors
What it answers	"How fast could this page be?"	"How fast is this page for actual users?"
Availability	Always (Hoppla loads the page itself)	Only once your site has enough real-user traffic
Best for	Debugging and catching regressions before release	Confirming the real-world experience and your search standing

Use them together: Lighthouse to find and fix problems, Core Web Vitals to confirm the fix reached real users.

The Metrics

Each metric is reported as a p75 field value and rated good, needs improvement, or poor using Google's standard thresholds.

Largest Contentful Paint (LCP)

How long it takes for the largest piece of content (usually a hero image or headline) to appear. This is the closest proxy for "how long until the page feels loaded."

Rating	Threshold
Good	≤ 2.5 s
Needs improvement	2.5 s – 4.0 s
Poor	> 4.0 s

Interaction to Next Paint (INP)

How quickly the page responds to user interactions like taps, clicks, and key presses. It measures responsiveness across the whole visit, not just the first click. (INP replaced the older First Input Delay metric.)

Rating	Threshold
Good	≤ 200 ms
Needs improvement	200 ms – 500 ms
Poor	> 500 ms

Cumulative Layout Shift (CLS)

How much the page visually jumps around as it loads. A high score usually means images or ads without reserved space, or fonts that reflow the layout. CLS is a unitless score.

Rating	Threshold
Good	≤ 0.1
Needs improvement	0.1 – 0.25
Poor	> 0.25

Supporting Metrics

Hoppla also records two diagnostic metrics that help explain the headline numbers:

• First Contentful Paint (FCP) — when the first piece of content appears (good ≤ 1.8 s).
• Time to First Byte (TTFB) — how long the server takes to send the first byte of the response (good ≤ 0.8 s). A slow TTFB often drags LCP down with it.

Configuration

Setting	Default	Description
Check interval	24 hours	CrUX data updates slowly, so once a day is plenty.

Results

Each check records:

• Status — ok or warning
• LCP, INP, CLS — the p75 field value and rating for each Core Web Vital
• FCP, TTFB — supporting diagnostic metrics
• Data availability — whether CrUX has enough real-user samples for your site

Alerts

Core Web Vitals is advisory, so it never opens an incident.

Event	When
warning.degraded_performance	One or more Core Web Vitals fell into the poor range
warning.cleared	Metrics have recovered

Tips

• Don't worry if there's no data at first — CrUX needs real traffic to build up. Smaller sites may never get field data; lean on Lighthouse instead.
• Watch TTFB — a slow server response makes good LCP almost impossible. Fix it first.
• Reserve space for images and ads to keep CLS low.
• Compare against Lighthouse — if lab scores are good but field scores are poor, the problem is something your real visitors hit (slow networks, older devices) that a clean lab run doesn't.