Pages, attention heatmaps and resources

Frontend → Pages answers how each page performs and how it is read. Frontend → Resources answers what the pages pull in, and what could be smaller.

Pages

Each row is a path. It shows the views, a traffic sparkline, load p75, and LCP, INP and CLS at p75, with the split into good, needs improvement and poor. It also shows time on page, page size and errors. Vitals on this page count full page loads only. The list is computed from raw views, so it covers the application's retention period.

Open a page for its detail:

• Time on page: only the time the tab was in front, not the age of the tab.
• How far down the page: the distribution of scroll depth.
• Where on the page the time went: the attention heatmap, described below.
• Sections of the page: per section, where it sits on the page, how many visitors saw it, time on it (median and p75), how much of it was on screen and, for videos, how many played it and how far they watched.

The tiles for views, load and the vitals open the sessions behind them, including only the slow or the poor ones.

Attention heatmaps

The heatmap is not a click map. It shows how long each part of the page was on screen. It is rebuilt from stored session recordings, so it works for visits that were recorded before anyone opened it. The page is cut into fifty bands from top to bottom, and each band is credited with the seconds it spent in view. Credit stops 30 seconds after the visitor's last activity, so a tab left open does not count. Phones (narrower than 768 pixels) and desktops are kept apart, because the same page is a different shape on each.

The heat is drawn over a picture of the page that your install takes itself, a screen at a time. For a page behind a login, the picture is rebuilt from a recorded visit instead. You can ask for a new picture. The heatmap covers only recorded sessions within the replay retention, so it needs session replay to be on for the application.

Page sections

The tag times parts of a page automatically. That covers elements with data-rum-section="name", every <section> with an id, and every <video>. Up to ten more rules can be added under Application settings → Page sections. A section counts as on screen while at least half of it is visible, or while it fills at least half the viewport, and only while the tab is visible. A section counts as seen after one second on screen. For a video, the time played and the furthest point reached are also recorded. Sessions can be filtered by a section that was seen.

Resources

The tag records resource timing for up to 150 resources per page. Resources sums them up. It shows how many loads there were, the share of the time spent waiting on servers against the network, and how much was served compressed. Cards break this down by type, by third party, and by the slowest resources. The waterfall of any single page load is on its page-load view, reached from a session. See One page load.

The asset audit

Under Optimisation opportunities, your install downloads the files your visitors actually loaded, and checks three things:

• Compression: whether Content-Encoding is set. The saving is measured, not estimated: the server gzips the file and reports the difference.
• Minification: judged from line length, comments, indentation and the .min. naming convention. The saving shown is the size of the comments, indentation and empty lines.
• Caching: whether Cache-Control: max-age is missing or shorter than an hour.

It only fetches URLs that appeared in that application's own traffic in the last seven days. It refuses private, LAN and localhost addresses unless ASSET_AUDIT_ALLOW_PRIVATE=1 is set. It stops at 3 MB or 8 seconds, and does not analyse responses that are not 200. It runs in the background every ten minutes, checks up to twelve files per application, and rechecks a file after a day. Run the audit starts it now.

Resource timing is the largest table in the database. If storage matters more than the waterfall, turn it off with data-resources="0", or lower data-max-resources.