Browsers are pretty quick at scaling images

I used to be a real nitpicker when it came to preparing images for the web. I’d laugh at people using large images in web pages, showing them in a smaller format by setting the width and height properties.

In the days before broadband was everywhere it was bad karma to do this, because a large image file would take a long time to download. You needed to prepare the image at the size you were going to be displaying it. Nowadays, things are a little different.

A client asked me recently to propose a new layout for a page that had a fixed grid. Unfortunately, their CMS could was limited to a couple of image sizes that were a complete mismatch with said grid. So I used CSS scaling to get them to fit. Unfortunately, the client wasn’t convinced this was a feasible technique to use. That’s why I did a few quick tests to see if using scaled images in a web page would slow down rendering.

A quick test

I created a page with 150 random images on it. Fifty of them were 24bit PNGs, another fiftly were JPEG and the rest were 8 bit GIFs. Next, I created a copy of that page and set the CSS size properties for the images to a lower number, scaling all images to 61.5%. I then used Google’s Speed Tracer extension for Chrome and Yahoo’s YSlow for Firefox to see if there would be any difference in page load and render times.

No difference whatsoever

The results were pretty clear. Even with 150 images on the page, there was absolutely no difference in page rendering times in Chrome. Both pages finished rendering in around 4:10 seconds. In Firefox, the results were much more erratic, but both pages averaged at around 6.5 second. In both cases I didn’t worry about caching, since I was interested in differences in rendering speed, not download speed.

So there you have it. It may still not be 100% good karma, but to overcome design obstacles, using client side scaling isn’t as bad as it used to be. If you need a few images to fit that you can’t prepare or resize on the server, you won’t have to worry about it slowing down your page. However, actually scaling an image usually makes the file smaller, so if you can you still should.

14 Comments

  1. I want to know why you took my tag cloud is you put your link as you leave I’ll report you to the police post, trying to restore everything as before

    Comment by turi — March 30, 2010 @ 3:40 pm

  2. Turi, I’m not sure what you are talking about, but I did absolutely nothing to your website.

    Comment by Roy — March 30, 2010 @ 6:09 pm

  3. now my comments will not go through! My god!

    Comment by Noah — April 3, 2010 @ 10:35 pm

  4. I am having the same problem as turi because my tag cloud is now your link see for yourself here at gourmetsnow.blogspot.com

    Comment by Noah — April 3, 2010 @ 10:37 pm

  5. Please respond and help me!

    Comment by Noah — April 3, 2010 @ 10:37 pm

  6. That’s pretty interesting and I had never really considered how long it would take the browser to resize the image. It is interesting and good to know, I’ve done it occasionally, but more to prevent users from breaking the layout or worrying about uploading exactly the correct sized image. Thanks for the info.

    Comment by Patrick — April 11, 2010 @ 1:15 am

  7. @turi & Noah, a solution to your problems (without going to the police): http://dotnetgeekstudynotes.blogspot.com/2010/04/adding-flash-animated-tag-cloud-label.html

    Comment by jerone — April 11, 2010 @ 2:57 pm

  8. Interesting article. I’m only struggling with two missed test here: IE and cache.
    IE has always been the biggest headache for developers and with the newest modern browsers, also the slowest. Besides IE does the rendering different then other browsers and differ on the width and height calculations.
    Second cache, if both the image and the CSS is cached there mite not be any calculations done, because the end result is known (cached). If started with an empty cache every size needs to be calculated and mite give different results.
    Please correct me if I’m wrong. Maybe I make my own test case.

    Comment by jerone — April 11, 2010 @ 3:06 pm

    • Jerone, I would have tested with IE if it had a reliable way of measuring page render times. The point to using cached images is that it’s a given that larger images are usually bigger files. How much bigger would depend entirely on your project and on whether or not files would already be cached. To rule out load times, I used cached images. This then led me to conclude that the difference in rendering speed alone is negligible. I wouldn’t recommend using scaled images where you have the ability to provide correctly prepared ones. If you must however, rendering speed is not going to be an issue (at least not in FF and Chrome).

      Comment by Roy — April 13, 2010 @ 1:23 pm

  9. I realize your tests were intended to tevaluae performance ror a CMS which we can assume will be accessed by a desktop or laptop, but is scaling large images a sound strategy for mobile devices and netbooks? Wouldn’t low banswidth, low memory devices suffer from this extra load? Or am I simply old-fashioned for still using thumbnail previews?

    I always assumed the lessons in bandwidth frugality we learned in the 90s were good preparation for optimizing web content for today’s smartphones.

    That being said, I’m posting this comment from my Nintendo DSi-XL Opera browser and your site loaded VERY fast!

    Comment by brian — April 15, 2010 @ 6:31 am

    • Hi Brian, the keyboard on the DSi must be terrible.. ? Mobile devices still have only a fraction of the computing power of real PCs, so I’d not recommend using browser scaling in a special mobile edition of your site. The browser on my iPod and my Android phone show the regular version of most websites, and do scale the images. This is still pretty quick, but downloading high res images to a handset with a tiny screen just makes no sense. Then again, 800*480px screens are getting quite common on high-end smartphones…

      Comment by Roy — April 17, 2010 @ 2:55 pm

  10. Nice post. I agree with you totally. I try to use smaller images though… I don’t really like using width and etc… but I do sometimes.

    Comment by Tonye @ True Vine Productions — April 16, 2010 @ 4:27 pm

  11. I remember when scaled images yielded a performance penalty back in the 1990s when web browsing was new and fancy graphics cards were only for rich kids. Now, with video display technology (mostly driven by high-end gaming I suspect) that place high-performance processors right on the video card to handle OpenGL and the likes directly, I don’t see much this changing much.

    I suggest you try re-running your test with the standard VGA driver that comes with Windows, and see if the performance does change — that would be interesting because it would rule out the possibility of the additional processing being handled by your video card’s processor (assuming your video card driver is smart enough to off-load this, and the web browsers are taking advantage of it).

    Another factor to consider is that the processing power of many systems these days, including hand-held devices, are often better than most PCs from the 1990s. Even the new phones that can all run Java (in order to support Google’s Android) can run circles around an Intel Pentium I (80586; which could barely run Java applets under Netscape 4 on Windows 3.x back in the day — I don’t miss the ancient Trumpet Winsock and friends).

    I have noticed that most PCs these days handle web pages much better than machines in the 1990s. My favourite web browser is Opera, but I do use the others for testing purposes to make sure my web sites all function correctly in all web browsers. And yes, I completely agree that Internet Explorer is the biggest pain in the neck because whenever I wish to do something fancy, I always have to code something different just for it (I look forward to the day that I no longer have to support users who insist on using Internet Explorer, or when Internet Explorer actually supports the standards correctly, so that I don’t have to do extra troubleshooting and coding just for it).

    Thanks for the research you’ve done on this subject.

    Comment by Randolf Richardson — June 6, 2010 @ 12:10 am

  12. That’s good to know, with time constraints I find myself sometimes resizing images with CSS or HTML instead of taking them into PS like I should.

    I know back when I started it was a very taboo thing to do, but I have been wondering with the larger bandwidths available if is as much as a bad thing as before. It’s nice to see some real numbers to back that up. Maybe someday soon connections will become so fast that we won’t have to worry at all…

    Comment by Foxumon — August 23, 2010 @ 6:14 pm