> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RUM performance

> See where the Core Web Vitals of an application stand, which pages are slow and what a slow value is made of, what the pages load, what blocks their main thread, and how a page view loaded.

**RUM → Performance** tells how the pages of a browser application do for the people who open them. It is of one application
at a time, in one environment or in all of them, over the time range in view. The Core Web Vitals are measured by the
[Browser SDK](https://docs.molesignal.com/en-US/rum/browser-sdk.md), so an application that sends from something else has no page loads to grade, and the page
says so.

The tab has three views, which stand under its tabs: **Web Vitals**, **Resources**, and **Long tasks**. They share the
application, the environment, and the time range, and a link from one to another keeps the application and the environment.
Everything up to [Resources](#resources) is of the Web Vitals.

## Where the vitals stand

One sentence says how many page views there were and where LCP, INP, and CLS stand at the 75th percentile, each in the colour
of its grade. Under it are five levels: the three vitals, and the two that come before them, first contentful paint (FCP) and
the time to first byte (TTFB). Pick one to make it the level the chart, the grades, and the table are of. The choice is in the
address (`vital`), so a view can be shared.

A level is graded by the lines web.dev gives. They are the same for every application.

| Level | Good | Needs improvement | Poor |
| - | - | - | - |
| **LCP**, largest contentful paint | up to 2.5 s | 2.5 s to 4 s | over 4 s |
| **INP**, interaction to next paint | up to 200 ms | 200 ms to 500 ms | over 500 ms |
| **CLS**, cumulative layout shift | up to 0.1 | 0.1 to 0.25 | over 0.25 |
| **FCP**, first contentful paint | up to 1.8 s | 1.8 s to 3 s | over 3 s |
| **TTFB**, time to first byte | up to 0.8 s | 0.8 s to 1.8 s | over 1.8 s |

## Over time

The 75th percentile of the level in front, for each stretch of the time range. Two dashed lines mark where it turns from good
to needs improvement and on to poor. Drag across the chart to narrow the time range.

## Views by grade

For every level, a bar divides the views that had it among good, needs improvement, and poor, with the share that was good at
its end. The level in front says its three shares in words, with how many views each is and the line it is cut at. The shares
are counts of views whose value is at or under a line, not estimates.

## Pages and other dimensions

The table lists the most viewed values of one dimension, each with its views, the 75th percentile of every level in the colour
of its grade, and the share of its views that had the level in front good.

* **By** chooses the dimension: page (`view.url_path_group`), browser, operating system, device, country or region, or version.
* The table reads the 50 values with the most views, and ordering a column orders those. Click a heading to order by it, and
  click it again to reverse the order. Ordering by a level makes it the level in front.
* A value with fewer than 30 views is grey and stays at the end of a ranking by a level: a handful of views says nothing about how
  fast a page is.
* Narrow the table by words in the value. The dimension, the order, and the words are in the address.

## What a value is made of

Click a row to open a drawer on the views of that value. Its address holds the value and the vital, so the drawer opens
again from the address. **View in Explorer** opens the explorer on the same views. Switch between LCP, INP, and CLS in the head.
For a page or a version, **Alert on this** opens the rule editor on the vital of the open tab, narrowed to that page or version; it needs
`alerts.manage`. See [RUM alerts](https://docs.molesignal.com/en-US/rum/alerts.md#alert-from-a-page).

* The first line says where the vital stands for this value and over how many views. For LCP and INP it names the longest part.
* **What it is made of** (LCP and INP) is one bar of the parts the level takes, with how long each took. For LCP they are the time
  to first byte, the delay before the image starts to load, the time to load it, and the delay before it is painted. For INP they
  are the delay before the handlers run, the time they take, and the wait for the next frame. Each part is the mean over the
  views within 10% of the 75th percentile of the value, so the parts add up to about the level. A bar of only some of the parts
  would read as if it added up, so a value whose views do not report every part has no bar. CLS is a score and has no parts.
* **The element** is the one that was painted last (LCP), interacted with (INP), or moved (CLS), with how many views it was in and
  its 75th percentile. For LCP the file of an image or a video is shown beside it. A row opens the explorer on the views that had
  that element.
* **Over time** is the same chart, of this value alone.
* **The worst views** are the five views with the highest level. Each opens in the explorer, and its session opens whole.

Press <kbd>Esc</kbd> or click outside the drawer to close it.

## Resources

**Resources** (`/rum/performance/resources`) tells what the pages load. One sentence says how many requests the pages made, how
long the 75th percentile of them took, how many failed (an error status, or no answer), and how many resources and bytes a page
view asked for on average.

The table lists groups of requests, the most requested first, each with its number of requests, the 75th percentile of its time
and its size, the share that failed, and the share that was delivered from the cache.

* **By** chooses what a group is: a host and a kind of request (the default), a host and a path, a kind, a protocol, how the
  request was delivered, or whether it blocks rendering.
* **Kind** and **Status** narrow the requests (the statuses are client errors from 400 to 499, server errors from 500, and no
  answer), and the search narrows them to the requests whose address has the words. What narrows the requests applies to the table
  and to the panel beside it.
* The table reads the 100 groups with the most requests, and ordering a column orders those. A group with fewer than 30 requests
  is grey and stays at the end of a ranking by anything but its number of requests.
* A share of failures is orange from 1% and red from 5%. The share from the cache is a dash for requests that do not say how
  they were delivered.

Click a row to open a panel beside the table. Its address holds the group, so the panel opens again from the address.

* The first line says where the 75th percentile stands, how many failed, and which part took the longest.
* **Time over the range** is the 75th percentile of the group in each stretch of the time range.
* **Parts of the requests** is one bar of what the requests around the 75th percentile took their time on: redirect, DNS,
  connection, TLS, the time to the first byte, and download. Each part is the mean over the requests within 10% of the 75th
  percentile.
* **How they were answered** lists the status codes of the group, the commonest first, with their share of the requests that
  said how they ended.
* **The slowest requests** are the three that took the longest. Each opens the load of the view that made it, with the request
  chosen.
* Where requests carry the id of a trace, a line says how many do, and opens the explorer on the requests of the group.

## Long tasks

**Long tasks** (`/rum/performance/long-tasks`) tells what blocks the main thread of the pages. One sentence says how many long
tasks ran, how many of the page views met at least one, and how long a long task ran and held up the input at the 75th
percentile.

The table lists groups of long tasks, the most first, each with its number of long tasks, in how many views, and the 75th
percentile of how long they ran and of how long they held up the input. A time is orange from 100 ms and red from 200 ms.

* **By** chooses what a group is: the script and the function a long task is put down to (the default), a page, a version, or how
  the long task was triggered. The search narrows the long tasks to the scripts whose address has the words.
* A browser that reports long animation frames names the scripts that ran in one, and MoleSignal puts the long task down to the
  script that ran the longest (see [what MoleSignal adds](https://docs.molesignal.com/en-US/rum/events.md#what-molesignal-adds)). Safari and Firefox report a
  long task without a script, and so do the long tasks received before the script was derived. They are one group,
  **Unattributed**, and count like the others.
* As in Resources, a group with fewer than 30 long tasks is grey and stays at the end of a ranking.

Click a row to open a panel: how the long tasks of the group were triggered, which pages they happened on, and the three longest.
Each of the longest opens the load of the view it blocked, with that long task chosen on the main thread.

## The load of a view

A view of a browser opens in the explorer's drawer on **Load waterfall**, and its fields are in the next section. The drawer
opens from a row of the explorer, and from the slowest requests and the longest long tasks above.

* One sentence says how long the page took to load, when the first byte came, how long the largest paint took and what it was of,
  and how many resources and long tasks the view had.
* The time axis begins where the view began and ends after the page was loaded. Lines mark the first byte, the first and the
  largest paint, the document ready, and the end of the load. The file the largest paint waited for says so.
* **Main thread** shows the long tasks on the same axis. A request that blocks the first paint says so.
* Each request has a row, in the order it began. Its bar runs from when it began to when it ended, and is cut where the first byte
  came: the wait before, and the download after. The first fifteen are shown, and the rest are folded into a line that says how
  many there are and what most of them took. Requests that began after the page was loaded are counted in a line of their own.
  **Kind** and **Show** (blocking, slow from 500 ms, failed) narrow the rows.
* Click a request, or a long task on the main thread, to open it at the right: what it was, how it ended, its size, how it was
  delivered, what it took its time on, and the trace it joined. For the file the largest paint waited for, the panel also says how
  long the paint waited to start, to load, and to be drawn. A request opened from another page that began after the page was
  loaded is not on the axis, and its panel says so.

A screen of a mobile application has no page to load, so its drawer shows only its fields.

## How the numbers are counted

Every number of the Web Vitals is counted over the matching rows of `rum_views` by [`/api/v1/rum/aggregate`](https://docs.molesignal.com/en-US/api/rum#measure-rows),
so a view that was reported again as it changed counts once, at its latest revision. The numbers of Resources are counted over
`rum_resources`, and those of Long tasks over `rum_long_tasks` and, for the share of views, `rum_views`. A card whose counting takes
longer than the time budget says so, and the others stay: narrow the time range and read it again. The load of a view reads the
requests and the long tasks with its id, over the time of its load.

The elements, the parts, and the worst views come from the attribution the SDK reports with each vital (see the fields of
`view.performance` in the [event format](https://docs.molesignal.com/en-US/rum/events.md#view)). A browser that does not measure one leaves the view without it.

The page needs the permission that reads the rest of RUM, `streams.query`. See [RUM](https://docs.molesignal.com/en-US/rum#permissions).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.