Single-Page App Shows Fast Tiers but Slow Users
A retail web app is a single-page application (SPA) with a JavaScript-heavy product page. Backend monitoring shows all APIs healthy: server response p95 is 200 ms and error rate is under 0.5%. But the support team reports the product page 'takes forever' for a subset of users, mostly on mobile networks in one region. The frontend team insists 'the backend is fast, so it's the users' phones.' Digital Experience Monitoring is being introduced. There is no synthetic monitoring yet, and the browser agent has just been deployed to a sample of real users. The product page loads roughly 40 API calls and several large images.
1. Backend is fast but users are slow. What does that tell you, and what would you instrument or examine with the browser/RUM data?
Read the worked answer
A fast backend only bounds one segment of the user's experience. Total page load = network (DNS, connect, TLS, transfer), front-end processing (JS parse/execute, rendering), and backend calls. If the backend is 200 ms but users wait many seconds, the time is in the browser/network layers, not the server.
With the browser agent (RUM), examine: page load / DOM-ready / fully-loaded timings, the waterfall of the ~40 API calls (are they serialized or parallel?), time-to-first-byte vs. render time, JS execution and long tasks, and resource timing for the large images. Segment by region and connection type to confirm the mobile/regional pattern. Look for a few slow API calls that gate rendering even though each is individually fast, and for render-blocking or oversized resources.
2. The RUM data shows the 40 API calls are issued mostly in sequence, and large images are not lazy-loaded. How do these interact with the mobile/regional pattern, and what would you prioritize?
Read the worked answer
Sequential calls add latency: 40 round-trips × per-call latency. On high-latency mobile networks, per-call latency (including connection setup) is much larger than on office Wi-Fi, so serialization is far more punishing for exactly the affected users - this explains the regional/mobile subset despite healthy server times. Un-lazy-loaded large images compete for bandwidth on constrained mobile links and delay meaningful paint.
Prioritize: (1) parallelize or batch the API calls and remove redundant ones; (2) lazy-load below-the-fold images and compress/resize the large ones; (3) reduce render-blocking JS. These target the network-bound segments the RUM data implicates, rather than the already-fast backend. Validate with RUM before/after on the affected segment.
3. The frontend team argues 'it's the users' phones.' How would you test that claim with the data available?
Read the worked answer
Segment RUM by device class, browser, connection type, and region. If slow experiences concentrate on low-bandwidth/high-latency connections regardless of device model, the problem is network/serialization, not phone capability. If they concentrate on specific old devices even on good networks, device/JS-execution is implicated. Also compare the same region on Wi-Fi vs. cellular: if cellular is dramatically worse while device mix is similar, the network path and chatty design are the driver. The decisive test is whether the slowdown tracks connection quality (fixable in the app) or device hardware (not fixable by the app). Then reproduce the serialized-call waterfall under throttled conditions to confirm.