Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

CSS3 vs. CSS: A Speed Benchmark

I believe in the power, speed and “update-ability” of CSS3. Not having to load background images as structural enhancements (such as PNGs for rounded corners and gradients) can save time in production (i.e. billable hours) and loading (i.e. page speed). At our company, we’ve happily been using CSS3 on client websites for over a year now, and I find that implementing many of these properties right now is the most sensible way to build websites.

Until today, all of that was based on an assumption: that I can produce a pixel-perfect Web page with CSS3 quicker than I can with older image-based CSS methods, and that the CSS3 page will load faster, with a smaller overall file size and fewer HTTP requests.

Further Reading on SmashingMag: Link

As a single use case experiment, I decided to design and code a Web page and add visual enhancements twice: once with CSS3, and a second time using background images sliced directly from the PSD. I timed myself each round that I added the enhancements, and when finished, I used Pingdom5 to measure the loading times.

Here’s a fictitious Web page for Mercury Automobiles6 that might have been online had the Interweb existed back in the 1950s. The page was designed to showcase specific widely compliant CSS3 properties that in the past would have had to be achieved using background images.

Mercury Automobiles Diagram

Above is a diagram that breaks down where I applied visual enhancements first with CSS3, and then with CSS background images (i.e. the image-based approach):

  1. linear-gradient
  2. border-radius
  3. radial-gradient
  4. text-shadow
  5. box-shadow with RGBa

The Experiment Process Link

Day 1
I coded the HTML and CSS from a structural standpoint. That means no rounded corners, no shadows, no gradients and no images aside from logos and car photographs. I decided to include Web fonts at this phase because I wanted to focus on stuff that could also be done with the Web-safe font of your choice (Helvetica, Georgia, etc.). Furthermore, @font-face was around long before CSS3.

Mercury index7

This gave me a blank canvas to add visual enhancements. The index page8 shows the end of my day 1 work, as well as what unsupported browsers will display, the appearance of which is structurally intact and visually pleasing. More on this later, but the way I see it, older browsers aren’t penalized with a broken layout, and modern browsers are rewarded with a few visual bonuses. Part of implementing CSS3 is about planning ahead and designing websites that look fine as a fallback.

Day 2
Starting with the base index page, I created a CSS3 page9. It took 49 minutes to complete. Here is the CSS code (css3.css10):

