Although my excitement for Gatsby has faded over the past years, one of the features I really liked was the blur-up image effect used in Gatsby Images. The eye-catching feature was introduced in Gatsby to showcase what a static site builder can do for you during page generation: Producing a highly compressed thumbnail image from the original that can be shown on the web page as a placeholder while the full image is still loading.
Why use blurry images on websites?
The purpose of the effect is to create the illusion of faster loading speeds and it avoids showing an empty space where an image will load. The pattern is not new and has been applied by Medium and Facebook before.
Interestingly, I could not find a single study that confirms the alleged benefits for perceived performance are real. Some people even report they feel irritated by seeing a garbage image. I suspect this has something to do with expectations: If you know the blurry image is a fuzzy prelude to the final image, you may just as well enjoy the smoother transition effects.
The page speed metrics introduced by Google honors visual completeness and shows that I am not alone with my excitement about loading speed illusions. A blurry placeholder can increase visual completeness earlier and can have a positive impact on Google page ranks.
Avoid 2 common mistakes that affect build times and page loading performance
However, there are many implementations that fail badly and sacrifice real loading speed: the thumbnail image data has to be fetched over the wire in addition to the original image and may block the main thread during the most crucial hydration phase.
Coming back to Gatsby, there was an additional problem with their workflow: Image processing is computationally heavy and the blur-up effect would slow down static site generation. Even worse, this slow-down is multiplied by the number of images on all pages of your site — a major reason why I think Gatsby lost ground and was more and more viewed as a slow tool. Not sure, if they will ever recover from that.
These issues helped me realize a conceptional flaw that is inherent to many static site-builders, not only Gatsby: They are performing computational-heavy task at the wrong time. The best time for image processing is not during site-building. Ironically, these static-site builders neglect their own mantra when it comes to image processing: build your web components as early as possible.
Following this rule, a blurry image can be generated as soon as it is added in the content management system and it will never have to be re-generated unless you change or remove the image from your article.
Blogody progressive image loading concept
Admittedly, a speedy and visually convincing solution is not that simple to implement. As we saw earlier, a state-of-the-art approach spans the entire publication process from content creation to the website page loading. This is exactly where Blogody shines: while using a Jamstack approach internally, the integration of the full publication workflow into one SaaS app allows to make optimizations at any stage of the content creation process.
When an image is uploaded to Blogody, the platform immediately calculates and stores image dimensions and a blur-hash, which is s a small string that encodes a low-resolution blurry image of the original. This image meta data is always available through the Blogody API which is also used internally. Both image dimensions and the blur-hash are then later used to construct the image placeholder that is shown before the full image is loaded.
The computational impact for one image is negligible and it will never have to be done again as it is stored alongside the image — much better than re-calculating the meta-data on every static-build for all images. Furthermore, the encoded blurry image is really small, much smaller than a scaled-down JPEG image of the same pixel size. This property is really important as the placeholder image needs to be available as early as possible, without significantly increasing the payload that needs to go over the wire.
Why use BlurHash?
BlurHash is a new, compact representation of a placeholder for an image invented by Dag Ågren, a developer of the food delivery company Wolt. What makes the implementation genius is that a visually pleasing placeholder is encoded into less than 40 characters or bytes, which is typically 20 times smaller compared to the more widely used practice of making a base64 encoded thumbnail image.
To illustrate the point, have a look at the feature image of this article. The Gatsby image algorithm derives a 20x13 pixel thumbnail that takes about 895 bytes whereas BlurHash only needs 37 bytes:
As you can see, both pictures resemble the color distribution of the original, but the blur-hash has a significantly smaller footprint. This is especially important for low connection speeds for which the placeholder was invented in the first place.
The scaled-down thumbnail shows more detail, brighter colors but also more artifacts as it has not been smoothed the same way. Those artifacts may lead to irritation, that’s why I think the blur-hash version is less likely to be confused with a garbage image or site malfunction.
Blogody blur-up image implementation
Now you know why BlurHash is a great choice for Blogody. As we saw earlier the blur-hash is generated whenever you add a new feature image to your page and it is saved together with the image dimensions in the Blogody database. This is the information delivered from the server to the client (your web page) from which the image placeholder is created.
There are some intricacies that need to be tackled on the client. The first difficulty arises because browsers do not know what to do with a BlurHash. Unlike the base64 encoded image that all browsers understand, the blur-hash must be decoded on the client. Although the process is fast, the resulting blur-hash image can only be shown after first render.
While this sounds like a drawback, it’s actually exactly what you want: lazy image loading. A blog article should show all text elements first and not be blocked a millisecond by image loading. However, what is really important is that the image placeholder does not lead to content shifts. That’s why Blogody initially shows a light-gray placeholder with the exact image dimensions on first render. The placeholder is quickly replaced by the decoded blur-image and finally by the full resolution image. Here is a typical timeline that illustrates the process.
On slower connections, you’ll see the blur-image for a longer duration, however, the initial gray placeholder is almost as quickly replaced. Due to the transition effects that Blogody uses between these sequences, you’ll hardly notice that the technique starts out with a gray area.
Image placeholder transition animations
The visual placeholder effects are enhanced with transition animations. A fast fade-in effect from the initial gray placeholder to the blur-image and a slightly longer fade-in of the final full resolution image contribute to a smooth progressive loading effect.
On fast internet connections the whole sequence would not be visible. The animation therefore ensures that Blogody feature images are always blended-in nicely.
Perfect page speed rankings despite blur-up effects
While image effects are nice, many implementations deteriorate your Google page ranks. The solution presented here takes special care, so the fancy effect does not impact speed metrics negatively. The key elements for this achievement are:
- A representation of the placeholder image is generated on the CMS.
- The placeholder image string has negligible size due to the BlurHash.
- Only the BlurHash is transferred over the wire, decoding is done on the client.
- Zero content shifts due to a properly sized placeholder on first render.
- Lazy fade-in of blurred and final images after first render.
Here is the Lighthouse speed report that I determined with the Chrome developer tools. Not much that can be improved here.
I’ve come a long way to finally present a convincing solution for the feature image blur-up effect that ensures nice transitions for both fast and slow connections, positively impacts page speeds and does not slow down build times. The best part: this feature works out-of-the-box on all Blogody sites, no configuration changes needed.
This post was originally published at Blogody News on October 25, 2021.