| > for a page with 2.4MB of JS spread over 296 files. Fair point, there is always sweet spot in benchmarks like this. That said there are examples of delays that they mention which seem to be independent of the amount of requests. >> I believe you misread. They use a shallow tree in their scout js file; all of the resources a page will need are declared there Being shallow doesn't fix the problem when resources are split up at all and that's what the article (correctly) suggests to benefit from HTTP/2 features. As we move away from a single bundle.js file we need to think more about how to manage splits. E.g. The article talks about splitting into `application` and `vendor` hashes, and you mention grouping by churn or functionality. So presumably we agree that being able to split files without significant speed loss is a major feature of HTTP/2. All I'm suggesting is that the filename hashing strategies need to be improved to avoid application errors when splitting. If we don't improve filename hashing strategies then we'd still have to rely on small HTTP cache durations, or we'd get temporary errors while caches expire, which is a problem because the whole point of the article is to have extremely long cache durations. As they say, "Files loaded by the scout can have extremely long cache times because [...]" Then as the article says, "This can be solved by using hashes of the file contents rather than version numbers: vendor-d41d8cd98f.js. If a file has not changed, its hash will remain the same." This is bad advice because they don't talk about dependencies affecting hashes. Even if that file hasn't changed but it depends on another file then its hash needs to change too, or else application.js will will have different contents depending on when it was loaded. Eg. application.js has a requirejs import of vendor.js requirejs(["vendor.js"], function(vendor){
}); So if we generated a naive hash as suggested then application-45345345345.js might look like, requirejs(["vendor-3455345ABCDFFF.js"], function(vendor){
}); Then vendor.js changes but application.js doesn't, and so application-45345345345.js is updated to read, requirejs(["vendor-f2ab4cde6f55.js"], function(vendor){
}); And now you can see the problem that application.js didn't change but it's dependencies did, so application-45345345345.js will have different data depending on when you access it which is exactly what you don't want with long HTTP cache durations. This can cause mismatches in what version of a file is imported, and cause application errors. The only way to have permanent URLs with content that doesn't change (a prerequisite for long HTTP cache durations) is to include dependencies in the calculation of filename hashes. Or you could have an dynamic resolver (eg. based on a manifest file) but ES6 and SVG have static imports. More to the point though, if you can resolve it at build time why not? When they say "This can be solved by using hashes of the file contents" this is a fundamental mistake and it's simply bad advice. |
If you do not include the hash of application.js in its filename then I think the main problem is whoever decided to use hashes for some scripts but not for others.
That being said, I don't use gulp and all that stuff. It seems to me that some people get so caught up in technology that they
1) Reinvent the wheel a million times. I admit that make has its short comings but I think a similarly general build tool is the way to go. Look into tup, they know what's up.
2) Don't notice that they are sitting atop a tower of abstractions and that their tower is starting to become unstable.
3) Are pulling in massive amounts of scripts as dependencies to build something that could've been implemented with little to no scripting at all, and with their high bandwith workstations and latest computers and devices they don't notice the fact that while they are trying to reduce load times (which by itself is a worthy goal) the browsers of their visitors are crashing because rendering these websites take more ram than is available on many devices. Jesus, fuck!
So that was a bit of a rant. Sorry about that, I guess.