4 ms·
Yes. https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 To quote the article: There is still a pro
by joshribakoff 9y ago
Yes.
https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 https://medium.com/webpack/webpack-http-2-7083ec3f3ce6
To quote the article:
There is still a protocol overhead for each request compared to a single concatenated file.
The compression of the single large file is better than many small files.
Servers are slower serving many small files than a single large file.
- danjoc 9y agoI'm really less interested in speed though. I want to optimize for file transfer bandwidth. Going all mobile data for a week has shown me two problems. JS has severely bloated websites, and staying up to date with software patches is expensive. In both cases, the amount of new material being transferred is very low. A point update on a JS library or patch is a few lines change, but we must download the entire library again. Compounding this for JS is every site using the same libs are sending the same data, because of browser origin policies. One way around that is CDNs, but then you are submitting to a centralized point of failure/spying. Sending the whole file again is the easiest route for developers, but the most expensive for mobile only cord cutters.
- joshribakoff 9y agoWebpack does that with chunk hash. Common chunks go into common.js, and my app goes into app.js, if I change my app's JS, only app.js gets downloaded which is probably 50kb whereas common.js is maybe 300kb. The point is there is a tradeoff between speed & efficiency. If every line of code were its own file, you'd have a high amount of efficiency when only 1 line changes, but loading that would be a nightmare on mobile.