Our performance test currently tracks editor-centric metrics such as: editor loading time, editor typing time, time to select a block, time to open the inserter, time to hover an element on the inserter. While we did a number of iterations and improvements to the frontend rendering of Gutenberg, we don't have a metric to track. It would be a great addition to our performance numbers.

Tasks

V1: the MVP is having visibility in what happens in the server and the browser.

While tracking the time spent in the server is useful, it doesn't directly correlate to user-perceived performance. We need to track client metrics as well. For example, WordPress processes the post to render, so it can identify the blocks in use. With that information, it enqueues only the CSS of those blocks instead of the CSS of the whole block library. This certainly takes more time in the server, though we expect it to improve the perceived performance by the user. If we only tracked server metrics, they'd report this behavior as a regression, and we'd lack tools to understand how it impacted the actual user-perceived performance.

• #47442 Log front-end metrics in codehealth.
• #47037 Add support for Time To First Byte. Tells us the time it takes the server to render something.
• #47938 Add support for Largest Contentful Paint. Tell us the time it takes to render a meaningful part of the page in the client.
• #48288 Add support for a new metric, LCP-TTFB, so we have a better sense of how certain changes impact the rendering in the browser.

Later:

• Content: add images and other meaningful elements to the homepage template, so LCP metric can catch regressions on those areas. For awareness, core is in the process of tracking this front-end metrics as well. See https://core.trac.wordpress.org/ticket/57687 They plan to use the theme test data https://github.com/WPTT/theme-test-data
• Content: in addition to track the homepage, track a single large post template as well.
• Metrics: use the server-timing API to measure WordPress specific metrics. See example.
• Metrics: add support for First Contentful Paint. Tells us the time it takes to render some part of the page in the client.
• Runtime: consider using the latest WordPress (nightly?) so we report the latest. The runtime is now the older WordPress that Gutenberg supports, so it lacks many improvements.
• Runtime: consider improving how some Gutenberg code is hooked into core, so it's faster. For example, add short-circuit hooks to certain global styles code (e.g.: wp_get_global_settings) so it's "hookable" by Gutenberg. By doing this sort of changes, the logic will run only once.