5 ms·

Sprites and concatenated js/css are still useful. HTTP/2 lets you make 100 requests over a single connection, and that's a lot better than making 100 requests o

Sprites and concatenated js/css are still useful. HTTP/2 lets you make 100 requests over a single connection, and that's a lot better than making 100 requests over 100 connections, but it's still not going to beat one request over one connection.

acdha 12y ago
That would be an interesting thing to benchmark, particularly since separate resources can be cached independently. If you're using every single image, line of JavaScript, etc. as soon as the page loads, a single large file will probably still be faster. If, however, you have a mix of things which are only used for optional features, not on every page, etc. there's room for some nice improvements because independent resources can be loaded immediately whereas a huge concatenated JavaScript file has to wait for the entire transfer before it can be safely executed. If your site really needs jQuery and 90 plugins to work at all, that doesn't help, but if a fair amount of your code can be loaded independently the overall load time can be shorter if some of the code executes while other resources are still fetching rather than waiting until it has everything. The independent fetch + caching is also more valuable for repeat visitors who have cached copies of everything which didn't change – i.e. if you only touched an icon in the footer of your page, the experience is better if your header logo displays instantly out of the cache rather than having to wait for an entire sprite to reload.
plorkyeran 12y ago
One image with 100 icons also still compresses better than 100 files with 1 icon each.
riquito 12y ago
Sprites are way more demanding memory wise than smaller images.
- Millennium 12y ago
  Performance on the Web isn't RAM-bound at this time, unless you're running on a Raspberry Pi or somethin. Network performance is a much stronger limiting factor, which is why protocols like HTTP/2 are being made in the first place. I'm also skeptical that sprites must necessarily be significantly more demanding memory-wise than smaller images. Implementations may vary, but at least in current browsers, when you make an Image tag/object with the same source as one you've already loaded, the second one loads instantly. This at least makes it appear that both image tags are getting some kind of lightweight view into the same image data -maybe just a pointer to the same bucket of bits- as opposed to having to re-download and/or re-copy the image data for each instance.
  - ricardobeat 12y ago
    I think he means the empty space that is demanded by sprites, in memory it occupies space as a bitmap. If you use a smart sprite builder that optimizes stacking, it will probably be less than 10% overhead, but still relevant.
  - laurencerowe 12y ago
    You probably have fewer tabs open than I do... The memory usage of CSS sprites (which are implemented as css background images rather than Image objects) was definitely an issue a couple of years back. Inlining the images as base64 data uris seems much better.

acdha 12y ago

That would be an interesting thing to benchmark, particularly since separate resources can be cached independently. If you're using every single image, line of JavaScript, etc. as soon as the page loads, a single large file will probably still be faster. If, however, you have a mix of things which are only used for optional features, not on every page, etc. there's room for some nice improvements because independent resources can be loaded immediately whereas a huge concatenated JavaScript file has to wait for the entire transfer before it can be safely executed. If your site really needs jQuery and 90 plugins to work at all, that doesn't help, but if a fair amount of your code can be loaded independently the overall load time can be shorter if some of the code executes while other resources are still fetching rather than waiting until it has everything. The independent fetch + caching is also more valuable for repeat visitors who have cached copies of everything which didn't change – i.e. if you only touched an icon in the footer of your page, the experience is better if your header logo displays instantly out of the cache rather than having to wait for an entire sprite to reload.

plorkyeran 12y ago

One image with 100 icons also still compresses better than 100 files with 1 icon each.

riquito 12y ago

Sprites are way more demanding memory wise than smaller images.

Millennium 12y ago
Performance on the Web isn't RAM-bound at this time, unless you're running on a Raspberry Pi or somethin. Network performance is a much stronger limiting factor, which is why protocols like HTTP/2 are being made in the first place. I'm also skeptical that sprites must necessarily be significantly more demanding memory-wise than smaller images. Implementations may vary, but at least in current browsers, when you make an Image tag/object with the same source as one you've already loaded, the second one loads instantly. This at least makes it appear that both image tags are getting some kind of lightweight view into the same image data -maybe just a pointer to the same bucket of bits- as opposed to having to re-download and/or re-copy the image data for each instance.
- ricardobeat 12y ago
  I think he means the empty space that is demanded by sprites, in memory it occupies space as a bitmap. If you use a smart sprite builder that optimizes stacking, it will probably be less than 10% overhead, but still relevant.
- laurencerowe 12y ago
  You probably have fewer tabs open than I do... The memory usage of CSS sprites (which are implemented as css background images rather than Image objects) was definitely an issue a couple of years back. Inlining the images as base64 data uris seems much better.