Make WordPress Core

Opened 2 weeks ago

Last modified 10 days ago

#58360 new task (blessed)

Measure additional performance metrics on each commit

Reported by: joemcgill's profile joemcgill Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: needs-patch
Focuses: performance Cc:

Description

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 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 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 here and used in the Gutenberg repo.

Change History (2)

#1 @flixos90
11 days ago

I would say, given that load time performance is where WordPress struggles the most (LCP passing rate of WordPress sites is far lower than CLS, INP, or FID passing rates, see https://cwvtech.report) we should focus on additional load time metrics first.

I would suggest using LCP like you are saying, but also TTFB. While that should give us similar values like the wp-total Server-Timing metric, it is measured in a more holistic way also encompassing the request so it provides another reference point which IMO is useful to have alongside wp-total: Effectively TTFB is server response time as seen from the client, while wp-total is just the WordPress-specific response time as seen from the server.

Regarding the implementation: While Gutenberg uses the implementation you mentioned, I think it would be worth considering using https://github.com/GoogleChrome/web-vitals instead, as that is a library specifically to measure those metrics. Rather than manually implementing it and having to ensure our implementation remains up to date with Web Vitals changes, using that library would simplify things by avoiding that. This command is an example of using that library in a headless browser, and I think we could follow a similar approach in our CI workflow.

#2 @oandregal
10 days ago

Thanks for the follow-up.

In the original ticket at #57687, I mentioned tracking LCP and LCP-TTFB in addition to TTFB. The editor tracks all these three because they provide different perspectives on performance (perceived performance for the user, client-only, and server-only respectively). It'd be great to have these as a common set tracked both in the editor and core.

Note: See TracTickets for help on using tickets.