I'm trying to optimize my site for speed. I used images for the rounded corners before but now I've changed them with border-radius and -moz-border-radius css rules. Which way is the best for speed? I used to think that css rules are faster but I've seen a lot of sites talking about css sprites and I'm a bit confused now. Oh and I don't care about IE compatibility so you can suggest any method you want.
The speed goes like this: CSS > sprites > separate images.
The sprites is when instead of having separate images for the corners you use a single image and slice/position it with CSS. It's fatser, because you only download one image then. CSS is the fastest, because it doesn't need to download anything.
For those browsers that support radius CSS properties, use those. They are definitely faster, because no image needs to be loaded and they can be rendered by the browser's native engine.
For those (older) browsers that don't, apply an image-based workaround.
Don't worry too much about this stuff, though. The speed improvements reachable through optimizations in this area are very, very minuscule.
Both are exactly the same, except that because CSS3 specifications has yet to be finalized, Mozilla implemented border-radius with the -moz- vendor prefix. You'll need that, and the -webkit- version for rounded corners to function on Webkit (Chrome, Safari) and Mozilla (Firefox) browsers.
As for speed.. it is unclear whether you are talking about transfer or rendering speed. In either case I would suggest that the difference is negligible, and you should use all three for maximum browser support (minus IE, of course)
I would recommend CSS Sprites. This is a good tutorial: http://bavotasan.com/tutorials/simple-rounded-corners-with-a-css-sprite/
Related
Is there a way to disable antialiasing for images in Chrome/Webkit? For performance reasons, I'd like to not have the browser smooth images larger than the actual files.
Image interpolation mode in Chrome/Safari? mentions this problem from a year and a half ago, so hopefully Webkit has added some sort of support since then.
Edit: Upon further research, Using nearest-neighbor with CSS zoom on canvas (and img) seems to go further into this, but isn't clear on exactly what works.
As browsers are finally starting to agree on CSS3, many web developers are rubbing their hands in excitement over their new, image-less web designs. They're clean. They're scaleable. They're powerful.
With border-radii, box-shadows, font-faces and the like, now we can convert our designer's beautiful design into lines of code, instead of packing our pages with img tags.
Two related questions:
Is there a point when the stylesheet(s) get so large that they actually [negatively] affect performance to a noticeable degree?
In a web application with lots of icons (in the range of 16px to 48px size), how noticeable would the performance boost be by using an icon font?
Is there a point when the stylesheet(s) get so large that they actually [negatively] affect performance to a noticeable degree?
It's just common sense really. If your stylesheet(s) become quite large then that will have just as negative an effect as having lots of images. In general terms a stylesheet (with lots of CSS3 and fancy bits) will be faster to download than a load of images.
I'd recommend taking it case-by-case and deciding whether CSS or images provides the better solution taking into account download speeds, browser support requirements, desktop vs mobile and so on.
In a web application with lots of icons (in the range of 16px to 48px size), how noticeable would the performance boost be by using an icon font?
Unless you were talking about hundreds/thousands of icons then there really isn't going to be a hugely noticeable difference in performance. Remember with icon fonts you're also probably having the user download some custom fonts.
Again it's really a case of using what is best for the current project.
I don't think there is a definitive answer to your question but hopefully what I've said clears it up a little for you.
I don't think there is a "point", and performance is not related so much to the size as it's related to the style rules themselves. The main issues I've seen are related to CSS gradients (especially radial gradients). This was a year or so back, but I remember testing some mobile devices with some mixture of gradients and on (webkit) mobile devices, the web page's display was notably lagging. Removing the gradients and adding images removed the lag. Now, for all I know, most devices now may have newer webkit display engines which might fix that issue, but I do think it's still a valid point to consider.
The size of the CSS files does affect performance in a few cases. If the CSS is especially large, it will cause some issues. But as someone else mentioned, it is text, so its probably pretty small file. But if that CSS is split across many files, that becomes a bigger issue. I have seen some sites with 10-20 css files, all located on a single server. Depending on the browser, it can only open 2-6 (maybe 8) connections at a time to each server. If you have 10 css files, plus another 10 js, plus 100 other assets, thats going to take a relatively long time to open and close the various connections. One way to solve this is to concatenate the CSS files as part of your development process. Some tools that do this that I like are Yeoman or Codekit. Those tools will also automatically minify the CSS as well making the one file they generate that much smaller.
Using an icon font is good because they are scalable and use a single file. As you zoom in on a page, the icons continue to look great, while the pngs you might use look terrible. The icon font is also one file, so for the same reason as above, its one file versus 10s-100s. If you do need to use PNG files for some parts that are not icons, look into using sprites, often referred to as CSS Sprites. This is a technique for combining several images into a single png file, which can then be used on the site with some creative CSS.
The whole point of CSS is that the styles cascade upon one another. Extremely large style sheets would lead me to believe the CSS is not written properly and therefore not cascading down. That being said, I suppose its possible have large properly cascading style sheets in which case I would recommend using a minifier to eliminate white space and compress your code to make the load time faster.
As for the icons are concerned, you could possible create a sprite (a collection of multiple images) and then use CSS positioning to only show the icon you needed. In this way the server would fetch only one large image instead of a lot of smaller images. Granted it, the one image is larger than the others, but nothing kills load time and slows a page's performance than a ton of fetch requests by a server for images.
My project's creative designer and I have had some amicable disagreements as far as whether it is better to use slices of his comp or rely on the browser's rendering engine to create certain aspects of the user experience.
One specific example is with a horizontal "bar" that runs the entire width of the widget. He created a really snazzy gradient that involves several stops of different colors and opacities, and he feels that the small size of the image is preferable or at least comparable to the added lines of CSS code needed to generate the gradient natively.
We're already using CSS sprite technique to reduce the number of return trips from the server so that's not an issue for us. Right now it's simply the pro's and con's of using sliced up imagery versus rendering with CSS and HTML.
Is there a definitive rule as to how large an image needs to be to be the "worse" option of the two?
UPDATE: Since a few people have mentioned the complexity of the gradient as a factor I'm going to present it here:
-webkit-gradient(linear, left top, left bottom, color-stop(50%, rgb(0,0,0)), to(rgba(0,0,0,0.9)));
Very complex! ;-)
Measure it! Not the answer you like I think, but it really depends how complex the CSS will be and therefore how long it takes to be rendered.
In most cases it'll be the render time (CSS version) vs. request overhead and transmission time (image version). You will most probably see the big numbers here. Since you're already using image sprites you're reducing the request overhead to a minimum.
Browser compatibility should also be something you should be aware of. Here images will often win over CSS when it comes to gradients and something like that.
Some very complex CSS3-site to demonstrate what I mean: http://lea.verou.me/css3patterns/
This is a VERY nice case study, but incredible slow. It lags when loading. It lags even more when scrolling. And I am sure it is much slower than a solution using an image sprite for all of that.
Don't treat me wrong! I love CSS, but images are fine too. Sometimes even finer.
Summary
Measure it! When you do not have the time to measure, then estimate how complex the css would be. When it tends to get complex, then use images. When you've compatibility issues, then use images.
In general, if it can be done with CSS, definitely skip the image. If for no other reason it's easier to maintain.
HOWEVER, a complex gradient is likely where I'd give in and throw in an image. Having recently implemented some CSS gradients, it is a bit of a mess right now.
Ultimately, Fabian Barney has the correct answer. If it's an issue of performance, you need to measure things. In the grand scheme of things, this is likely low on the performance issues to dwell on.
i think CSS is more reusable. Imagine you have to repeat the same image over and over again in the same web document. Lots of HTTP requests there. But that's my opinion, please correct me if I'm wrong I think CSS is way more expressive and flexibly stylish.
However, there are things you have to watch out for. Stuff like browser specific prefixing kill pages with too much CSS.
I am working at an app that causes lots of browser reflows. Performance is a key issue here. From the performance point of view Is it better to use a CSS3 gradient or an image gradient for some DOM elements? Does a page that uses CSS text shadows and gradients will have a slower reflow as a page that uses images to achieve those visual effects?
Also, are there any reflow tests out there I can use?
For drawing, CSS gradients and shadows do task the CPU more than images. Performance used to be pretty bad, these days they are acceptable. If you have a ton of gradients/shadows, you should just implement them and do the tests in your real-world setting. If you just have a few, I wouldn't worry about it.
It depends a lot on how the browser renders it, but for the most part those things will render slower. In addition, you'll have a less pixel-perfect display in older browsers. However, this also serves to segment your audience, as generally those with updated browsers also have updated computers. So, it's a trade-off that can work in your favor to essentially serve a stripped down version of your site to those that wouldn't be able to handle it. It's not guaranteed, but I've found it usually balances out pretty well.
Overall, real-world testing is the way to go. Build it, see if it works, and fix performance issues once you find them. I wouldn't hesitate just because there's a chance it might not work. If it works just fine and you don't try it, you'll never know!
Back in the old days, one would always need to scale images in Photoshop, because the browsers did a terrible job of it. Firefox now seems to scale images smaller quite nicely. Do the other browsers do a nice job too?
Internet Explorer 7 doesn't do so well, but IE8 does. You can change IE7 to use the better method from IE8 with a simple line of CSS.
img { -ms-interpolation-mode: bicubic; }
P.S. I found this out when working on an intranet page where bandwidth wasn't a problem. For something on the internet I would seriously consider resizing the image to reduce the number of bytes.
If you're asking whether or not you're safe to display large images in small areas on a webpage, I wouldn't risk it: resize the image prior to posting/let your framework resize the image. You'll save the client from downloading a huge file, and you'll know exactly how the image will display.
Most modern browsers are good at scaling images, although none will be as good as a proper graphics application.
However if you have a graphic you are scaling to be smaller it still has to be downloaded before scaling it, so it is better to have a small one if you can, especially if you have mobile clients