Progressive JPEGs and the STK, take 1

Posted by

    From version 4.7.5 of Enonic CMS, JPEGs can be served progressively encoded for smoother loading of images. There are, however, problems incorporating this into a responsive website.

    You might have thought that "a JPEG is a JPEG". Think again. JPEG images can actually be stored in different ways, and they behave differently based on how they are encoded. The traditional way of saving JPEGs is with a so called "baseline" encoding. I won't go into the technical details on how these files are actually saved, as there are more than enough resources covering this on the web. The practical difference, however, is of more importance for this article.

    When a baseline encoded JPEG is loaded in the browser, the image appears in full detail, line by line. In most cases, on a high speed connection, you probably don't notice the loading at all. However, on slower connections (i.e. mobiles), baseline encoded JPEGs appear one line after another, and you won't really get a full impression of the image before the entire file is loaded.

    An alternative way of saving JPEGs is with a progressive encoding. When a progressive JPEG is loaded in your browser, the image will appear blurry and with little detail at first, becoming more and more detailed as the file is downloading. In other words, the practical difference between baseline and progressive JPEGs is how they are displayed when they are loading. A baseline JPEG appears with full detail from top to bottom, while a progressive JPEG is shown in its full dimensions instantly,  getting increasingly more detailed.

    So, why is this important? It is all about the user experience. Most of us would rather want to see the full image becoming more and more detailed, than waiting for the whole image to appear. In addition, large images generally turn out with a smaller file size when they use progressive encoding.

    Ok, that was the introduction. Now to the core problem we are seeing trying to implement progressive JPEGs in a responsive website (built on the Enonic STK). The STK is built to select an optimised version of any image in any given setting. If the site width is 1000 pixels, and the image is supposed to fill the entire width, a prescaled image of 1024 pixels is used. If the same page is shown on a lower resolution (i.e. a mobile), a smaller prescaled image is used. In short, this is done by adding the URLs to all prescaled versions in a data attribute on the image element, while the actual image shown on page load is a transparent placeholder image with the correct aspect ratio. A script is run to calculate the actual displayed width of the placeholder image, which in turn is replaced with the closest sizes prescaled version.

    With baseline encoded JPEGs, this works great. If we turn on the progressive encoding, however, problems occur. Actually, before doing any modifications to the STK, the progressive JPEG doesn't appear at all until the entire image is loaded! This behaviour seems to be identical in the browsers we have tested (Chrome, Firefox). If we load the image directly, it has the progressive behaviour, but changing the image src-attribute from the placeholder URL to the image URL makes it load very slow.

    It turns out that removing the image's src attribute completely before setting the correct image URL makes the image load progressively again, but this makes the content surrounding the image jump up and down (since the image loses it's dimensions when the src-attribute is removed).

    This is obviously a browser problem, but it is unclear if it is per design or just a bug. Because of this behaviour, we can't recommend enabling progressive encoding of JPEGs on a site built with the responsive STK. This is also the reason progressive encoding is turned off by default in 4.7.5 (but you can turn it on in the CMS configuration if you want to).

    We will continue our testing and try to find a workaround. If you have any comments on this, please post them below.

    Comments