The history of delay Javascript feature & why avoid it

Historically, the delay Javascript feature has been linked to the Wordpress world.

It was a way to have more control of third-party javascript since many third-party plugins are used in Wordpress and installed(loaded) by their proprietary plugin, differently from other platforms, where you inline their Javascript in some code injection feature and have more control of how the Javascript loads.

Third-party Wordpress plugins are known to not care about performance and make anything(load priority of their Javascript) in order to have their plugin produce “better” results.

As for inserting inline code to have more control, Wordpress never had an official code injection feature. You can paste code in header.php or footer.php but it isn’t the same. This is why simply code injection plugins have millions of active installations. A lot of other plugins and even theme also offers code injection feature.

In the feature defense, Wordpress also offered no API for deferring or running the queued javascript asynchronously. Only started so in 6.3.

Shopify, which also doesn’t have an official code injection feature, also has plugins offering it with thousands of installations.

Shopify shouldn’t have this feature trending within since they have good Core Web Vitals numbers. But due to how bad Shopify scores on Lighthouse, this feature started popularizing, with apps offering it quickly reaching thousands of installations.

Wix, Squarespace, Webflow, and Framer, which officially offer code injection features in their apps, don’t seem to have popular apps/plugins with this feature(delay Javascript) yet.

And this is how it gets confusing. The feature doesn’t even address any of the Pagespeed recommendations.

It has popularized rapidly because it virtually removes all the main-thread render-blocking Javascript from cold loading since all of it is delayed.

Even if you use total blocking time as a predecessor of INP, you won’t have a guarantee of improving it, as long tasks will still run after the initial loading. This technique only fools Lighthouse snapshot mode.

The popularity of apps/plugins that delay the Javascript until user interaction exploded when in the Lighthouse v8 version TBT gains more percentage of the total scoring, going from 25% to 30%, almost ⅓ of the total score.

Why avoid Delay Javascript

As of today, TBT still has a 30% weight of the scoring.

With this scenario, you can get a score of 80/100 simply by using delay and faking your real Javascript usage:

In this scenario, you have:

• Bad LCP Core Web Vitals
• Needs Improvement CLS Core Web Vitals
• Needs Improvement FCP Web Vitals
• and Needs Improvement Speed Index metric

On desktop, a similar scenario can also happen:

• Needs Improvement LCP Core Web Vitals
• Needs Improvement CLS Core Web Vitals

But still an 80/100 score.

It not only doesn’t address real issues but also “masks” others by hiding them under a good scoring.

This is why you should avoid using this feature.

With a scenario like this still in play, we can also argue that it incentivizes the use of this feature.