Front-end performance in AppSignal

The Performance view reports web vitals measured on your users’ devices and connections.

​

Web vitals summary

The view has cards for five metrics: LCP, INP, CLS, FCP, and TTFB. Values, ratings, and trends appear when measurements are available. 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. For example, selecting the last four hours compares them with the previous four. This shows whether a value changed. When a trend spikes, check how many measurements sit behind it. A single measurement is too little to establish a regression. 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 help explain a poor LCP. Slow TTFB points to the server or network. Fast TTFB with slow LCP points you toward resource loading or rendering.

​

Percentiles

Values are reported at a percentile you choose: p75, p90, or p95. Start with p75. Google’s thresholds use it to rate Core Web Vitals. Use p90 or p95 to see slower experiences that an average can hide.

​

Per-route breakdown

Beneath the summary, the table shows up to 20 pages, with a sample count and available metrics for each. 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. The table prioritizes pages with more measurements, then sorts those shown by LCP. Compare metrics across a row for clues:

• A slow TTFB points to time spent waiting for the server or network before rendering can start.
• A fast TTFB with a poor CLS means the response starts quickly, but the layout shifts unexpectedly.

Routes are listed as the templates your application reported. For other routes, the processor derives an approximate template from the URL. 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 table. You can then inspect one part of the application. 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:

• Metric availability varies by browser. CLS and INP need specific performance entries, so browsers without them do not contribute those values. 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.