WordPress.org
Get WordPress

Make WordPress Core

Opened 12 months ago

Last modified 4 months ago

#61027 new enhancement

Bundled themes: edit front-end JS to work with Interactivity API

Reported by: adamsilverstein's profile adamsilverstein Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords:
Focuses: performance Cc:

Description (last modified by sabernhardt)

Note:

  • Leveraging the Interactivity API for core themes will help us test and consume our own APIs.
  • The Interactivity API will already be enqueued if any block leveraging the API is used (Query, expanding Search and Navigation for example)
  • Existing code would stay in place for cases where the theme is used on WordPress < 6.5.

Change History (13)

This ticket was mentioned in ​PR #5795 on ​WordPress/wordpress-develop by ​@flixos90.
12 months ago #1

  • Keywords has-patch added

This PR uses the Interactivity API to replace the custom frontend JS code for the Twenty Twenty-One theme. More concretely:

  • Uses the Interactivity API module if available (requires WordPress 6.5 or newer).
  • Adds a store for handling state and a few other dynamic aspects (in interactivity.js module).
  • Avoids loading the regular frontend JS code (primary-navigation.js, responsive-embeds.js, dark-mode-toggler.js) as it replaces those functionalities.

One important consideration: Since the server-side portion of the Interactivity API does not process this content automatically (unlike blocks, which are processed server-side), it is important to hydrate any dynamic attributes to have the correct initial state. For example, if you add data-wp-bind--aria-expanded="state.something" to a tag, you should also set the actual aria-expanded="true|false" attribute depending on what the initial value of state.something is expected to be.

This is an experimental PR, primarily as a proof of concept and to get a better idea of how the API works, and what _should_ or _should not_ be done with it.

To test it, you need to have the Gutenberg plugin activated. You should then see a script[type="module"] pointing to the new Twenty Twenty-One interactivity.js file in the <head>.

A few observations:

  • 196 lines of custom JS (with Interactivity API) vs 314 lines of custom JS (manual approach)
  • 2.1 kB custom JS (with Interactivity API) vs 4.5 kB custom JS (manual approach)
  • 15.5 kB overall JS (with Interactivity API) vs 4.5 kB overall JS (manual approach)
    • While in this example the Interactivity API itself leads to a net increase in JS, it has to be considered that the benefits will become better the more code uses the API. For instance, a site with just a default WordPress theme is hardly realistic, and the amount of JS typically increases heavily the more plugins are used. With several sites loading 100s of kilobytes of JS, the size of the Interactivity API itself would play a minor role compared to the reduction of custom JS code gained from it (see the amount of custom JS as an indicator for that).

Unrelated: While working on this, I discovered and reported https://core.trac.wordpress.org/ticket/60111 which I think is a bug.

Trac ticket: https://core.trac.wordpress.org/ticket/61027

#2 @adamsilverstein
12 months ago

  • Keywords has-patch removed

I see @flixos90 already started working on this in ​https://github.com/WordPress/wordpress-develop/pull/5795

#3 @sabernhardt
12 months ago

  • Summary changed from Twenty Twentyone: Replace frontend jQuery usage with Interactivity API to Twenty Twenty-One: Replace front-end JS with Interactivity API

Summary edit: TT1 only uses jQuery with Customizer scripts ('twentytwentyone-control-color', 'twentytwentyone-customize-controls', and 'twentytwentyone-customize-preview').

#4 @sabernhardt
12 months ago

  • Description modified (diff)
  • Summary changed from Twenty Twenty-One: Replace front-end JS with Interactivity API to Bundled themes: edit front-end JS to work with Interactivity API
  • Type changed from defect (bug) to feature request

Let's discuss any possible integrations in (classic) bundled themes on this ticket.

#5 @sabernhardt
12 months ago

#60986 was marked as a duplicate.

#6 @sabernhardt
12 months ago

#60985 was marked as a duplicate.

#7 @sabernhardt
12 months ago

#60987 was marked as a duplicate.

This ticket was mentioned in ​Slack in #core-performance by mukeshpanchal27. ​View the logs.
12 months ago

#9 @karmatosed
8 months ago

  • Keywords has-patch added

#10 @flixos90
6 months ago

  • Keywords has-patch removed
  • Milestone changed from Awaiting Review to Future Release
  • Type changed from feature request to enhancement

Per the latest iteration on the ticket summary, we should probably use this as an overarching ticket for work that should span across multiple sub-tickets (one ticket per theme).

We already have a few related Trac tickets with the original purpose of replacing jQuery in classic default themes with vanilla JS. Given the direction of the Interactivity API, it would IMO make sense to repurpose these tickets as a part of this effort. For reference, here is an older Make Themes post about the original effort: ​https://make.wordpress.org/themes/2021/10/04/the-performance-impact-of-using-jquery-in-wordpress-themes/

By replacing jQuery with the Interactivity API in those older themes, we would solve two problems at once: Migrate away from jQuery, and facilitate adoption of the more performant Interactivity API.

We will need tickets for the following themes:

  • Twenty Twelve (jQuery): #54171
  • Twenty Thirteen (jQuery): …
  • Twenty Fourteen (jQuery): …
  • Twenty Fifteen (jQuery): #60985
  • Twenty Sixteen (jQuery): #55126
  • Twenty Seventeen (vanilla JS): …
  • Twenty Nineteen (vanilla JS): …
  • Twenty Twenty (vanilla JS): …
  • Twenty Twenty-One (vanilla JS): …

Let's not open other tickets just yet, to avoid additional ticket overhead while this effort may still be stale. I think opening tickets would be best to do on demand as contributors want to own the effort for one of the themes.

Worth highlighting: When I say "replace jQuery or vanilla JS", I really mean "conditionally replace". We need to continue to support older WordPress versions where the Interactivity API was not available yet. Since the interactive features of the default themes have been quite simple and have rarely required updates throughout the years, I think it's reasonable to have two alternative versions of the implementation in each theme that is conditionally loaded based on whether or not the Interactivity API is available on the site.

Last edited 6 months ago by flixos90 (previous) (diff)

#11 @samiamnot
6 months ago

@flixos90 , Twenty Fifteen - #60985 (was reopened)

#12 @flixos90
6 months ago

Thank you @samiamnot, I had forgotten about that one. I closed #54172, since #60985 is closer to the goal.

This ticket was mentioned in ​Slack in #core-performance by mukeshpanchal27. ​View the logs.
4 months ago

Note: See TracTickets for help on using tickets.