/*-----CSS3 Started on 2/26/11 at 7:28 AM CST-----*/
h1 {
	text-shadow: -3px 2px 0px #514d46; }

#nav {
	-moz-box-shadow: 0px 0px 12px rgba(88, 83, 74, .7);
	-webkit-box-shadow: 0px 0px 12px rgba(88, 83, 74, .7);
	box-shadow: 0px 0px 12px rgba(88, 83, 74, .7);
	background-image: -moz-linear-gradient(top, #5c5850, #48473e);
	background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #5c5850),color-stop(1, #48473e));
	background-image: -webkit-linear-gradient(#5c5850, #48473e); 
	background-image: linear-gradient(top, #5c5850, #48473e); }

nav a {
	-moz-border-radius: 12px;
	-webkit-border-radius: 12px;
	border-radius: 12px; }

nav a:hover {
	background-color: #3a3e38;
	background-color: rgba(47, 54, 48, .7); }
nav {
	background-color: #070807;
	background-color: rgba(7, 8, 7, .7); }

body {
	background-image: -webkit-gradient(radial, 50% 10%, 0, 50% 10%, 500, from(#FBF8E3), to(#E6E3D0));
	background-image: -moz-radial-gradient(50% 10%, farthest-side, #FBF8E3, #E6E3D0); }

#learn_more, #details img {
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
	border-radius: 8px;
	-webkit-box-shadow: inset 0px 0px 8px rgba(88, 83, 74, .2);
	-moz-box-shadow: inset 1px 0px 1px rgba(88, 83, 74, .2);
	box-shadow: inset 0px 0px 1px rgba(88, 83, 74, .2); }

#learn_more a {
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
	border-radius: 8px;
	background-color: #cc3b23;
	background-image: -moz-linear-gradient(top, #cc3b23, #c00b00);
	background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #cc3b23),color-stop(1, #c00b00));
	background-image: -webkit-linear-gradient(#cc3b23, #c00b00);
	background-image: linear-gradient(top, #cc3b23, #c00b00); }

a {
	-moz-transition: all 0.3s ease-in;
	-o-transition: all 0.3s ease-in;
	-webkit-transition: all 0.3s ease-in;
	transition: all 0.3s ease-in; }
/*-----CSS3 Finished on 2/26/11 at 8:17 AM CST (49 minutes) -----*/

Day 3
I added visual enhancements by slicing and CSS’ing background images directly from the PSD. Even though there is less code, all of the extra app-switching and image-slicing added up to a total of 73 minutes to complete. Check out the page for the CSS image-based approach11. Here’s the code (css.css12):

/*-----CSS (the image-based approach) Started on 2/27/11 at 12:42 PM CST-----*/

#header {
	background: url(../img/navbg.png) left top repeat-x; }

body {
	background: #e6e3d0 url(../img/radial_gradient.jpg) no-repeat center top; }

#nav {
	background-color: transparent; }

h1 {
	background: url(../img/mercuryautomobiles.png) no-repeat center center;text-indent: -9999px; }

#learn_more {
	background-image: url(../img/learn_morebg.jpg);}

#details img {
	background-image: url(../img/detailsbg.jpg);}

#learn_more a {
	background: url(../img/learn_more_abg.jpg) no-repeat;}

.css3 {
	background: url(../img/css3_hover.png) no-repeat center top; }

.smashing {
	background: url(../img/smashing_hover.png) no-repeat center top; }

.trent {
	background: url(../img/trentwalton_hover.png) no-repeat center top;}

.css3:hover {
	background: url(../img/css3_hover.png) no-repeat center -20px;}

.css:hover {
	background: url(../img/css_hover.png) no-repeat center -20px;}

.smashing:hover {
	background: url(../img/smashing_hover.png) no-repeat center -20px;}

.trent:hover {
	background: url(../img/trentwalton_hover.png) no-repeat center -20px; }

.css {
	background: url(../img/css_hover.png) no-repeat center -50px; }

/*-----CSS (the image-based approach) Finished on 2/27/11 at 1:55 AM CST (1 hour and 13 minutes)-----*/

Production Time Results Link

So, we’re looking at a 24-minute difference: 49 minutes to add visual enhancements with CSS3, and 73 minutes to do it with images. For me, CSS3 was not only quicker but far more enjoyable, because I was focused on only one window (my CSS editor), unless I opted to pull some of the code from CSS3 Please13. On the other hand, slicing images and switching from Photoshop to FTP to the CSS editor and back again was a hassle, and it did take longer.

It’s also worth noting that I did my best to stack the deck against CSS3. I coded it first so that any initial hashing out would be done before heading into day 3. Also, the images I did slice are as optimized as I could reasonably make them: one-pixel repeating slivers, and medium-resolution image exports. Overall, 24 minutes may not seem like a lot of time, but this is a fairly simple page. Imagine how much time (and money) could be saved over the course of a year.

What? Still not convinced?…

File Size And Loading Time Results Link

I took both of my pages over to Pingdom Tools14 to compare file size and loading times.

Pingdom comparison

Both pages are pretty fast, but CSS3 prevailed, with 10 fewer requests and a file size that was lighter by 81.3 KB. While loading times were close, the larger PNG files used on both pages accounted for most of the heft, which amounted to a .75 second difference on average. And when we’re talking 3 to 6 second loading times, those differences sure can add up.

CSS3 CSS Difference
Size 767.9 KB 849.2 KB 81.3 KB
Requests 12 22 10

For argument’s sake, I created yet another version of the image-based CSS version, with a sprite containing all four images used in the original version, and then I measured loading times. This CSS Sprited version15 did improve things, taking HTTP requests from 22 to 19 and the overall size from 849.2 KB down to 846.7 KB. The way I see it, these differences are minimal and would have added to the development time, so it’s all relative.

Without getting too sidetracked, I think the difference in loading times is significant. If a website gets 100 hits a day, the difference may not matter much, but on a higher traffic website the effect compounds. Shaving seconds or even milliseconds off the loading time of a website is no small improvement in user experience. The image-based approach could lead to upwards of a 15 to 27% drop in page traffic (based on a 5 to 9% per 400 ms rate)16. That’s a lot of dinero to lose. I wonder how much time and money could be saved by serving a CSS3 border-radius sign-up button on a website with as much traffic as Twitter’s.


Another striking example is all the CSS3 that can be found in Gmail’s interface. The CSS3 gradients and rounded corners are there to increase page speed. Speaking of Gmail’s continued use of HTML5 (and CSS3)17, Adam de Boor had this to say about speeding up page rendering:

Google’s current goal is to get Gmail to load in under a second. Speed is a feature.”

And this:

The company has found that using CSS3 can speed the rendering time by 12 percent.

Convinced yet? No? Okay, I’ll keep going…

Thinking About The Future Link

Website Updates: The Easy Way and the Hard Way Link

CSS3 really pays off when it comes to making updates and future-proofing Web pages from a maintenance perspective. Looking at the Mercury Automobiles website18, think about what would have to go into changing the height of the three-column car images or the width of the bubble hover states for the navigation. For the sake of a quick production, I sliced these images to match precisely. One option would be to open Photoshop, rebuild and resize the images, update the appropriate CSS properties, and upload. Another would be to plan ahead and slice “telescoping” images, making one end a short rounded corner cap and another longer image on the opposite end that slides to fill the interior space. You’ve probably seen and done this before:

<div class="border_box_top"></div>
<div class="border_box_bottom">
	<img src="your_content_here.jpg" />

This isn’t ideal. While the technique comes in handy in a variety of instances, adding extra HTML just to achieve a rounded corner doesn’t seem efficient or sensible.

What If You Want to Go Responsive? Link

Serving different-sized images and changing the font size to suit a particular screen resolution simply couldn’t happen without CSS3. It’s wonderful how all of these new properties work together and complement each other. Imagine how time-consuming it would be to res-lice background images to accommodate varying image and font sizes that display at different screen resolutions. Yuk.

The Take-Away Link

For me, this simply proves what I’ve known all along: CSS3 pays off when it comes to production, maintenance and load times. Let’s revisit the numbers once more…

CSS CSS3 Results
Production time 73 minutes 49 minutes CSS3 33% faster
Size 849.2 KB 767.9 KB CSS3 9.5% smaller
Requests 22 12 CSS3 45% fewer

Yes, this is just one experiment, and the outcome was influenced by my own abilities. This isn’t meant to finally prove that implementing CSS3 no matter what will always be the right way to go. It’s just food for thought. I encourage you to track development and loading times on the websites you work on and make the best decision for you and, of course, your client.

We’re all concerned about browser compatibility, and opinions will differ. For me and most of my clients, this would be a perfectly acceptable fallback19. Perhaps with more experiments like this that yield similar results, these statistics could be cited to both employers and clients. If a website could be produced 49% faster (or even half of that) with CSS3, imagine the benefits: money saved, earlier launch times, more time spent on adding “extras” that push the product over the top, not to mention a better browsing experience for everyone.

Further Reading and Resources Link

  • Why We Should Start Using CSS3 and HTML5 Today20,” Smashing Magazine
    This editorial takes a realistic and encouraging look at the state of browser support and calls for the industry to move toward innovation rather than wait for a gate to be installed.
  • CSS3 + Progressive Enhancement = Smart Design21,” Perishable Press
    A comprehensive look at CSS3 that first examines the benefits of CSS3 over image-based methods, including less bandwidth, quicker implementation, increased flexibility, reduced HTTP requests and fewer server resources.
  • Google Gmail to Harness HTML522,” Macworld
    Google is all about speed, and this interview with Adam de Boor reinforces its view that, along with HTML5, CSS3 renders pages faster.
  • CSS Three — Connecting The Dots23,” Smashing Magazine
    Coming up with creative and sensible ways to get the most out of CSS3 will require experimentation. Right now, there are tons of property combinations and uses out there waiting to be discovered. All we have to do is connect the dots. It’s time to get your hands dirty and innovate!
  • Download the Mercury Automobiles .zip file24
    Feel free to pick things apart and learn more.

(al) (vf)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24

↑ Back to top Tweet itShare on Facebook

Trent Walton is founder and 1/3 of Paravel Inc., a custom web design and development shop based out of the Texas Hill Country. When he’s not working on client projects, he’s probably writing & designing articles for his blog, or contributing ideas for the next edition of

  1. 1

    Brentley Broughton

    April 21, 2011 5:13 am

    Great article! It’s great to see a real-world example & comparison that most designers will go through on a project to project basis. With speed becoming even more important on the web, it’s more important to keep an eye on such things as background images & extraneously loaded items.

    It seems designers need a reliable, browser compatible process for making rounded corners in designs. For something so seemingly small, rounded corners can be a headache.

  2. 2

    Thanks for putting it all down on paper. It’s great to see a side by side comparison showing where the time is saved (both in production dollars and site loading). I hope this gets more people on board with CSS3… let the learning begin!

  3. 3

    Great article, I fully agree and I think you are doing a goob job in convincing CSS3 is the way to go. We should not wait but use it now. Recently I completely re-engineered the front-end of this website:

    Using HTML5, CSS3 and a few performance tuning tips and the improvement in speed is dramatic (despite the page being still heavy because it is a photo site).

  4. 4

    Lovely stuff, nice example and true facts

  5. 5

    excellent post, good to see that using the latest css3 has an added benefit of being faster.

  6. 6

    Excellent article, a proper real-world situation and more ‘ammo’ for convincing clients (and colleagues alike) to use CSS3. More of this please Smashing Mag!

  7. 7


    April 21, 2011 5:56 am

    Very interesting to see the difference in time efficiency. Time to crack out the CSS3 tutorials!

  8. 8

    Excellent post!

    I’d advocate this approach with designing in the browser, so that your client gets to see their work in their own browser, and doesn’t have any false expectations from seeing a PSD of their work.

    Then, when you show them the result in Chrome/Firefox/other advanced browser, you can really explain progressive enhancement to them.

  9. 9

    Thank you, Trent, for another great contribution to the betterment of the internet.

    Have you tested any issues with performance lag of CSS3 in Safari when combined with javascript animation?

    Worked on a project with a large background gradient made with CSS3 that seemed to caused the browser to “jump” while a javascript powered automatic scroll took place. (

    Thanks again.

  10. 10

    Nice article.

  11. 11

    Nice article. Interesting to see how much of a measured difference CSS3 techniques can make in production & network times.

    However, to expand on what @Chris McKee pointed out, it doesn’t account for *page rendering* times.

    CSS3 techniques can lower production & latency times, but some effects (like box shadow & gradients) can drastically increase the page *rendering* times. Worse, the page can feel sluggish even after fully loading (ie redrawing box shadows while the page is scrolled).

    Rendering performance will surely improve as browsers make better use of hardware acceleration, but in the meantime it’s worth being aware of the possible performance hit of using CSS3 tricks.

  12. 12

    Zoe Gillenwater

    April 21, 2011 7:36 am

    Really cool! I haven’t timed myself doing the CSS3 vs CSS versions of a site, but I have measured the response time of a real page with and without CSS3, and got similar results. I’ve spoken about it in lots of my conference presentations and wrote about it in my book Stunning CSS3; you can actually read the excerpt from Chapter 1 that goes over the performance case study at I compared speeds in three different browsers and found that, ironically, IE 6 benefited the most in speed by adding CSS3.

  13. 13

    From a purely performance-minded perspective, I have to wonder what the results would have been if you sprited your images ( to the extent possible), bringing the non-CSS3 image count down from 17 to ?.

    More work to do that, but it would make things more interesting!

  14. 14

    Benjamin Cahill

    April 21, 2011 8:19 am

    I love the idea of CSS3 and all, but I suppose you need quite a powerful machine to view websites designed with a bunch of CSS3 smoothly.

    The difference between the speed of scrolling on a 1.6GHz Athlon running 64-bit linux between the CSS3 and CSS pages was quite noticeable—i.e. the CSS page was perfectly smooth during scrolling, and the CSS3 page was quite slow.

    Now I know why is so slow…

  15. 15

    I’m using CSS for my web development works. But now it is cleared. And I’ll learn CSS3 very quickly for my works. Thank you for the articles.

  16. 16

    I’ve started using javascript feature detection to use the CSS3 properties which are supported, with a fallback to images for those that aren’t. Obviously takes longer to develop, but it seems like best way to use CSS3 properties now and not alienate IE users.

    • 17

      Ryan McLaughlin

      April 21, 2011 7:05 am

      When a browser does not recognize a property, it will naturally fallback to one that it does recognize. To put it another way: browsers will skip unrecognized properties. So in cases such as gradients vs. background images, Javascript is unnecessary. For example:

      background: #FFF url(‘bg-gradient.png’);
      background: -moz-linear-gradient(top, #F8F8F8, #FFFFFF);
      background: -webkit-linear-gradient(#F8F8F8, #FFFFFF);

      Here, browsers that do not support these defined linear gradients will fallback to the background color and image. Browsers that do support them (Firefox and Webkit) will skip over the image and rely on the CSS3 gradient.

      Hope this was helpful.

      • 18

        I think he meant CSS3 properties such as box-shadow, border-radius, text-radius, etc. where you can’t have another CSS property as a fallback. In such instances, you need to use a feature detection tool to do some subtle visual changes.

      • 19

        Ryan, that’s not entirely true. AFAIK, Safari applies both the gradient and the background-image. Correct me if I’m wrong.

        • 20

          No, in that case Safari only applies the gradient. Try it, you’ll see.

        • 21

          Ryan McLaughlin, wouldn’t that show both the image and a gradient on top of that? hmmm.. I might need to look into something like this more.

          • 22

            Ryan McLaughlin

            April 25, 2011 7:15 am

            Sean, no. When you declare the properties, the browser will read them ascending downwards in line (depending on how you look at the code) and accept the most recent, valid property. Therefore, in the case of Safari, the first background will be overwritten by the -webkit-linear-gradient

            Give it a try in Firebug, you’ll see no image being downloaded.

      • 23

        The only problem with this approach is that in this case the image WILL BE DOWNLOADED by the browser so you didn’t save any download time, with the css gradient, plus you have one extra line in your code…

        By the way more and more clients are beginig to accept the fact that screen design is not like print design. Nothing will look egsactly the same in all browsers (not to mention that a user has 100 ways of interfiering with the layout, intended or unintended), and that a their websites look and feel doesn’t depand only on those damn rounded corners.

        Altought there are still a lot of conservative clients out there who can’t be convinced with any of the affore mentioned benefits of CSS3 and they don’t want to hear of any browser incondsistencies.

        But no worries I like hacking :)

        • 24

          Ryan McLaughlin

          April 25, 2011 7:12 am

          From my research, the point I was trying to make with background-image is that the image will NOT be downloaded and thusly skipped over to the gradient.

          Try it in Firebug, you’ll see no image being downloaded.

    • 25

      Hey Sam, Instead of using images as a fallback, try CSS3 PIE. It works great for things like, gradients, rounded corners, multiple backgrounds and box-shadow in IE. Super easy to implement and actually looks/works great.

      • 26

        Joshua Briley

        April 21, 2011 7:31 am

        I’m a huge fan of CSS3 PIE. Saves me lots of time on development. I do find the pie.php to be more cnosistent than the .htc, however.

      • 27

        Although CSS3 PIE is an amazing solution, it often does slow things down and causes other problems (for example when a user uses the zoom feature).

        It shouldn’t be used as a crux, after all, sometimes that little 3px rounded corner just isn’t worth punishing IE7 users with such a performance hit.

        • 28


          April 22, 2011 12:52 pm

          IE7 users live in a slow insecure world. I doubt they even notice.

        • 29

          Guilherme Ventura

          April 25, 2011 4:58 am

          i’ve been using the CSS3 PIE in some projects, and the perfomance really slows a bit in the IE7 , and i had some problems (including a break of the layout itself). one quick tip is set position:relative to the elements what you use the PIE properties.

          • 30

            The button with that slow transition in the hover is a new one on me. That’s a snazzy feature. CSS3Pie seems to be the best answer out there as of now. It takes a bit of adjusting to get working correctly and has its limitations but for now it’s what works. The fact that a small file like can fix a majority of these problems says to me that the people developing IE don’t care about progressive browser design.

          • 31

            I am not a big fan of pie … Only does half of the work and I do agree most of the element that is targeted via PIE need to have the position:relative properties set.

      • 32

        CSS3PIE is great. A guy I work with, @philsherry, had an article in Web Designer Mag recently on some of its features, reposted on the company blog:

    • 33

      Personally, I save that development time and just let IE users see a slightly different version. I know a huge slice of the web design/dev community agrees with me!

      • 34

        Adam Jenkins

        April 21, 2011 6:58 am

        Sorry Greg, I meant to vote your comment up but pushed the wrong button!

        I do the same thing, saves massive development time. IE users won’t see any rounded corners or box shadows or things like that. But the site still looks and works great in their browsers, it just doesn’t get the nice subtle design aspects that webkit/FF4 gets.

      • 35

        Damn straight man, I dropped support for that dino IE6, and am slowing down on IE7 support.

      • 36

        Unfortunately, our clients are rarely members of the web design community. Procedure at the agency where I work dictates that our sites should be near identical in all supported browsers – so it’s only through a bit of extra dev that I can use CSS3 at all.

      • 37

        While I whole heartedly agree, I am yet to meet a customer who’d be happy with that approach!

        • 38

          They change their tune a bit when you tell them that getting all those fancy design elements in IE means extra work for you, therefore you’ll have to bill them extra for it. :)

          • 39

            Or you don’t get them to work and you just let the site look different!

            Saying that having a website that looks different between browsers is a bit outrageous of an idea!

      • 40

        Guilherme Ventura

        April 25, 2011 5:35 am

        Greg, is a nice solution for us, the developers, but sometimes the client require the same layout in all major browsers, INCLUDING IE7/8 (sometimes then ask me to incude IE6 too, but no way for that.), in this cases, i use the CSSPIE as much as i can, because the PIE have your flaws too. but is a very nice solution, and works for me. :)


      • 41

        I definitely have to agree with this but also understand that, in many cases, the clients want the full experience in every browser imaginable.

        If you work with an agency or a firm of some sort (more-so if you work on a fixed contract/salary-based) then you probably don’t have much choice with what you’re told to do but for the people who do have a choice I’ve seen many of them simply charge more for that extra bit of browser compatibility.

        From a consumer standpoint having all that backwards compatibility might sound great, but it adds to development time and costs. It’s not a trivial matter to just make something that looks exactly the same in IE6 or IE7 as it does in the latest version of Firefox or Chrome, and you should be charging more to accommodate that.

        It’s a double-edged sword really, since some may not like that and could easily refuse to work with you based on that, but frankly, that’s the price you pay. I support old browsers, but “support” does not mean “looks the same”.

  17. 42

    Missing -o-linear-gradient() in your code ^_^

    • 43

      Trent Walton

      April 21, 2011 6:02 am

      Aaron, good catch. I’ll update the example site & get an edit in the article soon. Thanks.

      • 44

        While you’re at it, you might as well add -ms-linear-gradient, which has been added to the upcoming IE10. :)

        See the IE10 PP dev guide.

        • 45

          Trent Walton

          April 22, 2011 6:03 am

          Totally! I built this page before we got that lovely piece of news :) For this particular example, I think I’ll opt to leave it as is because it was such a single point in time sort of experiment.

          But -ms-linear-gradient will be finding its way into all my work moving forward! Huzzah!

          • 46

            Elizabeth Kaylene

            April 22, 2011 11:57 am

            For the sake of debate, if each browser has its own specific line of code to create a gradient, but all browsers can read an image with a gradient, wouldn’t it be faster to just make the one image, or at least take the same amount of time?

            I’m not in any way an old timer clinging to the ways of the past, but I do find it amusing that each browser has a different method of displaying CSS3. Sigh. There will always be something in these browsers creating extra work for us!

          • 47

            Elizabeth – As long as the browser-specific code is the same across all browsers (box-shadow and text-shadow are good examples of this), then it’s simply a matter of copying the line and changing the browser prefix (or, an even faster method – let a tool do it for you). Of the more common features (background gradients, drop shadows, border radius), at least that I’ve used, only the gradient one had actually different approaches, and that was only because the W3C was slow in coming up with a standard. Once the W3C published the standard, Apple released a version of Safari that complied (though I actually liked their original implementation, it was quite powerful in some aspects).

            However, I think you’re confusing the purpose of browser prefixes with the old hacks we used to use. Browser prefixes are meant to be a temporary means of implementing new features, with the ultimate goal of phasing out each of them as time goes on. Again, border-radius is a good example to use here. Firefox 3.6 and Safari 4 (the previous versions of both) used their vendor prefixes for border-radius, but in their most recent versions (FF4, Safari 5), they’ve converted to the standard border-radius property ( If you don’t mind Firefox 3.6 and Safari 4 users falling back again, you could drop the webkit and gecko prefixes now, thus removing two lines of code for each border-radius instance.

            Keep in mind, too, that things like rounded corners don’t just take one image if you’re not using fixed-sized boxes, but rather take an element and image for each rounded corner. Plus, the old way requires either a solid background, or one simple enough that the “mask” part of the corner images would blend with the background. Change that background and you have to remake the images. Change the background to something more complex and you’re SOL, especially if your rounded corners move in relation to that complex background. Then, you have the added bonus of rounding images in an element, rounding (non-image) borders, rounding the drop shadows, and a dozen other subtle interactions that were either tedious and time-consuming, or nearly impossible without CSS3 (and that’s just for border-radius).

  18. 48

    One negative thing about using css3 that’ll go away with time – when I update a gradient, or any other css3 property with multiple browser prefixes – it takes me MUCH longer to update the same property multiple times than it would for me to update a single image that renders the same on each of those browsers. Just a little frustration really, because I still love css3 to bits.

    • 49

      John Flickinger

      April 21, 2011 6:09 am

      There are some tools that help with this. Colorzilla put together an excellent generator where you can visually create a gradient and it exports the css with all of the variations for Mozilla, Webkit, IE, and Opera. You can either use the generated css, or modify it however you’d like, but overall it’s a pretty useful tool.

    • 50

      Stefan Goodchild

      April 21, 2011 6:49 am

      You could use something like * to create your CSS to get round this.

      eg. I’ve created a “rounded()” mixin that generates all the required browser specific alternatives for border-radius so in the actual SASS file to get rounded corners on an element you just add +rounded(3px). To edit the radius size (or drop shadow definitions etc) you only need to edit the one line and SASS does the rest.

      * is another option.

      • 51

        Excellent point! I almost included a bit about that in the article.

      • 52

        Chris Schmitz

        April 24, 2011 6:58 am

        I think if you throw Compass and SASS into this equation you can significantly cut down CSS3 dev times. I’d be interested to see the numbers on that as well :)

    • 53

      Ryan McLaughlin

      April 21, 2011 7:08 am

      This can be a little tedious, however, there are some plugins to code editors and websites that make this task much more bearable. is a great example

    • 55

      Start using LESS or Sass with mixins and that problem goes away ;)

    • 56

      The find + Replace panel combined with a few regular expressions and nice kit of keyboard makros are a coders best friends :)

  19. 57

    Michael Sunarlim

    April 21, 2011 5:57 am

    Great article! A little note to the last results table: I think you should not count the percentage as [CSS3-CSS difference] / [CSS3 result], but it should be [CSS3-CSS difference] / [CSS result] no?

  20. 58

    A nice post indeed.

    Personally, one thing stopping me from getting on the CSS3 boat completely is the lack of total support in IE (chiefly 7 and 8). The pure css3 version you created in this article doesn’t render correctly, where as the one with images does. Factor in the time to IE hack the site, and we’re in the middle of a pure CSS3 and image based variant.

  21. 59

    Jeremy Nicoll

    April 21, 2011 6:05 am

    Keep in mind that using 1 pixel width/height images that repeat over and over can have a negative impact on browser rendering performance. Since the biggest hit for downloading something that small is going to the be the HTTP request, you can easily afford to make the image 30 pixels and reduce rendering time in the browser.

  22. 60

    The ‘speed’ benchmark seems to be referring to the standard metrics (Requests / Size) and ignoring the actual page performance.

  23. 61

    Great article, Trent. I love your work. I use CSS3 techniques in many/all client projects.

    @SmashingMag – *Bug* I am viewing your site in a window width of ~715px. The navigation at the very top of the page is partially hidden above the page.

  24. 62

    You don’t need to surround the tag with a to achieve a rounded corner. You can apply a border on the and use rounded-corner CSS style. See below as an example.

    img {border:5px solid red; -moz-border-radius:10px;}

  25. 63

    Niels Matthijs

    April 21, 2011 6:33 am

    This is all nice if your clients accept full degradation for IE9- (which is a pretty large part of your audience). If not, you’ll take longer than the simple css implementation, but you’ll lose on performance and future-proof-ness. It’s a pretty difficult situation to be in.

  26. 64

    Dan Sensecall

    April 21, 2011 6:47 am

    This is a great article – nice idea and interesting findings to match.

  27. 65

    Manuel Strehl

    April 21, 2011 6:50 am

    Very interesting approach. However, I’d also be interested in the time difference of the onload event (that is, performance in the browser). Have you looked at both pages in Firebug to see, when it fires?

    • 66

      I went through the effort and fired up firebug to test this and I got the following:

      css3 onload: 675ms
      css onload: 1.01s

      results may vary.

      • 67

        Manuel Strehl

        April 21, 2011 12:30 pm

        Cool, thanks! I find it interesting, that the time is almost cut in halves, and laying out the CSS3 rules doesn’t have such an impact as downloading the pre-rendered images.

  28. 68

    cancel bubble

    April 21, 2011 6:51 am

    Great article (in theory), however I think it’s a little flawed (and I know it’s just an experiment):

    “The page was designed to showcase specific widely compliant CSS3 properties that in the past would have had to be achieved using background images.”

    The test case is biased from the start, IMO – and the design naturally degrades for non CSS3 browsers. You designed something you already knew how it would degrade as well as designed something that would prove your point.

    It would have been far more effective if it were a real design that had gone through the real design process of some back-and-forth revisions.

    • 69

      Trent Walton

      April 21, 2011 7:06 am

      A web designer should always plan ahead when designing a site— so that it will degrade without breaking. If we’re not doing that already, we should be.

  29. 70

    My colleague noticed that you mentioned you have used HTML / CSS3 for the last year for your clients work .. when looking on your portfolio and looking at the source code we could only see one HTML 5 / CSS3 website ..

    The article it self was great but I was hoping to see some real life examples ….

    • 71

      Trent Walton

      April 21, 2011 7:19 am

      Kam, dig a little deeper :) That simply isn’t so. CSS3 can be found all over our work, whether or not the HTML doctype is HTML or XHTML.

  30. 72

    I liked the article, but can you double check your percentage math on “The Take-away”? 49 minutes is 33% faster than 73 minutes. You could say that 73 minutes is 49% slower than 49 minutes, though. I think the other percentages have similar issues.

  31. 74

    Great article Trent. Totally agree with the points you’ve made and the overarching point that using emergent CSS technologies today is the way to go. However, I have one issue with semantics.

    My issue is some pretty deep nerd-level stuff that I think most people would ignore with a “so what, who cares?” but I think as someone who is leading the charge with these new technologies you should be careful with the language you use. The title of the article, “CSS3 vs. CSS” and referencing “CSS3” and “CSS” as if they are two completely separate entities is, in my opinion, a little damaging to the case. Isn’t the title actually saying something like, “CSS3 vs. All the previous soft versions of CSS”? That’s what the example shows and that’s the reality. The language used makes it seem like CSS3 is some completely new technology here to wipe “CSS” of the map. I know you know that is not the case, and I understand a good number of people also understand, but there are also a lot of not-as-informed people that are fully latching on to the term “CSS3” and using it as a buzzword to hype up every new thing that gets produced on the web. “CSS3 developer” is already becoming a go-to for resume padders and slightly uninformed job posters. Continuing to write great articles on the topic of the advancements of CSS and referring to it using a version number will only make it worse.

    I know we need some way to refer to these new technologies, but I don’t think we need to reference a version number. We’re just writing “CSS” like we always have been. CSS “versions” are a fallacy. The CSS spec is a living thing that changes over time and it’s super unlikely that we’ll ever have a time when all browsers implement all of the same features at the same time. If we’re going to fully embrace these new technologies in practice, we also need to do so in the language we use to describe them.

    So yeah, definitely don’t want to take away from the excellent points made in the article. But can we please stop trying to apply a version number to everything? It’s just “HTML” and “CSS.”

    • 75

      Trent Walton

      April 21, 2011 8:43 am

      Tyler, I agree that CSS3 and CSS are one entity, and notice the same unfortunate thing about CSS3 resume buzz. For this article, I think it was necessary to cite the version as a way to differentiate & compare.

  32. 76

    So the faster you work, the less you get paid, or do you scale your billing?

  33. 77

    Just so you know, in the take away section, two of your statistics are incorrect. Production time should be 32% faster, and number of requests is 45% less.

    (49-73)/73 = ~32
    (12-22)/22 = 45.45 repeating

    Other than that, great post!

  34. 79

    I think i have that page sliced and coded in less than 2 hours.

    So nice test but you work slow

  35. 80

    Great experiment, Trent. I’ve been trying to weigh the benefits of CSS3 compared to images on a few of my websites and you’ve persuaded me toward CSS3 for the parts I can. Thanks for the article.

  36. 81

    Douglas Bonneville

    April 21, 2011 11:41 am

    No point creating hybrid pages. Just code with the bkdg images until IE8 is less than 10%. By the time that happens, the site you are working on will have refreshed entirely once or twice. However, this works great for HTML5-based apps for mobile devices, which don’t need the fallback. So pure CSS3 is great for mobile, bad for desktop. Hybrid CSS3 / CSS is OK for desktop, but CSS for now is best because you get no bonus point for doing work twice.

    • 82

      You know, quite a few people share your thoughts on this topic and it’s detrimental to the progression of the web.

      No matter what, there will always be less-advanced browsers/devices/etc. Only creating web sites and apps targeted to the features of the lowest common denominator does nothing but keep the creation of web sites/apps stagnant.

      Where are these users of IE versions less than 9 that are up in arms about not having rounded corners and gradients? They’re a fallacy. We’ve be through this time and time again. The cross browser differences in styling and feature support are an issue that we (designers, developers, power users) have to deal with. The every day, average Joe internet user doesn’t know about these issues because they are not running multiple browsers like we do. They have “The Internet” which is probably whichever browser was on their machine when they bought it.

      Imagine if we applied a form of your logic; only using technologies that are available on every browser, to other scenarios, say Mobile devices. That would mean that iPhones should definitely not have advanced features like visual voice mail, because, well a lot of people still have Nokia 5150s and they damn sure can’t have visual voice mail.

      You are wrong and positioning yourself to get left behind as we move into more and more advanced times in the web.

      • 83

        Douglas Bonneville

        May 2, 2011 6:28 am

        “Where are these users of IE versions less than 9 that are up in arms about not having rounded corners and gradients?”

        I’ve been building websites for 16 years, 10 of which have been with employers like AOL, Nationwide Insurance, and other larger companies I can’t mention here – all huge companies where views are counted in the millions. The IE users you are concerned about are in the marketing departments of these companies and demand that users have the same experience across all platforms. They are also the corporate customers who aren’t exactly cutting edge in their IT departments. The largest company I have yet worked for *just* moved on to IE8 from IE6 3 months ago. There are many corporations who have not yet moved off of IE6, and will take another year to do so. In this case you have to code for the lowest common denominator, if you expect to be able to get to market on time and maintain your code with a team. That is reality, and not platitudes.

        At the same time, we are developing cutting edge CSS3 mobile content on the best CMS systems in the world.

        I’m not left behind. I’m leading the pack, because what I do makes good sense and I get paid a lot to make sense to corporations who’s revenues are in the billions. I don’t see my situation changing any time soon. In the meantime, we’ll code for FF4 / IE8 with 100% consistent marketing visuals, and keep delivering stable code on time to meet corporate internal and external marketing needs.

  37. 84

    Brian O'Connell

    April 21, 2011 1:02 pm

    IE9 is out with very little support for CSS3 enhancements. The IE10 platform preview is out with really no greater support. I’m really not optimistic that any version of IE will have sufficient CSS3 support within the lifetime of any design I’m creating right now. I hate for new techniques to be dragged down by IE, but I also hate for my designs not to look their best in every browser.

    • 85


      I think that browsers should have to conform to a body (W3 might spec out what is HTML 5/ CSS 3 etc but it is up to the browser developers to support it).

      Wouldn’t it be better if browser developers were legally forced to include a non-removable banner in the top of the browser window stating “this browser does not fully conform to web XHTML and CSS standards”.

      I bet Microsoft would soon bring IE up to scratch…

  38. 86

    Florescu Adrian

    April 21, 2011 1:47 pm

    If Google will make all of his users with IE download Google Chrome (Or any new browser), we will just design and no headache with IE hacks.

  39. 87

    Stupid test. It’s not about draw speed.

  40. 88

    This is a great article – nice idea and interesting findings to match

  41. 89

    Thanks for this – was a bit “reluctant” of getting involved toooo much at the moment with css3 but this sure knocks that idea on the head – right get in and get dirty – damn fine job thankyou

  42. 90

    Ramesh Vishwakarma

    April 21, 2011 9:06 pm

    I think now it’s time to look new technologies and advance features. CSS3 has a good feature that we can make lightweight site without using any image. Personally I hate those people who are still using old IE6 browser in the age of new technology. :)

  43. 91

    Hey there Trent, this is a FANTASTIC and well written article, I’m so happy I stumbled onto this because it brought me to smashing-magazine also! what a cool site… Anyway I love your points and I loved the results at the end, css3 is obviously NOTICEABLY more efficient than the original css. Thanks for doing the test for all of us, you saved many of us programmers a lot of time! :-P


    Chairman & CEO

  44. 92

    Nice tutorial good to know that removing the images and just using CSS3 is the right thing to do.

  45. 93

    Good article. And for all y’all people who are thinking that websites have to look the same in every browser the answer is NO! Just use some good fallbacks for older browser support. Just use the latest technologies and stop complaining that it’s not supported in IE. Clients and there users have to understand that if they are using an older browser they don’t get the latest techniques and sweet stuff. That’s the only way to move forward and bring the web to a higher level. Get Hardboiled!

    Read this book and you will know what i mean with getting Harboiled: Hardboiled Web Design by Andy Clarke >

    • 94

      That’s all well and good in theory, but clients don’t care about any of that, unfortunately. If they see a mockup with rounded corners, and the finished product is squared off, they’re going to question it. If you explain that they need to update their browser, they’ll say “Oh, well XXXX’s website has rounded corners!” and assume you’re not doing your job properly.

      You might be able to get away with blaming their browser if they’re somewhat knowledgeable about computers, but a lot of the clients I work with are not.

      • 95

        I have to agree with Martijn here sorry Sam. The last 5 or so websites I have developed all had rounded corners and shadows on the visuals sent to the client and at the development stage were all implemented with CSS3 and not one of the clients questioned it.

        2 of the 5 sites where for clients who I know for a fact all use IE6 as there default browser and yet they didn’t question it.

      • 96

        Ask clients outright,

        “Would you prefer me to spend my time hacking around issues for older browsers like IE6 or spend it instead on making the website look the best that it can on better desktop browsers, as well as on a whole host of mobile browsers?”

        I’m confident you’ll be surprised by their answer.

        • 97

          Totally agree with you. Clients need to be informed about the issues and rely on us as professionals to give them our expert opinion, but at the end of the day it is up to them to make the call.

          In my experience, clients want the work completed as quickly as possible and don’t want to carry the cost of hacks and tweaks – what’s important to them is getting a return on their website investment, and a rounded corner is probably not going to do much more to improve that.

  46. 98

    Very interesting and usefull post!
    Thanks a lot, Trent!

  47. 99

    This is a cool article though there are a few things which kind of left me puzzled.

    Firstly, the comment below:

    “So, we’re looking at a 24-minute difference: 49 minutes to add visual enhancements with CSS3, and 73 minutes to do it with images. For me, CSS3 was not only quicker but far more enjoyable, because I was focused on only one window (my CSS editor), unless I opted to pull some of the code from CSS3 Please. On the other hand, slicing images and switching from Photoshop to FTP to the CSS editor and back again was a hassle, and it did take longer.”

    I don’t know about anyone else but I always work in a local environment and so in the scenario above, both versions would have started with me slicing all the assets I required for the task in photoshop, then I would put them all in the dev environment and then would code the CSS whilst flicking back and fourth to view in a browser.

    Whilst I agree there are less images in the CSS3 version, there is also a lot more code and I think time wise this would have balanced out.

    Secondly, I used your example pages (CSS3 page and CSS WITHOUT sprites) and ran them on pingdom… I got the original CSS without using sprites loading in 3.3 seconds (tested it three times in three different browsers) and all were the same. The CSS3 version came out at 3.6 sec, 3.7 secs and 7.2 secs (screenshots available if needed).

    Now don’t get me wrong, I too want to move to the latest technologies and also believe it to be detrimental to the future of web design that we all push to adopt the latest practices and keep things moving. However, I think the biggest problem designers/developers we face is the fragmentation of platforms and browser engines.

    We already have to style pages differently for print, screen, mobile platforms and a plethora of browsers so why use something that shows minimal (if any) benefits and isn’t yet supported by all browsers (this would replace the IE6 fix issues with IE7 & IE8 issues)? Unless people enjoy the idea of coding separately for IE?

    • 100

      Trent Walton

      April 22, 2011 5:59 am

      Jordan M, I can appreciate that people have different workflows, and won’t be surprised if some find slicing images to be quicker. I just find all the zooming and cropping to be laborious :)

      Your second point about speed is also valid. I think results will vary greatly from reader to reader for load times, especially because the largest elements on the page aren’t the CSS properties, but the car illustrations & fonts that are loaded with both versions. That’s why I focused more on HTTP requests and file size.

      That being said, here are a couple more URLs for testing with everything but the unique stylesheets stripped out. Maybe check those at pingdom to see what you get.

      Above all else, It’s important to note that this is only one experiment. I’d love to see people create their own, and work however works best for them & their clients.

  48. 101

    worth reading! those comparison charts you have given are very useful.

  49. 102

    Good work but predictable results really. I mean surely a future technology wouldn’t be very useful if it didn’t increase productivity.

  50. 103

    I’m definitely saving this article to show to future clients. While I’ll do fall-backs where time and money allow, I prefer progressive enhancement. It’s not a huge deal if some users don’t see rounded corners, but it is a huge deal if the page can be much faster.

  51. 104

    Great article.

    But have you tried this test with javascript in action ?

    Because for my new website, I tried to use css 3 like box-shadow and border-radius, and with javascript code on the same page, firefox is so slow !
    When I remove box-shadow and border-radius properties of my css, firefox is running the page perfectly.

    Do you have any idea ?

    • 105

      Trent Walton

      April 25, 2011 6:17 am

      I’ve yet to come across an issue like this, but I bet there are an infinite number of possibilities / combinations relating to the specific js and/or css you’re using.

  52. 106

    Hey there Trent,

    I really enjoyed this article, I had no idea css3 was that strong until your “benchmark” article here pointed it out… I mean that load time is not to be ignored in my opinion!

    Also, Sorry to the moderators here at smashingmag for using Keywords and trying to advertise my company with “Keywords” yesterday, didn’t eve see the rules above, I apologize!

    Regards! And great article again Trent, thanks for saving all of us other web designs the time and heartache of doing this test ourselves ;-)

    Jeremiah R.
    Chairman & CEO

  53. 107

    Really like this article. Very good thanks

  54. 108

    so really ineterest CSS3 feature, it’s can make possible now….hohohoho

  55. 109

    Jeremiah Reagan

    April 23, 2011 9:28 pm

    Hey there Trent, I just got done mentioning this EXACT article and post to a couple friends and employees of mine. This is EXTREMELY resourceful. I’m so happy that you saved all of us “web developers” the heart-ache and time of doing something like this ourselves.. Thanks again! Your results were great too, I could not believe the load time difference in your 2nd or 3rd graphic Trent, between CSS3 and CSS, WOW, eye-opening to say the least. Sorry about last time too, I posted a comment saying “great job trent” but I think I violated the rules by putting up keywords and phrases pointing to my domain, stupid me, I didn’t see the rules above the darn comment. Sorry Administrators! :-(

    Anyway great job again and thanks for these “benchmarks” – they come in handy bud!
    Jeremiah R.

  56. 110

    Awesome recommendation on CSS3 pie

    Thanks for the heads up!

  57. 111

    Great article!

    Personally i think that as long as we, Designers/Developers, try to make i.e behave like a modern browser with all resources available now, css3, in I.E world, will be just a hacked css.

    The most important thing is to take full advantage of modern Technologies/Browsers and move forward. If before css3 you would use a sliced image for border, why would you do that now, if you can totally do it with css3? And believe me once I.E users see that on chrome they will sure ask why in their I.E browser looks different!

    CSS3 wins always!


  58. 112

    I have used the following code for IE gradients in my new project and it has worked fine for me –

    FILTER: progid:DXImageTransform.Microsoft.gradient

  59. 113

    Great article there :)

  60. 114

    Peter Cranstone

    April 25, 2011 7:34 am

    Hi Trent,

    Just ran a couple of tests for you using our Mobile Performance solution (Android). The performance difference is “quite dramatic”… a 41% performance improvement.

    Regular CSS – 877.6kb – 30.32 seconds
    CSS3 – 796.6kb – 17.89 second

    links to regular css waterfall performance chart:

    link to CSS3 waterfall performance chart:


    5o9 Inc.

  61. 116

    Jeremiah Selengia

    April 25, 2011 8:13 am

    Excellent article CSS3 is definitely going to be utilised in every project, I just wish I.E will give it the support.

  62. 117

    Fantastic stuff, I’ve been holding back on writing css3 for client projects, but this article has showed me that it’s time to start doing so.

  63. 118

    Big problem with this example is that it does not work in any version of IE. I know all the CSS freaks out there hate IE, but since roughly 70 – 75% of web users surf with it, coding something that does not look right in IE or have the intended impact can and will get you in trouble with paying clients. The old school css technique works in all browswers I tested. For this example to truly be a fair benchmark test you would need to include the time it would take to have this work in IE as well.

  64. 119

    Gilberto J Perera

    April 25, 2011 11:59 am

    Had no idea the Pingdom page speed tool existed. What do you recommend to use as a benchmark? Google Page Speed, Pingdom, or other page speed tools? Thanks.

  65. 121

    Using PROPER tools like pngquant, you could have reduced the image size of all PNG files by at least 60%! Test run with the main image redcar.png:

    $ identify redcar.png
    redcar.png PNG 1000x312 1000x312+0+0 DirectClass 8-bit 456.039kb
    $ pngquant 128 redcar.png
    $ identify redcar-fs.8.png
    redcar-fs8.png PNG 1000x312 1000x312+0+0 DirectClass 8-bit 117.688kb

    cu, w0lf.

  66. 122

    MarketAgent 007

    April 25, 2011 7:18 pm

    Thanks for taking the time to experiment! This is a very informative article. I Photoshop the hec out of my buttons with drop shadows, inner glows, inner shadows, gradient strokes, gradient overlays and adjustment layers. So for now, I have to stick with old-school CSS sprites because it will take longer for me type all of the CSS than it would to slice a sprite. On the contrary, a pure CSS (no image) button will always look crisp and sharp no matter how near/far the browser zooms in. Guess it’s time for me to take some typing lessons!

  67. 123

    A nice comparison article, but like most others, one thing it didn’t cover is the rendering performance. Obviously it’s much more difficult to test, but it’s equally as important as load time, especially on mobile devices. I’ve always found CSS gradients to be somewhat slow to render in the past, so I’d be really interested in the differences with images there.

    Also, 1px-wide image slices? Using them for things like page background can cause rendering issues as the blitting in most browsers isn’t hugely efficient. The PNG format on the other hand, is, so a 50px-wide version will be negligibly larger in filesize (especially after running it through something like ImageOptim) and quicker to render.

  68. 124

    Nice to see it all worked through like that; I had my suspicions but had not taken the time to measure like you have. Well done.

    However, taking up some comments from other above, bringing IE into the picture can quickly reverse any production time savings, because only the simplest cases work well with nice tools like CSS3PIE without requiring gymnastics of some form. I recently hit a case where IE near drove us around the bend, so of course I blogged about it :)

    Of course, I could have taken the line that IE6 just isn’t worth the bother, but some clients don’t understand that. This is especially so for business websites whose clientele include people working in the finance industry, many of whom are stuck with IE6 on the desktop at work — but who are high-value customers that will buy, say, a case of wine or an expensive gift over the Internet when at work. Those customers are worth treating properly, not chastising with an orange gradient bar telling them to upgrade their browser (which they can’t!)

    I look forward to the shiny new CSS3 future and all of our recent websites make good use of CSS3, but I doubt it saves us much time once we factor in IE workarounds. Until IE6 fades into the distance, or CSS3PIE manages to overcome some of its current limitations, I can’t see that changing.

    • 125

      Nothing, absolutely nothing can justify the fact that they are using an eleven year old browser. If any, their hatred should be towards their IT managers, not web designers.

      • 126

        Douglas Bonneville

        May 2, 2011 7:05 am

        Not true. Massive companies have huge slow moving infrastructures. Getting a new browser is like trying to turn a cruise ship around in a mall parking lot.

        For instance, updating a browser has implications that involve the Securities and Exchange Commission and legal requirements revolving around auditing. It’s 1000% more complex than most people realize. IE6 and 8 will have to be catered to for years to come.

        • 127

          Douglas Bonneville

          May 2, 2011 7:06 am

          Woops, I meant to add that my example applies to companies that deal in finances and investing or insurance.

    • 128

      Douglas Bonneville

      May 2, 2011 7:02 am

      @ Ross: Agreed 100%.

  69. 129

    Good article. But when I think about IE & customers, I am really worried. If someone could stop the progress of IE development, it would be a better deal

  70. 130

    Love the article man, you guys continue to amaze!

  71. 131

    Hey Trent,
    how important is increasing the page load speed when we are all running on high speed internet?

    Come on, let’s be realistic. I think is much more important the time you spend on a project than the page load speed, or at least this is what is happen in real world where money are coming from our clients :)


    • 132

      load times are very important as is using CSS3 instead of images. The importance is because of… mobiles and tablets.

      I’ve been reviewing mobile/tablet visitors for the last couple of years and all the sites I review have one thing in common; increasing hits and increasing sales.

      Our newest problem is we don’t know if the user has a 2,500 resolution (iMac) or a 320px resolution (iPhone as an example). With images you are constantly running the risk of the design breaking. With CSS3 instead of images you negate a whole pile of issues.

      I’m surprised that few have commented on this. I strongly believe we are heading into a greater “portable” era and the age-old issue of speed and size is just as important now as it was when I was surfing on a 2,400 modem.

    • 133

      I think page speed is very important. More about why I feel this way:

  72. 134

    Great article and a nice subtle design.

    You might watch out for using too much text-transform: uppercase; All uppercase text is harder to read. It can be good to draw attention to short, important pieces of information but too much makes the site harder to use. In my opinion this mock design has far to much uppercase text. Just imagine if every website had that much uppercase text!

  73. 135

    Pedro Duarte

    April 29, 2011 6:44 am

    While i do think CSS3 is a great improvement, when developing web apps for the mainstream user, we need to think twice about what to use.

    From experience, most of the users, don’t know or don’t care about upgrading browsers ( i’m not talking about tech savvy or enthusiasts ).

    What i see around web app development nowadays, are designers, front-end developers creating GUI’s that are 95% based on Apple styling and for Apple gadgets…

    When developing an app that will not be targeted to any user in particular we need to go through what to use in order to minimize the browser problems.

    So yes, i do love CSS3 but i’m not using it intensively on the projects that our company is working on because we know that to create a user experience that can be as similar as possible when using different browsers, will be a pain and unfortunately the end user will not see it as a “plus”. The user wants a app that works, period… with or without box-shadow… with or without border-radius or gradient.

    So, we keep going the CSS 2.1 way and trying to minimize the usage of images and when needed, just try to make the loading quicker or at least, create sprites so it only has to load it once.

    My 2 cents :)

    • 136

      Why not make CSS3-capable browsers even faster, then? You can cut down on http-requests for CSS3-capable browsers by providing CSS3 versions of your image-based stuff. When you do that, the browsers will ignore the image and just render the CSS3.

      The point here is that while CSS2.1 + images works, CSS3 can (and, arguably, does) work *better*.

      I do agree with the Apple-esque fad of styling, but if you’re already doing something that could be done in CSS3, that could improve performance for the browsers that can use it, why not?

      • 137

        Because it costs more development time and the boss (for in house folks) or client won’t go for it.
        I would pose the inverse question to you:
        Since the “old” way works in all browsers and there’s little to any noticeable improvement, why pay extra to make an css2 version, css3 version, create and integrate a sniffer with your existing framework that determines which version to serve?

  74. 138

    I am using this last 1 year and me and my clients are happy to use it. they like it.
    I just want to kill IE6. i am agree that css3 is quicker.

  75. 139

    Pedro Duarte

    May 2, 2011 5:30 am

    I still think that CSS3 is a great “tool” vs 2.1 …
    But i still think that, if you are just developing for a niche of users, that like to see clean and crystal “crisp” design it’s ok to use CSS3 …

    If you are, imagine, developing a web app for you municipality … where all citizens will interact with it on a daily basis, and a great percentage of those citizens aren’t tech savvy, nor interested in being tech savvy, they just use the computer to surf and pay bills for example … there’s a high probability that those users won’t upgrade their browsers that often.

    Of course, again, if you are developing a web app or a website, whatever, to be viewed by niche users ( example, smashing magazine! ) … well, that’s a different story :)

    My 2 cents … i don’t really mean i’m right, it’s just part of my opinion … but yes, we should implement CSS3 in all the projects we can … but not ALL projects can be developed with CSS3… it’s a matter of knowing your market target, user profiling/personas … i mean… lot’s involved :)

  76. 140

    CSS3 its good to use, but css3 not working all browser like

    1. Chrome: working perfect rounded corner and shadow.
    2. Mozila: working perfect rounded corner and shadow.
    3. Safari: only working rounded corner, not working shadow.
    4. IE8: no shadow no shadow.

    Then what is use full?

  77. 141


    May 4, 2011 8:26 am

    As fwolf mentioned, with image optimization you can reduce the images sizes.
    I’ve deleted the unused pictures from the downloaded package (salesman copy.png and mauto.jpg).

    The total size of original images was 820,1 KB. With only png optimization the size is 774KB (94.38%), but if you use the proper image formats (for example 8 bit transparent PNG) and optimization, the total image size is only 205 KB (24,99%) !

    Only one image suffered minor, but acceptable quality degradation (redcar.png).
    Image sizes in a table:
    The optimized images:

  78. 142

    Piotrek Okoński

    May 6, 2011 4:51 am

    Why do we even have to convince people to use CSS3?
    We should should stop supporting old crippled browser to speed up the transition.

  79. 143

    Have you checked “” in IE as IE does not rendering the rounded corner and in most of the cases client need site compatible to all browsers specially in IE…


  80. 144

    I think all the main problem lies in the fact that the user is aware of his handicap just by using IE as a tool for surfing. If each user know that a car he drives has its shortcomings and handicaps compared to other cars would not be complaining at the very comfort at least until they are aware of this fact.

    So, my bigger concern is how to explain to customers that issue than to spend extra time and money that they can meet and satisfy.

  81. 145

    This is the best code architecture ever. And this is very easy and comfortable coding. But everyone must know the basic of it. It has more complexity to all browser. Need to get fix it. Nice post.

  82. 146

    CSS3 is obviously better. I just look around some developers. And all are agreed with me that leaving CSS they are now using css3 for better prospect. Thanks for the post.

  83. 147

    css3 is not friendly with IE………………….
    whereas the major population use IE
    so it is a drawbeck of IE

    but thanx for dis article

  84. 148

    Really intresting, but too bad untill IE will support it its useless..
    Unfortunatly i have some clients that use ie7-8 and its kind of a problem, but the future seems really great :)

  85. 149

    Scott R. Godin

    February 27, 2012 9:16 am

    Just a note: you seem to have several missing images in this article and may wish to inspect your media archive to see where they went.

    Otherwise, quite interesting. We’ve been using more and more CSS3 in our designs, replacing the older image-slicing way of doing things, with fallbacks to solid/square for unsupporting browsers, and I cannot tell you how much more enjoyable the whole process is.

  86. 150

    You forgot something that many developer and designers forget to factor in when considering page load times. The processing ability of the computer itself. Tools like pingdom and etc aren’t actually running the instructions included in javascript, css, etc files. they are just looking at the size of the file and (hopefully) scanning for links to new files. Actually implementing these instruction can slow a website down considerably and MUST be considered. I’ve seen css3 and JS animation that crashes older computers but looks fine on on the developers machine.

    Best practice (IMO) is to load the website or webpage in question on a slow older laptop with little processing power, like a great deal of your potential customer will be using, and then see how long it takes and if it causes performance problems. Remember, Mr. Joe OldPerson probably has other things running, more than one window open and there’s a good chance he has malware on his computer sucking up resources. If the web browser crashes on your website. He’s not going to contact you and complain. He just going to curse you under his breath and restart his ancient copy of IE and go somewhere else.
    You can say “it’s not my fault” till your blue in the face but that’s not going to make millions of Mr. OldPerson’s come back to your website.

  87. 151

    Did someone just say they are abandoning css for css3 with no thought for the people still using IE which doesn’t support CSS3? More power to them and more visits for my clients websites! You go dudes!

  88. 152

    I’m surprised you referenced that 2010 interview with Adam de Boor. Almost 2 years later, and Gmail still can’t even render to CSS1 standards :-/

  89. 153

    Wesley Hales

    May 22, 2012 7:04 am

    Good stuff, but I would only agree with this for desktop environments.
    Looking at the render/paint/load time for your CSS+images it’s 900ms and CSS3 only is 2.28 seconds. What does this tell you? computational burden is greater when it’s left to the device/browser to render this stuff – which in the end means battery drain. Take it from netflix (… a presentation which explains their philosophy “don’t do in software what can be handled by hardware” iow, Hardware can just paint images. CSS requires software to calculate, render and paint.

  90. 154

    Everyone here seems to be like “hurray CSS3”, I’m surprised.

    CSS3 makes rendering slow. I do prefer CSS3 when I don’t need it in a lot of places and the effects are simple, but using it for complex gradient backgrounds and shapes is nuts!

    I recommend always using images when possible, atleast with backgrounds. There’s background-size rule if you need adaptive design.

    The number of requests argument is bad. You should base64 encode images – no extra requests at all. While the initial load will be slower, it doesn’t matter much as the user won’t be redownloading everything with every new request (unless the webserver is badly configured). All in all, what I mean is that you need to be very careful and not overuse CSS3 features. Unless the design is minimalistic, the users will have a laggy experience.


↑ Back to top