35

One thing I have noticed on some sites is that they use one BIIIIIIIG image containing lots of little images, then use CSS background-position to define the coordinates of each image, rather than use individual images.

Here's where I'm at:

Cons for using big sprite sheet

  • Need to load a large image to just display even one small image
  • Need to write (or generate) a long stylesheet with a class for each image
  • Cluttering CSS with lots of class definitions may impact performance
  • If one image changes (or another is added), cache problems may be encountered both on the image and the CSS associated with it
  • Requires a <div> with proper styling (display: inline-block; width: 32px; height: 32px; background-image: url('spritesheet.png');) which adds yet another class to the mix.
  • Many more that I can't remember now I'm typing them.

Pros for using big sprite sheet

  • ... Erm... none yet.

In fact the only thing that comes close to a pro here is that when I cut up the sheet into individual images the resulting folder took up 3Mb on disk (due to each file being <100 bytes and my allocation size being 4k). The actual files themselves come out less than half the size of the sheet and CSS, so even with the overhead of an HTTP request there is a significant space saving.

Basically, my question is: Does anyone have ANY pros for using a big sheet over individual images?

Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • 2
    retrieving a 'big' image (which gets cached) from the server is almost always faster than multiple requests to get all the separate images. – PeeHaa Nov 08 '11 at 12:13
  • 5
    None of your cons are actual cons. – thirtydot Nov 08 '11 at 12:14
  • 1
    http://stackoverflow.com/questions/2082829/should-i-use-a-sprite-like-technique-for-thumbnails-on-my-website here are the pros – Yisela Nov 08 '11 at 17:55
  • It's a minimal advantage for a large site where elements are repeated on many pages. Otherwise it's a waste of time. – Hal50000 Dec 01 '15 at 16:15

8 Answers8

23

The aim is to reduce HTTP requests. In addition, sometimes the compressed sprite will weigh less than the original images.

Recently I had a website with a lot of transparent gradients (white to trans, grey to trans) and some black and white on transparent images. By putting them all in a sprite and reducing the colors in the png to 8 I could get the sprite to be smaller in filesize than the original images (just... it was about a 0.5% saving). By reducing the number of HTTP requests from 10 to 1 though meant the site loaded faster (if measuring time from first connection to all data transferred).

In that case, a measurable increase was found.

I agree though that it's possible to mess things up and to end up with a larger sprite than needed, especially if you aren't using PNG compression.

Note two years after posting this – if you are using SSL, you should look into SPDY (my note in a further two years will mention HTTP 2.0 instead of SPDY!). SPDY negates the benefits of spriting.

Rich Bradshaw
  • 71,795
  • 44
  • 182
  • 241
  • 1
    Okay, but if the images are used across a number of pages, but never all at once, wouldn't it be better to have individual images which gradually lead to them all being in cache? – Niet the Dark Absol Nov 08 '11 at 12:24
  • Of course, it depends on exactly what you are doing. Generally speaking, there is always something that could be sprited somewhere on a page. I often will just sprite 4 small images, and leave the rest for instance. PNG is the only format I think it's worth doing this with because the blank space compresses to almost 0. (As opposed to JPG or BMP) – Rich Bradshaw Nov 08 '11 at 13:01
  • i will definitely checkout SPDY – alireza easazade Sep 29 '19 at 04:59
9

Not much of what you said as Cons really are cons at all.

