4 ms·

> Concatenating / bundling your assets is probably still a good practice, even on H/2 connections. Obviously this comes on balance with cache eviction costs and

> Concatenating / bundling your assets is probably still a good practice, even on H/2 connections. Obviously this comes on balance with cache eviction costs and splitting pre- and post-load bundles. I guess this latter part refers to the trade-off between compiling all your assets into a single file, and then requiring clients to re-download the entire bundle if you change a single CSS color. The other extreme is to not bundle anything (which, I gather from the article, is the standard practice since all major browsers support HTTP/2) but this leads to the described issue. What about aggressively bundling, but also keeping track at compile time of diffs between historical bundles and the new bundle? Re-connecting clients could grab a manifest that names the newest mega-bundle as well as a map from historical versions to the patches needed to bring them up to date. A lot more work on the server side but maybe it could be a good compromise? Of course that's the easy version, but it has a huge flaw which is all first-time clients have to download the entire huge mega bundle before the browser can render anything, so to make it workable it would have to compile things into a few bootstrap stages instead of a single mega-bundle. I am clearly not a frontend dev. If you're going to throw tomatoes please also tell me why ;) * edit: found the repo that made me think of this idea, https://github.com/msolo/msolo/blob/master/vfl/vfl.py https://github.com/msolo/msolo/blob/master/vfl/vfl.py but it's from antiquity and probably predates node and babel/webpack, but the idea is you name individual asset versions with a SHA or tag and let them be cached forever, and to update the web app you just change a reference in the root to make clients download a different resource dependency tree root (and they re-use unchanged ones) *

staticassertion 4y ago
There's probably some balance here. Since there's a limit of 9 concurrent requests before throttling occurs you can bucket 9 objects, concatenating into each. So if you have a bunch of static content, concat that into 1 bucket. If you have another object that changes a lot, keep that separate. If you have two other objects that change together, bucket those, etc. Seems like a huge pain to think about tbh. Seems like part of the problem would be solved by compiling everything into a single file that supported streaming execution.
philsnow 4y ago
Another tool that bears on this idea is courgette [0], in that it operates on one of the intermediate representations of the final bundle in order to achieve better compression. https://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html https://blog.chromium.org/2009/07/smaller-is-faster-and-safe...
Klathmon 4y ago
There's a good middle ground of bundling your SPA into chunks of related files (I prefer to name them the SHA hash of the content), and giving them good cache lifetimes. You can have a "vendor" chunk (or a few) which just holds all 3rd party dependencies, a "core components" chunk which holds components which are likely used on most pages, and then individual chunks for the rest of the app broken down by page or something. It speeds up compilation, gives better caching, no need for a stateful mapping file outside of the HTML file loaded (which is kind of the point of the <link> tag anyway!), and has lots of knobs to tune if you want to really squeeze out the best load times.

staticassertion 4y ago

There's probably some balance here. Since there's a limit of 9 concurrent requests before throttling occurs you can bucket 9 objects, concatenating into each. So if you have a bunch of static content, concat that into 1 bucket. If you have another object that changes a lot, keep that separate. If you have two other objects that change together, bucket those, etc. Seems like a huge pain to think about tbh. Seems like part of the problem would be solved by compiling everything into a single file that supported streaming execution.

philsnow 4y ago

Another tool that bears on this idea is courgette [0], in that it operates on one of the intermediate representations of the final bundle in order to achieve better compression. https://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html https://blog.chromium.org/2009/07/smaller-is-faster-and-safe...

Klathmon 4y ago

There's a good middle ground of bundling your SPA into chunks of related files (I prefer to name them the SHA hash of the content), and giving them good cache lifetimes. You can have a "vendor" chunk (or a few) which just holds all 3rd party dependencies, a "core components" chunk which holds components which are likely used on most pages, and then individual chunks for the rest of the app broken down by page or something. It speeds up compilation, gives better caching, no need for a stateful mapping file outside of the HTML file loaded (which is kind of the point of the <link> tag anyway!), and has lots of knobs to tune if you want to really squeeze out the best load times.