PHP Image Resize on the Fly VS Storing Resized Images

PHP image resize on the fly vs storing resized images

This sounds like premature optimisation. Do you know how many users your site will have/ how much computational grunt your server(s) will have? Go with the simplest (maintenance-wise) option, i.e. resize on the fly, until performance becomes an issue, then figure out from there what to do.

It might be an idea to implement some sort of server side caching of your rescaled images, if they're likely to be repeatedly hit, but I don't think this need extend as far as explicit pre-rendering.

Resize and cache images on the fly vs saving different sizes on server

I do this for thumbnails... pretty easy with Intervention image library... I mean, simple... http://image.intervention.io/

// open an image file
$img = Image::make('public/foo.jpg');

// now you are able to resize the instance
$img->resize(320, 240);

// finally we save the image as a new file
$img->save('public/bar.jpg');

That's it... and yes, resizing on the fly is a bad idea...

resize image on the fly using php

You cannot output html and images to the browser in the same script.

You should either:

• use a separate script to output the image and call that from the html like (simple example):

  <img src="your_script.php?id=XX&size_x=XX&size_y=XX">

• save the images to a file and link to that file from your html.

You could also encode the images as base64 strings and use that in your image tags but that would lead to a very large html file unless you are talking about simple buttons.

php image resize on-the-fly vs full size image

Essentially, it depends on

• What's the original-to-desired width/height ratio? It's not a big deal serving a 500x500 image and showing it as 250x250, but wasting bandwidth on 1920x1080 images is. Also, mobile devices might not have enough resources available to actually display the webpage if you serve too many big images.
• What do you have more of: bandwidth or CPU power? Can you make sure nobody uses your on-the-fly resizer as DOS target?

Generally solutions with a cache, even a very temporary one, are much better though.

[AD edit]

The discussed images are 5 "featured" images in the frontpage which
will not stay the same for more than an hour max. so isn't it a waste
to create another image copy of every uploaded image just for that?

It is. But you could simply create a separate folder for these thumbnails, and setup a cron job to wipe files older than an hour. Here's an example I use on my site (set to 30 minutes):

*/15 * * * * find /var/www/directory/ -mmin +30 -exec rm -f {} \; >/dev/null 2>&1

Is it better to resize Image on demand or on upload?

Disk is cheap and resizing on demand is very expensive. I'd never resize on demand for every request. I think you have two options:

• Generate all the different sizes once on upload.
• Store the original, resize on the fly the first time a particular size is requested, and cache that for future requests.

Update: nginx has a nice module for resizing on the fly. I'd never use it in production by itself, but if you couple it with a reverse proxy, you'll essentially get the second option without having to write any code.

How to resize images on the fly in PHP

For a server running php, you can use one of these libraries to resize the images on the fly:

1. meenie/munee
2. mos/cimage

You can install the library using composer by running composer require meenie/munee or composer require mos/cimage

Then you can link your photos by using one of these:

1. Meenie: <img src="/path/to/image.jpg?resize=width[100]">
2. cImage: <img src="/host/img.php?src=test.png&width=100">

On The Fly thumbnail/resize generation of images

I have successfully created a on the fly image refactoring application using Imagemagick. The performance is great and I am able to resize/crop/watermark/reformat etc all via a restful request. I use memcache to cache the binary blob of the refactored image and this gives me a massive performance boost.

EDIT: I used the Java Imagemagick libs initially and kept running into issues, the PHP libs are far better imho ( this was about a year ago, its possible that the Java libs have improved )

Serving Images with on-the-fly resize

I suggest you set up a dedicated web server to handle image resize and serve the final result. I have done something similar, although on a much smaller scale. It basically eliminates the process of checking for the cache.

It works like this:

• you request the image appending the required size to the filename like http://imageserver/someimage.150x120.jpg
• if the image exists, it will be returned with no other processing (this is the main point, the cache check is implicit)
• if the image does not exist, handle the 404 not found via .htaccess and reroute the request to the script that generates the image of the required size
• in the script specify the list of allowed sizes to avoid attacks like scripts requesting every possible size to shut your server down
• keep this on a cookieless domain to minimize unnecessary traffic

EDIT: I don't think that PHP itself would slow the process much, as PHP scripting in this case is reduced to a minimum: the image scaling is done by a builtin library written in C. Whatever you do you'll have to use a library like this (GD or libmagick or so) so that's unavoidable. With my system at least you totally skip the overhead of checking the cache, thus further reducing PHP interaction. You can implement this on your existing server, so I guess it's a solution well suited for your budget.

---

Related Topics