Add an HTML attribute to delay JS execution after ActivationStart

[tvereecke]

I suggest the addition of a new HTML attribute to indicate whether or not a specific <script> should execute before or after activationStart.

Benefit

Having this option would have these benefits:

• Allows more aggressive eagerness values for pre rendering.
• Reduces the risk that certain data is skewed when pre-rendered pages were never activated.
• Reduces the overhead to test all 3rd party vendors on a page

Use case

I am thinking about sites having several ad providers (or analytics).

More aggressive pre-rendering options can skew analytics/ads data.

Unless all these 3rd party providers take into account activationStart I want to be able to easily control delaying them from doing any work.

[domenic]

I'm definitely in favor of this. It's an idea we've had for some time, but were kind of waiting for evidence that it would help in the real world. (In particular, we were unsure on how many third parties are manually added vs. using tag managers.) Hearing this from you helps a lot!

The biggest challenges here are surface-level ones, IMO. In particular:

• How does this interact with blocking=render, async, and defer? Probably there is a natural answer, but also, will people be upset at us for adding yet another entry into the script-scheduling matrix?
• How general should this feature be, either in the initial version, or in terms of future-proofing the design?
  • You could imagine wanting to delay other subresources (<link>, <img>, etc.) in the same way.
    • <img> already has loading=lazy, so if we were to extend, we'd want to take that into account.
  • You could imagine wanting to delay loading until other declarative triggers, e.g. delayuntil="lcp" or delayuntil="idle".

Just off the top of my head, my current favorite idea is to extend the loading="" attribute to work on <script> and include a new value, after-activation. For now, <img loading=after-activation> would not work, and <script loading=lazy> would not work. But it feels like it's in the right space.

[tunetheweb]

Some idle musings...

I wonder if "activation" is too tied to speculation rules and this should be more generic for other use cases - like after a tab opened in the background is foregrounded? after-viewed? We also ignore CWVs if page is hidden before FCP so wonder if we should combine that with some of your ideas above to be after-fcp? But not loving baking a metric name in there (metrics are constantly changing!)

[nhiroki]

This could also be useful in terms of activation performance. We saw some cases where async scripts prevent onprerenderingchange from running.

[jeremyroman]

My handwave was something like after="token token2 token3", where we could have potentially multiple things and it runs after all of them.

The interaction with async and defer is definitely slightly annoying, but I think manageable. It seems likely that some kind of asynchrony should be required (i.e., we don't block the parser until prerendering completes) though I guess that's not necessarily a given. My hunch is that it should simply imply async, full stop. But possibly we could require you specify async or defer, and be willing to block other deferred scripts on this one.

Maybe we could reuse loading, it's very close but not quite a perfect fit. One particular awkwardness is that for lazy loading it's quite likely that avoiding the fetch is the main point. For scripts after prerendering, though, we might still want to fetch (perhaps with lower priority than usual, perhaps not) and even compile the script -- just not execute it. (On the other hand, if the script is huge or something maybe we really do want to not fetch it either.)