How To Handle Loading Of Images That May Not Exist?

Rahul Nanwani -

When you are handling millions of images on your website or mobile application, it's quite possible, over a period of time, a few images may cease to exist. And when you try to deliver those images on your applications, the users end up seeing a broken image like the one below.

A sample page with broken images as seen on Google Chrome browser

Surely this is not something that you would want showing up on your application. But how to handle loading of images that don't exist anymore?

Let's talk about some ways you can fix this broken image problem to maintain the UX standards of your application.

1. Periodic data cleanup

If an image does not exist, then it should be removed from the database.

An image URL that is incorrect or points to an image that no longer exists, is most likely a data issue. So the first thing that you can do to counter the broken image problem is to periodically check all images for sanity.

You would pick up a list of image URLs that have been added over, let’s say, the last week and check if you are able to retrieve those images (a 200 OK HTTP response). If yes, then the image stays in your database, else you can discard the image.

Advantages

  • Solves the problem at the root level.
  • One-time effort in writing the script.

Disadvantages

  • Lengthy execution times (nearly impossible) for millions of images.
  • Waste of network bandwidth.
  • Can't catch errors for the time between two consecutive runs of the cleanup task.

2. Handle it in your application

If an image does not exist, we can replace it with a new one.

Another way to handle this issue is by listening to the error event that gets fired when the image fails to load. In HTML, this can be done with the onerror attribute of the <img> tag.

<img src="http://example.com/non-existent-image.jpg" />

If the original image fails to load, then it is replaced by the image mentioned in the onerror attribute handler.

Similar handling can be done in mobile apps as well.

Advantages

  • Can handle data issues in real-time.
  • No need for periodic checks.

Disadvantages

  • Won’t work for images loaded as background (at least for websites).
  • Problems may continue in older versions of your website or application that cannot be updated with the new code.
  • Different code for different platforms.

3. Handle it on your image server

If the image does not exist, then the server should not send the error at all.

Your image server knows if an image does not exist and sends a 404 Not Found HTTP status code to the client. Instead, the server itself could replace it with a default image, correct the HTTP status code and then send it to the browser or the application.

Advantages

  • Works in real time without any periodic checks.
  • No handling needed on any application or any version of any application.
  • Works for all kinds of images.

Disadvantages

  • You need to build a server that can handle this rerouting for you.
  • Difficult, if not impossible, to get it working with simple image delivery setups like CDN + S3 storage.

4. Handle it using a third-party image server like ImageKit.io

ImageKit.io automatically provides server-side handling of non-existent images. Using ImageKit’s URL-based transformations, you can specify the default image that should be delivered, if the original image does not exist, with the original image URL itself. To give an example,

<!-- The non-existent image URL -->
<img src="https://ik.imagekit.io/demo/img/non_existent_image.jpg" />

<!-- Specifying the default image to be displayed in the URL -->
<img src="https://ik.imagekit.io/demo/img/tr:di-medium_cafe_B1iTdD0C.jpg/non_existent_image.jpg" />

The default image is specified using the di- parameter in the URL. In this case, the default image is from a cafe.

Deliver a default image, the one on the right, instead of the broken image, the one on the left.

Being a URL-transformation, this gives you the flexibility to specify a different default image for different kinds of images without having to write any code to handle the error cases.

You can read more about handling of non-existent images or default images using ImageKit here.

Considerations for image caching in error cases

Default images sent instead of a non-existent image should not be cached at all, or if it is cached, then the cache duration should be small, preferably a few hours. This leaves an opportunity for the non-existent image to be “fixed” or made available. When this happens, then the correct image would start getting delivered to the users automatically.

However, if the image is not expected to be fixed, then the cache duration can be longer.

Considerations for response code in error cases

If you wish to handle the error case in your application, then the image request should be returned with a 404 status code for the onerror to work.

If you are delivering the default image instead of a broken image from the server, then the response code can be 302 Temporarily Moved (ideally to prevent caching on intermediate layers like CDN, but handling with success and error handlers in application is impaired) or 200 OK (caching on intermediate layers can be controlled with caching headers)

Since images form a critical part of our application, ensuring that the UX is not broken because of data issues with images is equally important. I hope the above techniques will help in ensuring a better experience for your users on your website and app.

Drop a comment if you have any ideas on handling images that no longer exist on a web application.