-
Notifications
You must be signed in to change notification settings - Fork 83
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
Concerns about loading ES modules #228
Comments
Importing the modules directly from
To clarify things, HTTP/2 is about reusing the same connection for multiple requests. Though multiple requests still cause some overhead due to their headers in comparison to a single one.
Right, for anyone wanting to follow implementations in other browser engines, see https://wkb.ug/180574 and https://bugzil.la/1425310.
I'll try it again and provide some numbers. Sebastian |
Issue #216 is about refactoring the projet to use modern JavaScript features. PR #227 was the first part towards this goal, by introducing the first ES modules. We started considering the impact on performance so i'm pasting some previous comments to move the discussion here.
@PolariTOON wrote in #219:
@PolariTOON wrote in #227:
@LeaVerou wrote in #227:
@SebastianZ wrote in #227:
Let me reply to some of these comments:
This is not about importing the same module twice, but about the depth of the request graph which now looks like this:
This means that the browser have to wait for
csstest.js
to be fetched and parsed to fetchtests.js
, and then wait again for it to be parsed to fetch all the modules undertests/
. To allow the browser to load the page faster, we have to let it discover the files earlier. This can be achieved by reducing the depth of the module graph -- for example, importing all the modules from the top-level module (csstest.js
currently) -- or even better (in theory), by declaring them in the HTML code via<link rel="modulepreload">
.Indeed, once the browser knows about the files under
tests/
, these ones can be fetched in parallel and it's fine with the help of HTTP/2.As far as i know, only Blink browsers support module preloading currently so it's normal not to see any improvement in Firefox. As for Chrome, i guess the gain should only be visible if all the dependencies are preloaded. According to the waterfall below, this should save about 300ms, but this should not change the "Time taken" measurement on the page because it only counts the execution time and not the roundtrips between the client and the server.
Before #227:
After #227:
The text was updated successfully, but these errors were encountered: