Pages

Per-page performance and traffic. Find your slowest pages, your most popular ones, and the ones that start and end sessions, so you know exactly where to spend optimisation effort.

Pages takes the app-wide numbers from Overview and breaks them down by page. It is where you go from "the app is slow" to "this page is slow". It scopes to the app, period, audience, and filters in the scope bar.

What it answers #

Which pages get the traffic, which are fast or slow, and which start and end sessions? Answer it and you can prioritise: fix the slow page that lots of people see before the fast page nobody visits.

Group pages by #

A control at the top sets what counts as a "page":

• Path: the raw URL path, the default.
• Logical route: a route template you set with setUser and setRoute, so /orders/123 and /orders/456 collapse into /orders/:id.

The KPI strip #

Headline numbers for the selected slice, each compared to the previous equal-length period. They include page views and p75 LCP, so you read volume and the slowest-quarter load time side by side.

The pages table #

The centerpiece: one row per page, ranked by views, with traffic and Core Web Vitals together.

Sort by views to find your busiest pages, or by LCP to find your slowest.

Web Vitals distribution #

A split of every Core Web Vital across the app into Good, Needs-improvement, and Poor buckets. Where a p75 number gives one figure, the distribution shows the spread, so you can tell a uniformly mediocre experience from a good one with a poor long tail.

Entry and exit pages #

Two lists name the pages sessions most often start on and most often end on. Entry pages are your front doors, where first impressions and load speed matter most. Exit pages are where sessions stop, useful for spotting a page that loses people. For a marketing-oriented read of entries and exits, see Growth.

Related dashboards #

For resource timing behind a slow page, see HTTP objects. For the app-wide health these numbers roll up into, see Overview.