Call for 2024 roadmap priorities

[felixarntz]

It's time to work on the WordPress Performance Team roadmap for 2024! 🎉

The team roadmap should capture what we want to primarily focus on this year. This issue is an open call to share your personal or collective priorities for the year, so that we can aggregate them in an eventual public roadmap to share with the wider WordPress community.

This roadmap should eventually be published as the new "Roadmap" menu item on https://make.wordpress.org/performance/, replacing the current 2023 roadmap. (The 2023 roadmap won't be completely removed, it'll only be removed from the menu.)

For reference, see the similar issue that led to the 2023 roadmap.

If you're actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2024 as a comment on this issue!

For every priority that you would like to focus on this year, preferably include the following:

• A brief project name / title for the effort
• Which aspect of performance (or which Web Vitals metric) the project improves (one of the following values)
  • Interactivity (INP)
  • Layout stability (CLS)
  • Load time performance (LCP)
• 2-5 bullet points describing what the project is about

Last but not least, note that this roadmap is of course not set in stone. Priorities can shift over the year, and the roadmap should remain a living document over time that we keep updating as needed. So this initial set of priorities for 2024 acts as a solid starting point.

This issue will remain open for project priorities until January 5, 2024. Afterwards, the public roadmap will be drafted based on the priorities shared here. The roadmap draft will be shared for review in a future #core-performance chat, to allow for feedback and iterations before it is published.

[felixarntz]

Sharing a few projects here which are already clear as they're a continuation of efforts already started:

• Performant Translations (recent update blog post)
  • Improves metric: LCP (via TTFB)
  • Description:
    • Improves localization performance by >10% or even more when using PHP-based translation files
    • Complete pull request and commit to core
    • Implement PHP l10n file support on wordpress.org / GlotPress (Meta Trac ticket)
• Image Loading Optimization (via client-side detection) (GitHub overview issue)
  • Improves metric: LCP
  • Description:
    • Implement client-side mechanism to detect LCP image reliably, including support for different LCP images between desktop and mobile viewports
    • Notably improves accuracy of preloading/prioritizing the correct image that is the LCP image (and not lazy-loading it), compared to WordPress core's limited server-side approach
    • Ship first version as part of Performance Lab
    • Add background image support: Many blocks use CSS background-image to display images, but these don’t get optimized by any of WP native functionality (srcset & sizes, lazy-loading, fetchpriority, etc)
    • Consider feasibility for WordPress core
