Open Judahmeek opened 9 months ago
I've not got a lot of experience with asset serving via webpack but happy to dig further into it; though generally the idea is that it's better to have more requests for smaller assets so that they can be cached independently, and that HTTP/2+ helps enable this by lowering the cost of repeated connections (via TCP connection reuse).
In practice HTTP/2+ is still not universal enough to start saying "stop bundling everything into a single big blob", but it's enough that it's worth considering (this is one of the "advantages" of importmaps...).
I think ultimately it's probably worth making an option so people can optimize based on their expected audience - I'll have a play around with some of our apps to see what kind of difference this makes
I've tested this in a toy repo and can't see any obvious breakage. Effectively it just inlines things that are smaller than 8kb (I think).
Agree with @G-Rath on "more requests are better" bit, generally. With the sizes we're talking about here, it might not be the biggest problem in the world though.
My preference would be probably leave the default as is, but document and allow change through opt-in if one wants to fine-tune the performance. The latter might lead us nicely back to https://github.com/shakacode/shakapacker/issues/80
@justin808 what's your opinion, given G-Rath & Tom's feedback?
@G-Rath @tomdracz Can either of you think of any possible issues with changing Shakapacker's default asset rule to use
asset
instead ofasset/resource
?According to Webpack's documentation on asset modules rules, this would inline smaller assets, reducing the number of fetch cals from the client in exchange for a slight increase in bundle size.