Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicit JavaScript Compile Hints (file-based) #174

Open
marjakh opened this issue Oct 4, 2024 · 11 comments
Open

Explicit JavaScript Compile Hints (file-based) #174

marjakh opened this issue Oct 4, 2024 · 11 comments

Comments

@marjakh
Copy link

marjakh commented Oct 4, 2024

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
Copy link

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

Screenshot 2024-10-04 at 12 32 37 PM

@ljharb
Copy link

ljharb commented Oct 5, 2024

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

@Gaubee
Copy link

Gaubee commented Oct 5, 2024

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
Copy link

ljharb commented Oct 5, 2024

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
Copy link

Gaubee commented Oct 5, 2024

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
Copy link
Author

marjakh commented Oct 5, 2024

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
Copy link
Collaborator

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
Copy link
Author

marjakh commented Oct 7, 2024

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
Copy link

kurtextrem commented Oct 8, 2024

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
Copy link

mmocny commented Oct 8, 2024

Potentially related: https://github.com/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
Copy link
Collaborator

WICG hat on

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants