Web Vitals & RUM

Speed insights on managed.dev come from real-user monitoring (RUM) — the page load times your actual visitors experience, not a synthetic probe in a lab. Every environment collects them automatically, so you see how production feels to people on real devices and networks, and how a branch compares before you ship it.

What’s measured

managed.dev tracks the Core Web Vitals plus request-side latency:

• LCP (Largest Contentful Paint) — when the main content becomes visible.
• CLS (Cumulative Layout Shift) — how much the layout jumps as it loads.
• INP (Interaction to Next Paint) — how quickly the page responds to input.
• TTFB (Time to First Byte) — server-side responsiveness, where caching and the runtime do their work.
• p95 latency — the slow-tail server response time, reported alongside the median.

Read the p95, not just the average

A healthy-looking average hides slow outliers. If your mean response is 180 ms but p95 is 2.1 s, one visitor in twenty is having a bad time — often the uncached, logged-in, or cart-bearing requests that matter most. managed.dev surfaces p95 next to the median everywhere so the tail can’t hide behind it.

Reading the page

Open an environment in the dashboard and go to Insights → Performance. You get a trend over your selected window plus a per-page table, so you can sort by the worst offenders rather than guessing.

The Insights → Performance view for a production environment, showing a Core Web Vitals summary (LCP, CLS, INP) with good/needs-improvement/poor bands, a p95-vs-median latency trend line, and a per-page table sorted by slowest p95.

A useful way to work through it:

1. Start with the vitals summary to see whether LCP, CLS, and INP sit in the good band overall.
2. Switch to the per-page breakdown and sort by p95. A single slow template often drags the whole site’s numbers down.
3. Pick the worst page and open its traces to see where the time goes — a slow database query, an uncached fragment, a third-party call. See Traces.

Catching regressions before they ship

This is where first-class environments pay off. Because a preview environment emits the same RUM data as production, you can compare them directly.

1. Push the branch — git push managed feature/new-hero provisions a preview environment with its own telemetry.
2. Drive some real traffic at the preview URL (your QA pass, a Lighthouse run, a shared review link).
3. Open the preview’s Performance tab and compare LCP and p95 against production for the same pages.
4. If the new hero image pushed LCP from the good band into the poor band, you see it on the branch — and fix it before promoting.

Note

RUM needs real page loads to populate, so a brand-new preview environment will look empty until it receives traffic. Run your QA pass first, then read the numbers.

Most TTFB regressions trace back to the runtime and cache layer rather than the front end. The FrankenPHP runtime, page cache, and persistent object cache are tuned to keep server response low — see the FrankenPHP runtime for how those fit together.

Next steps

TracesDrill from a slow page into the request that caused it.

The FrankenPHP runtimeThe application server and caches behind your TTFB.

Preview environmentsA live, fully-instrumented environment for every branch.