I currently use a repeating pattern of raster images on one of my websites, which isn't so complex that it couldn't be converted to vector, but hasn't, as of yet, been scaled up to look decent on HiDPI/Retina displays.
I'm considering converting the raster pattern to vector, and setting the resulting .svg image as the background, but I want to know whether there are any disadvantages to using vector images in a website background.
Depending on the complexity of the image (filters, masks, gradients...), it could consume more CPU to render the image; the good thing is that more and more graphic tasks are sent to the GPU, so that's not a big problem
Not compatible with older browsers
Browser support isn't perfect yet, so if you're using complex features, there might be differences in the way the final image looks
But I strongly believe that vector graphics have much more advantages than disadvantages, so go for it.
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.
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 a 100x100px image and i need to show that in 3 different dimensions in html,
50x50 60x60 70x70
so my dubt is if better to save img in 3 dimensions then do not use css or html width and height or if to use same img with css rules about dimensions... which solution is faster rendered ?
It depends.
If you are using the same image, Only 1 time image cache is required by the browser. So If you are displaying more than 1 type of image in the same page then dont go for multiple images. Otherwise go for multiple images.
But honestly, 100x100 if you have, It should not be a problem to load. Only in slow connections it will be problem (<128kbps). Otherwise i dont see a considerable difference.
I wouldn't worry too much about rendering speed, the main difference you'll see is in terms of image quality. Some browsers (Chrome) perform very high quality image interpolation, while others (IE, Firefox) opt for a faster algorithm that does not give as nice of a result. So you'll get the best, most consistent image quality by having the three separate image files, one for each size.
That said, since you're only scaling from 100x100 to a minimum size of 50x50 you probably don't need to worry too much about interpolation artifacts either. So I'd recommend just doing whatever is most convenient for you to implement.
And in terms of pure rendering speed, having the separate images will be faster, because no interpolation step is required in that case. In terms of initial page-load speed, however, having a single image will be faster, because there is only 1 file to download instead of 3 (or 4). As for using CSS or HTML tag attributes to set the width and height, there will be practically no difference in speed. The expensive operation is the interpolation of the image itself, and it doesn't make much difference if you specify the interpolation through CSS or through tag attributes.
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.
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