Disagreement with co-web developer about speed difference of height and width specified in image tags as opposed to in the css

May 7, 2008 3:36 PM

I am having a disagreement with a co-web developer I'm working with. He's insisting that having image width and height specified for images in the image tags is going to make an enormous difference in how fast this database driven site will render, while I feel that having the height and width called in the css for these images is enough. The site is very fast.

Let me clarify... I'm only talking about the thumbnails of images on the site (the data), all other images used for design etc. have image heights and widths specified. I feel that even if we lose a nano-second in speed (we have dedicated servers and enough bandwidth to land us on the moon) we gain so much in ease of updating the site. The client changes their mind all the time and if we need to change the thumbnail size, I can do it in 2 second in the global css file, as opposed to much longer to track down all the instances of img tags in the code. I also feel we'll gain a nanosecond from slightly less code bloat.

I see a lot of older articles on the web that mention adding image height and width tags as a help to optimize one's site, but if we're doing EVERYTHING else in the name of speed, is this issue really relevant today with users having faster and faster internet connections?

We can't seem to come to any agreement on this... anybody have any enlightened and educated opinions about this, circa 2008?

posted by semidivine to Computers & Internet (19 answers total)

Have you tried some simple benchmarking?

Whip up a page with, say, 100 images. then clear your cache and load the page. Try it both ways and see which renders more quickly.
posted by chrisamiller at 3:56 PM on May 7, 2008

Can you not have one function to generate the HTML for a thumbnail image, then just call it from wherever you need it? In a database-driven site with all thumbnails the same size, it shouldn't be any more effort to change image size in generated HTML as in CSS.

Also, latency is as much of an issue as speed. On an image gallery with, say, 20 content images per page, that's 20 separate hits on the server that stack up - in addition to a hit for each stylesheet and chrome image.

I'm having a hard time envisioning your page as it loads... do you have an example you could show? Does the CSS reserve the right amount of space for the thumbnail in the page flow, regardless of whether the image has loaded yet? If yes, then go with whatever benchmarks best. If no, I'd go with the HTML version regardless. It's annoying when the page reflows constantly.
posted by expialidocious at 4:02 PM on May 7, 2008

Just to make it clear: you're resizing the thumbnail images via CSS? Having the height and width in CSS vs, as inline attributes is certainly faster, especially if you are using a single class for the thumbnail images - but I'm more concerned that you're re-sizing the images at all. If the client wants the thumbnail images smaller, batch-processing the originals to create new thumbnail images and then changing the CSS to match the new size makes a lot more sense - otherwise you're downloading the same amount of data irrespective of the final "size" of the images, a big no-no.
posted by Bora Horza Gobuchul at 4:09 PM on May 7, 2008

I'd agree with chrisamiller in testing it out. I can't see anything by marginal differences.

However, being as your site is database driven, I don't see how you will need to update multiple instances of img tags, only the single tag (in code) serving your images.
posted by wongcorgi at 4:14 PM on May 7, 2008

Response by poster: It's many functions and many templates generating different instances of the same size thumbnail for different reasons. So no it's not just an image gallery with one database call... I'd tell you more but I'm under an NDA and I'd have to kill you. :) And yes the css reserves the right amount of space, height, width and location in the flow. And here's the kicker, the site loads super quick, despite all the database calls (most of which have nothing to do with the thumbnails) so I'm not sure why he's making such a fuss about this.

I could do benchmark tests, but there's no whipping up a page on this site... the structure is so complex I would actually have to do all the changes on all the templates (adding image heights and widths), test it, then go back to the original and test again. A royal pain.

I guess what I want to know is, is css height and width declarations just as good as or virtually as good as putting height and width declarations in the image tag itself. Anybody have experience they've already tested?
posted by semidivine at 4:17 PM on May 7, 2008

One of the main rules for any kind of development is to write it first as cleanly as possible and then (if things are too slow) to optimize. So you're right & your coworker is wrong.

There's probably tens of webpages out there which say this, but the first one I found with the argument laid out on optimization AFTER development & benchmarking was Thoughts on Code Optimization.

In terms of what you should do, I'd suggest...
Size the image in CSS first. Then make sure that your thumbnails are the correct size. And then start adding duplicate code to your HTML.
posted by seanyboy at 4:19 PM on May 7, 2008 [1 favorite]

It used to be the case that adding width= and height= attributes to your images would speed up the rendering of your page, because the browser would know the size of the images and would create placeholders, rather than reflowing the page every time an image loads. However, CSS width and height create the same placeholders and result in the exact same benefits, at least in Firefox and Safari. I tested this with a Web server that delays images by 5 seconds to simulate long load times.

Here's the Python code I used to test this, in case you want to do your own testing (or prove it to your skeptical colleague.)
posted by pocams at 4:20 PM on May 7, 2008 [2 favorites]

I'd suggest just doing it so it works reasonably well until you've got a version that's close to final, then going back in (and you have to *promise* your other developer, who just wants things done right -- a good trait in a web developer) and putting in the width and height tags in the HTML.

I'd also try to look for a way to have these be automatically generated by your code so you don't have to manually enter them, but if it won't work, it won't work, and that's you guys' call.
posted by amtho at 4:33 PM on May 7, 2008

If the HTML code produced in all the different templates/functions/instances is already identical, or can be made identical, then I'd create one function for thumbnail generation and call it from all those templates/functions/instances. No sense reinventing the wheel. You could even parameterize it if you needed different attributes.

And I'm with Bora Horza Gobuchul on batch processing for thumbnails. Not only for speed, but because browser-resized images look like shit. Much worse than even an automated resizing process would be.

