Server-side image resizing

One of the more frustrating aspects of working with users is when they upload massive images to a site, when they will only be displayed on screen as small thumbnails.

Browsers have long supported setting the image display size, but that still requires the full large image to be downloaded – taking time and bandwidth – and the resizing is often poorly done, leaving jagged artefacts visible.

To solve this problem we resize images at the server, prior to sending them to the browser. The browser still gets the size attributes, so it can reserve the space for the image, but it no longer has to download the massive original image, nor do any resizing. This means pages load faster, and look better, and the bandwidth overhead on both the server and the clients are reduced.

There are no settings controlling server-side image resizing: it happens automatically when needed. However if you're interested in how it works, read on.

Server-side image resizing is currently implemented on form/table-based image fields. Images uploaded onto rich text surfaces (either in forms, or direct on page surfaces) are not covered by this.

So how does this work?

A user uploads an image as normal. So if they upload a large image the upload process will still take the same time. (We could have resized the image before uploading, but there's lots of good reasons why we don't, as we'll see). Once uploaded the image is stored in its original size.

When the image is needed for display on a page, the desired sizing – as specified in the Query format configuration for the field - is examined, and a resized version of the image is created. The resized version is then kept for future page views, and if the image is needed in several different sizes, then multiple copies of the image are kept in the various sizes (hence why you want to keep the original on the server – you don't know what other sizes might be wanted later).

What actually happens is that the HTML sent to the browser with the reference to the image URL has the image URL adjusted, with an extra folder path inserted, where the folder name gives the desired size. Now the first time the image is requested in this size, that file and path won't exist on the server, so when the browser requests the image, the server's 404 file-not-found handler will see the request instead. It then manages the resizing of the image, and returns the image in the right size (not a file-not-found response). It also writes a copy of the resized image to the requested folder path, so the next time it is needed it can be delivered without repeating the exercise.

Sizing can specify the width or the height, in which case the aspect ratio will be preserved, or both, in which case it will be squashed to fit. All sizes are specified in pixels.

This works both with standard images (delivered from a public path to anyone with the URL), and with secure images (delivered via a handler to users logged in with appropriate permissions)

If the original image is deleted or changed, the cached resized copies of the image are immediately destroyed - so there is no interval in which an out-of-date resized image might be delivered. Since resizing is actually quite a fast operation, the cache deletion is 'trigger-happy' (ie pessimistic), deleting cached images whenever the table record is updated in any way, rather than spending time assessing whether the original image was actually changed.