Add next.js runtime data to the Chrome DevTools' Performance tab using the performance extension API

[and-oli]

Goals

The new Chrome DevTools Performance extension API is available in Chrome as an experiment. We would like to expore the integration of the API into next js to pursue the following goals:

1. Help next.js developers analyze and improve runtime performance of their applications by using the Chrome DevTools Performance Panel.
2. Bring next.js runtime data in the context of the browser execution, along with Network requests, JavaScript calls, rendered frames, etc.
3. Explore the API's potential to visualize unique Next.js performance aspects, such as server-side rendering (SSR) metrics.
4. Bridge the gap between the developer's mental model built on top of the next js framework and the browser model of their web app.
5. Gather in-depth feedback from the Next.js team on the current API's usability, functionality, and limitations.
6. Identify any gaps or missing features that would be critical for Next.js integration.

See more in the Background section below

Non-Goals

1. Implement a standalone next.js DevTools / profiler

Background

We (the Chrome Page Quality team) think allowing developers to extend the Chrome Peformance Panel can offer a significantly better experience for developers looking to improve performance to the current solutions available. For this reason we recently introduced the new Chrome DevTools Performance extension API.

Right now, it could get hard for developers using web frameworks like next.js or React to use Chrome DevTools to debug their applications because DevTools presents the data in terms of the browser model of the application. This model could be very different to the developer's mental model because of the abstractions introduced by the used framework on top. This is also true for the Performance panel and framework developers looking to improve their web app's performance.

For this reason, framework maintainers have created their own standalone devtools like React Profiler and Angular Profiler. However, these tools lack a big part (if not all) of the browser data (like network data, JavaScript calls, dropped frames, layout calculation, paining data, etc.) which is also important for performance optimization, especially when one needs to dive deeper into fine graineddetails. This leaves developers with a broken workflow composed of different tools that don't talk to each other, adding a lot of friction and context switching. Framework maintainers could implement improvements to their own tools to bring a complete picture, but this could mean investing significant work and adding a lot of third-party dependencies.

With the new Chrome DevTools Performance extension API we intend to alleviate a good part of these pain points by bringing framework data directly into Performance panel timeline.

For reference, we have a couple active PRs where the API is implemented in other frameworks

• React
• Angular

And here's an example of a timeline recorded by React's profiler being surfaced to the Chrome DevTools Performance timeline. We imagine we could add data strictly related to next.js' framework activity, f.e. server side rendering benchmarks:

We are looking to gather feedback about the API and explore other potential use cases where it (or an expansion) would be valuable in the web ecosystem. next js' feedback on this (and potential adoption) would be tremendously helpful, so please let us know what you think!

Key Questions for the next.js team & community

1. What are your initial impressions of the Chrome DevTools Performance Extension API?
2. How well does the current API align with your debugging needs and workflows?
3. What specific Next.js performance data would you like to visualize in the Performance panel?
4. What are your thoughts on the potential integration of this API into Next.js?
5. What challenges or concerns do you have regarding the integration?

Proposal

One potential starting point for implementing this is by adding calls to the API at places where the next.js framework is instrumented with OpenTelemetry (example) and adding the measured spans to the Chrome DevTools Performance timeline as well.

A challenge that might arise is that, because the perf panel extension API is based on top of the User Timings API, timings from the framework must be injected at the client side. The User Timings API allows to pass custom timestamps, so, technically, timings taken from the server can be injected at the client. However, a synchronization of the server and client clocks needs to happen to ensure this timings are accurate. This could be done by leveraging the performance.timeOrigin property