---
title: Optimizing Performance
description: >-
  Use the RUM Optimization page to identify and troubleshoot browser performance
  issues with Core Web Vitals analysis and user experience visualization.
breadcrumbs: >-
  Docs > RUM & Session Replay > Application Monitoring > RUM Browser Monitoring
  > Optimizing Performance
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Optimizing Performance

## Overview{% #overview %}

{% video
   url="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/optimization-workflow.mp4" /%}

The Optimization page helps to identify the root cause of browser performance issues using real user traffic data. Troubleshoot the causes of slow pages using browser KPIs such as [Core Web Vitals](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance.md#event-timings-and-core-web-vitals) (CWV) and Datadog's custom [Loading Time](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance.md#how-loading-time-is-calculated) KPI, which evaluates full-page load time from the user's perspective.

For deeper analysis, the Optimization page provides granular breakdowns of Core Web Vitals by user demographics such as browser, region, and app version. You can use this information to track performance trends over time, understand which user groups are most affected, and prioritize optimizations with precision.

## Prerequisites{% #prerequisites %}

To optimize your application, ensure you are using:

- [RUM Browser SDK](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/setup.md) version 5.4.0 or newer
- [Session Replay](https://docs.datadoghq.com/session_replay.md) for at least some sessions

## Selecting a vital{% #selecting-a-vital %}

Navigate to the [Optimization page](https://app.datadoghq.com/rum/vitals), found under the [Digital Experience > Performance Monitoring](https://app.datadoghq.com/rum/performance-monitoring) tab.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/page-selectors.fd7679197d35927933fd590e04faa46d.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/page-selectors.fd7679197d35927933fd590e04faa46d.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="You can check the Optimization page for the top most visited pages or specific pages." /%}

From this view, there are two ways to select a page or vital:

- Choose from a treemap of the most visited pages
- Enter a view name in the input box and select the page

Available vitals include:

- **[Loading Time (LT)](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance.md#how-loading-time-is-calculated)**: Datadog's custom KPI that measures the time for a page to load from a user's perspective.
- **[Largest Contentful Paint (LCP)](https://web.dev/articles/lcp/)**: Measures how quickly the largest visual element on your page loads, which is a critical factor in both user experience and SEO rankings. A slow LCP can frustrate users, increase bounce rates, and hurt search visibility. The Optimization page breaks LCP down into subparts (Time to First Byte (TTFB), resource load delay, resource load time, render delay) so you can pinpoint which phase contributes most to the overall metric.
- **[First Contentful Paint (FCP)](https://web.dev/articles/fcp)**: Measures the time from when the user first navigated to the page to when any part of the page's content is rendered on the screen. A fast FCP helps reassure the user that something is happening.
- **[Cumulative Layout Shift (CLS)](https://web.dev/articles/cls/)**: Measures the largest burst of unexpected layout shifts that occur during a page's life cycle. A layout shift happens when a visible element moves from one rendered frame to the next without any user interaction, disrupting the visual stability of the page. An important KPI for measuring visual stability because it helps quantify how often users experience unexpected layout shifts. A low CLS helps ensure that the page is delightful.
- **[Interaction to Next Paint (INP)](https://web.dev/articles/inp/)**: Measures how long it takes for a page to visually respond after a user interacts with the page. The Optimization page breaks INP down into subparts (input delay, processing duration, presentation delay) so you can identify whether the bottleneck is main-thread contention, handler execution, or rendering.

## Filter and evaluate{% #filter-and-evaluate %}

After selecting a page and vital, analyze performance insights:

- Adjust the time frame in the top-right corner
- Use dropdowns to filter by attributes
- Select a group in Show Filter Breakdown
- Evaluate vitals at different percentiles

For instance, a pc75 evaluation represents the 75th percentile value, commonly used for CWV.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/filter-and-evaluate.650a2cf2ea4d75a88333834049f439d1.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/filter-and-evaluate.650a2cf2ea4d75a88333834049f439d1.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Filter and evaluate your vitals for the selected view." /%}

## Visualize the user's experience{% #visualize-the-users-experience %}

The next part of the page helps you visualize exactly what your users are experiencing.

Based on the selected time period and traffic, the Optimization page highlights the most typical example of what users see on the page when the selected vital is captured. If you use [Session Replay](https://docs.datadoghq.com/session_replay.md), this is where you see a visual of the page.

For some vitals, you can also select other versions of the page to investigate by clicking See a different element.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/vitals-visualize.307ae53096d94c61bc8aa836a1b8313d.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/vitals-visualize.307ae53096d94c61bc8aa836a1b8313d.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Select different elements to preview and visualize the user's experience." /%}

For Largest Contentful Paint and Interaction to Next Paint, the Optimization page also displays a breakdown of the metric into its individual phases. Use the breakdown to identify which phase contributes most to the overall metric and direct optimization work to the relevant phase. For details on each subpart, see [Diagnose Core Web Vitals with subparts](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance.md#diagnose-core-web-vitals-with-subparts).

## Troubleshoot resources and errors{% #troubleshoot-resources-and-errors %}

In the troubleshooting section, you can see resources and errors that users encountered on the page that may have affected the vital performance. For example, for Largest Contentful Paint (LCP), you can see resources that were loaded before the LCP was triggered. Since LCP is an indicator of how long the largest element takes to load on the page, you could investigate the following:

- Anything that happens before then could be causing slowness or rendering issues
- Resources that are particularly slow or large could be contributing to performance issues
- Recurring errors that could be causing problems

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/troubleshoot.21278685705cb943bd01f40eb246ec41.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/troubleshoot.21278685705cb943bd01f40eb246ec41.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="The Troubleshooting section shows resources and errors that users encountered on the page that might have affected the vital performance." /%}

## View event samples{% #view-event-samples %}

To see everything in context with the rest of the page activity, scroll down to the waterfall and timeline of events. The waterfall shows the event timeline up until the moment the vital was captured.

You can select another sample event using the dropdown in the top left, and expand any event in the waterfall by clicking it to see the side panel, as shown below.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/view-event-samples.601b4e140b706c5fbe9dbfd5bb200074.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/view-event-samples.601b4e140b706c5fbe9dbfd5bb200074.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="View event samples to see everything in context with the rest of the page activity." /%}

## Browser profiling within event samples{% #browser-profiling-within-event-samples %}

For deeper root cause analysis, use browser profiling alongside RUM to identify what JavaScript or rendering activity is causing slow or unresponsive experiences. Profiling reveals performance issues that aren't always visible through Core Web Vitals alone. To get started, [ensure that browser profiling is enabled in your RUM SDK configuration](https://docs.datadoghq.com/real_user_monitoring/correlate_with_other_telemetry/profiling.md).

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/browser_profiler.f3c90929d45047a8f0ab89034d64e50f.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/browser_profiler.f3c90929d45047a8f0ab89034d64e50f.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Browser profiling example when analyzing an event sample." /%}



## Lighthouse audits{% #lighthouse-audits %}

[Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) is an open source Google tool that grades your pages on categories such as performance, accessibility, best practices, SEO, and agentic browsing, so you can find and fix what slows down or frustrates users.

A [browser Synthetic test](https://docs.datadoghq.com/synthetics/browser_tests.md) can run a Lighthouse audit and send scores to the matching RUM view. Lighthouse lab measurements complement the real-user field data on this page, so you can track frontend quality on a schedule.

The audit runs once per test run, on the final URL the test reaches, and reports five category scores from 0 to 100:

- **Performance**: Measures how quickly the page loads, displays content, and becomes interactive.
- **Accessibility**: Measures how well people with disabilities can navigate and use the page, based on automated checks.
- **Best Practices**: Measures whether the page follows modern standards for security, browser compatibility, and code quality.
- **SEO**: Measures whether search engines can discover, understand, and index the page.
- **Agentic**: Measures how well AI agents can understand, navigate, and interact with the page.

### Prerequisites{% #prerequisites-1 %}

- A [browser Synthetic test](https://docs.datadoghq.com/synthetics/browser_tests.md) that runs on **desktop Chrome** from a managed (Datadog) location.
- [RUM data collection enabled on the test](https://docs.datadoghq.com/synthetics/guide/explore-rum-through-synthetics.md), with a RUM application selected. The test injects the RUM Browser SDK into the page it loads, so the tested site does not need to be instrumented for RUM separately.
- The test must be saved and run on a schedule or on demand. Audits do not run while you create or record a test, or on runs triggered from CI/CD.

### Set up a Lighthouse audit{% #set-up-a-lighthouse-audit %}

You can enable Lighthouse audits from a RUM application or from Synthetic Monitoring:

- **From a RUM application**: On the Optimization page, select a view that has no Lighthouse data yet, then select Create a Synthetics test in the Lighthouse panel's empty state. RUM data collection and the Lighthouse audit are enabled automatically, and the test is linked to the RUM application. Finish configuring the test and save it.
- **From Synthetic Monitoring**: Create or edit a [browser test](https://docs.datadoghq.com/synthetics/browser_tests.md), enable [RUM data collection](https://docs.datadoghq.com/synthetics/guide/explore-rum-through-synthetics.md) and select your RUM application, then turn on Run Lighthouse audit (available only when RUM data collection is enabled). Record the steps that reach the page you want to audit, then save the test.

### View Lighthouse results{% #view-lighthouse-results %}

After the test runs, Lighthouse results appear in two places under [Digital Experience > Performance Monitoring](https://app.datadoghq.com/rum/performance-monitoring). The Lighthouse panel and table are scoped only by application, view, and time frame. Other page filters, such as browser, country, or team, do not apply.

On the **Optimization page**, when a single view is selected, the Lighthouse panel shows the view's most recent audit in the selected time frame:

- Five category score gauges
- The change in each category score compared to the previous time frame
- Lab metrics measured by Lighthouse
- Passed and failed audit counts
- Score trends over time

From the panel, you can open the report in the Lighthouse viewer, download it as JSON, or open the originating Synthetic test result.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/lighthouse-panel.0f120dc219e4819631b3f60442091af3.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/lighthouse-panel.0f120dc219e4819631b3f60442091af3.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="The Lighthouse panel showing category scores, lab metrics, audit results, and a score trend over time." /%}

On the **Performance Monitoring summary page**, the Lighthouse section shows the **Lighthouse scores by view** table, which compares scores across views. Use the percentile selector (p75 by default) to choose which percentile of audit scores in the selected time frame the table shows, and select a row to open the Optimization page for that view.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/lighthouse-scores-by-view.fd1a927ba440463733a8b185ce9ce2ad.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/browser/optimizing_performance/lighthouse-scores-by-view.fd1a927ba440463733a8b185ce9ce2ad.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="The Lighthouse scores by view table comparing category scores across RUM views, with a percentile selector." /%}

### Metrics and attributes{% #metrics-and-attributes %}

The `@synthetics.lighthouse_audited` attribute is set to `true` on each audited view. To find audited views in the [RUM Explorer](https://docs.datadoghq.com/real_user_monitoring/explorer.md), switch the event type to Views and search for `@synthetics.lighthouse_audited:true`. Audited views come from Synthetic tests rather than real-user sessions, so remove any `@session.type:user` filter from the query.

The category scores are available as metrics, so you can graph them on dashboards and alert on regressions with monitors:

- `rum.measure.lighthouse.performance`
- `rum.measure.lighthouse.accessibility`
- `rum.measure.lighthouse.best_practices`
- `rum.measure.lighthouse.seo`
- `rum.measure.lighthouse.agentic`

The Lighthouse score metrics are tagged with `application.id` and `view.name`.

## Further Reading{% #further-reading %}

Additional helpful documentation, links, and articles:

- [Configure browser tests in Synthetic Monitoring](https://docs.datadoghq.com/synthetics/browser_tests.md)
- [Interactive Lab: Optimize Frontend Performance with Datadog RUM Browser Monitoring](https://learn.datadoghq.com/courses/rum-optimize-frontend-performance)
- [Real User Monitoring](https://www.datadoghq.com/blog/real-user-monitoring-with-datadog/)
- [Monitor Core Web Vitals with Datadog RUM and Synthetic Monitoring](https://www.datadoghq.com/blog/core-web-vitals-monitoring-datadog-rum-synthetics/)
- [From data to action: Optimize Core Web Vitals and more with Datadog RUM](https://www.datadoghq.com/blog/rum-optimization/)
