Tracking Web Vitals in Production with RUM

Your Lighthouse score is 98. Your homepage still feels slow to the prospect on a mid-tier Android phone in a conference hotel, and that prospect is the one you spent $400 to get there. Lab tests run on a clean machine with a fast connection tell you what could happen, not what is happening to the people filling out your demo form. The only way to close that gap is real user monitoring: instrumenting your live site to capture performance as your actual visitors experience it, then acting on what you find.

For a B2B marketing or RevOps leader, this is not an engineering vanity metric. Slow pages quietly tax every program you run. Paid traffic bounces before it converts, organic rankings soften, and your highest-intent visitors get the worst experience because they are the ones loading heavy, script-laden landing pages from the road. This article covers how to set up real user monitoring for Core Web Vitals, how to read the data, and how to turn it into a prioritized fix list.

Why Lab Data Lies (and Field Data Doesn’t)

Synthetic testing tools like Lighthouse and PageSpeed Insights run in a controlled environment. That control is exactly the problem. They use one device profile, one throttled connection, and a cold cache. Your audience is a distribution: a director on corporate fiber, a buyer on hotel wifi, a contractor tethering off a phone in a parking lot.

Field data, collected through real user monitoring, captures that distribution. It tells you the difference between your median visitor and your unlucky 25th percentile, which is usually where the conversion damage lives. Two metrics in particular only make sense in the field:

• Interaction to Next Paint (INP) measures how quickly your page responds when someone clicks, taps, or types. You cannot meaningfully measure responsiveness without real interactions, and lab tools fake them.
• Cumulative Layout Shift (CLS) in the field captures shifts triggered by real scroll behavior, late-loading ad slots, and embedded widgets that a synthetic run often never reaches.

Lab data tells you whether a page can be fast. Field data tells you whether it is fast for the people who pay you. Optimize against the field.

If you want the engineering-side companion to this measurement work, our Core Web Vitals optimization playbook walks through the specific fixes once RUM has told you where to dig.

What Real User Monitoring Actually Captures

A RUM setup collects performance metrics from the browser of every real visitor and ships them somewhere you can query. At minimum, you want the three Core Web Vitals plus a couple of supporting signals:

1. Largest Contentful Paint (LCP): when the main content becomes visible. Targets under 2.5 seconds at the 75th percentile.
2. Interaction to Next Paint (INP): responsiveness to user input. Targets under 200 milliseconds at the 75th percentile.
3. Cumulative Layout Shift (CLS): visual stability. Targets under 0.1 at the 75th percentile.
4. Time to First Byte (TTFB): how fast your server or CDN responds. A useful early-warning signal that often explains a bad LCP.
5. First Contentful Paint (FCP): the first pixel of content, helpful for diagnosing whether a slow LCP is a rendering or a loading problem.

The key discipline is to track the 75th percentile, segmented by dimension, not the average. Averages hide your worst experiences. A page can show a healthy average LCP while a quarter of your mobile visitors wait five seconds.

Segment or you’re flying blind

Raw site-wide numbers are nearly useless for prioritization. Capture and slice every metric by:

• Device type (mobile versus desktop) — almost always your biggest split
• Page template (homepage, pricing, blog post, demo form) so you know which pages to fix
• Geography and connection where your buyers actually are
• Traffic source, so you can correlate slow paid landing pages with wasted spend

That last cut is the one that gets a RevOps leader’s attention. When you can show that your LinkedIn campaign lands on a template with a 4-second LCP at the 75th percentile, the conversation about page performance stops being abstract.

Choosing a Real User Monitoring Approach

You have three practical paths, in rough order of effort and depth.

1. Free field data from CrUX

The Chrome User Experience Report aggregates field data from real Chrome users and powers the “field data” section of PageSpeed Insights and Search Console’s Core Web Vitals report. It costs nothing and reflects what Google uses for ranking signals. The tradeoffs: it is limited to Chrome, it lags by roughly a month, it only covers pages with enough traffic, and you cannot segment by your own dimensions like traffic source. Use it as your baseline and your sanity check against Google’s own view.

