RFC: Support Report Web Vitals as Opt-In CloudWatch Metrics

Is your feature request related to a problem? Please describe.

With reportWebVitals in a custom _app.js we can support recording Web Vitals as per docs: https://nextjs.org/docs/advanced-features/measuring-performance#web-vitals

Describe the solution you’d like

• Support a /analytics endpoint.
• Use same site domain to avoid updating CSP or CORS.
• Upload minimal data with Async POST requests to edge lambda.
• Configure analytics lambda to record custom metrics in CloudWatch, perform Async transforms of minimal data from client and formatting metrics and dimensions.
• Metrics should support per page analysis.
• Metrics package should be decoupled and deployment would be optional configuration.

Describe alternatives you’ve considered

Two popular managed services for this:

• https://speedcurve.com/
• https://nextjs.org/analytics

These are good services, but they are paid services.

Additional context

• Further support for alarms and regressions could be added by open extensibility.
• Further support for regional dimensions might be wanted.

Background reading: https://developer.mozilla.org/en-US/docs/Learn/Performance/Measuring_performance

[danielcondemarin]

With that being said this is potentially a non-starter as it would require custom implementation. I don’t believe that is an attractive proposition but if there is still an interest in the feature then it can be done 🤷‍♂️

What do you think if we introduce our own performance-relayer client implementation? To start with it could be the similar or same as Next.js Vercel one.

So if users opt-in to the Analytics functionality we’d bootstrap the backend Analytics endpoint in Lambda@Edge for them.

component: @sls-next/serverless-component
inputs:
  analytics: true

Client side they could install an NPM module, e.g.

# pages/_app.js
export { default as reportWebVitals } from '@sls-next/analytics-client';

Later on, we could provide some way to allow for extensibility.

I think you can make an async call and don’t wait for the response. But I thought this is a reporting API from client side anyway, i.e it doesn’t block rendering of the page itself? I haven’t used this new feature yet so not as familiar with it.

That’s right @dphang it doesn’t block rendering. Ideally we would support using the Beacon API which is generally more efficient than using fetch directly and it handles when metrics are sent and the page is unloaded (e.g. an external link click).

[simonireilly]

@danielcondemarin, sure, I can elaborate.

Data Collection

It is probably best to begin with the implementation in NextJS source code.

https://www.github.com/vercel/next.js/tree/canary/packages%2Fnext%2Fclient%2Fperformance-relayer.ts

This performance-layer.ts module in required in client/index. It is mounted in a useEffect hook to run after DomContentLoaded has occured.

Line 49 has the hardcore’s endpoint for vercel-analytics.com. I would expect this to be a process.env in the future as this proprietary endpoint hard coding is not OSS in my opinion.

This module will observe the metrics required from the web-vitals package

• Cumulative Layout Shift (CLS)
• First Contentful Paint (FCP)
• First Input Delay (FID)
• Largest Contentful Paint (LCP)
• Time to First Byte (TTFB)

Custom CloudWatch Metrics

Capturing these as Custom CloudWatch Metrics would be the proposed solution. There could be unique metric names for each of these five webvitals per deployment.

• MyNextServerlessCLS
• MyNextServerlessFCP
• MyNextServerlessFID
• MyNextServerlessLCP
• MyNextServerlessTTFB

MetricDatum can be seconds as sent in the value field of the body from the nextJS performance-layer.ts.

These can be visualised in percentiles as the user wants, but defaults of P75 (recommended bench marker https://web.dev/vitals/) would be ideal for any dashboard.

To enhance these metrics it would be possible to add some dimensions.

• Device='mobile' | 'tablet' | 'desktop'
• Page=${body.page} ( Next page .e.g. /[slug].js
• Region=${process.env.AWS_REGION} (default lambda env)

It is worth noting that you cannot aggregate custom metrics along multiple dimensions, being overly specific means you cannot re-aggregate for the global metric.

Presentation (CloudWatch Dashboard)

These dashboards are some what limited but the main components can be achieved:

• Number type widget with the real user index (1-100). It must be possible to determine this from the metrics sent as Vervel receives nothing other than what next sends. This will just involve a little algebra which can setup a custom formula for a CloudWatch trace using the other metrics.
• CloudWatch graphs for each web vital metric with configured percentiles.
• Potentially there will be an either column or row layout to separate mobile/tablet/desktop

The last piece is the pages section. Having this dimension will be helpful I think, but visualizing so many dimensions might be overload.

Some trial and error might be required.

Hope that makes sense. The architecture would be as described previously.

• API endpoint for receiving metrics
• Extract Transform web vital to CloudWatch metric with dimensions in lambda