[wp-trac] [WordPress Trac] #58360: Measure additional performance metrics on each commit

[WordPress Trac]

#58360: Measure additional performance metrics on each commit
------------------------------+-----------------------------
 Reporter:  joemcgill         |      Owner:  (none)
     Type:  task (blessed)    |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Build/Test Tools  |    Version:
 Severity:  normal            |   Keywords:  needs-patch
  Focuses:  performance       |
------------------------------+-----------------------------
 In [55459] we added a new workflow that records server timing metrics for
 each commit. While server timing is an important metric, it only tells
 part of the story. As @oandregal pointed out in [https://oandre.gal/the-
 value-of-time-to-first-byte/ his writeup] about measuring performance
 metrics across different versions of WordPress, we often need to take a
 wholistic picture of how a change affects the user experience by
 considering additional performance metrics like LCP, TBT, and CLS,  which
 are user-centric and can be calculated using [https://web.dev/vitals/#lab-
 tools-to-measure-core-web-vitals lab data].

 == Metrics to consider for inclusion

 * Largest Contentful Paint (LCP)
 * Total Blocking Time (TBT)
 * Cumulative Layout Shift (CLS)

 == Implementation notes

 Our current performance workflow executes `npm run test:performance`,
 which already uses the `test-e2e` framework from `wp-scripts` to measure
 server timing, so adding additional front-end measurements can be
 implemented similarly to how it's been implemented
 [https://github.com/WordPress/gutenberg/blob/%40wordpress/e2e-
 tests%407.4.0/packages/e2e-tests/specs/performance/front-end-block-
 theme.test.js#L11 here] and used in the Gutenberg repo.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58360>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform