Server-side image resizing performance

Question

I have been noticing more and more from the big sites (Google, Facebook, Youtube and co) that they are resizing images "close" to their desired measurements client side and I am wondering whether this is a shift in the way people are thinking or them being lazy.

Take a scenario of adding a new image size to a standard set of images at particular sizes for a set of products (e-commerce) which number into the 100's of thousands, maybe millions.

Imagine I have a copy of my original image that is 300x350 or whatever and client side, resize it to 200x250. I do this for each product for 20 products on a page.

Is the work and problems server-side of accomodating this new size really worth the benefit client side?

If not then what is a good way to judge when you should pre-process a certain size?

If yes, is there ever a time where server-side processing and caching might become overkill (i.e. housing 8 images of 110x220, 120x230, 150x190 etc)?

Answer 1

I decided to test this first on a single image on a page and did some multiplication math to anticipate multiple images. I should note:

• I was using pngs for this test however pngs seem pretty standard.
• I was using a particular function which apative resizes the image so that the width and height would always fit the original aspect ratio of the image I resized.

I got an image which was 450x450 (roughly) and decided to resize it down, client side, to 200x200 (all measurements in this answer are pixels). I found very little CPU jump by it despite the resize being more than half of the images total size.

The quality was also good across all modern browsers, Chrome, Opera, Firefox and IE all showed the image as clear as if it was done in Photoshop or GD.

On on IE7 I didn't notice much of a CPU jump and the quality was good provided I used a percentile resize based upon the images size constraints.

Overall the additional storage, computation and coding required to make even this size cache server side seemed to be at a disadvantage to the power that can be implied on the user end.

That being said, if I were to start doing multiples of this type of resizing (say 20, as in my question) I would probably start to hit problems.

After some tweaking around I found that anything under 1/3 of the original images size, provided the image was under 1000px in width or height, seemed to be negliable to CPU and general computer performance.

With the added function I was using I got just as good quality from resizing client side as I did server side. The specific function I used (for interested parties) was:

function pseudoResize($maxWidth = 0, $maxHeight = 0){

$width = $this->org_width;
$height = $this->org_height;

$maxWidth = intval($maxWidth);
$maxHeight = intval($maxHeight);

$newWidth = $width;
$newHeight = $height;

// Ripped from the phpthumb library in GdThumb.php under the resize() function
if ($maxWidth > 0)
{
    $newWidthPercentage = (100 * $maxWidth) / $width;
    $newHeight          = ($height * $newWidthPercentage) / 100;

    $newWidth = intval($maxWidth);
    $newHeight = intval($newHeight);

    if ($maxHeight > 0 && $newHeight > $maxHeight)
    {
        $newHeightPercentage    = (100 * $maxHeight) / $newHeight;

        $newWidth = intval(($newWidth * $newHeightPercentage) / 100);
        $newHeight = ceil($maxHeight);
    }
}

if ($maxHeight > 0)
{
    $newHeightPercentage    = (100 * $maxHeight) / $height;
    $newWidth               = ($width * $newHeightPercentage) / 100;

    $newWidth = ceil($newWidth);
    $newHeight = ceil($maxHeight);

    if ($maxWidth > 0 && $newWidth > $maxWidth)
    {
        $newWidthPercentage = (100 * $maxWidth) / $newWidth;

        $newHeight = intval(($newHeight * $newWidthPercentage) / 100);
        $newWidth = intval($maxWidth);
    }
}

return array(
    'width' => $newWidth,
    'height' => $newHeight
);
}

So it does seem from my own testing that housing every size of every image your going to use, i.e. as I asked in my question:

If yes, is there ever a time where server-side processing and caching might become overkill (i.e. housing 8 images of 110x220, 120x230, 150x190 etc)?

Does seem to be overkill in modern computing and rather you should go for close measurements if you intend to use many different size of many images.

I have found, however, that if you have a standard set of sizes and they are small then the advantage is actually to server side resize and storage of all sizes since forcing the client to resize will always slow their computer down a little but scaling under 1/3 of it's original size seems to not make too much of a difference.

So I believe that the reason why sites such as FB and Google and Youtube don't worry too much about storing exact measurements of all their images is because "close-to-measurement" scaling can be more performant overall.

Answer 2

Consider following: Image resizing is heavy process for server. It first of all costly itself. Secondly it is harddrive IO operations which ARE quite slow. SO it all depends on how loaded your server is.

For client it matters in two ways:

1) Thumbnails are smaller in file size and hence are much faster to download. SO they will appear way faster. But that all depends on speed of Internet connection, which day by day is increasing. Have you seen how large images are loaded? They will not be displayed whole at once, but rather by 'lines'

2) If you try to display large image in small size, the quality will be much much much lower. It is because of how browsers process it. They do not have capabilities of Photoshop and cannot do proper quality resizing.

3) Many large images on single page will increase memory usage by that page. On some not so powerful computers that may give terrible lags while scrolling opening it.

As a solution to this question i more tend to do what i have seen in one of Drupal modules (imagecache if i am right).

It does not create thumbnails on image upload. Instead it creates them on request time using .htaccess and mod_rewrite capabilities. It checks if requested file does not exist and if no it redirects request to small and light-weight PHP script which will create the thumbnail, write it to filesystem and then output to client.

So next visitor will already get previously created thumbnail.

Thus you implement postponed/lazy image resizing, which will make the load smoother (stretch it in time).