3 ms·

Another strategy is to make the files cacheable, and have some version naming scheme to invalidate caches. You can also lazy load features as most users will li

by z3t4 7y ago

Another strategy is to make the files cacheable, and have some version naming scheme to invalidate caches. You can also lazy load features as most users will likely only visit the front page and then leave after 3 seconds. No need to have users wait for functionality they wont use.

deleted 7y ago
[deleted]
hinkley 7y ago
Several of the bundling tools have had a way to emit the file with a hash of the contents on the end of the filename, rather than using version numbers. One of the places this helps you is when you push out a one line javascript bug fix without invalidating your CSS caching across the entire site, because the CSS files are identical. It also helps you with people with the website open when the new code gets pushed. They either have all the old code or all the new code and no bizarre mishmash of the two.
- z3t4 7y ago
  With making the files cache-able I mean not bundling them. The first load will be longer (unless you use lazy loading), but successive page loads will get the files from cache, and if there's an update, only that file will update. It's not usual to have updates shipped several times per day, and if there's many users there will also be many unnecessary reloads of the bundle. It's a bit of a optimization as to be 100% sure users always get the latest files the version naming scheme is needed, but most of the time it will work anyway, eg. if you have no caching layers /CDN etc in-front of the web server. So if you want to shave off milliseconds on first load, go with the bundle, but if you want to save user's bandwidth and make your site/app more lightweight - don't bundle!
  - vimslayer 7y ago
    Most bundlers have ways of splitting the bundle into smaller pieces that can be cached (and cache-busted with the hash in filename) independently. I think that's what the parent commenter was talking about. So you don't have to choose between one huge bundle and hundreds of individual non-bundled files, with code splitting and lazy loading, you can do something in the middle and have like 3-30 "minibundles". Then, if you make a modification that only affects one of those bundles, only that bundle needs to be reloaded and others can still be served from cache.

by z3t4 7y ago

deleted 7y ago

[deleted]

hinkley 7y ago

Several of the bundling tools have had a way to emit the file with a hash of the contents on the end of the filename, rather than using version numbers. One of the places this helps you is when you push out a one line javascript bug fix without invalidating your CSS caching across the entire site, because the CSS files are identical. It also helps you with people with the website open when the new code gets pushed. They either have all the old code or all the new code and no bizarre mishmash of the two.

z3t4 7y ago
With making the files cache-able I mean not bundling them. The first load will be longer (unless you use lazy loading), but successive page loads will get the files from cache, and if there's an update, only that file will update. It's not usual to have updates shipped several times per day, and if there's many users there will also be many unnecessary reloads of the bundle. It's a bit of a optimization as to be 100% sure users always get the latest files the version naming scheme is needed, but most of the time it will work anyway, eg. if you have no caching layers /CDN etc in-front of the web server. So if you want to shave off milliseconds on first load, go with the bundle, but if you want to save user's bandwidth and make your site/app more lightweight - don't bundle!
- vimslayer 7y ago
  Most bundlers have ways of splitting the bundle into smaller pieces that can be cached (and cache-busted with the hash in filename) independently. I think that's what the parent commenter was talking about. So you don't have to choose between one huge bundle and hundreds of individual non-bundled files, with code splitting and lazy loading, you can do something in the middle and have like 3-30 "minibundles". Then, if you make a modification that only affects one of those bundles, only that bundle needs to be reloaded and others can still be served from cache.