Is the only benefit of using css image sprites that there is less http requests?
Or is there other benefits?
Also is there an easy way of detiming which area of a sprite to show?
Like you said, one of the main advantage is to reduce the number of requests to the server, improving the response time (especially if you're loading a large amount of small images). But this is not the only reasons people use sprites.
If you don't use sprites for a "mouse over" display, the user will see the image disappear for a second... and it looks really bad. This is because if you change the image instead of just moving the sprite around it will load a new image and the loading time can be visible to the end user.
.bad{
background:url(abc.jpg);
}
.bad:hover{
background:url(abcHover.jpg);
}
.good{
background:url(abc.jpg) 0px 0px;
}
.good:hover{
background-position:15px 0px;
}
Another advantage of sprites is that you can keep all your images in one location and in some cases it makes more sense (for menus and so on).
To determine which area of a sprite to show, just use photoshop or any other image editing software.
The primary benefit is your pages load faster, mainly because of reduced HTTP requests.
You could generate your sprite using a tool.
Disclaimer - I wrote this tool.
It is much easier to get image placement (especially next to text) the same cross-browser. You can adjust images up/down/left/right with out using vertical-align and padding.
I find it easier to keep track of all the images if they are in a single file. Especially since I usually have a transparent png images and and then use gif images for ie6. I save my png sprite map as a gif and add one line with background-image in my ie6 css and my images are switched.
I use photoshop or gimp to get approximate locations in the sprite map and then use firefox to fine-tune the placement.
Yes, there is another benefit. Every image file has his own headers, describing image type, colors etc. So when you combine images to a single sprite, you win some kb.
But as you said before, mostly you win by reducing HTTP requests count.
In terms of determining the area to show, I will typically place my elements on pixels that are multiples of 100. So if there's a sprite with a bunch of 64x64 pixel icons, I'll typically have them at (0, 100), (0, 200), (0, 300), etc.
This way, I don't have to type in an exact measurement (or any other developer for that matter) and save keystrokes when setting all my background-position properties.
Related
I made this question yesterday: background repeat tiled bgImage inside an sprite image?
So as long is not posible to repeat backgrounds wich are inside of a sprite image,
What is the best* strategy when creating the sprite?
i mean, choosing:
should i try to put ALL the images in one sprite? (including big backgrounds that could be repeated)
One sprite for icons. Backgrounds a part?
other
*) when i say best i mean with the most accesible/usable/perfomance
i am always create three sprite sheets.
first; for those images which is not repeating at all like arrow, button etc.
second; for those images which repeating y-axis.
third; for those images which repeating x-axis.
or
If there is no repeating images in the design then there is no need for other to sprite sheets
sprite for x-axis http://imageshack.us/photo/my-images/401/xaxissprites.png/
sprite for y-axis http://imageshack.us/photo/my-images/28/yaxissprites.jpg/
Sprites are old! There are newer techniques that you can use. But when you will used sprites. I would make one sprite for icons and one sprites for other images.
But you can also used data uri's / base64 encoding for images. This is the new technique for image. And the replacement of sprites. With sprites, you have http requests. With data uri's you have no http requests. It make you website faster! And the speed of the website is a more important thing.
Here you have a article about Click here And here you can create the data uri's. Here. But data uri's are not supported in ie7. For ie7 you can make a fallback to single images.
Used the data uri's and forget the sprites. Sprites is a technique in 2011. Data URIs is totally 2012! :-)
In my opinion, sprite must be defined for your users first. If your users are seeing different pages for their authority, you must divide your sprites by authority. Second is the background and icon, button grouping. Every image file has a header in it. In header, they contain size, colormap and any other additional info. Headers are mostly increases the file 1KB - 3KB average. So we can think that less image, less data transfer. In summary, I suggest you to use one sprite.
Other think is the tools for this. You can use sprite sheet tools for generating your sprites and writing your CSS. These tools are generating minimum image size (using some algorithms to order sprites) and automatically generate CSS file depending on the sprite positions on the sprite sheet. If you are on mac, you can use Sprite Master for this.
The typical rule of thumb when it comes to using CSS sprites for images is that you should only do it for smaller images (like icons) and that actual image content should always be represented through <img> elements. My question is: why? Aren't the advantages of spriting worthwhile for content images as well?
One reason I have read is to enable the use of alt text, to be more syntactically correct and accessible to screen-readers. However, when that is a concern, couldn't you just as easily use a single tiny transparent image with all the syntactical sugar atop a sprite that presents the real visual content?
You could, but:
Content images don’t tend to be re-used as much as UI-type images like icons. Imagine a newspaper site: if every content image they used in every story was part of a sprite, that sprite would very quickly get huge, and would be downloaded even by users who only looked at one story.
Website content is generally expected to be maintained by people who don’t know CSS. It’s a bit unreasonable to expect content editors to edit a master sprite image file, re-save out to a JPG, and pop in some CSS just to put an image on a page.
If you sprite a lot of large image files, the sprite file will get really large. It might take an unacceptably long time to download when the user first visits the page, or it might use up too much bandwidth on users who only end up seeing one of the images within the sprite.
Obviously, those are generalisations — in a specific situation, it might make perfect sense to sprite larger/more content-y images.
On using an <img> tag with a tiny transparent image file for sprites, you can do that for any sprite images — it’s often useful for clipping and positioning the sprite image beyond what background-position allows.
One additional reason I can think of, is search-engines; if you have an image with a descriptive alt-tag or a figure element with a figcaption, search engines will be able to find, classify and show it.
Sprites are usually usefull for static contents (images that are common on many pages).
Content pictures often appears in only one page, so you can't add it to your sprite file.
If you want to have real-time sprite generation, making custom sprite file with all your pictures, I think the generation cost is far more expensive than the duplicated HTTP calls it saves.
Sprites are here to save HTTP requests, but you should not waste server-side computation time to make it, nor put expensive and unusefull pictures in your sprite file.
Sprites should be used for common icons across the whole website and not for page specific content. When you use sprites for big images you get a lot of white space that is wasted.
According to http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/ this is also a problem:
Another (but much less important) downside is that if a sprite-using
page is zoomed using the full-page zoom feature that’s present in many
browsers, the browser may need to do extra work to get the correct
behaviour at the edges of these images — basically, to avoid adjacent
images in the sprite from “leaking in.” This isn’t a problem for
small images, but can be a performance hit for bigger ones.
From the research I've continued to do on this, another potential issue is memory consumption. Despite the fact that sprites may be compressed enough to download quickly, the footprint they fill in the client machine's memory is after the browser has rendered them, meaning it can be quite large, even for sprites with fairly small file sizes.
I haven't seen a definitive answer on whether or not this memory footprint is any larger than what one would see when loading the same number of images without sprites. I will be testing that in the coming weeks for the project that prompted this question, so I will return and update this answer once I have a conclusion.
Sprites are used to reduce the amount of requests to a server. The impact of lots of small requests is slowing the server more than one bigger request. But if the image of sprites, I like to call it sprite-map, is too large, it will also slow down the performance. The other thing of importance is like you sad the possibility for each single picture to give some name, to manage and to index by search engine.
i want to know about sprite technology used in css regarding fast accessing of the web pages.
They are cool because you can minimize http requests with them and make your page's performance improve. They are considered good in terms of SEO as well. Check out this for more info:
CSS Sprites: What They Are, Why They’re Cool, and How To Use Them
This page gives a pretty good overview.
Essentially it puts all of the page's images into one large image file and then uses CSS to display only parts of that file (to give the effect of multiple images). This has the advantage of only requiring the browser to make one request for all the images rather than a bunch of individual requests (each of which has an overhead).
If you have the group of icons for example , you are creating one jpg or png file and adding the images one after another. Then you just creating the backgrounds based on only one image and fixing it in percentage / pixels view. It makes your code organized and saves images loading time . For example , you have a window and it has close , unfold icon. You can create a png file named windowControlSprite.png that contains two icons one after another , then you can create properties in your css to this element. #somediv {background-position:0px -20px;}
Also, you can find CSS sprite X and Y easily with tools like http://www.getspritexy.com/
Otherwise you need to use image editors like Photoshop or use Firebug to find X and Y coordinates.
I want to put images of the 1024x768 as backgrounds and load quickly using css. I could use
background(url....)
in the CSS, but will that solve the issue, of downloading images quickl?
Thanks
Jean
If you have to use this technique, then remember to compress and cache the image, this will speed it up somewhat, but try and be creative with alternative solutions.
For example can the background repeat on the x-axis? If it can you'll be able to create a 1px wide version that you can repeat across the page.
Try searching for this. It helps cutting off a few KB of data. PNG Gauntlet is also a free software for PNG compression that also cuts Gama correction that causes problems with IE6 and IE7.
Body background images are usually saved with lower quality, thus reducing size.
If your backgrounds are changeable, preload them. It is done by putting divs of zero height at the beginning of the page, and assigning background-image style to each. The images are loaded at the beginning, so when the background of the body gets changed the user doesn't notice the lag.
Google started to count the load time already, so classic preloading causes problems with SEO. Loading with JS, after the page fully loads is an option, or even assigning styles with JS after certain actions are made is also a solution.
remember you can't change the user dsl speed. so css background would be good. Maybe start with take a higher JPEG compression to minimize the file
(btw. i hate (full size) background images at websites with my dsl light)
I want to know when not to use CSS sprites. CSS sprites works great, but are there any occasions when they create a lot of headaches?
Like all things, there are times when it is useful, and there are times when it is harmful.
Many developers like to use CSS sprites because it saves on request time -- the browser makes one request, downloads the image, and all the various sprites are now automatically cached and blazing fast.
So how can it hurt?
Because download size != memory size.
That PNG or GIF that's only 10kb might actually be much, much greater in size once the browser loads it in memory. The issue is that while something like GIF will compress solid areas of color, the browser expands it out to a bitmap, where all images of equal dimensions use equal memory.
And it loads a new bitmap every time you use that image somewhere.
So everything in moderation.
See: http://blog.mozilla.com/webdev/2009/06/22/use-sprites-wisely/ for more info.
Maintainability of your site will suffer from using them. Only combine images that belong to the same logical unit and are unlikely to be updated separately. Keep images that are likely to change separate to begin with.
CSS sprites works bad for <input type="text"> where the user can enter more than fits in the box, as the background then scrolls in some versions of IE.
They also works bad if you want to repeat the pattern.
They can cause headache for your users if they want to download a particular image. First they won't get the "Save image as" option. If they figure out to use "View background image" they'll get a huge image with lots of other images on there too.
This is why sprites are best saved for "utility" (i.e. buttons) or design images.
We had a tough time when we wanted to position the image dynamically.
background-image: url(../images/a.gif);
background-repeat: no-repeat;
background-position: left bottom;
This is tricky (if not impossible) to do using a sprite.
Sprites should never be used when the size of images are very different.
Because in that case the size of sprite is quite huge.
Recently I converted 3.5MB pictures to a sprite, and size shooted up to 17MB!
Using larger pic might be a headache...
When pics are combined in smaller size, and neighbouring pics are just 1 or 2 px between each other, then CSS sprites can be a good solution.
In our case, http://www.nbhuntop.com, we just use it for menu components including: Home, About, Products. And all the pics are in gif format, and no one will download these pics at all.