Explicit JavaScript Compile Hints (file-based)

[marjakh]

Introduction

This proposal introduces a new magic comment that signals to browsers that the functions in a JavaScript file are likely to be needed by the website. This allows the browser to parse and compile them eagerly, which can improve page load times.

Read the complete Explainer

Feedback

Please provide all feedback below.

[miketaylr]

https://x.com/cramforce/status/1842215550862401944 documents interest from Vercel (screenshot for posterity):

[ljharb]

Why would there be JS code in a website that isn't likely to be used?

[Gaubee]

Why would there be JS code in a website that isn't likely to be used?

@ljharb

For example, in a Web-Photoshop application, users are likely to use only a portion of its features.

However, the key point of this proposal is to prioritize the compilation of certain functions, similar to Android's Baseline Profiles, which mark the most critical functions during the app's startup phase to enhance the user experience. For instance, in a Web-Photoshop application, priority should be given to functions related to "file opening, file encoding/decoding, and UI rendering," thus speeding up the display of PSD files to the user.

[ljharb]

In an application like that, for developers that are knowledgeable enough to add these hints, why wouldn't they be using dynamic and/or deferred loading already to load unlikely-to-be-used files on demand, or lazily?

[Gaubee]

Lazy loading is certainly feasible, but it comes with its own costs.
Frameworks like Qwik take this to the extreme, but choosing such a framework for development itself incurs a cost, especially for projects that cannot switch frameworks.
Or use bundle tools to splitting codes, there is still a development cost involved, not to mention that import is an asynchronous function, which can affect the execution flow of some projects.
Additionally, there are deployment costs. Splitting into multiple files, even with HTTP/2 multiplexing, still incurs higher costs compared to a single file.

I think this proposal is meaningful because lazy loading is an indirect approach to make the browser focus on compiling the JS files that have already been downloaded. And this proposal, can directly addresses the need for "priority compilation."

[marjakh]

Indeed, the current state of the world is such that web sites ship a lot of code which is unused for the initial page load. All major browsers implement lazy parsing & compilation (with various heuristics) and I don't see that changing any time soon. This proposal is only about making the lazy/eager hints explicit. It makes the browser compile more eagerly than currently (not more lazily).

Loading everything unneeded by the initial page load on demand is probably not realistic because of latency: it's too late to start loading the JS when the user initiates an interaction.

And even if a website only shipped the critical code and everything else was loaded on demand, there's currently no non-hacky way to signal that to the browser, so the browsers would anyway need to assume there's a lot of unused code and do lazy parsing & compilation. Only if the majority of the web pages switched to that model, the browsers could consider tweaking their heuristics to be more eager (e.g., eager compile everything up to a quota).

You can also see the magic compile hint as a declaration "we've optimized the web page, this file (these functions) are really the important ones, and the rest will be loaded on demand" and at that point the browser can make them eager.

[yoavweiss]

Puts Shopify hat on

Shopify is supportive of this feature. We would be interested in providing these hints to the browser. It would have been great to see some improvement numbers from the relevant experiments though, as that could have helped us prioritize the related work.

[marjakh]

If you send me a link to a representative page (which can be loaded without logging in / without the cookie banner being too annoying), I can even benchmark it for you and measure how much we can save by selecting the optimal functions for eager compilation.

[kurtextrem]

Framer would also be interested. We bundle functions that get executed for sure. We also have React around in the bundle.
I participate in WebPerfWG calls and can also provide feedback there if needed/wanted.

An example URL of a page built using Framer is our own homepage: https://www.framer.com. Really curious how the results would look like.

[mmocny]

Potentially related: https:/mmocny/proposal-async-event-listeners, use case 4 and 5.

I agree with a lot of the points raised in this proposal and this thread, though I wonder if the mechanism by which hints should be provided should at a different layer: registering (optional, lazy) event listeners in the first place.

I think that functionality of a page is either necessary for loading & bootstrapping the default experience, or lazy and optional, depending on specific user input.

I am keen to see this work progress!

[yoavweiss]

WICG hat on

Given the support, I think we can move this incubation to the WICG.