Why real user monitoring without Core Web Vitals is misleading
Server metrics and lab runs answer the question “is the service working,” not “how does a person experience it.” Processing queue, application response time, and error rate stay normal while a page on a phone takes several seconds to assemble because of a heavy set of scripts and third-party embeds. A synthetic run from a fast test bench in one region will not see this difference.
Real user monitoring without Core Web Vitals produces a stream of raw measurements from which it is hard to derive a decision.
The median load time looks even because fast visits pull it up, while the slow tail on a specific device model or network does not make it into the median. The numbers are there, but where exactly the user loses patience is not visible.
Thus a whole class of failures falls out: the interface responds, requests go through, but the share of users reaching the target action drops. The cause is a layout shift after a banner loads, a late response to a tap, or a blocking third-party script.
Neither a server emergency alert nor a lab run shows this: they lack real traffic and client diversity.
The combination of real user monitoring and Core Web Vitals closes the gap: frontend metrics are collected from real sessions, broken down by page type, device, and geography, and metric alerting reacts to tail degradation, not average.
Below is how to set up collection and thresholds so that this becomes an actionable signal rather than another monitoring dashboard.
What collecting metrics from real user sessions provides
Complaints about “it’s slow” appear when the problem has already grown, while checks on a fast machine show normal the whole time.
The reason is the gap: synthetic runs come from one node, while visitors come from hundreds of device models, different networks, and under peak load.
Collecting metrics from users, or real user monitoring, closes this gap: each guest’s browser sends field values Core Web Vitals — main content render time, interaction responsiveness, layout shifts — tied to page, device, region, and release version.
Hence the speed of detecting degradation. Degradation alerts are configured based on percentile shifts, not averages: if the 75th percentile for rendering drops after a rollout, the on-call engineer gets a signal in the first minutes, not a week later from complaints. The average may stay normal — fast sessions pull it up, so it is not used as a reference.
Then a whole class of “it opens for us but not for the client” incidents goes away: the debate about reproducibility is replaced by data for a specific group of devices and networks.
A single health metric appears — the share of slow sessions, which development, operations, and product read the same way. On the performance dashboard it is broken down by release, device type, and geography, so it is clear which rollout worsened the picture and for whom.
The result for web application monitoring is that regressions are caught before complaints, not after. We’ll break down how collection is deployed and where alert thresholds are set.
Data collection options: agent, synthetic, hybrid mode
The method of telemetry collection determines which failures you will see at all. An agent in the browser records real sessions: LCP, INP, CLS, and errors come from live users — with their network, devices, and extensions.
Synthetic checks run from fixed points and provide a baseline: degradation is visible from them, but how people behave on a weak connection is not.
Metric instrumentation matters more here than the source itself. If the same names from the agent and from synthetic checks are not given common dimensions, the series do not align and comparison falls apart into two unrelated charts.
Hybrid monitoring brings the streams into a common panel, while server logs cover what the browser does not see: backend response time, error codes, request queues.
| Option | When it fits | Limitations |
|---|---|---|
| Browser agent | Live traffic, important to see Core Web Vitals on real devices and real networks | Ad blockers and consent refusals cut out part of the sample; without server context the cause of a failure is not visible |
| Synthetic checks | Critical scenarios — login, payment, search: need a reproducible baseline and availability control | Do not reflect the profile of real devices; test only pre-described steps |
| Hybrid monitoring | Mature product: need to link a user complaint with backend degradation | Requires unified metric instrumentation and naming discipline; harder to maintain |
| Server logs | Root cause diagnostics: backend bottlenecks, integration errors | Say nothing about what happened in the browser before the request |
In practice, the modes do not compete: we choose the leading one for the task and add the second where a blind spot hinders incident investigation. We bring everything into Grafana — one panel instead of three tabs, and alerting triggers on degradation, not on a random spike.
Implementation stages: from page inventory to runbooks
Implementing real user monitoring (RUM) starts not with a dashboard of charts but with an inventory: which page templates carry the load, which scenarios lead to the goal, and where Core Web Vitals degrade on real devices.
Then we structure the work so that by the first alert, thresholds, routing, and a response runbook are already ready.
-
Inventory of pages and scenarios. We compile a list of templates, entry points, and critical transitions, noting where metrics are captured by standard instrumentation and where separate measurements of key block speed are needed.
-
Collection schema. We define dimensions for analysis: device type, region, connection channel, client-side version. This separates degradation for all users from a problem in one segment.
-
Alert thresholds. We calculate by percentiles, not averages — the average hides slow sessions. For each metric we fix an observation window so that a short spike does not wake up the whole team.
-
Alert deduplication. We collapse signals from one incident by page template, failure type, and time: otherwise one instrumentation mistake produces hundreds of alarms, and monitoring stops being read.
-
Routing. Critical signals go to the on-call shift, quality metrics go to scheduled review, infrastructure ones go to the relevant engineers.
-
Validation on real traffic. We observe for the first weeks, compare readings with external sources, run training alarms, and remove false positives.
-
Handover. We hand over the collection schema, configured thresholds, routes, and incident investigation instructions — the monitoring lives on without us.
Collection configurations, dashboards, and response runbooks
Every collection rule and every alert remains with you as a working artifact, not a verbal agreement. We hand over the kit below upon completion of real user monitoring setup — it is enough to maintain and evolve monitoring with your own team.
- Collection configurations: sampling rate, metric list, breakdown by routes and device types — with an explanation of why the thresholds were chosen this way.
- Dashboards: Core Web Vitals summary by page and user group, separate panels for mobile traffic; each with a label showing the norm and owner.
- Access policies: observer, on-call, and administrator roles, notification recipient list, rights to change thresholds; keys are stored in your secrets vault.
- Response runbook: at what deviation who is paged and within what time, what is recorded in the investigation, when the alert returns to observation mode.
- Monitoring documentation: data path diagram from browser to panel, metric dictionary, procedure for connecting new pages, and a check that the sensor is alive.
- Procedure for rolling back configuration to the previous version and investigating false positives so that edits do not lose history.
- Threshold change log and a rule for reviewing them — alerts do not become background noise and remain meaningful after launch.
Handing the solution over to the team consists of two training sessions, one for on-call staff and one for developers, and a control period when we are available and answer operational questions.
Online store case study: share of slow sessions dropped threefold
Before the project, the frontend was checked with synthetic measurements from one point: a script opened the home page and returned a steady result.
The real picture differed from it — the share of slow sessions during peak hours stayed around 21%, and this was learned from support requests several hours after degradation began.
What measurement on live sessions showed
Measurement on real sessions (real user monitoring) was broken down by page type, device, region, and release number.
The main contribution came from product cards on mobile: main content render speed there was three times worse than on desktop, and the layout shift on the listing occurred when banners loaded.
Some degradations arrived with a release and lived until the next one — there was no way to compare versions with each other.
What was changed
Metric collection was tied to the release and page, budgets were set at the 75th percentile separately for mobile, and alert rules were configured in Grafana with a 15-minute window: a short spike does not wake the on-call engineer, a sustained deviation raises an incident.
Third-party scripts were moved outside the critical rendering path, and the product card stopped blocking content with recommendation blocks.
The share of slow sessions decreased from 21% to 7% — threefold, and incident response time dropped from several hours to 10–15 minutes. The metric stopped being a checkbox report: a regression is visible at rollout and rolled back before customers notice it.
How does real user monitoring differ from synthetic checks?
Synthetic checks are a script that on a schedule walks through a scenario from external points: login, search, checkout. The conditions are identical — a fixed browser profile, a specified connection channel, a clean cache.
Therefore the result is reproducible and suitable as a baseline: a deviation from the baseline almost always means a failure in the application, not in the environment.
Field metrics are taken from real sessions and answer a different question — how users experience it.
The spread across devices, carriers, and regions is so large that average values are useless: decisions are made using the 75th and 95th percentile of rendering delay and input responsiveness.
Comparison of approaches is conveniently summarized in one table:
| Approach | What it shows | Where it is indispensable | Limitations |
|---|---|---|---|
| Synthetic checks, lab metrics | Scenario response time from external points | Availability, confirmation of recovery after a failure, regions without traffic | Only pre-described scenarios and a “clean” environment |
| Field metrics | Distribution of metrics across real sessions | Prioritizing optimizations, drops on slow devices | No reproducibility, requires traffic volume |
| Hybrid | Synthetic run in a real browser | Complaint investigation: user steps and page state | Storage of recordings and user consent |
The failure points differ between approaches. Synthetic checks do not know about a scenario that was not described, while field data without instrumentation does not show which specific request consumed the time.
Therefore the report includes both the distribution by page and a breakdown by load stages, and investigation is conducted on a sample of sessions with preserved context.
In the on-call circuit, the roles diverge even more. Synthetic checks give a binary signal and trigger instantly — availability alerting relies on them.
For field metrics, the threshold is set by a sliding window and the share of affected sessions: otherwise one user on a bad network raises an alarm for the whole team.
Technical concerns before launching metric collection
Before launching collection of metrics from real users, an engineering team usually has four objections: site speed degradation, code changes, noise from bots and outliers, and security team questions about data. Let’s break down how each is addressed by configuration, not promises.
Will metric collection slow down the site itself?
The beacon is sent asynchronously, outside the critical rendering path, so it does not affect visit metrics. The payload is tens of bytes, sent after the load event or on page exit. If the send fails, one metric is lost, and the page keeps working.
Are changes to the application code needed?
Basic collection is connected with one tag; access to the build is not required, and the release cycle does not shift. For single-page applications, instrumentation of transitions between virtual pages is added — otherwise metrics will merge into one address. This is at the template level; business logic is not affected.
How do you filter bots and outliers in metrics?
We filter out bots by a combination of signals: client headers, absence of interaction events, even crawl intervals. Sessions with zero time and background tabs are flagged so they do not spoil the distribution.
We look at percentiles: the working reference is p75, the tail is p95; we do not use the average, as isolated anomalies pull it up.
What about data and storage requirements?
We collect anonymized measurements: without field contents or identifiers in clear text. Retention period and region are set by policy, and consent for analytics is linked to the banner. This is sufficient for a security team review.
Let’s discuss the task: what to send and how we’ll start work
To come back with an implementation estimate rather than clarifying questions, we need a minimum of inputs. Below are the things that noticeably speed up the start: the team usually already has some of these, and we reconstruct the rest on a short call.
- List of key pages and scenarios — checkout, catalog, payment: we collect real user monitoring metrics for them first, not “for the whole site.”
- Target metric thresholds: main content render speed, tap responsiveness, visual stability. It is enough to formulate the business requirement (“the share of sessions meeting it should be no lower than a given value”); we will select the exact values together.
- What is already configured: synthetic checks, lab measurements, analytics counters — so as not to duplicate collection or conflict with existing reports.
- Access: read access to the monitoring and analytics account, a test environment for validating instrumentation, and a contact for the frontend owner.
- Alerting and on-call channels: where the degradation signal arrives (messenger, email, on-call system) and who responds to it during and outside working hours.
- Dimensions important for investigation: devices, browsers, regions, connection type — they determine where to look for the cause of degradation.
- Calendar of rollouts and major frontend changes — to distinguish release regression from background network noise.
If something from the list is missing, come with what you have: we will gather the missing inputs together, and set up the first measurements in a test environment.
Describe the task — we will come back with an implementation estimate and a work plan, with owners and stage deadlines.