Comment Re:Why is this a troll? (Score 1) 103
> [CSS Sprites are] only a win if your images are tiny. Why are you optimizing for this? Tiny images do not take long to download, even on dialup, because they are tiny.
The point is to reduce the number of HTTP connections, and thus avoid pointless latency. A TCP connection takes time to set up because there's a back-and-forth, and if the client is far from the server this can introduce a significant delay in loading static resources. Not to mention that the browser may have to reflow the page as the new images come in, which looks ugly. (Albeit that can be mitigated if image width/height are specified in the HTML).
> [Combined CSS/JS files are] less egregious than suggesting CSS Sprites, but it still suffers from the same problems. These are not large files, and if they are large files, the headers are not larger.
Again, the point is to reduce the number of HTTP connections, not to reduce the total header size. We did this on our site and got a pretty significant speedup.
> What, seriously? Are you really optimizing for your visitors who load one and only one page before their cache is cleared? Even though you "measured... and found the number of page views with a primed cache is 75-85%"?
For a public site, this can be important. A user coming to your site for the first time may only be there on a whim: if it's taking a while to load, then they may either abandon the load or get a bad first impression that your site runs slowly.
>> Keep in mind, if you use a far future Expires header you have to change the component's filename whenever the component changes.
> And if you ever change something but forget to change the file name, your visitors will have to reload everything on the damn page to get the current version of the one thing you changed.
True, but a good engineer can solve this problem. We solved it by including each resource's last-updated-version (from source control) in the URL, via some clever template and filesystem magick. This means the developer doesn't have to remember to change the file name, which would be a version control nightmare anyway.
The point is to reduce the number of HTTP connections, and thus avoid pointless latency. A TCP connection takes time to set up because there's a back-and-forth, and if the client is far from the server this can introduce a significant delay in loading static resources. Not to mention that the browser may have to reflow the page as the new images come in, which looks ugly. (Albeit that can be mitigated if image width/height are specified in the HTML).
> [Combined CSS/JS files are] less egregious than suggesting CSS Sprites, but it still suffers from the same problems. These are not large files, and if they are large files, the headers are not larger.
Again, the point is to reduce the number of HTTP connections, not to reduce the total header size. We did this on our site and got a pretty significant speedup.
> What, seriously? Are you really optimizing for your visitors who load one and only one page before their cache is cleared? Even though you "measured... and found the number of page views with a primed cache is 75-85%"?
For a public site, this can be important. A user coming to your site for the first time may only be there on a whim: if it's taking a while to load, then they may either abandon the load or get a bad first impression that your site runs slowly.
>> Keep in mind, if you use a far future Expires header you have to change the component's filename whenever the component changes.
> And if you ever change something but forget to change the file name, your visitors will have to reload everything on the damn page to get the current version of the one thing you changed.
True, but a good engineer can solve this problem. We solved it by including each resource's last-updated-version (from source control) in the URL, via some clever template and filesystem magick. This means the developer doesn't have to remember to change the file name, which would be a version control nightmare anyway.
