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.
Related
As a web developer, I have to cut a layout similar to this (example website by Ruben Bristian):
Should I bother with cutting multiple small images like a logo:
a label:
and so on? Or should I just make one big background image with all elements like this:
and make a positioned <a href> with display: block; for a linked logo?
A single image has smaller size than multiple elements altogether. What are the other pros and cons?
Use separate images.
Here are a few reasons why:
Maintenance:
It's going to be much easier to maintain in the future, if/when there comes a point when you want to build on what you already have. Furthermore (and subjectively), the background image is not critical to the design. It wouldn't look broken if parts of the background were clipped. It would look broken however, if the logo were distorted.
Bear in mind also that newer, sharper displays are being developed. It's much easier to display the standard resolution background (it's already blurry, so clarity is not essential), and maintain two versions of the logo. One for standard displays, one for HD.
Semantics: What if the user has images disabled? Sure, it's unlikely, but what about Google? You should have some proper markup with real content. Your site needs real textual content in order for Google's crawlers to gather information about it. Use CSS image-replacement techniques to build the interface.
Another note on HD displays:
It's convention to serve larger images to HD (retina) displays, and use CSS to downsize them, effectively increasing their dots-per-inch. If you use just one image, the user will have to download a considerably large image. More bandwidth used by you, and slower experience for your users.
Furthermore, the text will look horrible on HD displays. It makes much more sense to allow the browser to render razor-sharp text to the user.
Accessibility: For a start, screen readers won't have a clue what your site is about. That might not be so relevant in this case, but it's best practice to build and accessible website. If you want to include some smaller text on the site, some users may be unable to read it. Normally they would increase the font-size, but if you use images, they're powerless.
I may have over-dramatised this answer, but the advice is well-intentioned.
I would honestly try a little bit of a different approach. The "photo" part of the image would be one image, the logo another, and maybe the double bar on either side of the heading another (but might not be necessary.
I would use the photo part as a bg image on a div, and within code the rest.
I wouldn't make the text part of the image at all. Try using a service like Google Web Fonts to get a good font.
The approach will save you lots of maintenance time, and also help with performance.
PROS:
Total bytes loaded is lower.
You do not have to worry about how little images are put together to become the total image.
if you just use 1 image you will find that it will be much easier to maintain the fluidity of the layout. You will not have padding/alignment issues, rendering issues, etc. Realistically the load time should be the same either way, maybe a tad longer for multiple images as the browser would have to render more css, but i imagine it would not be very noticable. In the end it really comes down to what is better for the job. I pretty biased towards 1 clean image :)
I guess you have to think about how you are going to use each element individually, and how they are going to change in the future.
You might want to change the logo, animate it, or want to re-use it elsewhere. The background image might change, or become multiple images in some sort of transitional gallery.
If this its never going to change (unlikely), then, yes, flatten it in a single image.
I personally would have as a separate background image. Then perhaps have the logo and the label on another transparent png and utilise css sprites to re-use them throughout the site. This will halve the number of requests required to download the logo/label, and allow you to optimise each image separately ie the complex background photo, and the more simple logo/label.
I have recently begun using image sprites and they are definately great for reducing http requests. Is there a point where it becomes bad practice?
Im thinking particularly where a lot of extra markup has to be added to support them. For example, using them for list bullet points, I have to add two or three extra spans to get everything alligned etc.
Theres also the annoying point that you cant use repeating images, so therfore there is always the toss up between one large image as part of sprite or a tiny 1 pixel image used for repeating downloaded on its own.
Im really looking for an opinion on the two situations outlined here + any other general considerations/guidelines for using sprites.
They can often cause performance issues on mobile devices. I'm not 100% certain why (never really dived into the problem), but I'm assuming it's because the mobile webkit is loading a new copy of a relatively large image into memory for every instance of it on the page. Since mobile devices often have very small amounts of RAM, it can quickly cause the page to slow down.
I've run into this issue before when having about 300 "icon" sprites on a page at one time, each pulling from a sprite image that contained about 50 different icons. Going back to "normal" methods of one icon per image (or 2-3 for hover states) solved performance issues on this particular page.
Also, many browsers (mobile and otherwise) will often not 100% respect the clipping of sprites when you slightly resize the page content (e.g. using "Zoom In/Out" on the browser itself). You'll often see little pieces of the sprite next to the one you want to use.
As for your bullet example, you shouldn't ever need more than one extra div/span. You would set a margin-left on the li and position your "bullet div" in the empty space it creates.
That being said, I use sprites all the time because they're convenient, just be aware of a few issues with them. Generally, I have sprites.png, sprites_h.png and sprites_v.png for horizontally and vertically repeating pieces.
Write two simple test pages, use sprites on one, and not on the other. Use a tool like http://www.webpagetest.org/ to measure the performance in a few different browsers. Once you have data, you can make decisions.
I would divide sprites by related elements, like navigation and content-related sprites, so you can benefit from sprites and keep a logical order in your code. Don't forget that readable and understandable code should be a priority (particularly with CSS, it can get very messy) unless you're working on a Google-scale project.
1) First, should I order the images in my spritesheet a certain way?(like biggest to smallest images, or images that appear at the top of the page to bottom of the page?)
2) Say I have a css spritesheet that contains before and after images. Like the image shows a cow, but when the image is hovered, it shows a cow with wings. Is it in my best interest to not use css spritesheet for that then? Does the css load all the pictures in my spritesheet at once?
3) Is a spritesheet better in terms of caching? Unrelated, but what does it take for a browser to cache something? I mean if it's only after a single page view, perhaps it's not worth it.
4) Lastly, I want to start a forum. I don't know anything about forums yet, but I plan to start one soon. I'm thinking of just having like a default set of 40 images that people can only choose from as their avatars. Should I even make a spritesheet for those images (if it's even possible)?
I know this is a lot of questions, so please answer any that you have knowledge of. Thanks!
A 'spritesheet' is just one large image. So...
1) Doesn't matter.
2) Again, it's just one image. If not all users will want to activate the 'after' feature, then you can save them some bandwidth my making the afters a separate sprite. If most people will want to use the after feature, then you can save them bandwidth by making it all one sprite. (Though note if we're talking really large images, there will be a practical limit to how much you want to stick into one sprite. No one is going to wait to download 1mb file, for instance).
3) Again, a sprite is just an image. It has the same caching pros/cons as any image.
4) 40 hits on the server is a lot compared to 1 sprite. So, based solely on that, a sprite would be useful. But if it's rare that you'll get more than 10 or so of those avatars on one page, then the sprite would be a detriment, as it's loading such a large file.
Just on the ordering of images, I have a sprite file for a site I’m working on that contains various browser logos with version numbers added to them. As such, there’s quite a lot of repetition in visual information in the file.
I was quite surprised to find that the direction of the repetition could have a big effect over the file size I could achieve for the image when saving as a PNG. When I had similar logos in columns, the file came out at about 120 KB; whilst when I arranged them as rows, it came out at 41 KB.
Once the project’s live I’ll post the actual images. It’s probably quite rare to have such similar images repeated in a sprite file; normally your images would be different, or you’d just use the same image repeatedly. (Indeed, I might end up refactoring my sprites so that the varying bits are in their own file.) But I hadn’t realised that such supposedly similar images could be encoded in two files of such varying sizes, purely based on the geometric arrangement of the elements in the image file.
1) Not sure, but I don't think it would matter much, if at all.
2) The best way to do this is with CSS image rollovers.
3) Spritesheets would be better for caching, since it's only a single image, instead of the web server having to connect, send an image, disconnect, send again, send another image, disconnect, etc...
4) I would just use single images. There's really no reason to use a spritesheet in that situation.
In what scenarios CSS sprites would be good to use and when not? Is it time saver or only server request saver?
I think bandwidth use will be same because image is same like ong big image but it's in a parts?
When and where use of css sprite is a time saving(in work) option ?
For navigation it's good for rollover pre-loading effect but not good for images disabled people?
What are other good usage which can save our time once and in future (if changes comes in design) both?
Edit: Sprites is only for css background so should we use images in background as much as possible to save sever request, is it good idea?
Update:
To implement takes more time then regular method and mostly client do not much worry about some slowness like http request. My question is can we save time in site making process and future maintenance of website using css sprite. or regular method is enough.
In nutshell my question is: “can CSS sprites save our designer and xhtml css coder time (I'm not talking about server request)?”
It reduces the number of HTTP requests which will enhance site performance.
CSS Sprites are the preferred method
for reducing the number of image
requests. Combine your background
images into a single image and use the
CSS background-image and
background-position properties to
display the desired image segment.
In Minimize HTTP Requests
CSS sprites are a time saver because it is a server request saver, as server requests are notably time-consuming. Using CSS sprites usually decreases your webpages' load/render time dramatically. There are times when they cannot be used, such as with background images repeating in two dimensions, but when you can use them, it's almost always worth the effort.
Of course you shouldn't sprite groups of images that are very big, especially if they're not very likely to be shown. Don't sprite an entire photo gallery into one big image, for instance =)
Other measures which amount to pretty much the same thing would be minifying, compressing and combining your scripts and styles into only one js file and one css file.
EDIT
With regards to your clarification, i'd say no, CSS sprites will always mean more work, never less, compared to just using the separate images as they are. I still wholeheartedly endorse their use, tho =)
CSS sprites are best used for elements that have a fixed width and height. Otherwise, you need large empty spaces in your sprite image, which can (depending on file type) increase the size a bit.
Due to the way different file formats compress images, sometimes a CSS sprite image will have a noticeably smaller file size than the total file size of separate images. That’s a nice bonus.
As mentioned, sprites reduce the HTTP request overhead, which can help load time. I’ve never seen any numbers on the magnitude of this effect.
Sprites will add a bit of time for your CSS developers. It shouldn’t affect your designers. But bear in mind that your developers code the site up once; the benefits of sprites apply every time someone looks at the site.
It will only reduce the number of requests but that will benefit both the server and the client. The server will not need to handle as many requests. The client, because it is limited in the number of parallel requests that it can make, will render faster as many of it's previous "requests" for the image will be served from its cache, allowing it to make the requests that it does need more expediently.
Using sprites reduces the number of requests and thus also the network overhead. Loading a few sprite image is faster and uses less bandwidth even if the image data is the same (or even a bit more) than the individual images.
It needs a bit more work and some planning to combine the individual images into sprite collection images, so the development time is somewhat longer. The difference is less if you have it in the plan to start with rather than combining the separate images afterwards.
Any scenario where you have several same size background images that replace each other (or complement each other) is ideal for sprites.
As long as you have something like a dynamic photoshop PSD file in the back, then the designer's maintenance won't be an issue. But if it is a static file like PNG/GIF, then maintenance will take more time as you cannot control the individual images separately anymore.
Overall, sprites is a great idea. Use it for fixed width & height images that are less likely to be updated frequently.
Sprites are always good to use. They help speed up the loading of web pages and prevent the blinking effect on navigation hovering.
How do you approach the use of image sprites in css?
Should I take all the images in my website and combine them to one image sprite? Is it really that beneficial?
How hard is it to maintain those images and change them later on?
Should I take all the images in my website and combine them to one image sprite?
Of course not. You're taking it too literal.
I find sprites are best used for groups of similar images. Examples include:
All states of a graphical button
States of icons
All permutations of a background (unless it needs to tile two ways)
Is it really that beneficial?
If you have a lot of them on a busy site, very. It saves a request for each image, saving the user time and your server a whole bunch of concurrent connections.
How hard is it to maintain those images and change them later on?
If you've used them logically, pretty simple. If you need to add another navigation item, you open up your nav sprite and expand it. For things like navigation it can actually be easier to maintain because you have like comparisons right next to you in the same document.
Edit, having seen one of the more extreme examples, I'll add that I would never go that far because:
It's 60k to download. Not huge but on slow connections, that's 60k that has to be downloaded before anything shows. If all your visual assets are tied up, it can make the load time seem longer.
Your CSS becomes a nonsensical mish-mash of background-position commands. If you do want to make changes you have to go back to the sprite and measure everything. Again and again and again.
God have mercy on your soul if you need to enlarge something in the top-left of the sprite. You'd probably just add a new sprite below the current ones.
And that might lead to bloat. Indeed, just loading all these images might be loading a whole lot of material that some users will never actually see. Loading unused data is probably worse than a connection overhead (considering how easily static content can be served by multiple cheap servers or a CDN)
The other examples are a lot more simple and worthwhile (IMO).
Sprites are a great way of cutting down load-time on graphics (sometimes), and always a way of cutting down requests to the server. Generally speaking, they may take some serious planning as you don't simply want to drop a bunch of images onto a canvas and export as a jpeg. I would suggest you study some sprites currently in use by larger companies like Amazon. Get an idea for how they layout their elements, and what types of images they even consider for use in sprites.
You'll also want to evaluate your site and be sure whether you can successfully implement them or not. If you weren't planning on using them to begin with, it may require a lot of back-tracking and updating to prepare for them.
Amazon Sprite
Ebay Sprite
Current.com Sprite (Whoa)
Google
Sprites work well when you’ve got an element with at least one fixed dimension (width or height), and you want it to have a different background image in different circumstances.
When I’ve tried it, I’ve found that sprite image files tend to be smaller than the total size of the individual images files they’re made from, so you can get bandwidth savings as well as the other two benefits:
fewer HTTP requests
no delay waiting for another image to download when an image state changes on hover
That does depend on the contents of the images though.
Personally, I wouldn’t put unrelated images together in one sprite image, as I think it makes maintenance too non-obvious. Also, as mentioned in To Sprite Or Not To Sprite, really big sprite images can use quite a bit of browser memory. (Whether this is actually a bad thing depends on the context.)
The idea is to avoid unnecessary HTTP requests. This is especially an issue if you have a lot of small icons (say, for a WYSIWYG editor like the one used on this site). If you have twenty 16x16 pixel icons, that won't amount to much bandwidth, but it will still mean twenty extra requests each time the page is loaded.
Other candidates for sprites are button states and anything that's purely decorative but part of the layout.
If you use roll-over background image changes, you'll also find that you'll either have to preload the roll-over state image (either with JS or with silly hardcoding) or you'll encounter some latency as the browser requests the previously unused image. Sprites can alleviate that.
Things you probably shouldn't be making sprites of are pictures that are NOT just graphical elements (e.g. graphs, illustrations, avatars, ads) or that will change a lot (e.g. avatars or ads).
It's not impossible to change sprites, but depending on how much thought you put into the arrangement of the sprite sheet, it may be very hard to do. There's nothing forcing you to make the sprite sheet ultra-condensed, but it's obviously better for the file size if there's not much unnecessary whitespace in it (see Google).
Note that the extra requests may not be a problem for you if you have a relatively low traffic site (which almost everybody has, unless you're Google or Amazon). Sprites may still improve performance for mobile devices, though, as it means less chances for errors and thus lower latency.