• Template loading performance
  • Improves metric: LCP (via TTFB)
  • Description:
    • Implement further measures to improve performance of loading theme template files
    • Consider block theme HTML templates and classic theme PHP templates and template parts (e.g. Trac #59719, Trac #59600)
    • Improve performance of loading block patterns
    • Improve performance of loading theme.json configuration (e.g. Trac #57789)
• More accurate image sizes attribute
  • Improves metric: LCP
  • Description:
    • Implement smart logic to more accurately predict which image dimensions the “sizes” attribute needs to use based on how large the image will show up as
    • Consider layout implications from block themes and classic themes:
      • For block themes, it may be possible to predict via block layout from within PHP
      • For classic themes, it may rely on a client-side mechanism potentially inspired by the “Image Loading Optimization” approach
    • Potentially support sizes="auto" where relevant and supported: Lazy-loaded images don’t need sizes attributes to be calculated prior to layout, and can be made more accurate.

[westonruter]

Reduce CLS by reserving space for variable-height elements while loading

Improves metric: CLS

• Capture heights of embeds in the block editor across various breakpoints to then serve as min-height for element containers on frontend while loading. Container queries can be used to set proper height for each breakpoint.
• Initial code which could be used on frontend can be found in Layout Shift Terminator.
• Proof of concept for block editor integration can be seen at rtCamp/wp-cls-terminator: Remove CLS from Block Editor Embeds. See also Reduce cumulative layout shift (CLS) by attempting to determine heights of embeds beforehand ampproject/amp-wp#4729.
• Instead of using the editor to do the measurement, there may be an opportunity to use the client-side detection logic in Optimization Detective: Server-applied optimizations informed by client-side detection #869 to identify the elements causing layout shifts and apply the space reservations when it does its optimization pass via WP_HTML_Tag_Processor. This would allow for optimizing elements which occur outside of the block editor.

cc @thelovekesh

[joemcgill]

Thanks for kicking this off, @felixarntz. Some additional ideas I'd like to see us explore next year:

Improvements to page caching strategies
Focuses on metric: TTFB

• Research into why popular page caching plugins are not showing better TTFB outcomes than the general WP population, based on this CWV tech report and see if there are opportunities for improvement.
  • Keep in mind that bundling a file caching mechanism into core was removed in 2.5 as a design decision (see additional context from Alex Mills from around that time)
• Pursue additional opportunities to reduce redundant rendering of templates and template parts, like adding caching to get_template_part() (example code is in https://github.com/johnbillion/extended-template-parts) and introducing enhancements that make block template and template parts more cacheable.

API for registering scripts on a Web Worker
Focuses on metric: LCP|INP

• Move non-critical scripts off the main thread – example implementation in Emoji Loader enhancement (#58472)
• Related: Partytown PL module proposal
• Related: amp-script and WorkerDOM
• If not an API, at the very least we could do some research & outreach to identify good opportunities for using workers

Improve Core Automated Performance Tests
Focuses on: infrastructure

• Improve stability of performance tests
• Improve data collection and visualization tools (e.g. CodeVitals Dashboard)
• Create better content for test cases (i.e., replace the theme unit test data)
• Add additional test cases to a matrix (e.g. PHP versions, db load, object cache, template types, more themes, etc.)

[mukeshpanchal27]

Eliminating jQuery usage from the frontend in WordPress default themes
Focuses on metric: LCP

• What: Almost all older WordPress default themes up until Twenty Seventeen load jQuery in their frontend for logic that could easily be achieved by vanilla JavaScript. In this effort the affected themes should be modified to eliminate that dependency.
• Why: jQuery is a relatively heavy JavaScript library, particularly when considering that much of its use-case is now obsolete with what is available in more modern vanilla JavaScript, even in now outdated browsers. Replacing jQuery with vanilla JavaScript in such instances can lead to LCP improvements of up to 30%.
• Early Trac tickets and pull requests exist e.g. for Twenty Twelve and for Twenty Fifteen

[swissspidy]

Client-side image compression

Focuses on metric: LCP

• Leverage browser capabilities and technologies such as WebAssembly in order to:
  • Generate all thumbnails client-side and not on the server (reduces server load, allows parallel processing)
  • Compress images before upload and allow compressing existing images
  • Use powerful MozJPEG encoder and provide a path for further enhancements in the future (e.g. WebP, AVIF)
• Use Media Experiments plugin as a starting point
• Exact scope and roadmap TBD.
• Great momentum:
  • Client-side thumbnail generation came up in the past for things like WebP, and GB recently expressed interest in image compression as well.
  • A recent demo was well received and shows the high potential of such a feature.

Interactivity API Adoption

Focuses on metric: INP

• Interactivity API launched in 6.4 and is a lightweight way to make blocks and other elements interactive
  • Great alternative to more bloated approaches, e.g. using jQuery for a simple lightbox effect
• There is potential for increased outreach around this API to increase ecosystem adoption
  • Add to default themes
  • Documentation, blog posts, etc.
• Explore opportunities to extend this for dynamic content islands on otherwise cached pages
• Support work on the API to help shape it and ensure a robust solution lands in core

Scale reusable testing environment usage

Not focusing on a particular metric.

• Now that it has become easier for people to run performance tests (wp-scripts, tutorials, GitHub Actions), find ways to make it even simpler and further increase usage
  • Raises awareness for performance metrics and helps developers catch regressions
• Think big: find ways to run tests against the entire plugin directory (e.g. with Tide)

[adamsilverstein]

oEmbed Lazy Loading
Focuses on metric: INP, LCP

• Ensure iframe lazy loading works accurately, optimize heuristics
• Lazy loading tag based oEmbeds
• Module proposal - Module Proposal: oEmbed Optimizer #888

AVIF support
Focuses on metric: LCP

• depends on Edge adding support
• may depend on <picture> element support for adoption

[felixarntz]

Speculative prerendering and prefetching
Focuses on metric: LCP, INP

• Implement support for Speculation Rules API (also see slide deck, Speculative prerendering #908) to prerender or prefetch URLs in a smart way
• Assess effectiveness and reliability of the different configurations via Performance Lab usage
• Provide API for plugins to include/exclude routes for prefetch and/or prerender
• Consider opportunities using current link tags approach for prefetching and prerendering

Interactivity API enhancements
Focuses on metric: INP

• Explore how Interactivity API (see Epic: Interactivity API - public 1.0 version gutenberg#56803) can be used to encourage and simplify INP best practices, i.e. avoid long tasks blocking the main thread (potentially using web workers? related to @joemcgill's web worker API proposal above)
• Collaborate on the API to make relevant enhancements as needed, address any developer or performance pain points (related to @swissspidy's Interactivity API adoption proposal above)

[felixarntz]

Thank you everyone for contributing ideas! 🙌

Closing this issue now as initially announced. We'll start a draft for the roadmap very soon and will share for public review. Let's aim to get it published before end of the month.