Investigate INP improvements

[adamsilverstein]

Overview

INP is the new metric for interactivity that is one of the Core Web Vitals. The goal of this issue is to track work on issues raised in the INP research document and develop mitigations or suggestions for improvements.

Details

Core

• Core-provided jQuery is often the wrapper code for user land code. This results in tooling misattributing issues to jQuery directly, when in actuality it's user code built on top of jQuery.
• React dependency on wp-polyfill and regenerator-runtime is outdated and can be removed, work already started on this in https://core.trac.wordpress.org/ticket/60962
• wp-embed.min.js shows up again because of the attribution issue, the real issue is likely with the embeds themselves
• Common elements like carousels and forms show up in the data, these should/are be/ing proposed for Gutenberg as canonical blocks.
• Interactivity API is a hopefully path forward to letting developers move away from jQuery, for the interactivity API we can:
  • Work on adding performance telemetry/debugging features
  • Upgrade core themes that rely on jQuery to use the Interactivity API instead when available

Plugins

Many of the issues noted in the research document are related to specific plugins.

• Investigate these plugins and suggest specific fixes if they operate public repositories.
• Several optimization plugins use the lazysizes script which is causing issues, we should investigate an upstream fix or dropping use when not needed (eg native lazy loading, improved sizes)
• Several themes were also identified for further investigation.
• Publish a post on the WordPress developers blog explaining common approaches for fixing INP.

Third parties

• Embed issues with providers like TikTok and Youtube can be addressed in the Embed Optimizer plugin
• Typekit JS code showed up as an issue, we should propose TypeKit support for the new Fonts API (if not already planned or discussed)
• Tags for chat scripts (HotJar, intercom), analytics and ads create a majority of the issues on sites and may not be something core or even plugins can improve directly (with the exception of plugin provided ads like WordAds). What we an do is provide education around or reference versions of optimized implementations as well as tooling to help users or developers better understand the impact of third party code.

Task tracking

• Remove React dependency on wp-polyfill and regenerator-runtime - https://core.trac.wordpress.org/ticket/60962

... more items to be added as they are created ...

[westonruter]

• Tags for chat scripts (HotJar, intercom), analytics and ads create a majority of the issues on sites and may not be something core or even plugins can improve directly (with the exception of plugin provided ads like WordAds).

This also adds some pressure to explore the Partytown band aid (#176) to mitigate the symptoms of these third party script performance problems.

[jazir555]

Tags for chat scripts (HotJar, intercom), analytics and ads create a majority of the issues on sites and may not be something core or even plugins can improve directly (with the exception of plugin provided ads like WordAds). What we an do is provide education around or reference versions of optimized implementations as well as tooling to help users or developers better understand the impact of third party code.

The common mitigation for optimizing third party code performance is to delay their Javascript from loading until user interaction (scroll, click, tap, mouse movement etc). This negates their performance impact as the code is not downloaded at all in the initial render and not loaded until needed. Plugins like Perfmatters or Debloat utilize this method. Could javascript delay functionality be built into core at an API level and exposed to developers?

[westonruter]

@jazir555 sounds like a good area to investigate. In addition to delaying the download until user interaction, this should also yield to the main thread before executing the script as well.

[jazir555]

@jazir555 sounds like a good area to investigate. In addition to delaying the download until user interaction, this should also yield to the main thread before executing the script as well.

Another complementary strategy is to locally host the third party code. There are many plugins which do this for various types of resources. Locally hosting files eliminates network latency as no additional connections have to be established with a third party domain, which improves performance.

Some examples:

CAOS (Locally Host Google Analytics): https://wordpress.org/plugins/host-analyticsjs-local/

OMGF (Locally Host Google Fonts): https://wordpress.org/plugins/host-webfonts-local/

There is even an unmaintained plugin to locally host any third party js/css file.

HELL (Host Everything Locally): https://github.com/Dan0sz/host-everything-locally

But I think that can be taken even further. I propose that core should add the ability to locally host any file type via a dedicated Wordpress API. There could be a settings panel where urls for resources could be manually added, as well as the ability to automatically download external resources to be served locally. This would be especially useful for filetypes none of the above plugins can locally download, such as non-google fonts, as well as SVGs, video, etc.

This would require some sort of search and replace functionality to update the urls within the html to ensure plugins and themes are serving the locally hosted copy of the file, and to eliminate the external HTTP requests to the third party server.

In the case of SVGs and Font Files, this opens up some interesting capabilities, as it would then be possible to compress the SVGs, and also optimize the font files (font subsetting, font filetype conversion to WOFF2, glyph stripping, etc).