I'm making a sprite and its reaching about 4000px in height. Is there a general size for maximum sprite height that is used within the graphics design community?
Browsers will have to decompress (and keep in memory) the whole image even if you only use very few sprites in it, and even if most of the image is blank/white.
For a desktop client you've only missed an occasion to be a good citizen by using too much memory (and browser are already sucking a lot of memory).
For some mobile client (eg. IPhone for files over 25k after degzipping), it can be more problematic, the image won't be cached at all, thus it may be better to have 2 files <25k and two HTTP request than one >25k file and a single request never cached.
Last problem, PNG compression is line-based, there is less overhead in having wide images than tall ones (though too wide could be theoretically bad in some case, since you can have only one prediction filter type per line).
Oh and also, with too much spriting, you may end with way too much different colors in the same image, and miss the opportunity for decent paletted image. Testing all combinations of this is tedious, but if you can, grouping your sprites by main colors of gradients is a good heuristic (since gradients/blur needs many different colors).
I don't think the focus should be on how big the sprite is physically (width x height) but rather how big the sprite file size is and ask yourself the question if it would be worth splitting the sprite into multiple sprites.
Quite often we split our sprites based on color so have sprites that are predominantly blue or red or yellow. That way we get smoother gradients and overall image quality while keeping image file sizes down
Related
I've read a lot about the benefits of using sprites in css for icons and logos, but this seems to be largely used for lossless formats such as gif and png. I'm wondering if the benefits are still there with jpegs and images? I want to build a header from a number of smaller pictures that may be displayed in different orders. Will combining them into a single jpg still have the speed benefits of the normal use cases for sprites?
It might depending how big those jpegs are. Usually images are combined to reduce http calls back to the server. If they are small in size then combine them, if not then leave them separate and call which ever ones you need.
The main benefit of using the sprites for multiple images is that it provides a smaller amount of header information being sent. Therefore having larger pictures inside of the sprite would have less of an overall impact on the whole project, there would be a small increase but the adaptability of the system is reduced using sprites. If the picture is going to be changed at any point i would keep it outside of the sprite.
You can reap the same benefits in terms of reduced round-trips, etc. but:
The level of compression is likely to suffer; JPEG is tuned to reduce the size of single images, and does poorly with abrupt transitions (as in a collage, which your meta-image would basically be)
For the same reason, it's possible that the edges of your sprite images will be less sharp than they are now, as they're being lossily compressed (and so slightly combined) along with adjacent image data.
My site have a big css sprite image.
Site: http://www.protohaber.com/demo
Sprite Image: http://www.protohaber.com/demo/templates/v1/images/proto_sprite.png
My site is works slow (e.g. page scrolling slow, etc..) at browser in some computers (low cpu computers)
Maybe you should try to use PNG Gauntlet to optimize the image.
Another Solution could be to split the Sprite into two or even more.
I think the principal reason for this is because the image is too big (almost 1.5 Megabytes), So just imagine how much the cpu have to calculate to move the background from one side to another. I think you sprite has a lot of resources which doesn't belong to it (like some images (the girl, caution alert, etc). Also you are mixing a lot of color at the same sprite which make the images bigger because has more colors to render.
I think one option is break apart the sprite into separate one which will make the file smaller (the slow processors can handle, render and move better small images), remove the images like (the girl, caution alert, etc) and make them jpg file which will make the file also smaller.
the idea of sprites is reduce the request to the server but if this reduce the performance of you application is best idea to make a couple of more request and have a better performance for the final user.
I notice that the file size of CSS sprite (.gif) keep growing over the period. That is because we keep adding new icons / sprites, and we never remove the existing sprites, because we are afraid of breaking existing design (offset recalculation or the sprites may be used somewhere that we overlooked).
I wonder how do we reduce the number of sprites? The image file size keep growing and growing.
You will have to do a manual check (do a search for the sprite name first, but once you have your results you will have to use pen and paper) to realise which images are being used. You can replace those ones for the new ones without touching the positions for the rest, but before doing that I would consider:
Changing your gif to png-24 or SVG, as they weight less and have WAY better quality, specially with transparency involved. SVGs are also scalable, great for retina display devices, although not supported by all browsers (meaning IE) and therefore need an alternative.
Using different sprites for different categories of images (for example, one for menu icons, another one for social icons, etc) so it's a bit easier to manage. You would be having two or three more server requests, not a real difference.
As from my experience, you have to do that one time clean up.
And then do things right !!!
Do OOCSS and use speaking names for specific sprite images.
I would recommend reading http://devblog.xing.com/frontend/a-so-called-sprite-revolution-on-xing/
After this, administrating the sprites will be muuuuch easier, but as I said, the one time effort is need.
Also, because GIF is not the format you want to use :-)
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.
Does it matter how long and wide an image is when using CSS sprites? I noticed the SO sprite image is one long image, with all the sprites on top of each other.
Would having the sprites grouped together increase performance?
Due to png's filter/compression algorithm, large swaths of uniformly-colored pixels barely contribute to the file size.
The minor file-size cost of arranging your sprite vertically (like Stack Overflow), as opposed to squeezing your icons into a perfect square, is probably well worth the benefits of having cleaner CSS and a more maintainable sprite.
It would increase performance if you could reduce the image size. I doubt it would increase performance by much because reducing the image size will not reduce the amount of requests which is the whole reason for using sprites. That said, someone using dial-up might notice a difference.
Yes in few cases it would, because collectively many different images have a larger size than a single large images. Also the there will be no need for sending request for each image, all the required images will be available in a single sprite image. Then later your css will cut and use the required areas.
The difference will be noticed in low bandwidth connections where with multiple images each will be rendered with a little time gap, where as in a sprite based css, each will show almost simultaniously