Menu Search
Jump to the content X

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. 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 Pingdom1 to measure the loading times.

Here’s a fictitious Web page for Mercury Automobiles2 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 index3

This gave me a blank canvas to add visual enhancements. The index page4 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 page5. It took 49 minutes to complete. Here is the CSS code (css3.css6):

/*-----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 approach7. Here’s the code (css.css8):

/*-----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 Please9. 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 Tools10 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 version11 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)12. 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)13, 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 website14, 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 fallback15. 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 Today16,” 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 Design17,” 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 HTML518,” 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 Dots19,” 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 file20
    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

↑ 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

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

  8. 8

    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.

  9. 9

    Nice article.

  10. 10

    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.

  11. 11

    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.

  12. 12

    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!

  13. 13

    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…

  14. 14

    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.

    • 15

      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.

      • 16

        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.

      • 17

        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.

        • 18

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

        • 19

          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.

          • 20

            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.

          • 21

            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.

      • 22

        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:

    • 23

      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!

      • 24

        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.

      • 25

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

      • 26

        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.

      • 27

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

        • 28

          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. :)

          • 29

            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!

      • 30

        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. :)


      • 31

        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”.

    • 32

      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.

      • 33

        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.

      • 34

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

        • 35

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

        • 36

          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.

          • 37

            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.

      • 38

        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 :)

        • 39

          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.

  15. 40

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

    • 41

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

      • 42

        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.

        • 43

          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!

          • 44

            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!

          • 45

            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).

  16. 46

    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.

    • 47

      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.

    • 48

      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.

      • 49

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

      • 50

        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 :)

    • 51

      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

    • 53

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

    • 54

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

  17. 55

    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?

  18. 56

    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.

  19. 57

    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.

  20. 58

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

  21. 59

    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.

  22. 60

    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;}

  23. 61

    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.

  24. 62

    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.

  25. 63

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

  26. 64

    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?

    • 65

      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.

      • 66

        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.

  27. 67

    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.

    • 68

      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.

  28. 69

    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 ….

    • 70

      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.

  29. 71

    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.

  30. 73

    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.”

    • 74

      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.


↑ Back to top