Chris Burbridge : Web + Brand Strategy That Matters

TimThumb vs. add_image_size() for Responsive Images

Personal notes here.

Using jQuery Picture for dynamically selecting which size of an image to load in which case. It’s awesome. You wrap your image an an HTML5

element, and give it data-* attributes for different @media query 

breakpoints (that’s how responsive-ness works), and it intelligently loads the image for that breakpoint.

As the default image, you can load a transparent GIF, or nothing, or you could load the smallest image. Also, include an <img> tag within a

My project is loading a bunch of thumbnails, and we want all the images to come out the same size—just about square. In this case, 205 pixels wide, and 216 pixels high, on the desktop version. I can add an image size for this:

The true is for yes, do hard-cropping—force it to those dimensions. It crops from the center of the image.

I can also add smaller sizes for different breakpoints, like this:

(These sizes are not precise.)

Now, as I am looping through my images, I am wanting to grab the URL for each one. I could do it like this:

Then, I can access the URLs for the actual images by $myimg[‘desktop’][0], $myimg[‘tablet’][0], etc.

So now, in my image call, the image can be output like this:

Screen Shot 2013-07-21 at 9.23.04 AM

Then, I load jquery.picture.js, and within a jQuery script, I load:

What happens is, jQuery Picture will look at the width of the screen, to determine the “breakpoint” to use, and load that version of the image, dynamically. It works, and is cool.

In order to do this in this manner, you must set up the required image sizes. You could do this in the theme code, though the Simple Image Sizes plugin is very handy also. When doing it this way, you need to regenerate the images if you add sizes. (There are plugins to perform this operation, including Simple Image Sizes.)

The other way you could handle all these different image sizes, is to use TimThumb. Much hulabaloo about it, because of a hack back in version 1.10, but now we’re in version 2.8.11. In this way, you don’t need to worry about generating image sizes. It’s very fast, and it caches its results, so there should be no appreciable hit in performance (though theoretically, there might be a tiny one, because it’s loading a script to call an image, instead of loading a static, already-generated, image file).

If I wanted to generate the same cropped images using TimThumb, I could do it like this:

Just wanted to list out the pros and cons for myself.

Native Image Sizes

Pros:

  • Probably a slight performance improvement, because each request is to a static image file, instead of a script that’s loading a cached image file.
  • It’s native WordPress code. Updating WordPress means updating any improvements, fixes that might be added to the algorithm. (I.e., if it ain’t broke don’t fix it.)
  • I detected a very slight better quality of the native WP image, though it was subtle.

TimThumb Image Sizing

Pros:

  • Development-wise, it’s kind of elegant to simply call the same image file, simply passing it different size parameters. 
  • During development, you might be trying out a variety of different image sizes. In this case, it’s extremely fast to just tweak the parameters here, rather than have to physically change image sizes, and then regenerate them.
  • TimThumb has some different options, including:
    • Sharpness—a nice sharpness filter—works well
    • Quality reduction—if you want, you could on-the-fly scale down the image quality a bit—say, for the mobile version—this also works well
    • Control where the image is cropped—though I am not sure how useful this is, you can crop the image from the top or bottom, the left or right, if you want
    • There are a variety of other image filters you can use—though again, not sure how useful this is—With all these, I could see the advantage is if you wanted to do something different at different sizes, for some reason

In the end, I guess the main reason you’d want to use TimThumb is because it’s a little bit convenient, and kind of cool and magical. But unless you really wanted one of the extra features listed below, it makes more sense to use the native image sizing.