Mobile LCP field data conflicts with synthetic passes
A global retailer uses New Relic Browser on its React storefront and Synthetics scripted browsers from three cloud locations every 5 minutes. Mobile LCP p75 is 4.4 s on product pages and 2.3 s on category pages; desktop LCP p75 is 1.8 s. The synthetic product-page check reports LCP 2.0 s and passes its 3 s threshold. Analytics show 62% of mobile sessions are on 4G or slower, and 28% of product-page sessions load a third-party reviews widget that is not on category pages. Browser JS errors are flat, but AJAX calls to reviews.example.com have p95 3.1 s and fail 1.2%. A release freeze starts in 48 hours, and the team wants to add a synthetic alert only. Marketing says product pages are the revenue path. The observability lead must decide what to monitor and what to fix first.
1. Why can RUM show 4.4 s LCP while the synthetic check passes at 2.0 s? What does that imply about using synthetics as the primary performance gate?
Read the worked answer
The two data sources measure different populations. The synthetic check runs from cloud locations, probably on a fast network and desktop-like profile, without real user caching, consent state, device CPU, or the full third-party mix. RUM includes real mobile devices on 4G, slower CPUs, and the reviews widget on 28% of product sessions. A 2.0 s synthetic LCP is therefore consistent with a 4.4 s mobile field p75. Synthetics are still useful for availability, controlled regression, and catching a broken page from multiple regions, but they should not be the primary performance gate for field Core Web Vitals. Use Browser RUM as the source of truth for LCP by device, connection type, page, and geography. Use synthetics as a complement, and if you want synthetic performance to be meaningful, add mobile throttling and third-party blocking or allowlisting so the test approximates a real session. Adding only a synthetic alert would likely miss the mobile field problem that marketing cares about.
2. How would you isolate the reviews widget as a contributor without breaking the page? What Browser data and test would you use?
Read the worked answer
Start with segmentation, not a global change. Add a custom Browser attribute when the reviews widget loads, then compare LCP distributions for product-page sessions with and without the widget, controlling for device and connection type. Inspect session traces and resource timing for long tasks, main-thread contention, and requests to reviews.example.com. Query AJAX p95 and failure rate by page and widget state, and check JavaScript errors by browser. Correlation is not causation, so run a controlled test: feature-flag the widget off for a small percentage of product sessions, or run a synthetic product-page check with the domain blocked and another with it allowed. Compare LCP and long tasks between variants. If LCP improves only when the widget is deferred or blocked, the widget is a contributor. The safest first fix is often loading it after LCP or on interaction, not removing reviews. Keep a rollback path and monitor checkout and conversion paths, not just LCP.
3. What alerting and SLO structure would you put in place for the next release?
Read the worked answer
Separate field performance from availability. Define a Browser SLO for product pages based on the percentage of mobile sessions with LCP at or below 2.5 s, reported as p75 and as a good-session ratio. Alert on error-budget burn by device class and page group, not on a single p75 spike. Keep synthetic checks for page availability, login, and checkout flow, with a shorter window and a clear owner. Add a dependency alert for reviews.example.com AJAX failure rate and p95, but route it to the frontend team as a warning unless it affects the SLO. Before the release freeze, baseline the current LCP distribution and capture the widget-on versus widget-off comparison. After release, compare the same segments for 24-48 hours. If the SLO burns too fast, roll back the frontend change; if the synthetic stays green while the SLO burns, that is evidence the synthetic profile needs mobile throttling or a new flow step.