问题
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?
回答1:
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.
回答2:
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 :)
回答3:
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.
回答4:
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.
回答5:
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).
回答6:
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.
回答7:
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.
回答8:
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);}
来源：https://stackoverflow.com/questions/8050152/why-use-a-sprite-sheet-rather-than-individual-images