Advice for going live with ImageEngine in production environment

Introduction

Adding ImageEngine to a high-traffic site should be approached in a deliberate manner aimed at maximizing performance while ImageEngine's Cache is being populated. While ImageEngine can handle huge amounts of traffic, once the site’s traffic is directed to ImageEngine for the first time in production, there will be an empty cache; filling the cache with optimized images takes time and the response times and time-to-first byte will be slower while the cache is building up.

To make the transition to production traffic volumes less daunting ImageEngine offers a feature that will reduce the risk of slow response times and smoothen the time it takes to build up the cache.

This article will discuss this and some other things to keep in mind when implementing or deploying ImageEngine on a live site.

Use separate Engines for staging and production

As a matter of procedure, ImageEngine strongly encourages that staging and production Delivery Addresses be separate. As the URI for assets in staging and performance are often different, there is no performance benefit to using the same Delivery Address for staging and production.  

Improving caching performance

Simply explained, this feature will temporarily serve the original, unoptimized image while the optimized version is being processed. In other words, the optimization process is made asynchronous so that the end-users will not have to wait for the additional milliseconds for the optimized version to be ready.

How it works

The setting can be enabled in each engine’s settings, as an optional setting. (see customizing engine delivery)

The setting is called “Temporary Origin Image Fallback”.

We recommend the matching path for this setting to be /**/* to make sure all traffic is caught.

You can specify the Time To Live (TTL) for the original image to be kept in the edge cache before the edge cache again checks to see if there is an optimized version available. The default is 120 seconds.

Please Note: If you use ImageEngine directives on your site, be aware that some are not compatible with this feature. For example, if you use the `w` directive to define a specific width that an image must be served, the images will always be resized accordingly unless you override this by ticking the “Apply to all image requests regardless of directives” option.

When the setting is enabled, the first request for a fresh image will serve the original, unoptimized version of the image. This image is cached on the edges for the time specified (TTL). Meanwhile, ImageEngine will optimize the image so that it is ready for the next requests that match the optimization criteria (size, format, compression, etc). 

Once the TTL of the original image has expired, the edge servers will check back to see if the optimized image is ready. If it is, ImageEngine will start serving the optimized version and function as normal. As noted above, the default TTL is 120 seconds

Verifying whether an image is optimized

To check the status of individual images, you can inspect the response headers from ImageEngine.

Look for the imgeng-img-status response header. For the initial requests with this setting enabled, the header will return imgeng-img-status: origin-object. You’ll also notice that the cache-control headers have a short TTL.

Once the processed image is ready, the header will change to `imgeng-img-status: optimized` and the `cache-control` headers will also have the expected values.

Notes: 

• This is a preventative measure for any devices without optimized images in the cache. Be aware that accessing an image the first time may not have the expected optimization, as the original may have been passed. 
• The `Temporary Origin Image Fallback` setting will temporarily serve the image from the origin, while ImageEngine processes an optimized version,
• Please note that unoptimized images will be served using this fallback method which will result in an initial period where unoptimized images are served, but it will reduce broken images/long load times,
• Temporary Origin Image Fallback is not compatible with prefixing the origin.

Conclusion

Enabling “Temporary Origin Image Fallback”, will make the initial load and response time from ImageEngine faster in scenarios where the edge cache has a low fill rate, like when transitioning traffic to ImageEngine for the first time.

The setting can be left on even after launch, but please keep in mind that images will not necessarily be fully optimized immediately. This may result in unexpected or lesser optimization and performance results when using test tools like WebpageTest.org, Lighthouse or Pagespeed Insights etc.

Additional reading

Please see our Best Practices article for additional advice for getting the best possible performance from ImageEngine.

Learn how to get additional debug information from an image request.