Front-end performance in AppSignal

The Performance view reports web vitals measured on real page loads, from your users’ own devices and connections. Unlike a synthetic lab run, it tells you how the application performs for the people actually using it, on the hardware and networks they actually have.

​

Web vitals summary

Five metrics are summarized for the period you select: LCP, INP, CLS, FCP, and TTFB. Each one shows its current value, a label saying whether that value is good or needs work, and a trend line. The trend line is what tells a steady number apart from one that has been climbing. Each period is also compared against the one before it of the same length. Selecting the last four hours compares those four hours with the four before them, which is what tells you whether a number is getting better or worse. When a trend shows a spike, check how many measurements sit behind it before treating it as a regression. A spike built from a single measurement is noise. The ratings come from Google’s thresholds, which are listed with each metric on the web vitals page. The three Core Web Vitals are LCP, INP, and CLS. FCP and TTFB are supporting metrics that help explain a poor LCP: a slow TTFB points at the server or the network, while a fast TTFB with a slow LCP points at the front end.

​

Percentiles

Values are reported at a percentile you choose: p75, p90, or p95. Start with p75, which is the percentile Google’s thresholds are defined against, and the one to use when you want to know whether a page is good or not. Move to p90 or p95 when you want to know what your slowest users are living with, which is where problems that averages hide tend to show up.

​

Per-route breakdown

Beneath the summary, every route is listed with its sample count and its value for each of the five metrics. The sample count matters as much as the values: a route with four samples is a hint, not a finding. This table is where you find the work. Sorting by LCP brings the slowest pages to the top, and reading across a row tells you why a page is slow:

• A slow TTFB with an acceptable LCP means your server is the holdup.
• A fast TTFB with a poor CLS means the page arrives quickly but jumps around while it finishes loading.

Routes are listed as the templates your application reported. For anything that did not report one, AppSignal works out a template from the URL, which is rougher than telling it directly. Read more in reporting the current route.

​

Comparing releases

Filtering by app version restricts the whole view, summary and table alike, to the page loads reported by that release. Selecting a version also labels the trend lines with it. This is the quickest way to answer whether a deploy made something slower. Set appVersion to your release tag or commit SHA and every measurement carries it.

​

Filtering by route

Filtering by route narrows both the summary and the table, so you can read the numbers for one part of the application instead of an average across all of it. Those averages are often unhelpful on their own. A fast marketing page and a slow dashboard combine into a single number that describes neither of them.

​

What the numbers leave out

Two things to keep in mind when interpreting what you see:

• CLS and INP only cover some of your users. Both rely on browser features that only Chrome and other Chromium browsers have, so Safari and Firefox visitors contribute nothing to them. LCP, FCP, and TTFB cover everyone. Read more in browser support.
• LCP, FCP, and TTFB belong to the page load, not the route. The browser measures them once, when the page first loads. In a single-page application, they belong to whichever route the user opened first, not the ones they moved to afterwards. CLS and INP are measured per route. Read more in how values are attributed to routes.

If no web vitals appear at all, remember that they are sent in batches rather than one at a time. Work through troubleshooting.