Analysis of advantages and disadvantages of CSS Sprite

Most developers now have a pretty good grasp of the technology, as well as a lot of tutorials and articles about it. Almost all of the articles claim that designers and developers should use CSS sprites to reduce the number of HTTP requests and to save some traffic. This technology is used by a large number of Web sites, including Amazon, which uses large sprites .

But are the benefits of these widely-heated discussions really worthwhile? Do designers blindly use the technology without fully considering all the circumstances? Are designers paying too much attention to the popularity of CSS sprites and ignoring other factors that should be carefully considered? This article will discuss the pros and cons of using CSS sprites, paying particular attention to the "misuse" of sprites and explaining why "abusing" the sprite is a waste of time.

Browser caches all pictures

One of the benefits of sprite technology is the load time of pictures (when there are many sprites, the load time of a single picture). The size of a GIF picture that is created by the desired picture is significantly smaller than the size of all pictures before it is flattened. A single GIF has only one color table associated with it, and each GIF that is split separately has its own color table, which increases the overall size. Therefore, a single JPEG or PNG sprite is likely to be smaller in size than the total size of a picture divided into multiple sheets. But is it really as good as it might be?

In general, the browser caches all pictures – whether or not the picture is sprite or not. Sprite technology only saves bandwidth when the page is first loaded, and the cache is also valid for other pages that use the same image.

The Firefox cache displays a picture of the browser cache from Amazon.com (enter "About:cache" in the Firefox address bar to view).

Given that the prevailing speed is already much faster than it was when the technology was introduced in 2003-2004, it is not necessary to use a lot of sprite technology. There is a need to be clear, not to say that the sprite should not be used, but that it should not be abused for limited benefit.

The time cost of flattening pictures increases

Imagine how a three-state picture button is made: images that represent different States need to be placed close together to form a picture. When using Photoshop or other software transduction, different states are not together; they need to be cut out and merged into one picture.

If any of the picture states need to be changed, the entire picture needs to be recreated. For some designers this is not a problem, perhaps they will keep different button state of the source files, so that need to merge the time is simple. But the process is a bit complicated, and it's far from simple to cut out a single picture.

Is it really worth the sprite technology to save a few k of traffic and a few server requests (and only when the page is loaded for the first time)?

Time costs for coding and maintenance increase

After the picture slice output, the trouble still exists. Although accustomed to this process, the button sprite can be easily encoded into the CSS, but the other sprites is not so simple.

A single button is typically a <ul> element with a fixed width. If the sprite of the button is independent of each other, it is relatively simple to:<ul> the width and height of the list items and anchor points of the width of the same, each state of the sprite alignment. The position of the sprite can also be easily calculated based on the width and height of each button.

But what happens when you encounter a large sprite like Amazon or Google ? Can you imagine what it would be like to maintain such a file and change the position of the sprite in the CSS? What about the first time you created CSS code? A large sprite can cause endless testing and picture state re-placement relative to a simple button that makes it easy to calculate state positions.

Some of the styles used to position Google sprite pictures

Amazon's sprites does save at least 30 HTTP connections, and there's really a big improvement in performance. But by comparing these benefits with development and maintenance costs, and taking into account factors such as caching and speed, the decision to use such a large sprites may be less convincing.

Does the Sprites really need "maintenance"?

Of course, some people don't think that a sprite is the first problem that causes headaches. In most cases, when a sprite is created and encoded, it is rarely altered or affected by ongoing site maintenance. If you feel that the sprite maintenance is not a problem, then perhaps using a large sprite is the best choice.

Not all pictures are backgrounds

Another reason for not advocating the misuse of CSS sprites is that it causes developers to mistakenly use the background image. Experienced developers will consider accessibility issues in the project, and they understand that not every picture is a background. The background image should be left to the button and used to decorate the element, and the image used to convey important information should be inline in XHTML.

Amazon correctly uses inline image elements and decorative backgrounds.

Error using Sprites to affect accessibility

Some newly-started developers will use all the images as background images to save the number of HTTP requests (which is the benefit of using CSS sprites) – even those that convey important information. The result will be a lack of accessibility to the site, but also reduce the potential benefits of title and Alt in HTML.

Therefore, the CSS sprite itself is correct, and it does not raise accessibility issues (in fact, the correct use will improve accessibility). But it's not right to overdo it. Using a sprite can hinder web-building processes with accessibility and productivity.

What about the number of HTTP requests?

Many people argue that the most important part of improving site performance is reducing the number of HTTP requests. Also know that a study shows that the percentage of a site's daily visitors is not cached by the browser . Does this suffice to indicate that large sprites should be used in all cases? Maybe it is. Especially considering the importance of a user's first visit to a website.

Firefox's YSlow plugin displays the number of HTTP requests

Previous browsers generally allow only 2 concurrent HTTP connections, and Firefox and IE8 since version 3.0 allow 6 concurrent HTTP connections by default. This means that each server has 6 concurrent connections. Quote Steve Souders:

"It is important to understand that this is the basis of the server. Using multiple domain names, such as 1.mydomain.com, 2.mydomain.com, 3.mydomain.com, and so on, allows developers to take full advantage of the number of server connections. Still valid when all domain names are CNAME of the same IP address. ”

Therefore, it is also useful to use CSS sprites outside of the button state, and in the future, the benefits of using large sprites will become insignificant as the speed of network connections and the performance of the newer browsers increase.

What about the Sprites generators?

Another reason to love a large sprite is that you can use some sprite generators to simply create a sprite. Detailed discussion and evaluation of such tools is not covered in this article. However, from the author's study of such tools, the help is very limited, and the maintenance of these sprites, as well as the need for a considerable amount of work, which is also the need and profit balance.

Some tools, such as this one from the fondue project, provide output CSS options. Steve Souders's tool Spriteme is another option that provides CSS encoding. Spriteme will convert the existing site background image into a single sprite picture ("large" Sprite I mentioned earlier) and provide a download for encoding into the page. However, these tools only help to create sprites and do not provide much help with maintenance. Souder's tools seem to be ineffective for redesigned or layout sites, and are only useful for existing Web sites that do not use the Sprite method.

Existing tools can be improved, and new tools will appear in the future. However, given the above-mentioned shortcomings, is it possible that developers are still concentrating on their limited income?

Focus on multiple performance points of improvement

As mentioned above, the number of HTTP requests is a very important factor to consider for improving your site's performance. But there are other ways to reduce the number of connections, including merging scripts and style sheets, using remote library files (that is, using Google or Yahoo! Provided library file hosting).

In addition to the number of HTTP requests, there are many factors that developers can focus on to improve site performance. This includes server-enabled Gzip, proper placement of out-of-chain scripts, optimized CSS syntax, compression of large JavaScript files, improved Ajax performance, avoidance of known JavaScript syntax that could cause performance problems, and so on.

YSlow shows the factors that can improve the performance of your site beyond the number of HTTP requests

If developers take the time to think about all the factors that can improve the performance of the site, and then weigh the pros and cons, there might be good reasons to avoid abusing the CSS sprite and focus on the value for money.

Originally from: http://www.jb51.net/css/25893.html

Analysis of advantages and disadvantages of CSS Sprite