Screen load

Screen load lives in the Monitor area of the dashboard, under Performance.

At a glance#

What it does#

Screen load reports how long each screen in your app takes to become usable: sample counts and percentiles per screen, a sortable table, a distribution histogram of load times, a p50/p95 trend over the window, and a per-screen drawer with that screen's own percentiles.

The histogram is the part most people skip and shouldn't. Percentiles tell you where the boundaries are; the distribution tells you the shape — and a bimodal shape (two humps) is a different bug from a long tail, because it means two code paths, not one slow one.

When to use it#

When users say a specific part of the app is slow, and when you are deciding what to optimise next. Sorting by p95 and multiplying by sample count is a decent proxy for total user time wasted, which is a better prioritisation signal than either column alone.

Workflow#

1. 1

   Sort by p95, then weigh by samples

   The slowest screen matters less than a moderately slow screen everyone visits.

2. 2

   Look at the distribution before theorising

   One hump with a long tail means most loads are fine and some conditions are bad — usually network or cold cache. Two humps mean two paths, and you can go find them.

3. 3

   Open the screen drawer

   Per-screen percentiles let you check whether that screen's shape matches the app's or is distinctly its own.

4. 4

   Check the trend for the window around your release

   A step change in p95 dated to a deploy is a regression with a known cause.

Permissions and prerequisites#

Mobile only. Web apps measure the same idea as Page load, which is built on the same data path with web-appropriate metrics and labels.

Screens need names to be reported separately — see the naming note below.

Limits and edge cases#

• Unnamed screens collapse together. If your navigation does not give the SDK a stable screen name, everything lands in one row and the page becomes useless. Name screens explicitly.

• High-cardinality names are worse than none. A screen name containing an id creates one row per entity. Use route templates, not resolved paths.

• An empty window is stated honestly. No samples produces an explicit empty state rather than zeros, because zero load time and no measurement are not the same claim.

Troubleshooting#

Every load is in one row. Screen naming is missing or dynamic. Fix instrumentation, not the dashboard.

p95 is enormous but no user complains. Check for a background or preloaded screen being measured as a user-visible load — it inflates the tail without anyone waiting on it.

Where the data comes from#

Automatic when the navigation ref is set; otherwise mark boundaries with markScreenLoadStart / markScreenLoadEnd.

From the SDK

• Performance

Served by

• Analytics

Related#

• Performance SDK guide

• Overview

• Insights

• App start

• RUM overview

• Web Vitals

• Network

• Monitor overview