Render & Interaction

The Infrastructure & Network dashboard followed the data's path up to the first byte arriving; this dashboard starts exactly at that point. At this stage, the browser has already received the data, reads the front-end code, runs the scripts and lays out the page skeleton (the DOM).

The boundary between these two dashboards is fully deliberate. Since standard browser metrics measure the entire path from the start of navigation (which also includes network and server time), this separation prevents the two dashboards from overlapping and double-counting the same interval.

This dashboard splits into two key parts:

This part gives you the macro state of the second loading phase. The cards are:

• Browser processing time: shows the pure front-end share of the whole process.
• Page structure ready time: covers the entire path from the click to the page skeleton being fully ready.
• Slow-experience rate: the single key metric to lean on if you need to report to senior management. It isn't an average — it pictures the real share of users who had a poor experience.

This part gives you advanced tools for automated monitoring and closer analysis of rendering.

• UX Pulse: using the same logic as Infrastructure Pulse, it compares sudden shifts in the render layer over the last 24 hours against the previous 7-day average, split by device type. Since processing power differs sharply between phones and computers, and most render slowness happens on mobile, this split helps you tell whether the problem is site-wide or confined to weaker devices.
• Page-ready speed: a chart that compares Page structure ready time across device, browser or operating system, and sorts the results slowest first. Each bar has two parts: a solid section showing the median user experience, and a faded continuation running to the worst 5% of experiences. Bar colour marks status against the threshold (green: under 1.5s, orange: up to 3s, red: beyond 3s), and the vertical line marks the three-second slow boundary.

To optimize this phase's performance, apply the following approaches:

• Cut JavaScript size and execution time: heavy or unused scripts are the main obstacle to fast browser processing.
• Lighten the page structure: a high count of elements in the HTML raises the time it takes to build the DOM tree.
• Load scripts asynchronously: load non-essential scripts with the defer and async attributes so their execution doesn't block the page's initial render.
• Prioritize mobile optimization: if the page-ready speed chart shows a wide gap between mobile and desktop, focus on lightening the mobile version — since this phase happens entirely on the user's own browser and has nothing to do with the server.