2. The web-vitals library plus your analytics

Google maintains a small open-source web-vitals JavaScript library that measures all the Core Web Vitals in the browser. You wire it up to send each metric as an event into the analytics platform you already run, then build a dashboard on top. This is the sweet spot for most B2B teams: you get full segmentation by your own attributes, it covers all browsers, and it reuses tooling you already pay for. The cost is modest engineering setup and a little dashboard work.

3. A dedicated RUM product

Commercial tools give you waterfalls, session traces, and alerting out of the box, with deeper diagnostics for finding the specific element causing a layout shift or the script blocking an interaction. They cost more and add another vendor, but for a high-traffic site where performance directly drives revenue, the diagnostic depth pays for itself.

For most B2B sites, start with CrUX for the free baseline, then add the web-vitals library so you can segment. Graduate to a dedicated product only when you have proven the revenue case and need element-level diagnostics. If you’d rather not stand this up yourself, it’s the kind of instrumentation we build as part of our marketing-infrastructure engagements.

A Setup You Can Ship This Quarter

Here is a sequence that gets a working real user monitoring pipeline live without a multi-month project.

1. Establish the baseline. Pull your current Core Web Vitals from Search Console and PageSpeed Insights for your top ten templates. Write down the 75th-percentile numbers. This is your before.
2. Instrument with web-vitals. Add the library and send each metric to your analytics tool as it fires. Attach your key dimensions to every event: page template, device, and traffic source.
3. Sample sensibly. High-traffic sites do not need every single page view. Sampling a fraction keeps event volume and cost reasonable while preserving statistical signal.
4. Build the percentile dashboard. One table: rows are page templates, columns are the three vitals at the 75th percentile, split by mobile and desktop. Color the cells that miss target.
5. Set a regression alert. Trigger a notification when any template’s 75th-percentile LCP or INP crosses its threshold. This catches the marketing tag or hero image someone shipped on Friday before it costs you a month of conversions.
6. Review monthly with marketing in the room. Performance decays. New campaigns add scripts, new pages ship heavy. Make it a standing agenda item, not a one-time cleanup.

The architecture you start from matters here. Sites built on bloated, render-blocking stacks make every one of these numbers harder to move. We cover the structural side of this in the B2B website architecture that converts, and we explain our default tooling choice in why we build B2B sites on Astro — a lighter foundation means you spend less time fighting your own framework for every millisecond.

Turning Numbers Into a Fix List

Data you don’t act on is just expensive trivia. Once your dashboard is live, prioritize with a simple two-axis rule: fix the templates that are both high-traffic and failing target, starting with the metric that is furthest over threshold on your most-visited mobile template.

Map the common offenders to their usual causes so your engineering conversation is specific:

• Bad LCP usually traces to an unoptimized hero image, a slow server response (check TTFB first), or render-blocking scripts and fonts.
• Bad INP usually means heavy JavaScript on the main thread — frequently third-party marketing tags, chat widgets, and tag-manager bloat. This is often a place where marketing and engineering have to negotiate.
• Bad CLS usually comes from images and ad slots without reserved dimensions, or fonts that swap and reflow the page.

In our engagements, the single highest-leverage move is typically auditing third-party tags. Marketing teams accumulate them over years, and each one runs JavaScript that degrades INP for every visitor. Removing a few unused tags often improves responsiveness more than any code change the engineering team can make.

The Closing Loop

Real user monitoring is not a project you finish. It is a feedback loop you keep running: measure the field, segment to find the worst real experiences, fix the highest-traffic failures, and watch for regressions as new campaigns ship. Done well, it turns performance from a quarterly fire drill into a quiet, compounding advantage — faster pages, lower bounce on paid traffic, and a better experience for exactly the high-intent buyers who would otherwise get the worst of your site.

If you want a team that can stand up the instrumentation, read the field data, and ship the fixes that actually move conversions, let’s talk. We build this kind of measurement and performance work into the marketing infrastructure we deliver, so the numbers don’t just get tracked — they get better.