← Back to Blog
Summarize in: ChatGPT Google AI Claude Perplexity

Core Web Vitals on Client Sites: How to Track Lab and Field Data

· · Drafted with AI, reviewed by Pavol Bincik · How we write

TL;DR

Core Web Vitals change whenever a plugin, theme or tag changes, so a launch-day audit goes stale. Lighthouse gives a repeatable lab measurement that shows a regression at the next run. CrUX shows what real Chrome users experienced, as a 28-day rolling average, so it reacts slowly in both directions. Google uses Core Web Vitals in ranking, but says relevance comes first. Track both on the pages that matter. An uptime check does neither: it measures how fast the server answers, not how the page renders.

Most client sites get one PageSpeed Insights run at launch, and nobody looks again. Then a plugin update adds a script, the client uploads a large hero image, marketing adds a chat widget through the tag manager. None of that trips an uptime alert, and all of it can slow the page down.

The three Core Web Vitals and their thresholds

  • Largest Contentful Paint (LCP): when the largest image or text block appears. Good: 2.5 seconds or less.
  • Interaction to Next Paint (INP): how quickly the page reacts to clicks, taps and key presses. Good: 200 milliseconds or less; poor: more than 500. INP replaced First Input Delay as a Core Web Vital on 12 March 2024.
  • Cumulative Layout Shift (CLS): how much the layout jumps while loading. Good: 0.1 or less.

A page meets a threshold when at least 75% of page loads do, measured separately for mobile and desktop.

How much they matter for rankings

Google states that its ranking systems use Core Web Vitals. It also says that Search still shows the most relevant page even when its page experience is poor, and that good results in its reports do not guarantee top positions. For a client site, that means speed will not rescue weak content, but a slow page gives away an advantage it did not need to lose.

Lab data and field data are different measurements

Lab data comes from Lighthouse, the engine behind PageSpeed Insights. It loads the page once in a controlled, simulated environment. That makes it repeatable, good for debugging and good for spotting a regression right after a change. It has limits:

  • It cannot measure INP, because nobody interacts with the page. Total Blocking Time (TBT) is a reasonable stand-in, but not a substitute.
  • Scores move between runs, for example with ads, A/B tests or network routing, so look at a trend, not a single number.
  • The performance score has three bands: 0 to 49 poor, 50 to 89 needs improvement, 90 to 100 good.

Field data comes from the Chrome UX Report (CrUX): real Chrome users who have opted in to usage statistics and history sync. It does not come from crawlers. Two properties matter:

  • It is a 28-day rolling average, updated daily. A regression shipped today shows up gradually over the next weeks, and a fix takes just as long to show.
  • A page needs enough Chrome traffic to have its own data. Without it, PageSpeed Insights falls back to the whole origin, and a small site may have no field data at all.

So lab data tells you quickly that something changed; field data tells you what visitors actually felt.

Why an uptime check does not help here

An uptime check measures how fast the server answers the request. It does not render the page, load images or run scripts, so it cannot see LCP, INP or CLS.

It does see one input: the server's response time. Time to First Byte comes before First Contentful Paint and LCP, so a server that gets slower drags everything after it. A good TTFB is 0.8 seconds or less. A rising response-time trend after a hosting change is worth a Lighthouse run.

What usually slows client sites down

These are the usual suspects, not measurements:

  • Plugin and theme updates that add scripts, styles or web fonts.
  • New tags in the tag manager: chat widgets, pixels, heatmaps.
  • Images and videos uploaded by the client at full size.
  • Sliders and page builders that load on every page.
  • Hosting changes: a cheaper plan, a new server, a missing cache.

A routine that keeps up

  1. Pick two or three pages per client: the home page and the pages that bring enquiries or sales.
  2. Record a baseline in PageSpeed Insights: the lab score, LCP, TBT and CLS, and the field data if there is any.
  3. Run Lighthouse again after every update, and on a schedule in between.
  4. Check field data once a month. Remember it trails changes by weeks.
  5. Go through the tag manager with the client every few months and remove what nobody uses.

How Baromio tracks this

  • Lighthouse on a schedule: switch on Monitor Page Speed on an HTTP or keyword monitor. Baromio runs Lighthouse through Google PageSpeed Insights (mobile) and records the performance score, LCP, FCP, TBT, CLS, Speed Index and page weight by resource type. Free: 1 URL, weekly. Pro (9 EUR a month): 5 URLs, daily. Business (29 EUR a month): 15 URLs, daily. History is kept 7, 30 or 90 days by plan.
  • Alerts: you are alerted when the score falls below 50, the Lighthouse "poor" band, and again only if it drops another 15 points. A recovery alert follows when the score is back at 50 or above and at least 15 points higher.
  • CrUX field data: for the same monitors, Baromio saves a CrUX snapshot every day for that exact URL, for phones, desktops and all devices together: p75 LCP, FCP, CLS, INP and TTFB, each with its good / needs improvement / poor split. If CrUX has no data for the URL, no snapshot is saved and the Page Speed tab says so; that is normal for low-traffic pages.
  • From an AI assistant: the same field data is available through Baromio's MCP server (get-crux-data).

Sources

We use cookies to understand how Baromio is used and improve the product. You can accept or decline analytics cookies at any time. Learn more