Skip to main content

Transcoding: what it is, and why it is important

Definition

Transcoding means resizing an image or other media to multiple sizes, so that users can be shown a size that's appropriate to their screen and internet speed, the size at which the media will be displayed on a given page, and so on. It's called transcoding, and not just 'resizing', because it often involves re-encoding the media to a different format, to display efficiently on the web or wherever else it is going to be displayed.

There are two main reasons transcoding media properly is important: cost, and performance.

Performance

When you view an image on a webpage, 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. This not only puts your server's bandwidth under a lot of strain, but also means the image (and your website) are going to load a lot slower for the user.

This is even more important for videos, due to their larger size.

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 5x as big than it needs to be means you are going to pay five times 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 reasonably fit each possible use case. For example, you might have a 4K version, a 1080p version, and a 480p (640x480) version of an image or video; the 4K and 1080p versions for big, detailed displays of a given image, and the 480p version for thumbnails in galleries where a big size is not necessary. 

Outside of whether to code a solution yourself or use a premade one, there are two technical approaches to actually implementing media resizing.

Approach 1: Lazy (on-demand) resizing

When a user uploads a media file, you can choose to only resize it on demand - when someone 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 media, 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 a media file is requested, and the required size doesn't exist, there can be a noticeable delay for the user viewing the page while the resized version of the media 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 can potentially have 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 (images only)

In this approach, all of the resized media files are made before the user submission process is complete (after upload, but before submission). A user uploads a media file, and when submitting it, all resized files 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.

This doesn't work for video transcoding, as the processing time is far too long (your users would be sitting around waiting several minutes).

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 users 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 media should not be done on webservers themselves, for efficiency and server load reasons. This is covered in the next part of this guide.

Back to top