It's true that the download speeds available to end-users have increased quite a bit since dialup days, but that's stretched the speed curve out without increasing the average speed as much as you'd think.
posted by expialidocious at 4:34 PM on May 7, 2008

Response by poster: "If the HTML code produced in all the different templates/functions/instances is already identical.."

The html code is not identical. Just the image size is often the same. The class is different every time depending on its location and which template it's in.

Guys, I'm not asking you to help me reorganize the structure of the site. It is the way it is. The reason we are changing the size of the thumbnails (there are thousands) is that the data is ported from another older version of the site and there is no time to change them all and reupload, we have a superfast delivery time on this and we have to pick our battles. The resizing is minimal (but essential, the older size is just oversized enough to break the current design) and the thumbs look fantastic. Believe me, I wouldn't resize it this way if it looked like crap.

Thanks pocams... that's what I wanted confirmed, that css height and width attributes have the same effect on browser rendering as adding the attributes to the image tag.

Anyway, thanks to all of you for your responses.
posted by semidivine at 4:51 PM on May 7, 2008

Thirding the "code-resizing is the real WTF" opinion.

And I know you've replied to that:

>The resizing is minimal [...] and the thumbs look fantastic.

But which browsers have you tested in?

You might get a nasty surprise if you're looking at them in Mac Firefox, but not Windows Firefox. And Firefox beta 3 for Mac seems to be using the same bicubic resampling as Firefox 2 for Windows, which is hideous.

You say there are thousands of thumbnails and you don't have time.

I recently resized 50,000 quite large images with perl/ImageMagick and it took a few hours, but you know what? I was asleep at the time so I didn't mind.
posted by AmbroseChapel at 5:34 PM on May 7, 2008

For future ref, firebug (the absolutely amazing firefox plugin) has a tab called 'net' that shows you exactly how long each page element took to load. It's quite enlightening.

One benchmarking tip: With applications, if you want to try out an approach, it's often easiest to simply save a representative dynamic page as flat HTML. Then create a new version (say with height and width attributes on the img tags) and you can now compare them.

But in this case, I fail to see how the pages are going to load faster with img height and width tags. Sure the browser may do some resizing - which is annoying and may use some CPU, but i how would the files load faster? If anything the page will be slower since you now have approx. 22 extra bytes for each img tag. so if you have 200 thumbnails, that's 400 extra bytes.

So, yeah, you're sort of having a "How many angels can dance on the head of a pin?" conversation with your colleague. The answer doesn't really matter.

btw, Google "yfast". That'll get you some great optimization tips.
posted by kamelhoecker at 5:41 PM on May 7, 2008 [1 favorite]

As most everyone else here has mentioned, you should really batch generate those thumbnails. That'll make much more of a performance difference than whether or not you have image tag attributes.
posted by me & my monkey at 5:59 PM on May 7, 2008

Here's an example I noticed recently of browser differences in resampling.

Check out this Baltimore Sun editorial on the ending of The Wire (possible spoilers).

There are two thumbnails, resized in the code, just below the fold. I noticed them particularly because they looked pretty rough.

This image shows the difference between Firefox 2 for windows and Firefox 2 for mac. Any diagonal line looks like hell on the PC and contrasts are all wrong.
posted by AmbroseChapel at 6:25 PM on May 7, 2008

kamelhoecker: as expialidocious and pocams say, the (traditional) reason that explicitly specifying width and height causes the page to display faster is that the browser doesn't have to wait until the image header has arrived before laying out the page (or it doesn't have to re-lay the page from a default size to the actual size, depending on the browser). The image is a separate resource, so the latency to get it can be quite high. The CSS is also a separate resource, but it's only one separate resource for all the images (and is probably one of the first that the browser will grab).

(I haven't gone and tested a zillion browsers to see if specifying image size in CSS is as good as specifying it in the source HTML, but I'd expect that it is.)

When testing: testing the site as static files won't be representative unless those files are being served across a high-latency link, like your customers might be using. Bluetooth-tethered GPRS might be a good high-latency test case...
posted by hattifattener at 7:13 PM on May 7, 2008

One more note (that I hope is actually relevant to your question) - there are probably other reasons to include the image dimensions in the actual HTML besides loading speed - compatibility, usability, good practice in general. I do think you should put those dimensions in there eventually.

... even if there are perfectly good reasons (which which I can sympathize) to keep the HTML as you have it and not to make some kind of thumbnail-code-generating function.
posted by amtho at 7:13 PM on May 7, 2008

In addition to firebug in firefox, there's a corresponding Fiddler plugin for IE7 (from microsoft) that helps you time windows performance- really handy for tracking exactly what files are coming in, and how long they take.
posted by jenkinsEar at 9:03 PM on May 7, 2008

Nthing that setting the attributes in CSS vs. html is likely trivial in terms of speed (probably not even worth profiling) and that you should have a goal of doing both eventually and that you should really physically resize the thumbnails (and, perhaps, that I'd be interested if someone has a definitive answer to the speed question).

Adding that, for future projects at least, I think either or your co-developer need to put in charge enough that one of you can say 'this is how we're gonna do it' and the other says 'ok' (after sharing his/her opinion of course). On a tight schedule, this seems like a silly issue to have a disagreement about.
posted by danOstuporStar at 7:38 AM on May 8, 2008

Sorry I'm late to the party. I think you already have enough (valid) ammunition, but here's another factor to consider: browsers are generally very good about caching css. So if you set the value there, it will be downloaded when the visitor hits the first page and will thereafter be used from cache. If the values are set in html, every page will contain those markups and cannot be cached by the browser. Thus you will actually be sending more data over the wire (assuming visitors hit more than one page containing thumbnails) by embedding the values in html.
posted by JJtheJetPlane at 2:49 PM on May 8, 2008