Monitoring Core Web Vitals in production (without a separate RUM tool)
Lighthouse scores are lab numbers; your users live in the field. If you already ship a Sentry-compatible browser SDK for error tracking, you also have a Real User Monitoring pipeline — the SDK attaches Core Web Vitals to its page-load transactions. Here's what the vitals mean, what thresholds to hold yourself to, and how to read them in production.
The three (plus one) numbers that matter
| Vital | Measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | When the main content becomes visible | ≤ 2.5s | > 4.0s |
| INP — Interaction to Next Paint | How fast the page reacts to input | ≤ 200ms | > 500ms |
| CLS — Cumulative Layout Shift | How much the layout jumps around | ≤ 0.1 | > 0.25 |
| TTFB — Time To First Byte | Server + network time before anything renders | ≤ 800ms | > 1.8s |
Google evaluates these at the 75th percentile — your p75 user, not your average. A great median with a terrible tail still fails, which is exactly why lab tools can't replace field data: the tail lives on real devices and real networks.
You probably already collect them
The Sentry browser SDK's tracing integration measures Web Vitals automatically and attaches them to the pageload transaction as measurements. If that SDK points at jentry, the Performance page aggregates them per project — p75 per vital, colored against the Google thresholds, next to the transactions and errors from the same session.
import * as Sentry from '@sentry/browser';
Sentry.init({
dsn: 'https://<key>@jentry.app/<project>',
integrations: [Sentry.browserTracingIntegration()],
tracesSampleRate: 0.2, // vitals ride on sampled pageloads
});Reading vitals like an engineer, not a scorecard
- LCP regressions usually trace to the server (slow TTFB), a new hero image, or render-blocking scripts added by a marketing tag.
- INP spikes point at long tasks on the main thread — hydration storms, heavy event handlers, third-party widgets.
- CLS jumps are almost always images without dimensions, late-loading ads/banners, or fonts swapping.
- Segment before you optimize: a global p75 mixes desktop-on-fiber with mobile-on-3G. Filter by device/geo before concluding anything.
Wire vitals into the same workflow as errors
The advantage of vitals living in your error tracker instead of a separate RUM product: one project, one release timeline, one alert channel. When a deploy regresses LCP, you see it on the same release page that shows the deploy's new errors — and the suspect commit is already there.
Frequently asked questions
Do I need a separate RUM product to track Web Vitals?
Not if you already ship a Sentry-compatible browser SDK — its tracing integration reports LCP, INP, CLS, FCP and TTFB on page-load transactions, and jentry aggregates them per project at p75.
Why do my lab (Lighthouse) and field numbers disagree?
Lab runs use one synthetic device and network; field data is your real user distribution. Judge yourself on field p75 — that's also what Google's ranking signal uses.
What sample rate do I need?
Enough page-load transactions that your p75 is stable — for most sites 10–20% sampling is plenty. Raise it temporarily when debugging a specific regression.
Which vital should I fix first?
The one that's 'poor' at p75 for your highest-traffic segment. As a rule of thumb: TTFB improvements help LCP for free, so start server-side when both are bad.
Try jentry free
Hosted error tracking & performance monitoring. Works with your Sentry SDKs — send your first event in minutes.