# RUM Monitoring Real User Monitoring (RUM) collects performance data from actual visitors to your website. Unlike synthetic tests that run in controlled environments, RUM shows you how real users experience your site across different devices, networks, and locations. ## What is RUM? [#what-is-rum] RUM captures browser-based metrics as users interact with your website: * **Performance metrics** from the browser's Performance API * **Core Web Vitals** as defined by Google * **User engagement** like scroll depth and time on page * **JavaScript errors** that affect user experience ## Core Web Vitals [#core-web-vitals] VitalSentinel tracks all Core Web Vitals metrics: ### LCP (Largest Contentful Paint) [#lcp-largest-contentful-paint] Measures loading performance - how quickly the largest visible element loads. | Rating | Threshold | | ----------------- | ----------------- | | Good | ≤ 2.5 seconds | | Needs Improvement | 2.5 - 4.0 seconds | | Poor | > 4.0 seconds | **Common causes of poor LCP:** * Slow server response times * Render-blocking JavaScript/CSS * Large images without optimization * Client-side rendering delays ### CLS (Cumulative Layout Shift) [#cls-cumulative-layout-shift] Measures visual stability - how much the page layout shifts unexpectedly. | Rating | Threshold | | ----------------- | ---------- | | Good | ≤ 0.1 | | Needs Improvement | 0.1 - 0.25 | | Poor | > 0.25 | **Common causes of poor CLS:** * Images without dimensions * Ads or embeds without reserved space * Dynamically injected content * Web fonts causing text shift ### INP (Interaction to Next Paint) [#inp-interaction-to-next-paint] Measures responsiveness - how quickly the page responds to user interactions. | Rating | Threshold | | ----------------- | ------------ | | Good | ≤ 200 ms | | Needs Improvement | 200 - 500 ms | | Poor | > 500 ms | **Common causes of poor INP:** * Long JavaScript tasks blocking the main thread * Heavy event handlers * Large DOM size * Third-party scripts ### TTFB (Time to First Byte) [#ttfb-time-to-first-byte] Measures server responsiveness - time from request to first byte of response. | Rating | Threshold | | ----------------- | ------------- | | Good | ≤ 800 ms | | Needs Improvement | 800 - 1800 ms | | Poor | > 1800 ms | **Common causes of poor TTFB:** * Slow server processing * No CDN or caching * Database query delays * Geographic distance to server ### FCP (First Contentful Paint) [#fcp-first-contentful-paint] Measures initial render - when the first content appears on screen. | Rating | Threshold | | ----------------- | ----------------- | | Good | ≤ 1.8 seconds | | Needs Improvement | 1.8 - 3.0 seconds | | Poor | > 3.0 seconds | ## Using the RUM Dashboard [#using-the-rum-dashboard] The RUM section in your domain has nine views: | Page | What it shows | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | | **Overview** | All Core Web Vitals at a glance, with trends, a geographic performance map, and a per-page table | | **LCP** | Dedicated Largest Contentful Paint analysis with a table of the slowest LCP resource URLs | | **INP** | Interaction to Next Paint with input-delay / processing / presentation subparts | | **CLS** | Cumulative Layout Shift with **Above the Fold** vs. **Below the Fold** toggle | | **TTFB** | Time to First Byte with per-page and per-country breakdown | | **FCP** | First Contentful Paint with per-page and per-country breakdown | | **[Errors](/features/error-tracking)** | JavaScript, resource, and unhandled-promise-rejection errors, as individual events or grouped by type | | **[Engagement](/features/engagement-analytics)** | Engagement metrics correlated with performance | | **Page Views** | Individual page-view sessions, each with its Core Web Vitals, device, browser, and country | ### Overview [#overview] The RUM overview shows every Core Web Vital in one place: * A metric card per Web Vital (LCP, INP, CLS, FCP, TTFB) with the P75 readout, a green/amber/red status, and a distribution bar * A trend chart you can flip between metrics * A geographic performance map showing Core Web Vitals by country * A per-page table ranking pages by their Web Vital scores If RUM isn't installed yet, the page surfaces the install instructions instead of empty charts. ### Filters [#filters] All metric pages share the same filter strip: * **Date range** – pick any window, with an optional [compare-to-previous-period](#compare-to-a-previous-period) toggle * **Device** – Mobile / Desktop * **Advanced filter modal** – narrow by URL path, country, or browser using contains / equals / regex / batch operators (and their negations); multiple filters can be stacked ### Percentile Values [#percentile-values] VitalSentinel displays the **75th percentile (P75)** value for each metric. This means 75% of your users experience this value or better. The P75 is the industry standard for Core Web Vitals assessment and is what Google uses for search ranking evaluation. ### Per-Metric Pages [#per-metric-pages] Each Core Web Vital has its own dedicated page with: * **Metric card** – current P75 with status color and distribution bar * **Trend chart** – line + bar combo showing the P75 trend * **Geographic performance map** – same metric broken down by country * **Pages table** – pages ranked by the metric, worst first * **Metric-specific breakdown** – for example, LCP adds a table of the slowest LCP resource URLs; INP shows input-delay / processing / presentation subparts plus a script-domains table; CLS adds an Above-the-Fold / Below-the-Fold toggle ### Compare to a previous period [#compare-to-a-previous-period] Every RUM page can compare the selected window against an earlier one. Turn on the **compare** toggle in the date-range picker and choose a previous period. When comparison is active: * Metric cards and summary tiles show a **delta badge** with the change versus the previous period, colored by whether the metric improved or regressed. * Trend and breakdown charts overlay the previous period as a **dashed line**. * Per-page tables, the engagement correlation, LCP resources, and the INP breakdown all gain previous-period values for side-by-side comparison. Comparison is available on the Overview, every per-metric page, Engagement, and Errors. ## Engagement, Errors, and Page Views [#engagement-errors-and-page-views] The RUM section also includes three non-vitals views: * **[Engagement](/features/engagement-analytics)** – correlations between performance and engagement (scroll depth, bounce rate, rage clicks, clicks per session, time on page, and more). * **[Errors](/features/error-tracking)** – JavaScript, resource, and unhandled-promise-rejection errors, viewable as individual events or grouped by type, with browser / OS / device filters. * **Page Views** – a paginated list of individual page-view sessions, each showing its Core Web Vitals (LCP, INP, CLS, FCP, TTFB), device, browser, country, and an expandable resource waterfall. ## Data Interpretation [#data-interpretation] ### Sample Rate [#sample-rate] By default, 100% of visitors are tracked. For high-traffic sites, you can reduce this: * `data-sample-rate="0.5"` tracks 50% of visitors * `data-sample-rate="0.1"` tracks 10% of visitors Lower sample rates reduce data costs while maintaining statistical significance. ### Mobile vs Desktop [#mobile-vs-desktop] Core Web Vitals are measured separately for mobile and desktop: * Mobile devices typically have slower connections * Mobile CPUs are less powerful * Google uses mobile metrics for search ranking ### Geographic Variance [#geographic-variance] Performance varies by location due to: * Distance to servers * Network infrastructure quality * Device prevalence ## Best Practices [#best-practices] ### Improving LCP [#improving-lcp] 1. Optimize and compress images 2. Use a CDN for static assets 3. Preload critical resources 4. Minimize render-blocking resources ### Improving CLS [#improving-cls] 1. Always include width/height on images 2. Reserve space for ads and embeds 3. Avoid inserting content above existing content 4. Use CSS containment ### Improving INP [#improving-inp] 1. Break up long JavaScript tasks 2. Use web workers for heavy processing 3. Debounce input handlers 4. Minimize main thread work ### Improving TTFB [#improving-ttfb] 1. Use a CDN 2. Enable caching 3. Optimize database queries 4. Use HTTP/2 or HTTP/3 ## Related Features [#related-features] See how Chrome users experience your site Run on-demand Lighthouse tests Get notified when metrics degrade