Mobile Web Vitals Outlier: Synthetic Passes, Real Users Struggle
A travel company's booking single-page app serves 60% mobile users. Browser monitoring shows p75 Largest Contentful Paint of 2.3 s on desktop but 5.4 s on iOS Safari in Southeast Asia; Interaction to Next Paint is 380 ms. A scripted browser synthetic monitor running every five minutes from Singapore completes the hotel-search flow in 1.9 s and has not failed in 14 days. Support tickets describe a spinner that never resolves on hotel search, mostly from Android and iOS users on 4G. Last Thursday marketing added a tag-manager tag for a chat widget and an A/B testing tool. The Browser agent is deployed, session replay is available, and the team has not segmented page views by device, country, or connection type.
1. How do you reconcile the healthy synthetic result with the poor real-user data?
Read the worked answer
The two signals answer different questions. The synthetic monitor is a controlled availability check: one location, a fixed browser and viewport, a clean network path, and a scripted happy path. It can prove the flow works from a data center, but it does not represent a mid-range phone on a congested 4G connection, nor does it capture the long tail of real device and third-party behavior. Its 1.9 s completion time is not a contradiction of a 5.4 s p75 LCP.
RUM is the better signal for the user experience because it measures actual sessions. Before concluding anything, verify the segments: device type, browser version, country, and connection type. Check whether the synthetic monitor uses a desktop user agent or blocks third-party scripts, because either would make it unrepresentative. Also confirm the RUM sample size in the affected segment; a small sample can exaggerate p75.
The correct conclusion is not that one tool is wrong. It is that the synthetic monitor lacks the coverage needed to detect this class of regression, while RUM has detected it but lacks the diagnostic detail until it is segmented.
2. What data would you inspect next to find the cause of the stuck spinner?
Read the worked answer
Start with the page-view and interaction events for the affected segment, filtered to iOS Safari in Southeast Asia and Android on 4G. Compare LCP element timing and long tasks before and after last Thursday. Then examine AJAX and resource timing: a nine-second gap with no completed request often means a third-party script is blocking the main thread or a request is hanging until timeout.
Use session replay on a small sample of affected sessions to see whether the spinner is a UI state that never receives a response, and whether the page is visually blocked by the chat widget. Correlate with JavaScript errors and failed requests by domain. Break down third-party domains in resource timing to see whether the chat or A/B tool appears at the top of the slow list.
Do not stop at correlation. Compare sessions that loaded the new tag with sessions that did not, if the tag platform exposes that dimension. If it does not, temporarily disable one tag in a controlled test and measure LCP, INP, and spinner occurrence. Keep the synthetic monitor running throughout as a guardrail for hard failures.
3. What changes would you make to monitoring and tag governance after the incident?
Read the worked answer
Monitoring changes:
- Segment Browser dashboards by device, country, and connection type by default, and alert on p75 LCP and INP for mobile segments rather than only on aggregate page-load time.
- Add synthetic monitors with mobile device emulation and throttled network profiles from more than one region. Keep the existing desktop check, but stop treating it as coverage for mobile users.
- Create a browser alert on the rate of unresolved interactions or JavaScript errors by third-party domain.
Governance changes:
- Require performance review before new tag-manager tags ship, including async loading, timeouts, consent behavior, and a named owner.
- Set a performance budget for LCP and INP in the affected mobile segment, with a rollback rule if a tag pushes the segment over budget.
- Use session replay and RUM to quantify affected sessions and revenue, then give marketing that evidence rather than a generic request to remove tags. The goal is to keep the business capability while containing its runtime cost.