Skip to main content
Browser monitoring is a beta AppSignal Labs feature. The @appsignal/browser package is published under the beta tag on npm, and its configuration and API may still change between beta releases. Share feedback in our Discord community.
Web vitals are Google’s standard measurements of how a page feels to the person using it: how long it takes to show something useful, how quickly it responds, and whether the layout jumps around while loading. AppSignal for Browser measures them on real page loads, from real devices and connections, rather than in a synthetic lab run. Collection starts with init(). There is nothing to configure.

​
What each metric measures

LCP, INP, and CLS are the three Core Web Vitals. 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. Every value is rated against these thresholds. The summary in AppSignal labels each value with its rating, and the per-route table tints each cell by the same rating.

​
How values are attributed to routes

LCP, FCP, and TTFB measure the page load. The browser measures each of them once, when the page first loads, and never again. In a single-page application, that means they belong to whichever route the user opened first, not to the routes they move to afterwards. Measuring them again per route would need a browser feature that is still experimental. CLS and INP build up over the whole time a page is open, so AppSignal keeps a separate value for each route and starts over whenever the user navigates. Every route a user reaches through your router gets its own CLS and INP. To keep routes separate and readable, tell AppSignal the route template each time your router navigates:
Without it, AppSignal works out a template from the URL itself, replacing numbers and UUIDs with placeholders. That works, but telling it directly is exact. It is also the same value errors are grouped by, so one call covers both. There is a second reason to use templates. AppSignal only keeps a limited number of separate routes per application. Once you go past it, the rest are lumped together into one unnamed group that the route filter leaves out. Without templates, every URL counts as its own route, so that limit arrives much sooner.

​
When values are sent

Web vitals are batched and sent at page and route boundaries:
  • When the page is hidden, which covers switching tabs and backgrounding the app.
  • When the page is closed or navigated away from.
  • On a client-side route change.
If a page crashes or is force quit before any of those happen, nothing is recorded for that visit. If your router keeps the route after a #, AppSignal only treats a change as a navigation when the new value looks like a route, such as #/orders. A plain link to a section of the page, such as #pricing, does not end a route.

​
Browser support

LCP, FCP, and TTFB work in current versions of every major browser. CLS and INP need Chromium’s layout-shift and event-timing entry types. Safari and Firefox do not provide them, so those two metrics come from Chromium-based browsers only. Your CLS and INP numbers therefore describe a subset of your traffic, while LCP, FCP, and TTFB describe all of it.

​
Reviewing performance in AppSignal

The Performance view summarizes each metric for the period you select and breaks it down per route, filterable by percentile, time range, app version, and route. Read more in front-end performance in AppSignal.