Advantages and disadvantages of using CSS Sprite

Original:CSS sprites:useful technique, or potential nuisance?

CSS Sprites: Shark's fin or Sanlu?

The ubiquitous CSS sptites-one of the few that can skip the "popular" process directly and quickly and securely among several of the best CSS practices. Although it was really popular after Apart explained and approved the technology in a List, Peter Stanicek started talking about it as early as July 2003.

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

But are the benefits that are widely discussed really worth it? Do designers blindly use the technology without taking all the circumstances into account? Are designers focusing too much on the popularity of CSS sprite and ignoring other factors that should be carefully weighed? This article will discuss the pros and cons of using CSS Sprite, with particular attention to the "misuse" of sprites, and explain why "misuse" of sprite is actually a waste of time.

Browser cache All pictures

One of the benefits of sprite technology is the loading time of the picture (when there is a lot of Sprite, the time to load a single picture). The size of a GIF picture that is spelled by the desired picture is significantly smaller than the size of all pictures before flattening. A single GIF has only one color table associated with it, and each GIF that is individually segmented has its own color table, which increases the overall size. As a result, 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's supposed to be?

In general, browsers cache all images-whether the picture is sprite or not. Sprite technology only saves bandwidth when the page is first loaded, and caching works for other pages that use the same picture.

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

Given that today's universal speed is much faster than it was when it 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 Sprite should not be used, but to misuse the technology for limited benefits.

The time cost of flattening pictures will increase

Imagine how a picture button with three states is made: a picture that represents a different state needs to be placed together to form a picture. When using Photoshop or other software Chettu, different states are not together; they need to be sliced out and merged into a single picture.

If any of the picture states need to be changed, the entire picture needs to be saved again. This is not a problem for some designers, and maybe they will keep the source files for different button states separately, so it's easy to merge. But the process is a bit complicated, and it's not as simple as cutting out a single picture.

In order to save a few k of traffic and several server requests (also only occurs when the page is first loaded), Sprite technology is really worth it?

Increased time costs for coding and maintenance

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

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

But what happens when you meet a previous mention of a big sprite like Amazon or Google ? Can you imagine what it would be like to maintain a file and change the sprite in CSS? What about the first time you created CSS code? Compared to a simple button that can easily be computed for a state position, large sprite can result in endless testing and the redistribution of picture status.

Some of the styles used to locate Google's Sprite pictures

Amazon's sprites did save at least 30 HTTP connections, and there was a real 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 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 the ongoing maintenance of the Web site. If you feel sprite maintenance is not a problem, then perhaps using a large sprite is the best option.

Not all pictures are background

Another reason for not advocating the misuse of CSS sprite is that it can cause developers to use background images incorrectly. Experienced developers consider accessibility issues in their projects, and they understand that not every picture is a background. Background images should be left to buttons and decorative elements, and images used to convey important information should be inline with XHTML.

Amazon is right to use inline image elements and decorative backgrounds.

Error using sprites to affect accessibility

Some novice developers will use all images as background images to save on the number of HTTP requests (which are always highlighted by using CSS Sprite) – even those that convey important information. The result is a Web site that lacks accessibility, and also reduces the potential benefits of title and Alt in HTML.

As a result, the CSS sprite itself is true and does not raise accessibility issues (in fact, the right use improves accessibility). But the overuse of sprite, right or wrong, hinders the process of web-building with accessibility and productivity.

What about the number of

http requests?

A lot of people argue , the most important part of improving Web performance is reducing the number of HTTP requests. Also know that . Is this sufficient to justify the use of large sprites in all cases? Maybe that's it. Especially considering the importance of the user's first visit to a website.

Firefox's YSlow plug-in displays the number of HTTP requests

Previous browsers generally allow only 2 concurrent HTTP connections, 3.0 versions of Firefox and IE8 default Allow 6 concurrent HTTP connections . This means that each server has 6 concurrent connections. Quoting 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. is still valid when all domain names are CNAME of the same IP address.

Therefore, it may also be useful to use CSS sprites outside of the button state, and the benefits of using large sprites will become insignificant in the future as the speed of network connections accelerates and the performance of new browsers improves.

What about the sprites generators?

Another reason to love large Sprite is that you can use some  sprite generators to simply generate Sprite. Detailed discussion and evaluation of such tools is not covered in this article. However, from the author's research on such tools, the help is very limited, and maintenance of these sprites the same need for a considerable amount of work, which is also a trade-off between needs and benefits.

Some tools, such as the spriteme is another option that provides CSS encoding. Spriteme will convert the existing site background image into a single sprite image (the "large" Sprite I mentioned earlier) and provide downloads for the code into the page. However, these tools only help create Sprite and do little to help with maintenance. Souder tools seem to be ineffective for redesigning or layout sites, and only for those existing sites that do not use the Sprite method.

Can improve existing tools, and new tools will appear in the future. However, given the shortcomings mentioned above, is it possible that developers are still concentrating on limited income?

Focus on multiple performance elevation points

As mentioned above, the number of HTTP requests is a very important factor to consider in improving the performance of your Web site. 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! The provided library file is hosted).

In addition to the number of HTTP requests, there are many factors that developers can focus on to improve the performance of their Web sites. This includes server enabling Gzip, proper placement of external chain scripts, optimizing CSS syntax, compressing large JavaScript files, improving Ajax performance, avoiding the use of known JavaScript syntax for performance problems, and so on.

YSlow shows the number of HTTP requests that can improve the performance of the Web site

If developers take the time to consider all the factors that can improve the performance of the site and weigh the pros and cons, there may be a good reason to avoid abusing CSS Sprite and focus on the value-for-money aspect.

Summarize

Please don't misunderstand what I said. Many top bloggers and developers have praised the benefits of sprite for years, and in recent years have extended these ideas to the use of large sprite – and should take these views seriously. However, this has a perfect system and system, so that the Web site maintenance tasks to simplify and flow of the company, not everyone can enter. Most people work independently or accept projects created by others. In such cases, large sprite can cause problems that outweigh the gains.

Summary of sugar companion tomatoes

The title is a little eye-catching:) The rules of the original title translate to CSS Sprites: useful technology or potential trouble? The

About CSS Sprite was discussed at the  web standard Exchange Phase II. In fact, CSS Sprite is very useful place. But the premise is not to exceed the limit of one degree. Basically, a lot of questions will end up with the question of how to use them moderately. Old saying: Too much, in fact, still very reasonable.

To reduce the number of HTTP requests, you can compromise a little, classify the pictures, try to keep the content fixed, the later not too many changes in the graph into a sprite, such as some icon. The images that are often altered are grouped into groups of Sprite. It's really a waste of time and experience spent on puzzles to design fancy, short life-cycle topics. The

Article about foreigners, I now feel a bit long-winded. Maybe a lot of people will have this feeling too. In fact, it should be reflected that Japan has a special booklet to teach people to do some very basic things, the content of steps meticulous to the point of appalling. Most people will be dismissive of the basic things, feel that others are talking about Chine, advanced application, I still engage in these foundations, how embarrassing ah. The basics of

are not that simple, but who can really grasp these seemingly simple basics? Take a look at this basic question. > Do you really know html?

Once a master sent me a book, he wrote "Back to basic" send me, I give you here, I hope that we can make progress.