When you load one large image, it contains only one of the different attributes that an image needs (color table, mime type etc ex: imagine if you're using a progressive jpg format, one spritesheet will allow the image to be scanned once, whereas many will decrease load time significantly) instead of having the same information in 100 different files, it will lessen the filesize in the big picture.

Also there will only be ONE http request (or two, depending on how many spritesheets you have.) but if handled properly, only one per pageload.

If you're using bg images in CSS, then you already have made the css selectors so there is no extra work, just copy/paste the url.

I've never encountered any cache problems with spritesheets that can't be solved by pressing ctrl+F5.

It doesn't require a div with proper styling in any case at all. This is not an <img> tag replacement method, it's used primarily for bg images. Like for buttons and icon sets.

The pros far outweigh the cons in this method, the proof is that it has been taken up into use by so very many developers. If it were a terrible method, nobody would have picked it up and somebody would have already raised these issues when it was first put into use.

If anyone has more to add, don't be shy :)

Kyle
  • 65,599
  • 28
  • 144
  • 152
  • 2
    Even if the sprite sheet is 500kB in size, it will be downloaded once and only once, afterwards, it will be fetched from the browser cache. So, the number of requests goes down even more :D – mingos Nov 08 '11 at 12:36
4

Google describes it here. Basically it should reduce page loading time. Every new connection initialization adds some delay. In some cases it can also reduce data transfer size and therefore also reduce page loading time. It is suitable for images that change rarely or all together (themes). Then browser can use cached image and needs to check only one file for changes not every image one by one.

Cougar
  • 651
  • 4
  • 11
2

Sprite sheets are a mess. Period. No need to sugar coat it. They present a massive step backwards in design technology, which probably explains why the only people who like using sprite sheets are old school game developers. Sprite sheets only have one redeeming quality, they are a little faster to load. Other than that, they are garbage. Not to mention a nightmare to set up.

In what world is it "acceptable" to have to include 500 lines of code just to run a simple walk cycle. Hopefully some clever guys will come up with a solution as simple as dragging a self contained, alpha-supporting video format such as flv, but that would also run on tablets...

If you feel like writing a massive list about how great sprites are, I can only wonder how boring your design job must be. The bottom line is that if a "tool" is making it harder for you to do things which should be easy, then it's not a good tool. Throw it away.

Dude that knows his stuff...
  • 53
  • 1
  • Well, how else would I have just recently managed to get a 200-frame, 300x285 awesome animation in just 2.78MB, whereas having to downoad all 200 images one by one is not only inconsistent (images might not load in the exact right order) but takes 12MB instead. Sprite sheets have turned out to be extremely useful. – Niet the Dark Absol Sep 28 '13 at 09:21
  • Yes, making a spritesheet by hand is certainly a nightmare to setup however there are tools to literally automate every single aspect of this. – Hanna Oct 29 '15 at 17:19
1

Yes - number of requests.

Most browsers will only download around 2 resources per domain in parallel, so if you serve up a lot of small images, the user has to wait for for around half that many HTTP request-response cycles. If you use a sprite, that's only one request and one response (albeit a bigger response).

Chowlett
  • 45,935
  • 20
  • 116
  • 150
  • 1
    Not true now, but was a while ago. Most browsers have more than 2 connections now. – Rich Bradshaw Nov 08 '11 at 12:17
  • For HTTP/1.0, Chrome imposes a limit of 6 connections per domain. For HTTP/2 (which [almost all browsers](http://caniuse.com/#feat=http2) support), there is no limit. – Dan Dascalescu Dec 21 '16 at 10:06
1

If you have many images, the browser will need to download each and every one of them. Since the browser can only download a limited number of files simultaneously, this will take time. A single image will only tie one download slot allowing the page to render faster.

Additionally, if used in many other pages, the large sprite sheet will already be cached.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
1

this is specially good for a lot of small images, because the browser only has to do an http request for all the images, and not hundreds of them. So you're web loads much faster on the client browser.

the thing is loading speed. Only one http request is quite faster than dozens of them.

Kyle
  • 65,599
  • 28
  • 144
  • 152
Packet Tracer
  • 3,884
  • 4
  • 26
  • 36
1

Also, it helps keep your CSS cleaner. For instance, I use sprites for buttons (which also means no extra delay for loading the hover state img)

<button type="submit" class="vorige"><span>Vorige</span></button>

button  {display: block; width: 162px; height: 47px; background-position: 0 0;}
button:hover    {background-position: 0 94px; cursor: pointer;}
button:active   {background-position: 0 47px;}
button span {display: none}

.vorige     {background-image: url(../img/button/btn_vorige.png);}
.volgende   {background-image: url(../img/button/btn_volgende.png);}
.verstuur   {background-image: url(../img/button/btn_verstuur.png);}

because of the sprite I can leave out the code for a seperate hover image:

.vorige:hover   {background-image: url(../img/button/btn_vorige_active.png);}
.volgende:hover {background-image: url(../img/button/btn_volgende_active.png);}
.verstuur:hover {background-image: url(../img/button/btn_verstuur_active.png);}
Mirthe
  • 414
  • 4
  • 9