Web Vitals From Real Visitors: What to Measure and What to Fix

Page speed arguments often end with someone running a test on their own laptop and reporting that the site feels fine. It might, on a fast machine, on office wifi, in a warm cache. Your visitors are on something else.

Core Web Vitals exist to measure the experience real people have. This post covers what each metric means, why field data from real visitors differs from lab tests, how to read percentiles, and a sensible order for fixing things.

Lab data and field data

Lab data comes from a controlled test: a tool loads your page with a fixed device and network profile and reports numbers. It's repeatable, which is great for debugging. It's also a single scenario that nobody actually lives in.

Field data comes from real visits. Each visitor's browser reports how long things took for them. You get the whole spread: slow phones, flaky connections, ad blockers, far-away users.

You need both, for different reasons. Field data tells you whether you have a problem and for whom. Lab data helps you find why and check your fix quickly. OnyxMetric's Performance tab is field data: it collects Web Vitals from real sessions once you enable Web Vitals in your site settings.

The five metrics

OnyxMetric reports five. Three are the Core Web Vitals; two are supporting.

Largest Contentful Paint (LCP). How long until the biggest visible element, usually a hero image or headline block, appears. Good is under 2.5 seconds. Over 4 seconds is poor.

Interaction to Next Paint (INP). How quickly the page responds when someone taps or clicks. Good is under 200 milliseconds. Over 500 is poor. This replaced an older input metric and is more demanding, because it looks at interactions across the visit rather than only the first.

Cumulative Layout Shift (CLS). How much content jumps around while loading. Good is under 0.1. Over 0.25 is poor. It is the metric behind the experience of tapping a button just as an ad pushes it down.

First Contentful Paint (FCP). When the first piece of content appears. Good is under 1.8 seconds. It's a useful early signal for slow servers or render-blocking resources.

Time to First Byte (TTFB). How long until the server starts responding. Good is under 800 milliseconds. A bad TTFB caps every other metric, because nothing can paint before bytes arrive.

Why the 75th percentile

Averages mislead for speed data. A handful of very fast loads can hide a long tail of slow ones, and the slow ones are the visitors who leave.

Percentiles fix this. The p75 value is the number that 75 percent of visits beat. If your p75 LCP is 2.4 seconds, three out of four visitors had an LCP of 2.4 seconds or better. This is the percentile commonly used to judge Core Web Vitals, because it pays attention to the slow quarter without being dominated by extreme outliers.

OnyxMetric lets you switch between p50, p75, p90 and p99. Use them like this:

• p50 shows the typical visit.
• p75 is your report card.
• p90 and p99 show how bad the worst experiences get. Large gaps between p75 and p99 usually mean some device class or region is suffering.

Break it down before you fix it

An overall number rarely tells you where to start. The breakdowns do:

• By page. One heavy template often accounts for most of the poor results. Fix the worst page that gets real traffic, not the worst page overall.
• By device. If mobile LCP is 4 seconds and desktop is 1.8, you have a mobile problem: image sizes, JavaScript cost, or both.
• By browser. A spike in one browser usually points to a compatibility bug rather than a general slowdown.
• By country. High TTFB in distant regions suggests missing edge caching or a single-region origin.

Each metric also shows its change from the previous period, so a regression after a release shows up without you having to remember last month's numbers.

A fix order that tends to work

Work from the top of the page load downward, because earlier problems cause later ones.

1. TTFB first. If the server is slow, nothing else you do will fully help. Look at caching, database queries on the critical path, and whether pages can be served from a CDN.
2. LCP next. Identify what the largest element is on your slowest page. If it's an image, serve properly sized, modern formats and avoid lazy-loading it. If it's text, check that fonts and CSS are not blocking the render.
3. CLS. Reserve space for images, embeds and ads with explicit dimensions. Avoid inserting content above existing content after load. Fonts that swap late also cause shifts.
4. INP. Look for long JavaScript tasks. Heavy third-party scripts, large hydration costs and expensive event handlers are the usual causes. Break up long tasks and defer what is not needed for the first interaction.

Connect speed to outcomes

Performance work competes with other work for time, so tie it to results. Compare conversion on fast sessions with slow ones. Check whether your worst-performing page is also a high-exit page. Look at whether a funnel step with a big drop also has poor INP. If the answer is yes, the speed fix has an outcome you can measure. If no, maybe the problem is elsewhere.

Error tracking helps here too. A page that feels slow can in fact be failing: a script throws, the interaction hangs, the user gives up. Check the errors for the same page before you spend a week on image formats.

Traps

• Fixing the lab score and not the field score. A green lab run on a fast laptop doesn't mean visitors on mid-range phones are fine.
• Chasing a perfect number. Once you're in the good range at p75, returns diminish. Move to the next problem.
• Ignoring traffic mix. A campaign that brings many mobile visitors on slow networks will worsen your numbers without any change in your code.
• Judging a fix too early. Field data needs time and traffic to settle. Wait for a few days of visits before declaring a win.

Where to start tomorrow

Turn on Web Vitals for a site if you haven't. Wait a few days. Set the percentile to p75. Sort by page, find the worst page with meaningful traffic, check its device breakdown, and fix the highest-ranked cause on the list above. Then look again next week. Small, measured fixes beat a big performance project that never ships.