Table of Contents
  • Docs >
  • 9. Images in ShimmerCat Accelerator
Shortcuts

9. Images in ShimmerCat Accelerator

Images are the bulk of the average e-commerce web page, therefore policies around them are important to optimize loading times in a site.

As a general rule, the accelerator shouldn’t make an image worse.

At the moment, ShimmerCat accelerator supports three different policies related to images:

  • do not prioritize, optimize or scale images

  • do not change images, but prioritize and optimize them

  • prioritize and optimize images, also scale or generally transform them to some size or other specifications provided in the URL.

The first policy is by default, and is what one would normally get with a typical web server. It fits best sites which already have a different policy in place for handling images. The other two policies are opt-in, and are explained in some more detail below.

In this document, we talk about two kinds of sizes:

  • “byte size”: the size of the image file in bytes, i.e. the number of bytes that is reported in the Content-Length header field, or that is seen as the “size” property of the image file when saved in the filesystem.

  • “pixel size”: the width and height of the image in pixels, as shown in a viewer (at a 1 x 1 scale).

9.1. Prioritize and optimize (with no scaling)

With this policy on, the accelerator does the following:

  • It arranges things such that images which are seen first in a target device are sent first

  • Images which are initially on-screen are kept on either PNG or JPEG format, though they can be given a quality-preserving byte size optimization pass via some specialized tool. The JPEG and PNG formats enable our coordinated image-loading technique, which can come in handy for images shown early on the load process.

  • For images which are off-screen on page load, it creates and caches instances of the images in browser-specific formats, like WEBP, JPEG-XR, JPEG2000, or in SW-enabled formats like BPG and FLIF.

In those cases when new files for an image are created, these copies have the same pixel size than the original image. They may include quality changes to the images, but only those that tend to result in visual enhancement and artifact removal.

This policy works best for sites which already arrange for visitors to get images of the correct size in pixels, via some viewport detection mechanism.

9.2. Prioritize and optimize with scaling

This policy enables the following:

  • It arranges things such that images which are seen first are sent first

  • Images which are initially on-screen are kept on either PNG or JPEG format, and both their byte-size and pixel-size are changed to fit our best inference of the browser’s viewport.

  • It creates and caches instances of the images in browser-specific formats, like WEBP, JPEG-XR, JPEG2000, or in SW-enabled formats like BPG and FLIF, with the same pixel size than the original images.

We describe how the image sizes are deduced from the URLs in the HAPs page.