4 ms·
What's the complexity cost in SPDY or HTTP/2's case? For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files
by youngtaff 12y ago
What's the complexity cost in SPDY or HTTP/2's case?
For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability.
- timboslice 12y ago>the tradeoff of getting the bundles right, which of course reduces cachability If you are revving your bundles with hashes (main.8a4ce55.js), caching shouldn't be a problem. Not sure what your build process is, but there are plugins to do this on most setups.
- youngtaff 12y agoThat's precisely the point revving bundles with hashes is about destroying cachability. When two separate resources together at build time they're being coupled from a caching point of view if one gets changed and the other doesn't they they both have to be re-downloaded because the bundle has changed.
- josteink 12y ago> For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability. And all of this is a build-time problem. If we're going to engineer the HTTP-protocol to solve build-tooling and development related problems, we might as well add JS-linting and minifying to HTTP itself as well. Seriously: This problem is best solved elsewhere.
- youngtaff 12y agoYou've got it wrong the way around these aren't build-tooling and development related problems, they're problems with HTTP/1.x that we chose to solve using the build process.
- deleted 12y ago[deleted]