Picture widget updated: balancing image quality and project performance

Image for post
Image for post

Picture widget is the second most popular in Readymag after Text. Yet, from a viewpoint of bandwidth, images are hogs—they present the average largest project payload. That’s why one of our main optimization challenges is to display high quality images while minimizing their file size.

To meet it, we recently rolled out several updates to the Picture widget. In this piece, Readymag developer Sergey Nechaev describes our journey to deliver optimized images with the proper balance between size and quality. This post shares some technical details that will interest those who want to know how Readymag works under the hood.

Progressive image rendering

Technically, it works like this: when a visitor opens a page, all images in it start with tiny light-weight previews (they are called LQIPs — low quality image placeholders). Once the page is fully loaded, placeholders get replaced with the original quality images. LQIPs don’t actually make images load faster, but they help the user experience by telling page visitors that images are on their way.

Image for post
Image for post
A LQIP for a tiny PNG with contrast bold graphics. The size of the LQIP is 3.5 Kb and the original file size is 154 Kb
Image for post
Image for post
A blurred preview for the same image, as rendered in the browser
Image for post
Image for post
This is how the image finally looks in the project. Adapted to a 600px-wide widget, the size of the WebP file is just 51 Kb

We combine this technique with ‘lazy loading’ to make sure that viewers’ browsers only download images when they need them. On a slow connection, visitors get a fully usable page much faster, achieving a significantly better user experience. On a fast connection, the extra download of the LQIPs — or the delay of the high quality ones — does not lead to a substantial hinder.

Our journey to implement LQIPs

Another possible approach is to reduce image size. We compressed original images to the radical 40px (by width), saved them in minimal possible resolution, and made blurring browser-side. After forgoing server-side blurring and giving up on the necessity to save images in high quality, the resulting image size turned out to be very compact.

Neat bounds, transparency and rounded corners

Image for post
Image for post
An LQIP for a large JPG with colorful geometric graphics and text. The LQIP size is 1.4 Kb and the size of the original JPG file is 143 Kb
Image for post
Image for post
Adapted to an 800px-wide widget, the size of the final WebP file is just 44 Kb

For the special case of Background widget, we came up with the following solution: LQIP appears and stays above the widget as long as the main image under it is being rendered. To make the transition visually smooth, we make LQIPs dissolve with a slight transparent effect.

Corners of a Picture widget can be rounded independently, so we had to apply this functionality for the preview LQIP images too. Also, we had to keep in mind that users can set opacity for Picture widgets lower than 100% — in this case, preview images must have the same opacity.

Image for post
Image for post
A blurred preview with rounded corners

Summing up, progressive image rendering is the best practice for you if your website offers lots of graphics, slideshows and images in the background. In case it has only a couple of images on a page, you just won’t notice the update. Also, it is still not working for SVG and GIFs.

Converting images to WebP

We decided to detect support for WebP browser-side. This added one additional check during page load, but freed us from excessive browser-side rendering and helped shorten the html code, as we now don’t have to put all possible image variants in <picture> source and srcset attribute. Yet, srcset elements were left at minimum, because search engines take into account the quality of image retrieval in their ranking algorithms.

Afterwards we worked on the visual quality of images. We had to establish the best image compression settings. It’s quite easy to do with photographs — WebP allows to compress them without any visible artifacts. But in Readymag users often use graphical work, such as logos and interface designs with solid colors and clear bounds. It turned out that for them WebP format with standard settings doesn’t leave visual artifacts but often blurs the bounds. So we took a large pack of real images utilized by Readymag users and found out the best parameters that work for them.

Reworking image delivery mechanics

We decided to forgo preliminary images. Instead, we made a service that generates images on-the-fly and caches them for further use. Distributed processing allowed us to do that as quickly as just uploading an image. Once the image is generated and cached, it is retrieved even quicker. This way we got a flexible instrument that allows us to deliver literally individual images for each viewer, especially taking into view Scale layout and animations scaling.

Image for post
Image for post
A 2.3 Kb LQIP for a big PNG image. The size of the original file used to make the LQIP is 1.5 Mb
Image for post
Image for post
Adapted to an 600px-wide widget, the size of the final WebP file is just 126Kb

We tested the new format of image delivery on various large projects with traffic starting from 100 MB per view, and the efficiency turned out to be even higher than we expected. On average, the total size of images delivered to a user in the browser decreased by 2.5 times. Not only the conversion to WebP played a role, but also the adaptation of images exactly to widget sizes.

There are more updates to come! Learn about new features here.

We are eager to share how Readymag works under the hood. If you have some particular questions about our technical side, please message us at hello@readymag.com and we will try to cover the topic in future articles.

Written by

The most elegant, simple and powerful web-tool for designing websites, presentations, portfolios and all kinds of digital publications.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store