Skip to main content

1. Resizing, and why it is important

When you view an image on a webpage, there is an important consideration to bear in mind: the server has sent the image to your browser, and then your browser has rendered or 'displayed' that image on the screen. This means that the image sent by the server can be very different in size to how it is displayed on the screen.

This makes for an important efficiency consideration: if a server sends a 10000x5000 pixel image with a huge filesize, which is only going to be displayed on user screens at a maximum size of 1000x500 pixels, the server is wasting a huge amount of bandwidth. There are two main reasons this is a problem:

  1. For the user, even though they're only seeing a small image, they have to wait for the entire huge image to download before their browser can display it, making the website look slow.
  2. For the server, sending this huge image requires far more bandwidth, which in practical terms means a far higher cost.

Most CDNs, which are used to send image files (and other static content) to users for a website, charge for bandwidth per gigabyte. Sending an image that is 2x as big than it needs to be means you are going to pay twice the CDN costs for no good reason, and slowing the load time of your website at the same time.

As a result, you need to resize most media such as images and videos to fit the use case: a thumbnail image being shown as a preview in a gallery does not need to be as big as a full-size preview being shown when a user wants to view a specific artwork. There are two approaches to how you can actually implement this.

Approach 1: Lazy (on-demand) resizing

When an artist uploads an artwork, you can choose to only resize it on demand - when a user tries to view the artwork at a given size. If that size doesn't exist in your cloud storage, your "lazy" configuration resizes the image at that point in time, or if it already exists, just returns the file to the user.

Pros:

  • It's easier to set up
  • It doesn't cause any additional wait time for the user uploading the artwork, since the resizes aren't done at this stage
  • It allows for automatically deleting rarely used resized files, saving storage costs, since they can be re-generated without any hassle if a user subsequently requests that file. However, the savings will only really be substantial in cases where many files sit unused, which is normally a sign of a larger problem in the codebase.

Cons:

  • A website owner must be careful to only make a few sizes valid (e.g. 4k, 1080p, 480p). If valid sizes aren't specified, you could end up with a whole ton of unnecessary image files being stored in your cloud storage (e.g. 600x480px, 600x479px, 599x478px...) and end up with huge file hosting costs.
  • The first time an image is requested, and the required size doesn't exist, there can be a noticeable delay for the user viewing the artwork while the resized version is created. This is not usually a major problem, but is worth mentioning, especially in the context of 4K images or higher resolutions where the process takes a minimum of several seconds to complete.
  • Making lazy, on-demand resizing has some security pitfalls. Some solutions require making the cloud hosting bucket publicly accessible, leaving it open to malicious attacks on the bandwidth of the bucket's access point that could land a website with high unexpected costs.
Approach 2: Proactive resizing

In this approach, all of the resized images are made before the user submission process is complete. An artist uploads an artwork, and when submitting it, all resized images are created before the submission form shows that the submission is successful.

Unlike lazy resizing, this means there's a delay for the uploading user, as they must wait for the resizing processes to finish. However, with good coding the longer wait time situations can be avoided, for example by displaying the 1080p resized version to begin with, and showing the 4K resolution version only when processing has finished, instead of making the user wait for that one to finish as well.

Pros:

  • Unlike lazy resizing, there is no risk of undetected resize errors (since, if an error occurs, it will be known before the submission process finishes)
  • It avoids any potential problems with unnecessary size values
  • When coded correctly, it has no downsides in most art site situations compared to lazy resizing

Cons:

  • It's harder to code correctly, and with bad coding or efficiency, can make artists wait a long time (>10 seconds or so) on upload screens
  • For non-art sites, where some sizes might rarely be used, it can result in higher storage costs (since you are storing resized images that may never be needed, rather than generating them only when needed)
Implementation

Regardless of which approach is used, resizing images should not be performed on webservers themselves, for efficiency and server load reasons. This is covered in the next part of this guide.

Back to top