So, you are getting ready to start using ImageEngine on your live website! Congrats!
Adding ImageEngine to a high-traffic site should be approached deliberately to maximize performance while ImageEngine's Cache is being populated and to generally avoid problems that can occur when switching to a new CDN. Here are some things you need to know and things you will have to do to transition effectively.
All the following information also applies should you need to disable ImageEngine for any reason - in reverse, of course!
With minimal downtime, you can easily implement ImageEngine and ensure full business continuity with just a little preparation.
Verify your Engine configuration
You want to avoid surprises, so it's best to test your ImageEngine configuration before moving to full production. You can check whether an image can be served by replacing the current base domain in an image's URL with the delivery address for the engine you will be using.
For example, if the original image URL was https://www.foo.com/image.jpg
and your Delivery Address is `example.imgeng.in`,
then you will modify your image's URL to
"https://example.imeng.in/image.jpg"
If an image cannot be accessed and an error results, check the following:
- Is the image not at the origin that is specified for the engine? The origin of an engine is specified in the engine settings.
- Is there a host header or password required to access the content? These may be modified in the origin configuration.
- Is the origin blocking the request? Consider adding our User-Agent to your whitelist:
imageengine/*
4xx errors mean that the content is misconfigured or unavailable from where ImageEngine is being told to access it, and 5xx means that there is a major problem on your origin or in the connection between the CDN and your origin.
If you need assistance resolving a configuration issue, please enter a support ticket here: https://control.imageengine.io/support
Use separate Engines for staging and production
As a matter of procedure, ImageEngine strongly encourages staging and production Delivery Addresses to 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.
Prepare your origin servers for a traffic spike
If you previously had another CDN providing some caching, your origin was shielded from the major part of the traffic. ImageEngine must access images to warm the cache, so you should anticipate a traffic spike.
Make sure to use a low TTL if making changes to DNS
If you are implementing ImageEngine via making changes to your DNS, such might be the case when using a custom Delivery Address that is a domain subdomain.
Before the switch, reduce the DNS TTL to a few minutes to easily make rollbacks.
Be sure to revert the change after implementation.
Improving caching performance
ImageEngine can handle substantial amounts of traffic efficiently. However, the cache will be empty when a website's traffic is directed to ImageEngine for the first time in production. Filling the cache with optimized images takes time, leading to slower response times and time-to-first byte while the cache builds up. To avoid the worst consequences of operating without a populated cache, ImageEngine offers a feature that reduces the risk of slow response times.
In the engine's advanced settings, enabling the “Temporary Origin Image Fallback” feature temporarily serves 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 as an optional setting in each engine’s settings. (see customizing engine delivery)
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 an optimized version is available. The default is 120 seconds.
Please Note: If you use ImageEngine directives on your site, be aware that some are incompatible 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 very first request for a new image will serve the original, unoptimized version of the image from the origin. This image will be cached for the time specified (TTL). Meanwhile, ImageEngine will optimize the image for future requests.
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
Notes:
- This is a preventative measure for devices without optimized cache images.
- The `Temporary Origin Image Fallback` setting will temporarily serve the image from the origin while ImageEngine processes an optimized version. This will reduce broken images/long load times,
- Temporary Origin Image Fallback is not compatible with prefixing the origin.
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 remember that it is possible that an image will not be fully optimized on first request. When using performance test tools like WebpageTest.org, Lighthouse or Pagespeed Insights etc., make sure to run multiple tests.
Post-implementation
Verifying whether an image is using ImageEngine
To verify the status of individual images, you can inspect the base domain of the images, which, if you implemented ImageEngine on your site correctly, will be updated to whatever delivery address the response headers from images served from ImageEngine.
Look for the Server header. If served by ImageEngine, the image will return "scientiamobile imageengine' if it does not, either the image is still being served from the origin or there is another CDN in front of ImageEngine.
Also, view the imgeng-img-status response header. If the original image is being served, the header will return imgeng-img-status: origin-object. In this case, 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, which ImageEngine mirrors from the origin.
Monitor your old CDN for incoming traffic
If you previously used a different CDN for content, the traffic there should drop, but persistent traffic may still exist and should be investigated. Such traffic could be from areas of the site that were not updated during your implementation.
Additional reading
For Platform or framework-specific guides please see our integration guides
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.
Comments
0 comments
Please sign in to leave a comment.