RUM performance

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, 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 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.

​

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.

• 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 Esc 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). 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, 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). 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.