Feedback on v9.4.0 Core Web Vitals (LightHouse) - Amplitude implementation

[Vadorequest]

Since v9.4, Core Web Vitals are available to us so we can track apps performances. (read more at https://nextjs.org/blog/next-9-4#integrated-web-vitals-reporting)

---

About Amplitude

I've made a first implementation about how to track them using Amplitude analytics. Amplitude is free, up to 10 millions events per month. (then, it's around $50k/year 😨)

Amplitude is much better (IMO) than Google Analytics, both from a developer standpoint (tracking data is much easier and works well with SPA) and from an analytic standpoint (it's much easier to exploit data, test, iterate, observe the system, etc.).

---

Demo: https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-n62chq0lj.now.sh

• Open the browser console to see when reports are saved.
• Install https://chrome.google.com/webstore/detail/amplitude-instrumentation/acehfjhnmhbmgkedjmjlobpgdicnhkbp to see event and their content (very useful if you wanna play around a bit)

---

Feedback:

The current API is very simple. A bit too simple maybe. basically, each metric is received one by one in _app:reportWebVitals function.

While this is not an issue on systems such as Google Analytics, because it doesn't cost anything to send millions of API requests (AFAIK), it's not true with other systems, such as Amplitude (I really, really don't want to reach the 10 millions events limit 😅). Sending them in batches instead of one-by-one seems like a better solution with Amplitude.

Also, I was surprised by the behaviour, documented below:

/**
 * Group all vital metrics together, using their own "name" property as key.
 *
 * Meant to help regroup multiple reports together to send them all at once, to reduce API calls.
 *
 * @see https://web.dev/vitals/ Essential metrics for a healthy site
 * @see https://nextjs.org/blog/next-9-4#integrated-web-vitals-reporting
 */
export type NextWebVitalsMetricsReport = {
  reportedCount: number; // Number of times a report has been sent, kinda help to trace how long a same client-side session was
  reportId: string; // ID of the "report", helps grouping reports with different data but same reportId together when analysing data
  metrics: {
    FCP?: NextWebVitalsMetrics; // First contentful paint, triggers on page load
    FID?: NextWebVitalsMetrics; // First input delay, trigger on first end-user interaction (click)
    LCP?: NextWebVitalsMetrics; // Largest contentful paint, triggers on first end-user interaction (sometimes doesn't trigger)
    'Next.js-hydration'?: NextWebVitalsMetrics; // Triggers on page load
    'Next.js-render'?: NextWebVitalsMetrics; // Triggers on client-side redirection (<Link>)
    'Next.js-route-change-to-render'?: NextWebVitalsMetrics; // Triggers on client-side redirection (<Link>)
    TTFB?: NextWebVitalsMetrics; // Time to first byte, triggers on page load
  }
}

There are 3 main "steps":

1. Initial page load: 3 metrics are received immediately after initial page load (page refresh)
2. First end-user interaction: 1-2 metrics are received after the end-user first interaction
3. Further client-side navigations: 2 metrics are received after every client-side redirection (following <Link>, basically), those metrics are received for every link clicked, unlike the 2 other "steps" above that only happen once by browser-session

I though all events would be received at once and I'd just have to send one big analytic event to store it all. Also, some events (like LCP doesn't always trigger, sometimes it does upon first click, sometimes it doesn't and I can't tell why)

Eventually, I used batches of 5 and 2 metrics sent at once to avoid sending too many events to Amplitude. My website being used as iframe in other websites, it could have suffered from quite a lot of API requests sent, that'd have eaten my free plan.

I believe the Next.js team didn't provide those stats in the _app:render function itself to avoid useless re-renders (which would have made perfs worse), but I wonder if there isn't a better way for people interested only by the 4-5 most interesting metrics to get them all at once.

The worse thing about this design, is that it lives completely outside of the whole Next.js app. I had to rewrite a bunch of stuff that I thought I wouldn't have to duplicate (related to Amplitude config), because even though what I had done is re-usable between all my pages, those metrics live completely outside of the "page" concept.

Also, I'm not sure about how to analyse those metrics now that I'm tracking them. I guess it's great to have them around to be able to compare perfs across time and maybe pinpoint a specific feature that badly impacts performances after being shipped? I have a few ideas around, but no particular action plan yet.

Read https://web.dev/vitals/ if you want to take it deeper 😉

---

Commits:

1. UnlyEd/next-right-now@2a29911
2. UnlyEd/next-right-now@d09ff7a

Branch: https://github.com/UnlyEd/next-right-now/tree/v1-hyb-mst-aptd-gcms-lcz-sty, and more specifically:

• NextWebVitalsMetricsReport: https://github.com/UnlyEd/next-right-now/blob/v1-hyb-mst-aptd-gcms-lcz-sty/src/types/nextjs/NextWebVitalsMetricsReport.ts
• NextWebVitalsMetrics: https://github.com/UnlyEd/next-right-now/blob/v1-hyb-mst-aptd-gcms-lcz-sty/src/types/nextjs/NextWebVitalsMetrics.ts
• _app: https://github.com/UnlyEd/next-right-now/blob/v1-hyb-mst-aptd-gcms-lcz-sty/src/pages/_app.tsx#L80-L119

[housseindjirdeh]

Thanks for the detailed feedback @Vadorequest 😃

I've made a first implementation about how to track them using Amplitude analytics.

I've never heard of Amplitude before, but it looks great! Thanks for doing a test-drive with the current metrics reporting implementation with Amplitude, it's always great to hear how it can be used for different platforms (and if there is anything that could be improved to make things easier).

The current API is very simple. A bit too simple maybe. basically, each metric is received one by one in _app:reportWebVitals function.

Simple was the goal :)

Sending them in batches instead of one-by-one seems like a better solution with Amplitude.

That makes sense. The goal of the API was to simply expose every web vital metric (and a few custom ones) to the user every time they're determined. Since everybody is going to have a different use case with how they would like to handle the API, the user decides how to handle the results (send every one to analytics, or batch them, or only send values that are poor, etc...)

Eventually, I used batches of 5 and 2 metrics sent at once to avoid sending too many events to Amplitude. My website being used as iframe in other websites, it could have suffered from quite a lot of API requests sent, that'd have eaten my free plan.

To be honest, I'm sure many folks who use an analytics provider that limit the number of requests will also want to batch instead of sending every one on their own. Would you like to submit a PR that adds a section to the docs that quickly show? I think that would be super useful :)

Looks like the logic you laid out works well in your Next.js app, but maybe we could show a super simple example of how to batch metric results together?

[timneutkens]

Overall batching should be part of the analytics library that's being used and not really implemented by the end user themselves in most cases.

[housseindjirdeh]

Hmmm I guess I'm not aware how many analytics libraries handle it, but if that's the case that's even better!

[Vadorequest]

Overall batching should be part of the analytics library that's being used and not really implemented by the end user themselves in most cases.

Agreed. It's the job of the analytics lib to help about that. It's true that there may be too many different use-cases for Next to provide an API that is friendly with all, providing a "low-level" API like it's currently the case makes a lot of sense.

I think the most simple batching example would rely on "send all metrics if no more metric is received within X sec" (I forgot the technical term for that)
It could be one simple, yet efficient way to report metrics using batching.

Clearly, a default implementation that supports most use-cases would help getting started with this.

[AlbertWhite]

I have the same problem on my side. LCP is only triggered on first user interaction, even if happens long before the first user interaction.