Will an imageless design (using CSS to generate icons) load faster than a traditional image based design?
NOTE: I completely understand the flexibility of being able to change an icon's colour, size etc. will a few changes to the CSS file is much more efficient, but I am unsure about the loading time.
Background:
I am looking into completing a project for a client that is an imageless design using CSS to generate the page icons, which was a project requirement to decrease loading time on mobile devices. Normally, I would just slice out the icons in an image sprite and not worry about the load time seeing the browser would only have to load and cache on image.
Thanks!
Yes, if site icons can be generated entirely in (relatively efficient) CSS, this will load faster than images. The rub is that most icons are far too complex to be generated using CSS, and the CSS might in some edge cases become so complex that the maintenance issues associated with maintaining complex code across browsers might outweigh the benefits. But in general, if you can do it in CSS without having to bend over backwards, it would be optimisation—and in the scenario you describe might well be worthwhile optimisation.
I don't think the question is whether or not it's faster, but whether or not it's a good idea at all. I wouldn't sacrifice the flexibility of using images by making everything into pure CSS. You guarantee cross-browser compatibility with images, something that CSS3 cannot. Plus images are easier to maintain.
Think it in this way .. the size of css icon(the size of the code required to produce an icon) is an advantage and the other major advantage is the server hits. for ever image icon there is a hit which means there is a waiting time, downloading time, and rendering time, though its only in milliseconds the waiting time and downloading time are directly proportional to your server load.
In that case a css3 icon will not only save time and band-width but also reduce your server hits as the css file downloads only once and its contains all the style declarations for the entire site.
The advantages are enormous to choose a css icon. But there are some cases where a css icon is not suffecient, so its up to the developer to choose from a css icon or an image based on the requirements.
Related
My manager tells me not to use icon fonts on our websites, as it is another http request plus the extra kBs to download. Also because I would have to use content before for the font (I can't change the html), he prefers background images so it works in IE7.
Personally I love the little things, so nice and crisp and resizeable!
I get it if we only use a couple of icons on a website but if I would use, say 5 icons on a site - what do you guys think? Is it worth using an icon font or is he right thinking that it is not?
I am just a sucker for anything new and exciting, and this year it is the retina display.
Icon fonts and high density screens
Using icon fonts will be more and more relevant as more high resolution/density displays become available.
A 16×16px icon can look horrible on a high density display (>300ppi). It may either display incredibly small or unsharp due to automatic scaling. A 1em font icon on the other hand will render correctly and sharply regardless of screen density.
It of course all boils down to your
application users and
your requirements (IE7 seems to be the major breaker)
For now sprites are the way to go.
Downsides?
Icon fonts have a different problem as well. All icons are single colour. There's no font standard as of yet to have multi-colour capability. And it likely won't be. At least not for fonts. There are possibilities of doing multi-colour using SVG fonts which isn't a font standard/format per se but can be font container and used as a font delivery mechanism in your browser. Doing multi-colour icons as SVG fonts makes it possible to have colourful scalable icons (thanks to #Joey).
Vectorised icon images would better suit full colour resizeable icons.
Requests and font icons
Your boss' argument about additional request are simply false. It doesn't really matter whether your icons are part of a file or (in best case) part of a sprite image.
Both yield an HTTP request to fetch the resource. File size heavily depends on complexity and format but it may be that sprite image will be smaller. But having a few kilo larger font file doesn't really make much difference. They both get cached on the client afterwards.
I personally use Font Awesome as my primary resource for fonts, In my case I load it from the CDN hopping other pages that use it already fetched it and this was cached by the browser.
If file size is a concern, I can recommend to you this incredible awesome tool
http://fontello.com/
It allows you to merge several fonts into one single file, and only includes the icons you actually use.
http://www.icnfnt.com/ does the same for fontawesome, but I kinda like more fontello because it allows to use more fonts.
icon fonts is the way to go honestly in my opinion...
EDIT I lately have being using this app a lot too: http://icomoon.io/
When you use fonts, different browsers on different platforms will give different results. PNG files will give stable and independence results.
I have implemented a font icon library using icomoon and it works well on all the browsers including ie7. For small sets of icons this is a suitable practice, the font's scale properly, can be changed to any colour you require and you don't have to worry about PNG/GIF transparent background colours matching.
However... If your library becomes larger (mine is now around 40 icons), it becomes increasing difficult to maintain. If the designer ceases to work on the project, or you need to change the icons, it is a laborious process to update the fonts. Everything then needs to be retested. It is also difficult to dynamically icons using CSS (for ie7).
So, given the difficulty of maintenance, I'm considering switching back to a series of sprites (of different colours). The reasons being:
Any designer can easily add a new icon to the set.
The CSS doesn't need to be retested or altered.
You don't have to screw around with javascript workarounds for IE.
You don't need javascript at all.
For retina displays, simply create a verion of the sprite at twice the size,. You will probably need to have a different version of the CSS for retina regardless, as all the other images on your site will have the same density problem.
I would recommend 2 solutions to your problem these is what i would use for best customers support like they wanna change the text, size or other stuff
Use Fontsquirrel to make a webfont and embed it in your website trough your css and add it in your ftp directory if thats not getting pretty then use google web fonts
If non of that looks like it should i would go for the image solution your boss said..
All this also depend on which amount of time you have to solve your problem and such
Btw if you cant access the html i thought you could access the css which you can do trough most backends, if you cant then go for the image!
Last but not least, if you decide to go with the image solution, make a sprite which you direct trough on a background position. This way you only have to load 1 picture for all your little icons.
He's right. I'd use css sprites in this case. And if you have to support ie7 (I'm so sorry) you don't really have any options. Exploring those things on your own - of course, you never know what will come in handy or when.
I been working on rollover images with pure css and i am aware of 2 solutions to achieve the desired result. I wonder if there are any benefits which i am unaware of with those methods and if there is a preferred method or is it just a preference (I just want to make sure before i finish a giant project so there are no surprises later)
first method
The first method i run across is to save multiple images as one image.
then to set the image as the background of a divider (that is smaller then the whole image)
then on :hover you set background position to negative and the other images appear
Some cons and pros i thought of is that:
pros
you do not need to preload the images manually (by placing code at the end of css file)
It might be easier to organize your image files as there could possibly be fewer of them
cons
it can be difficult to know how much exactly move the image especially if you have seperate team designing the graphics
second method
The second method i run across is to set an image background of a divider and then to change the background url on :hover
Some cons and pros that i can think of on top of my head:
pros
possibly less time in development
can exchange rollover images with more ease and dont need to specify the size of the divider
cons
need to preload images at the end of css file
possibly more mess in your image folder if you have a lot of files
Is there any pros or cons that i am missing? Is one method generally preferred over the other and why? Or is it personal choice and there is no problem with using either one??
Update:
Here is a link to simple preload for the second method with pure css. I thought there was an even simpler way (of just placing the links) but i cannot find it. Still this is pretty basic.
Update(2):
I have learned that sprites have additional
benefits of making websites faster by reducing the number of http requests.
and benefit of rollover being as fast as possible with no flicker
And a blunder of making a less accessible site, and would limit the potential benefits of the title and alt attributes in the HTML. (if used incorrectly for all images instead of just decorations and buttons)
CSS sprites (the first method) is generally favored due to the fact that pre-loading isn't necessary to maintain a quality user experience.
the ALA link Wex posted is a good primer on the benefits of sprites, and Smashing Magazine recently published an article which addresses your concerns about background-position when using a sprite with many images
http://coding.smashingmagazine.com/2012/04/11/css-sprites-revisited/
The first method is much better than the second one. You don't always have to bundle up every image into one giant image - that usually makes it hard to add new images - but it does make sense to put every image and their hover state in the same image so you don't see a flicker on hover, and so you don't have to rely on some preloading script.
Here's a good article that talks about the benefits of using CSS sprites: http://www.alistapart.com/articles/sprites
I'm looking to use CSS gradients for an element of my web app that is drawn repetitively, as it would allow me more flexibility in dynamically changing its appearance. However, my question is whether gradients are more expensive for the browser to render than bitmap images. Or do images use more processing power? (And I'm not concerned with cross-browser compatibility- the app will only be used on the iPad)
According to an article on the Webkit Wiki, images perform better:
Sometimes it's tempting to use webkit's drawing features, like -webkit-gradient, when it's not actually necessary - maintaining images and dealing with Photoshop and drawing tools can be a hassle. However, using CSS for those tasks moves that hassle from the designer's computer to the target's CPU. Gradients, shadows, and other decorations in CSS should be used only when necessary (e.g. when the shape is dynamic based on the content) - otherwise, static images are always faster. On very low-end platforms, it's even advised to use static images for some of the text if possible.
Source: https://trac.webkit.org/wiki/QtWebKitGraphics#Usestaticimages
Of course, you have to balance that CPU time with the extra time it would take to load the image from the server. Also, for Internet Explorer, filters are extremely slow, especially if you have many on one page.
This above answer is directly lifted from How does the performance of using background-gradients in CSS vs using images?
These links can be useful read for you
Browser Repaint/Reflow performance: using CSS3 Gradients vs PNG Gradients
CSS gradients are faster than SVG backgrounds
http://leaverou.me/2011/08/css-gradients-are-much-faster-than-svg/
Runtime Performance with CSS3 vs Images
http://jacwright.com/476/runtime-performance-with-css3-vs-images/
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.