The next stage: help, I am trapped in a Webpack prison of my own construction. Writing my JavaScript requires 20gb of RAM and kernel settings changes. Sometimes I have to restart webpack to fix JS errors in my console. I can’t upgrade to webpack X+1 to get get performance fixes because my configuration only works in webpack X.
Requesting this many scripts was a major network bottleneck, and as a result my site took a long time to load. Web performance matters — its importance has long been well-known and documented. What seems more efficient to you: downloading 1000 lines of code 10 lines at a time, or downloading 1000 lines of code all at once?
…What?
I know we need to measure things and not go with intuition on performance, but my intuition is that 22 scripts — in the grand scheme of things — is not particularly many. I mean, the webpage that this blog post is written on makes 77 requests, with the first ~25 of those happening in the first couple of seconds.
Did he actually measure this “speed problem”? Was downloading 22 scripts verifiably a “major network bottleneck”?
I suspect it was a “time to first paint” issue, which would certainly make it feel like what the author describes. I agree that it is an imprecise way to say it though.
good point - I didn’t measure the speed problem but probably should’ve. It’s much less of / not a problem now with http 2, but back in 2016 this was a bit more relevant. Regardless, “major network bottleneck” is an exaggeration and I’ll edit this a bit for clarity. Appreciate the feedback!
I appreciate this post, because while a lot of this is rudimentary information if you’ve been working with javascript for any length of time, it so often just glossed over in tutorials and blogs. “Oh just use create-react-app/[other scaffolding tools]” or “just bundle here is a conf” is a pragmatic answer, but doesn’t explain much about why those bundling, splitting, minifying, and etc. steps are desirable from first principles.
It’s not as big of a problem if you know all of them up front. But ES modules don’t let you know this without using a bundler or bundler-like tool. See this post for why http/2 doesn’t solve the problem: https://engineering.khanacademy.org/posts/js-packaging-http2.htm
Thanks for the pointer! I hadn’t seen this before and haven’t been able to find good information on browser support yet. Do you know how well supported it is?
Additionally, it fails to solve two of the problems with just serving ES modules:
You still need to provide a static list of modules, so you’ll need a tool to convert your dependency graph into that list (a bundler?)
By splitting everything into multiple files, you lose compression efficiency. Assuming you need everything anyway, shipping as a single (or small number) of bundles will produce the best results.
Yeah it seems to be a little difficult to find information on. I know there’s support in Chromium, but not sure it’s in the others just yet. I’ve only experimented with this a little on small projects and nothing in production so I’m still trying to get my head around how it would work when things get larger and more complex! In that case bundling probably will always be a good idea. Also agree with the point about compression. Below a certain size it’s probably not a big issue, but there will definitely be a point where you need to consider that.
My hope is just that eventually I will be able to use this and avoid complex build steps for smaller projects with a manageable number of modules.
I have been using the default webpack config that vuecli set up. Has been working well for me. Also I wonder what the performance penalty of multiple files is now with http 2. On the first request the server can send the html and every js/css file at the same time so you don’t have multiple round trips
What seems more efficient to you: downloading 1000 lines of code 10 lines at a time, or downloading 1000 lines of code all at once?
This is a terrible way to explain something. You can’t download 1000 lines all at once. They all come one bit at a time. Also just vague feelings about speed are not useful. Measure the speed before and after the change and then use the results to make your decision. It certainly was true however that multiple JS files did cause slowdowns because browsers would only request a limited number of resources at the same time but I doubt it has much of an effect at all anymore. If I was writing a blog post and posting it here I would actually test this claim however.
The next stage: help, I am trapped in a Webpack prison of my own construction. Writing my JavaScript requires 20gb of RAM and kernel settings changes. Sometimes I have to restart webpack to fix JS errors in my console. I can’t upgrade to webpack X+1 to get get performance fixes because my configuration only works in webpack X.
…What?
I know we need to measure things and not go with intuition on performance, but my intuition is that 22 scripts — in the grand scheme of things — is not particularly many. I mean, the webpage that this blog post is written on makes 77 requests, with the first ~25 of those happening in the first couple of seconds.
Did he actually measure this “speed problem”? Was downloading 22 scripts verifiably a “major network bottleneck”?
I suspect it was a “time to first paint” issue, which would certainly make it feel like what the author describes. I agree that it is an imprecise way to say it though.
good point - I didn’t measure the speed problem but probably should’ve. It’s much less of / not a problem now with http 2, but back in 2016 this was a bit more relevant. Regardless, “major network bottleneck” is an exaggeration and I’ll edit this a bit for clarity. Appreciate the feedback!
I appreciate this post, because while a lot of this is rudimentary information if you’ve been working with javascript for any length of time, it so often just glossed over in tutorials and blogs. “Oh just use create-react-app/[other scaffolding tools]” or “just bundle here is a conf” is a pragmatic answer, but doesn’t explain much about why those bundling, splitting, minifying, and etc. steps are desirable from first principles.
With HTTP/2 many small files is not a problem. Just ship ES Modules directly to browsers. More granular caching, less dev tools.
yeah, the small files problem was more relevant in 2016
It’s not as big of a problem if you know all of them up front. But ES modules don’t let you know this without using a bundler or bundler-like tool. See this post for why http/2 doesn’t solve the problem: https://engineering.khanacademy.org/posts/js-packaging-http2.htm
Use modulepreload to preload all the module files:
https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload
Thanks for the pointer! I hadn’t seen this before and haven’t been able to find good information on browser support yet. Do you know how well supported it is?
Additionally, it fails to solve two of the problems with just serving ES modules:
You still need to provide a static list of modules, so you’ll need a tool to convert your dependency graph into that list (a bundler?)
By splitting everything into multiple files, you lose compression efficiency. Assuming you need everything anyway, shipping as a single (or small number) of bundles will produce the best results.
Yeah it seems to be a little difficult to find information on. I know there’s support in Chromium, but not sure it’s in the others just yet. I’ve only experimented with this a little on small projects and nothing in production so I’m still trying to get my head around how it would work when things get larger and more complex! In that case bundling probably will always be a good idea. Also agree with the point about compression. Below a certain size it’s probably not a big issue, but there will definitely be a point where you need to consider that.
My hope is just that eventually I will be able to use this and avoid complex build steps for smaller projects with a manageable number of modules.
I have been using the default webpack config that vuecli set up. Has been working well for me. Also I wonder what the performance penalty of multiple files is now with http 2. On the first request the server can send the html and every js/css file at the same time so you don’t have multiple round trips
This is a terrible way to explain something. You can’t download 1000 lines all at once. They all come one bit at a time. Also just vague feelings about speed are not useful. Measure the speed before and after the change and then use the results to make your decision. It certainly was true however that multiple JS files did cause slowdowns because browsers would only request a limited number of resources at the same time but I doubt it has much of an effect at all anymore. If I was writing a blog post and posting it here I would actually test this claim however.
hey, thanks for the feedback, I’m going to tweak the wording to hopefully be clearer