Core Web Vitals Monitoring: From Lab Data to Field Data

Every team has lived this scene: Lighthouse says 98, the boss's phone says the site is slow, and both are right. Lighthouse is a lab test — one synthetic load, simulated throttling, an empty cache, no real-world chaos. Your users are the field: mid-range Androids on hotel Wi-Fi, twelve open tabs, an ad blocker fighting your scripts. Core Web Vitals only matter as field data, because field data is what Google ranks you on and what your visitors actually feel.

The three vitals, in plain terms

• LCP (Largest Contentful Paint): when the main content becomes visible. Good: under 2.5 s. Driven by server speed, render-blocking resources, and image weight.
• CLS (Cumulative Layout Shift): how much the page jumps around. Good: under 0.1. Driven by images without dimensions, late-loading fonts — and, ironically, cookie consent banners.
• INP (Interaction to Next Paint): how fast the page responds to clicks and keystrokes. Good: under 200 ms. Driven by main-thread JavaScript — including heavyweight analytics and tag managers.

Why lab and field disagree

1. Lab tests one device profile; the field is a distribution. Your p75 mobile user does not own a MacBook.
2. Lab loads the page once, cold; the field includes returning visitors, slow caches, and third-party scripts that misbehave intermittently.
3. INP barely exists in the lab — it needs real interactions, which only real users provide.
4. The field has geography: your CDN's worst region is invisible from your office.

Google's ranking signal uses field data (CrUX, at p75). A perfect Lighthouse score with bad field vitals is decoration.

What continuous field monitoring looks like

The pieces you want from a real-user monitoring setup:

• Per-page, not per-site: vitals aggregated by URL, because /pricing and /blog have different problems.
• Percentiles, not averages: p75 is the standard; averages hide the slow tail where users churn.
• Trends over time: so the deploy that regressed LCP by 800 ms is visible the day it ships, not at the next quarterly audit.
• Joined to behavior: this is the step most setups miss. A vitals dashboard tells you INP is 450 ms; a vitals signal on the visitor journey tells you the user with 450 ms INP abandoned checkout. The second one gets fixed this sprint.

That join is Clycyo's angle: the same 1.1 KB tracker that counts pageviews records LCP, CLS, INP, and page-load time per visit, on the same visitor record as clicks, errors, and conversions. The connection between 'slow' and 'lost revenue' stops being an inference — it is visible per journey.

The tracker paradox

There is a special irony in monitoring performance with a tool that degrades it. A 100 KB analytics bundle adds main-thread work that worsens the very INP it reports. Whatever you choose for vitals monitoring, weigh the observer: at 1.1 KB, Clycyo's tracker is roughly 1% of the weight of a typical gtag + GTM stack (the tracker-tax breakdown is here).

A monitoring routine that takes 10 minutes a week

1. Monday: glance at p75 LCP/CLS/INP for your top five pages. Flag anything that moved more than 15%.
2. After each deploy: check the same numbers for the touched pages within 48 hours.
3. Monthly: sort pages by traffic × vitals badness; fix the top one. Compounding beats heroics.

Field data, percentiles, per-page, joined to outcomes — that is the whole discipline. Everything else is dashboard tourism.