appsignal

AppSignal Adds Next.js Integration - Automatically Adds Web Vitals Monitoring

Stefan Verkerk

Stefan Verkerk on

AppSignal Adds Next.js Integration - Automatically Adds Web Vitals Monitoring

Boom! Our latest release of the AppSignal for Node.js package now includes support for Next.js. The Next.js integration also includes end-to-end insights into application performance, as well as error tracking.

What Instrumentation Actually Does For You

When we say "We support a new integration", like for Next.js or for PostgreSQL that we wrote about last week, what does that mean?

When adding an integration, AppSignal does as much work as it can for you and automatically instruments many things out-of-the-box. For example, for Next.js that means AppSignal automatically instruments all incoming HTTP requests by default. For many setups, we take it a step further by automatically creating dashboards, and spare you the trouble of figuring out what makes sense to measure.

This is where we stand out as a monitoring tool for you: as powerful as expensive enterprise solutions, but as well designed and quick to bring you insights as individual use case tools. AppSignal comes with reasonable pricing, relaxed upgrade policies, and 🍪 stroopwafels 🍪.

What's in This Integration?

AppSignal for Node.js automatically instruments all incoming HTTP requests by default. However, as Next.js deals in the concept of "Pages" rather than routes, we need to be able to group all the requests made for your pages together with an action name.

Inside the Next.js integration itself, we export a page-aware handler that can either be used with a Next.js custom server instance or with an Express.js app. With the integration in place, your actions now have the HTTP method and pathname for your page added to them. This enables you to see a specific error or a performance incident. Here’s a screenshot of the error page where an error occurs for a GET request with the / path:

Error page AppSignal

This will make it easier to pinpoint what case is leading to that error. In a performance issue you will now also see that actions have the HTTP method and pathname added. In our example, in the screenshot underneath, you’re looking at a sample for a POST request with the /graphql path.

Performance page for Next.js in AppSignal

Magic Dashboard

When you have AppSignal ingesting your data, dashboards will magically automatically show in your list of dashboards. One of them will have your core metrics about the performance of Next.js. This is what it looks like:

Next.js Magic Dashboard in AppSignal

But there's more!

Measuring User Experience With Web Vitals and Next.js

A few weeks back, Google Chrome team introduced a Core Web Vitals metrics initiative. Core Web Vitals are the quality signals about the UX, on top of which the famous Lighthouse reports are built. We're excited to say that we've added support for Web Vitals reporting if you are on Next.js v9.4.

You can enable this by providing a middleware which will mount a route to /__appsignal-web-vitals and POST the metrics to that, and we’ll add custom metrics for these metrics on the server.

This works by exporting a reportWebVitals function from pages/_app.js as described here.

export function reportWebVitals(metric) {
  const body = JSON.stringify(metric);
  const url = "/__appsignal-web-vitals";
 
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon(url, body)) ||
    fetch(url, { body, method: "POST", keepalive: true });
}

A Magic Dashboard for Web Vitals

Upon successful setup, two new magic dashboards will be created for the user - one called Next.js that we mentioned earlier, and another one called Web Vitals.

From here, you can track key performance metrics for your Next.js front-end right alongside the other metrics available for your app.

  • Time to First Byte (TTFB): Time duration that starts when a browser requests a page and when it receives the first byte of information from the server.
  • First Contentful Paint (FCP): Duration before the browser renders the first bit of content from the DOM.
  • Largest Contentful Paint (LCP): The point in time in the page load timeline when the page's main content has likely loaded.
  • First Input Delay (FID): Time from when a user first interacts with a page to the time when the browser can respond to that interaction.
  • Cumulative Layout Shift (CLS): Quantifies how often users experience unexpected layout shifts.

...and this is what it looks like:

Web Vitals AppSignal Dashboard

This is the first time you'll be able to gather front end performance as experienced by the user in AppSignal. Web Vitals are still young, and if the data from it is as useful to you all as we hope, we will look into expanding support to other stacks as well. We'll reach out to some people using it to hear more.

Try Out AppSignal and Get a Box of Stroopwafels 🍪

If this has made you curious about AppSignal, set it up in five minutes and try it (for free). You can learn how to set up monitoring of your Node app with AppSignal, and read about all the out-of the-box support we provide from our docs. Once you've got data coming in, reach out to us and we'll send you a box of stroopwafels to chew on while enjoying AppSignal.

Share this article

RSS
Stefan Verkerk

Stefan Verkerk

Stefan often shares stories about his Mosaic script-kiddie years. Has been scaling startups since the 90s. Today, he does management and growth things at AppSignal. Has amazing Excel to SQL chops on his customized MacBook.

-> All articles by Stefan Verkerk-> Become an AppSignal author

AppSignal monitors your apps

AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!

Discover AppSignal
AppSignal monitors your apps