Over the last decade, we’ve gone from having a home PC to having a pocket PC that can access the internet everywhere. It came with plenty of freedom and new problems to solve. For example, we had to figure out how to present content on different screens.

This was answered through responsive design, meaning that we could rely on one codebase with adaptive layouts depending on the output device. Say you had a website with a large image for desktop computers that you wanted to display on mobile devices with smaller screens.

When you write HTML code you could use the srcset attribute on the image tag or a picture tag. Subsequently, the same image would be available in different sizes, and the browser would select the appropriate version.

However, the problems don’t stop at adapting to different screen sizes. There’s another characteristic called DPI. Let’s discuss this concept in detail using this photo of a gorgeous cheetah to remind us how quickly we would like our images to load.

Photo by Ahmed Galal on Unsplash

What is DPI

DPI stands for “Dots Per Inch.” Initially, this term was mostly used to refer to an attribute of devices that put digital images onto paper and vice versa. These included scanners and printers. Therefore, DPI wasn’t a big concern for web content.

However, in 2010, Apple released the iPhone 4 with a Retina display. The main goal of that display was to make the output on the screen look closer to an actual photo and remove pixelation. The image below shows the clear difference between the Retina and non-retina display.

Images from Wikipedia

What was the significant change here?

Before the Retina display, you could refer to a device’s screen resolution to determine how wide your page or other content to be displayed should be. But with the advent of Retina display, the pixel now has two interpretations; hardware pixels and software pixels (CSS pixels).

Device manufacturers choose how many hardware pixels go into a CSS pixel, and this attribute is known as the device pixel ratio. For example, the Apple Retina display had a device pixel ratio of 2, meaning that one CSS pixel was equal to four hardware pixels (2 pixels in height and 2 in width).

The Galaxy S4 then took it up a notch with a device pixel ratio of 3, meaning one CSS pixel was equal to nine hardware pixels (3 in height and 3 in width). LG then dropped the G3 with a device pixel ratio of 4, which Samsung also adopted with the Galaxy S6.

We should remember that a CSS pixel is designed to result in the same size when the same content is being displayed on different devices with the same screen dimensions. Therefore, their differing device pixel ratios are responsible for the slight variations in the similarly sized content.

These variations manifest in the form of sharper text and icons, which you can easily notice at the edges of the characters and objects or any other part where contrasting colors border each other. The web browser will automatically render the content to output a suitable result in each case.

Support for DPI in HTML

There are two standard ways of accommodating your HTML markup for high DPI screens when using a tag with the srcset attribute. The first option is to use the DPI (x) descriptor when specifying the URL:

<img srcset="
        cheetah.jpg,
        cheetah-2x.jpg 2x,
        cheetah-3x.jpg 3x,
    "
     src="cheetah.jpg"
     alt="Cheetah"/>

In the example above, the image will have the same screen size on all devices, and a browser will pick the one that matches the user’s screen DPI. But what if we need an image to have different sizes on different screens? Say you want to have full width on mobile and 400px on the desktop.

In that case, we would need to go with the width descriptor in the srcset attribute:

<img srcset="
        cheetah-400w.jpg 400w,
        cheetah-500w.jpg 500w,
        cheetah-600w.jpg 600w,
        cheetah-800w.jpg 800w,
        cheetah-1000w.jpg 1000w,
        cheetah-1200w.jpg 1200w,
        cheetah-1500w.jpg 1500w,
        cheetah-1800w.jpg 1800w,
    "
     src="cheetah.jpg"
     sizes="
        (max-width: 768px) 100vw,
        400px
     "
     alt="Cheetah"
/>

Notice how many sizes we included? That’s because mobile devices are different in size and also in DPI. So for a 400px-wide screen, we would need to have three images; 400px, 800px and 1200px. A browser will work its magic to pick the appropriate image based on the visible image size, display characteristics and other factors.

By the way, picking the sizes for srcset can be quite tricky. On the one hand, you could look up devices or screen sizes using analytics tools and target them directly. You may find sizes like 390px wide for the iPhone 12, 393px for the Pixel 5 and 375px for the iPhone SE, among others.

However, this approach comes with some drawbacks. Firstly, you’d need to update sizes whenever a new device is released and becomes popular, which can be quite the hassle. Secondly, having too many variants could decrease your CDN cache hit ratio, meaning you won’t be leveraging the full power of network edges.

So rather than going with specific devices, we recommend sticking with ranges like 400, 500 and 600 pixels. If we open the Chrome web browser with the Developer console and select Samsung or iPhone 12 Pro, we will see that the browser will load the 1200 pixels version because the screen DPI is 3.

Images for High DPI displays

If we change the device to iPhone SE, the browser will opt for the 800 pixels version. On that note, let’s have a look at the sizes of the images loaded for 1, 2 and 3 DPI:

• cheetah-400w.jpg — 42 Kb
• cheetah-800w.jpg — 141 Kb
• cheetah-1200w.jpg — 298 Kb

Therefore, upon loading an image on a higher DPI display, the size of the image will also increase. This becomes a bigger concern when we understand that high DPI displays are often mobile devices on networks that might not always be as good as home broadband. So how can we make images load faster in such cases?

Delivering smaller images for High DPI screens

When discussing images, their sizes and the bandwidth used, it is crucial to understand what happens when you display the bigger image (1200px) on a smaller physical screen (400 screen pixels). The quality improves, as seen in the example from the intro.

However, there’s only so much detail the human eye can see when it comes to photos. Consequently, we can use more aggressive compression for displays with higher DPIs. So let’s encode our 3x variant with lower quality.

The 3x version is 154Kb, which is still greater than the 1x, but two times smaller than the original version. So, now that we know what we’d like to achieve, here’s how to proceed:

Load the larger version of the image on high DPI displays, but use lower quality. Unfortunately, this isn’t possible to implement with the tag at the moment. This is because we can’t mix w and x descriptors; otherwise, we’d do something like https://website.com/images/logo-800w-2x.png, with 800w and 2x in the srcset attribute to tell the browser what image to load.

Instead, we can use the <picture> tag with media selectors. Fortunately, there’s a resolution CSS media selector that we can use in this manner. But it may not be that easy, seeing as browsers like Safari still don’t support it. Nevertheless, there’s a similar solution known as the –webkit-device-pixel-ratio selector that is supported everywhere.

Accordingly, let’s take a look at how to combine it with the srcset attribute:

<picture>
  <source
      media="(-webkit-min-device-pixel-ratio: 2) and (-webkit-max-device-pixel-ratio: 2.9999)"
      srcset="
            q50/cheetah-400w.jpg 400w,
            q50/cheetah-500w.jpg 500w,
            q50/cheetah-600w.jpg 600w,
            q50/cheetah-800w.jpg 800w,
            q50/cheetah-1000w.jpg 1000w,
            q50/cheetah-1200w.jpg 1200w,
            q50/cheetah-1500w.jpg 1500w,
            q50/cheetah-1800w.jpg 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <source
      media="(-webkit-min-device-pixel-ratio: 3)"
      srcset="
            q40/cheetah-400w.jpg 400w,
            q40/cheetah-500w.jpg 500w,
            q40/cheetah-600w.jpg 600w,
            q40/cheetah-800w.jpg 800w,
            q40/cheetah-1000w.jpg 1000w,
            q40/cheetah-1200w.jpg 1200w,
            q40/cheetah-1500w.jpg 1500w,
            q40/cheetah-1800w.jpg 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <img
      src="cheetah.jpg"
      srcset="
            cheetah-400w.jpg 400w,
            cheetah-500w.jpg 500w,
            cheetah-600w.jpg 600w,
            cheetah-800w.jpg 800w,
            cheetah-1000w.jpg 1000w,
            cheetah-1200w.jpg 1200w,
            cheetah-1500w.jpg 1500w,
            cheetah-1800w.jpg 1800w
          "
      alt="Cheetah"
      sizes="(max-width: 768px) 100vw, 400px"
  >
</picture>

Now that looks better as we load lower quality images for screens with a DPI of 2 or 3, and even lower quality from 3 onwards. Nonetheless, I wouldn’t recommend this example in the production because it’s not leveraging next-generation formats like WebP and AVIF.

Now, that looks better, as we load lower quality image for screens with DPI 2 to 3 and even lower quality from 3 onwards

To add next-gen formats into the mix, we need to use the type attribute of the tag and add a separate source for every format. It’s important to remember that the browser will use the first source it can load, so we should start with AVIF, then go to WebP, and lastly, JPEG.

<picture>
  <source
      media="(-webkit-min-device-pixel-ratio: 2) and (-webkit-max-device-pixel-ratio: 2.9999)"
      type="image/avif"
      srcset="
            q50-avif/cheetah-400w.avif 400w,
            q50-avif/cheetah-500w.avif 500w,
            q50-avif/cheetah-600w.avif 600w,
            q50-avif/cheetah-800w.avif 800w,
            q50-avif/cheetah-1000w.avif 1000w,
            q50-avif/cheetah-1200w.avif 1200w,
            q50-avif/cheetah-1500w.avif 1500w,
            q50-avif/cheetah-1800w.avif 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <source
      media="(-webkit-min-device-pixel-ratio: 2) and (-webkit-max-device-pixel-ratio: 2.9999)"
      type="image/webp"
      srcset="
            q50-webp/cheetah-400w.webp 400w,
            q50-webp/cheetah-500w.webp 500w,
            q50-webp/cheetah-600w.webp 600w,
            q50-webp/cheetah-800w.webp 800w,
            q50-webp/cheetah-1000w.webp 1000w,
            q50-webp/cheetah-1200w.webp 1200w,
            q50-webp/cheetah-1500w.webp 1500w,
            q50-webp/cheetah-1800w.webp 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <source
      media="(-webkit-min-device-pixel-ratio: 2) and (-webkit-max-device-pixel-ratio: 2.9999)"
      srcset="
            q50/cheetah-400w.jpg 400w,
            q50/cheetah-500w.jpg 500w,
            q50/cheetah-600w.jpg 600w,
            q50/cheetah-800w.jpg 800w,
            q50/cheetah-1000w.jpg 1000w,
            q50/cheetah-1200w.jpg 1200w,
            q50/cheetah-1500w.jpg 1500w,
            q50/cheetah-1800w.jpg 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <source
      media="(-webkit-min-device-pixel-ratio: 3)"
      type="image/avif"
      srcset="
            q40-avif/cheetah-400w.avif 400w,
            q40-avif/cheetah-500w.avif 500w,
            q40-avif/cheetah-600w.avif 600w,
            q40-avif/cheetah-800w.avif 800w,
            q40-avif/cheetah-1000w.avif 1000w,
            q40-avif/cheetah-1200w.avif 1200w,
            q40-avif/cheetah-1500w.avif 1500w,
            q40-avif/cheetah-1800w.avif 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <source
      media="(-webkit-min-device-pixel-ratio: 3)"
      type="image/webp"
      srcset="
            q40-webp/cheetah-400w.webp 400w,
            q40-webp/cheetah-500w.webp 500w,
            q40-webp/cheetah-600w.webp 600w,
            q40-webp/cheetah-800w.webp 800w,
            q40-webp/cheetah-1000w.webp 1000w,
            q40-webp/cheetah-1200w.webp 1200w,
            q40-webp/cheetah-1500w.webp 1500w,
            q40-webp/cheetah-1800w.webp 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <source
      media="(-webkit-min-device-pixel-ratio: 3)"
      srcset="
            q40/cheetah-400w.jpg 400w,
            q40/cheetah-500w.jpg 500w,
            q40/cheetah-600w.jpg 600w,
            q40/cheetah-800w.jpg 800w,
            q40/cheetah-1000w.jpg 1000w,
            q40/cheetah-1200w.jpg 1200w,
            q40/cheetah-1500w.jpg 1500w,
            q40/cheetah-1800w.jpg 1800w
          "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <img
      src="cheetah.jpg"
      srcset="
            cheetah-400w.jpg 400w,
            cheetah-500w.jpg 500w,
            cheetah-600w.jpg 600w,
            cheetah-800w.jpg 800w,
            cheetah-1000w.jpg 1000w,
            cheetah-1200w.jpg 1500w,
            cheetah-1200w.jpg 1800w
          "
      alt="Cheetah"
      sizes="(max-width: 768px) 100vw, 400px"
  >
</picture>

And here it is! The snippet that will give us the best mix of quality and performance. It’s also worth mentioning that there’s no javascript involved. The downside is that we would need to prepare 48 variants of the source image. This is where an Image CDN can help.

Using an Image CDN to reduce the number of source images

With Pixboost as an example, let’s see how to produce all the required variants using an Image Processing API. Firstly, you’ll need to create a free account at Pixboost.com. Then, when you log in for the first time, add a new image source as in the video below.

Now, you can use the /resize API to produce all the needed sizes and next-generation formats.

<img srcset="
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=400&auth=MTA0ODU5NDA0NQ__ 400w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=500&auth=MTA0ODU5NDA0NQ__ 500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=600&auth=MTA0ODU5NDA0NQ__ 600w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=800&auth=MTA0ODU5NDA0NQ__ 800w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1000&auth=MTA0ODU5NDA0NQ__ 1000w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1200&auth=MTA0ODU5NDA0NQ__ 1200w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1500&auth=MTA0ODU5NDA0NQ__ 1500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1800&auth=MTA0ODU5NDA0NQ__ 1800w
    "
     src="cheetah.jpg"
     sizes="
        (max-width: 768px) 100vw,
        400px
    "
     alt="Cheetah"
/>

The above code will cater to different sizes and next-generation formats by using the Accept header. A browser will send a list of supported formats to the API, and Pixboost will choose the best one to use. The only missing part now is the additional compression on screens with DPI >= 2. Finally, we have our new API feature; the ?dppx query parameter.

API support for High DPI screens

The new ?dppx hint passes the screen DPI to the API, so we can perform optimizations based on its value.

Having a ?ddpx and not a direct quality gives us plenty of room to add more enhancements. We believe the end-user doesn’t need direct access to those configurations, which would become harder to support in the long run. The most recent example is the AVIF format that was introduced last year. It enables us to use much higher compression while keeping the same level of visual perception. We can also use different quality and types of compression for various kinds of images such as photos, illustrations and more.

To introduce ?dppx support into our HTML code, we still need to use the <picture> tag with media queries. But just like with the <img> example, we don’t need to specify a separate <source> for the next-generation formats.

<picture>
  <source
      media="(-webkit-min-device-pixel-ratio: 2) and (-webkit-max-device-pixel-ratio: 2.9999)"
      srcset="
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=400&dppx=2&auth=MTA0ODU5NDA0NQ__ 400w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=500&dppx=2&auth=MTA0ODU5NDA0NQ__ 500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=600&dppx=2&auth=MTA0ODU5NDA0NQ__ 600w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=800&dppx=2&auth=MTA0ODU5NDA0NQ__ 800w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1000&dppx=2&auth=MTA0ODU5NDA0NQ__ 1000w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1200&dppx=2&auth=MTA0ODU5NDA0NQ__ 1200w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1500&dppx=2&auth=MTA0ODU5NDA0NQ__ 1500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1800&dppx=2&auth=MTA0ODU5NDA0NQ__ 1800w
      "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <source
      media="(-webkit-min-device-pixel-ratio: 3)"
      srcset="
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=400&dppx=3&auth=MTA0ODU5NDA0NQ__ 400w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=500&dppx=3&auth=MTA0ODU5NDA0NQ__ 500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=600&dppx=3&auth=MTA0ODU5NDA0NQ__ 600w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=800&dppx=3&auth=MTA0ODU5NDA0NQ__ 800w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1000&dppx=3&auth=MTA0ODU5NDA0NQ__ 1000w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1200&dppx=3&auth=MTA0ODU5NDA0NQ__ 1200w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1500&dppx=3&auth=MTA0ODU5NDA0NQ__ 1500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1800&dppx=3&auth=MTA0ODU5NDA0NQ__ 1800w
      "
      sizes="(max-width: 768px) 100vw, 400px"
  >
  <img
      src="cheetah.jpg"
      srcset="
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=400&auth=MTA0ODU5NDA0NQ__ 400w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=500&auth=MTA0ODU5NDA0NQ__ 500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=600&auth=MTA0ODU5NDA0NQ__ 600w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=800&auth=MTA0ODU5NDA0NQ__ 800w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1000&auth=MTA0ODU5NDA0NQ__ 1000w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1200&auth=MTA0ODU5NDA0NQ__ 1200w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1500&auth=MTA0ODU5NDA0NQ__ 1500w,
        https://pixboost.com/api/2/img/http://www.midday.coffee/dppx-demo/cheetah.jpg/resize?size=1800&auth=MTA0ODU5NDA0NQ__ 1800w
      "
      alt="Cheetah"
      sizes="(max-width: 768px) 100vw, 400px"
  >
</picture>

And now, we have the perfect snippet for showing responsive images on the website.

Obsolete methods

Some time ago, there was an approach that relied on the screen DPR client hint to pick an image source, and the Content-DPR header would confirm the image device pixel ratio in such requests.

Where the Content-DPR value differs from the DPR value (the screen DPR isn’t the same as the image DPR), the Content-DPR would be used to ascertain the inherent image size and scale the image accordingly.

This approach used the most recent instance of the Content-DPR if the Content-DPR header appeared more than once in a message. But over time, there was a lack of consensus around Content-DPR, with many not seeing image resolution as a transport-level feature.

Therefore, the new approach was to specify the intrinsic resolution within the EXIF metadata. As we speak, Content-DPR is no longer supported by many browsers, while others are in the process of dropping it, and a few have only kept it for backward-compatibility reasons.

Conclusion

The web changed a lot once we were able to use our phones, tablets, fridges and other devices to access the internet. To deliver images with higher visual fidelity, we need to support screens with DPI > 2. However, for the internet to be more accessible, we need to cater to people without fast connections by sending them only the data they need.

We can achieve this goal by using higher compression on High DPI screens. Additionally, using an Image CDN comes with some practical long-term benefits such as:

• Making your processes more lightweight when storing only one source image
• Cleaning up your markup by removing the need for a separate source for the next-gen formats
• Future-proofing your image delivery with automatic support for new formats and features (it is vital to note that switching to formats like AVIF can enable you up to 80% more compression than JPEG offers without losing quality, which bodes well for your website’s performance)
• Content-sensitive compression — an Image CDN can automatically change the compression quality for each image based on what’s in the image. For example, images with fewer colors and less detail will be compressed a lot more than those that are rich in detail, color and other patterns. By doing so, you can strike the perfect middle-ground between quality and size for each image.

If you would like to discover the shortfalls in your web project’s image optimization and the extent to which they diminish overall website speed, you can use Google PageSpeed insights and zoom in on PageDetox.

Credits

The method and API design are based on the article written by the web performance god — Jake Archibald.

Optimising images for High DPI displays was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

PNG and JPEG are the two oldest image formats that web developers use to add graphics to their web pages. Web standards came a long way, and often we use next-generation formats, such as WebP/AVIF/JpegXL, to deliver an image to the end-user. But JPEG and PNG are still the source of truth most of the time.

In this article, I’ll explain why converting PNG to the next-gen format is not as straightforward and how we went about it.

It’s also the 1st of November, and very appropriate to talk about images!

https://twitter.com/HenriHelvetica/status/1455172402405679106

We use Go and MagickWand library in the code snippets. You can get the latest version of the library using ImageMagick docker image that I maintain.

Our opensource Image CDN “transformimgs” that is available on Github is using the approach from this blog, and it works quite well in production.

Let’s get to it!

PNG

Let’s see what the main difference between JPEG and PNG are and when we use each.

Firstly, PNG is a lossless format, meaning when you compress/uncompress the image it doesn’t change. This is like a ZIP archive that doesn’t change the source data after you extracted it. On the contrary, the resulting image is not the same when using JPEG. So, if it is important to display exactly the same image then PNG will be our choice. However, it’s rarely a requirement for the Web, rather we want our images to look good. JPEG could introduce visual artefacts to the image, and usually, the images with fewer details and colours are affected the most. Generally, it makes sense to use lossless compressions for sharp images with few colours. The examples could be logos, banners, illustrations. We’ll look at some examples in the next section

Secondly, PNG supports transparency. If you’d like to show a background of the page on some parts of the image then you make those parts transparent. The popular use case is product images on online shops.

Keeping the above in mind it shouldn’t be a problem to choose the format for the source image. Though, when we use modern formats to deliver the image, they support both lossy and lossless encoding, and we can pick which one to use.

So, here comes the problem:

When is it better to use lossy or lossless compression when converting PNG to the next generation format?

Lossy or Lossless?

Lossy compressed images are smaller compared to lossless, but they also might have visual artifacts and glitches. Let’s take a look at some examples.

We use ImageMagick with WebP format here because it’s supported by all browsers: magick image.png -define webp:lossless=[true/false] image.webp.

Example 1. Illustration

Original PNG image:

When converting to:

• lossy — 100Kb
• lossless — 108Kb

The difference is 8 Kb which is 3% of the original image. Now, let’s zoom in a bit and see what happened to quality:

The lossless version is the same as the original, and we could see that the lossy image became smoother and also have some artifacts around the red notebook and shadow from the sweater.

The conclusion for us here was — 8Kb doesn’t worth quality loss, and we would prefer lossless compression over lossy in this case.

Example 2. Photo

Let’s look at the other example where PNG used for transparency:

When converting to:

• lossy — 16Kb
• lossless — 143Kb

The difference here is 127Kb which is 46% of the original image.

Let’s compare zoomed-in fragments:

There is a visible glitch in the plant’s pot texture, but most likely it will be lost to a human eye due to the number of details and colours. The difference in the size is huge, and the verdict is lossy compression would be much preferable in this case.

After running the experiments above on the bunch of PNGs, the requirement distilled itself:

We would like to distinguish between photos and illustration/logos then use lossy compression for the first and lossless for the latter

Solution

After the brainstorming session, we tabled two conceptually different approaches:

1. Use machine learning (we are a startup after all). We have a good dataset, so we could train a model and use it. There are a few cons:

• We don’t have an ML expert on the Team.
• Deployment would be complicated. ML model + training and using it in the application.
• How do you fix bugs in it?
• What if it will break free and will take over our servers/planet??!!!

2. Write a boring algorithm (we are a profitable startup after all) that would use image statistics. There are some cons here as well:

• Might be less accurate
• Analysing images are memory and CPU intensive and could be a showstopper in the case of Image CDN where images should be processed in a reasonable time on the first request.

We decided to go with option number 2 and fallback to the first if performance will become a problem.

Implementation

The next two sections are all about technical implementation. TLDR: The code works and is currently deployed in production. You could jump to the results section if going through the walls of code is not your cup of tea.

Before diving into the implementation we picked different types of PNGs that we want to classify. Using them we wrote a table unit test:

Now, we need to make it green :)

After digging the Internet, we found a very good article on image classification using ImageMagick. There was a solution from Jim Van Zandt:

write out the color of every pixel

sort by color

write out the pixel count for every color

sort by pixel count

Work your way through the list until you have accounted for half the pixels in the image.

If #pixels »> #colors then it’s cartoon like.

We’ve also reached out to the ImageMagick community and had quite a few very useful suggestions in this discussion thread.

That was a good starting point, so we implemented the algorithm, but got mixed results. The original approach intended to work on cartoon images, however, we would also want to include illustrations that have more colours and could be more complex than drawings.

However, it felt that idea of looking at 50% of the image is a step in the right direction, but the stat we make the decision on doesn’t behave exactly as we wish. After several hours of digging deeper and looking at numbers, we figured that instead of comparing the number of pixels to the number of colours it would be better to compare the ratio of the number of colors needed for 50% divided by the total number of colours. Here is the first implementation:

It worked for all test images except for the cases with a background. What we wanted is to exclude background from our calculation. We wrote a simple algorithm that removes the background colour:

• If the most popular colour covers more than 10% of the image then assume it’s a background and ignore it

That solved our unit tests, and we were ready to take a new version for a spin on the bigger scale!

We downloaded 300 most popular PNGs that are currently optimised through Pixboost and ran them through the func. Then we compared results manually and made some minor tweaks to increase accuracy, which is now in between 98–99%.

Ready for production, we thought. However, we ran all the tests on powerful laptops and once moved to servers and put under the load we realised one thing:

It ate all the memory!

Performance

Image processing is a resource intensive task. The MagickWand library we use builds an in-memory tree(cube) to calculate image histogram (number of colours). The tree grows proportionally to the number of colours used. At first, we thought there was a memory leak, and we spent a lot of time trying to fix it. We failed in the end because there was no memory leak, but Golang and Linux are very smart on when to release memory of the process.

But we still had a memory problem to solve. We identified 2 hotspots where memory footprint increased dramatically:

• Images with a big number of colours. That was a case mainly with real-life photos that would have 60k+ colours. What we also found is that PNG compression works poorly on those and, we could find them by calculating a ratio between a number of bytes and pixels:

if float32(len(imgData))/float32(imgWidth*imgHeight) > 1.0 {
	return false, nil
}

• When we process a medium size image (1000x1000) with not too many colours (under 5k) the memory consumption would still be high (more than 1Gb). We solved that problem, by downscaling images to 500 pixels wide before extracting a histogram:

err := mw.ReadImageBlob(imgData)
if err != nil {
	return false, err
}

if imgWidth*imgHeight > 500*500 {
	aspectRatio := float32(imgWidth) / float32(imgHeight)
	err = mw.ScaleImage(500, uint(500/aspectRatio))
	if err != nil {
		return false, err
	}
}

colorsCnt, colors = mw.GetImageHistogram()

We’ve also added a few more optimisations that helped us to reduce the execution time and memory consumption further. Here is the final result that you could also find on Github:

The code we ended up with is straightforward which means it will be easy to maintain and improve in the future.

At the end of the day, we still had to bump the type of instances in our clusters from 8 to 16Gb which made everyone happy.

Results

In the greater scheme of things PNGs only account for 5% of all Pixboost traffic, but:

• We believe in accessible Web and doing a poor job on one format makes it not
• We have few customers that heavily use PNG images
• 5% of our traffic is still about 20Gb daily and growing.

Once released a canary version to production, we ran 2 tests on different data sets that again included the most popular processed images. We compared the current production version output with a new one:

• 350 PNG images
• 202 images became smaller and 47 larger
• The overall size of optimised images dropped from 21Mb to 8.5Mb which is 3x better compression!
• The response time dropped by 2%.

Converted PNGs became 3 times smaller.

• 500 mix of PNG and JPEG images
• Overall size dropped from 45.7Mb to 43Mb which is 5% improvement
• The processing time dropped by 5%

Conclusion

It’s been fun working on this feature which involved a lot of discovery, testing and performance tuning. After all, our main goal is to deliver the best images to the users, and we could accomplish it in this case. Happy days and we look forward to improving the service further.

And you could all try it yourself using our Open Source version or SaaS offering!

Choosing between lossy and lossless conversion for PNG was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Images have come to dominate the Internet. Most of today’s websites are comprised of 50 to 80 percent images. Here at Pixboost, our mission is to optimize images, making them as small as possible so that we can serve them to our users as fast as possible.

So we were excited to begin implementing the new image format, AVIF, which is supported in the latest version of Chrome (86), and which will be supported in the next version of Firefox. AVIF also has significant corporate support, in fact it’s championed specifically by Netflix. In this post, I’ll briefly cover the current state of web image formats and then I’ll do a comparison to show how AVIF enables pages to load faster.

Image Types and Formats

There are two fundamental image types: raster and vector.

Vectors are the type you would use to create geometric primitives like lines, circles, rectangles, etc. They are mathematically based so can be scaled to an infinite size. Vectors also support text, so they tend to be used for things like icons and logos. The most popular file format for vectors is SVG, but we won’t be expanding upon that format in this post :).

Raster images on the other hand are made up of pixels (points), with each pixel having its own color. Graphics and photos tend to be raster, and the most popular raster file formats on the web are JPEG and PNG. The JPEG format is good for photos because it compresses them with some quality loss, but significantly reduces file sizes. The PNG format maintains complete quality and supports transparency, but doesn’t reduce file sizes as much. So from a practical perspective, JPEG is used in most cases and PNG is used primarily when transparency is required.

Then there’s WebP, a relatively new format developed about 10 years ago that is now supported by most browsers. Generally speaking, if you convert a JPEG or PNG image to a WebP image, the resulting file size will be 30% smaller and there will be no loss of quality. Nice, right?

However, AVIF, the new kid on the block, pushes the envelope even further for web developers. It compresses images better than WebP with the same quality!

File sizes: AVIF vs WebP vs PNG/JPEG

We ran tests using our clients’ images. We picked 500 of our most popular images and ran them through our /optimise endpoint with the following output formats: the original format (PNG/JPEG), WebP, and finally AVIF.

Here are the results:

• In 93% of cases, the AVIF image was smaller than the WebP image
• On average, the AVIF image was 47% smaller than the WebP image
• The WebP image was smaller than an optimized PNG/JPEG image in 99% of cases
• On average, the WebP image was smaller than the PNG/JPEG image by 33%

So from these numbers, we can suggest the following best practices with respect to raster formats on the Web:

• Use AVIF if it’s browser supported, else
• Use WebP if it’s browser supported, else
• Use PNG or JPEG

Let’s take a look at one specific example. Here’s the source image:

But what is the catch? Basically, AVIF is far more expensive to encode. It’s an extremely taxing process with respect to both CPU and memory. Using the same image set as above, we compared the required length of time to optimize images using WebP and AVIF, respectively. To process the 500 total images, it took:

• 391 seconds to load all of the WebP images
• 919 seconds to load all of the AVIF images

So that’s 2.5 times as long for AVIF, although the calculation included the time to download the images as well. When we compared just the CPU time to convert the images, we found that it took seven times more CPU time to convert AVIF vs. WebP.

Memory wise, when encoding a 1000x1000 image, the process consumed around 1GB of RAM.

But we also need to keep tooling in mind: it’s still early days for AVIF and so processes haven’t been optimized for it as they have been for WebP (for which it is possible to pick various performance options).

How would I use it?

In HTML, you can do as follows:

Or if you use an image CDN (like Pixboost), it’s as simple as one line:

But if you aren’t using an image CDN, you would need to convert your source image into an AVIF, so let’s have a look at the tools you could use for that.

Tools that support AVIF encoding

As I write this article in November 2020, it’s still early days for AVIF, so there aren’t currently a lot of options for using it.

But here are some of the existing ones:

• ImageMagick: AVIF files have been writable since version 7.0.8. If you know Docker, you can use this image that I’m maintaining. ImageMagick has quite a powerful CLI, so you could easily automate AVIF conversion if necessary.
• Squoosh is a web app that lets you upload an image and then choose the formats to which you’d like to convert it. It’s quite powerful with a lot of settings, but doesn’t allow you to do batch processing, so you would need to convert each image individually.

Supporting AVIF in the Pixboost Image CDN

Pixboost was one of the first image CDNs to introduce AVIF. Our API doesn’t require you to manually choose an image’s target format, but rather automatically selects the optimal format on a case-by-case basis. So if a client (web browser) supports AVIF, then generally an AVIF will be served. Pixboost uses Accept HTTP header to determine supported formats.

Let’s imagine that you have an image on your website that you currently serve as follows:

To leverage the full power of AVIF with Pixboost, you can simply wrap the source URL like so:

From this moment on, your image will be served in the optimal format!

Note that we currently have two limitations with respect to AVIF files:

• Source images cannot be larger than 1024x1024 pixels, which is related to memory consumption. We are working on a solution for this and will have it fixed soon.
• Transparent source images aren’t supported at the moment. This was a limitation of ImageMagick, which is used by Pixboost on the backend. ImageMagick actually already merged our pull request related to the issue, though, so we just need to update to the new version on our side. This will be done in the coming weeks.

Conclusion

AVIF is a great addition to the Web, and I think it’ll soon see wide adoption since in most cases, it produces images that are much smaller than the JPEG/PNG/WebP formats. After all, smaller website images allow you to support users with slower Internet connections and also have a positive impact on SEO.

But at the moment adding AVIF support is a bit of a hassle. However, you can avoid the hassle by simply using a third-party service like the Pixboost CDN. By the way, if you’d like to learn more about the AVIF format, I’d highly recommend watching this video by Google engineers:

Load Your Images Faster with the Next-Gen AVIF Format was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Google released a statement about updates to its search ranking. It all goes back to Core Web Vitals and how they affect user experience. The other thing to note you won’t need the AMP version of your page to be featured in mobile’s search “Top Stories” feature which is a step forward in my mind!

We covered Core Web Vitals last time, and it’s getting more popular with more tooling becoming available. There is a Chrome plugin now that could give you instant scores for the page. There is also a new article about how you can measure core web vitals for your site right now.

@dev_starikov wrote an impressive piece on CSS animations and how some time you’d need to decide between visual and performance.

@DebugBear did fantastic research on Chrome Extensions and how they contribute to the Web performance. Have a look and think of replacing the slow ones! What I also found is you could disable auto load for some of the extensions, so you would need to click on it to activate it. For instance, I could do that for LastPass.

Apple released a beta version of Safari 14 with some significant features added. For me, WebP and HTTP/3 support are the most remarkable. But there are many more here.

Houssein Djirdeh made an outstanding web app called “Perf Track”, which shows how different web frameworks perform. The app could be a great input for your new project when you can’t decide what framework to use :)

Native images lazy loading gets some improvements in the latest Chrome release. So far we were still recommending using intersection observer with JS for lazy loading but looks like this is going to change soon.

Stay safe, Pixboost Team.

Web Performance News, July 2020 was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey there,

There were some big announcements and updates in May. Let’s dive into it!

The new major version of Lighthouse has been released. TADAAM! Lighthouse is one of the most popular tools to measure web performance. In the link above you’ll find what’s changed and why the score is different now. There is also a new version of Lighthouse CI available and we updated the docker image that we use to run tests continuously on pixboost.com.

Google did a GOODle and released a new set of metrics that impacts users the most. They called them Web Vitals. The core set includes just 3 items that you are measuring on the real users opposed to synthetic metrics from tools like Lighthouse. I really love an idea of simplifying the web performance and making it accessible for everyone: “Site owners should not have to be performance gurus in order to understand the quality of experience they are delivering to their users. The Web Vitals initiative aims to simplify the landscape, and help sites focus on the metrics that matter most, the Core Web Vitals.”. If you are interested in the story behind the metrics then you’ll find this link interesting.

@hdjirdeh and @addyosmani wrote about optimising First Input Delay (FID) metric. Worth to mention that it’s one of the metrics from Core Web Vitals. You’ll find good advice on how to tame JS execution on your web pages.

Keeping subject of metrics hot @nicpenam did an amazing job by creating a website with links to useful docs from Chromium Speed Metrics team!

Chromium launched a new way of blocking ads that consumes too much resources on your device. This will eventually land on Chrome around August. I think this is a good step forward to make the Internet a better place.

Tim Kadlec wrote an awesome piece on “The Cost of Javascript Frameworks”. In the article he is using the real numbers from HTTP Archive to compare the big 4 — JQuery, React, Angular and Vue.js. The questions in conclusion are right on point and I enjoyed reading the blog. Sadly said, in my experience performance becomes important only once the first release is shipped. We need to change this mentality! And to add to this @scottjehl posted a tweet that shows a stat with median web page size on the Internet just passed 2MB:

Scott Jehl on Twitter

According to httparchive, March marked the first time the median webpage size surpassed 2 megabytes... a big (but not necessarily good) milestone. Good to also keep in mind that many (most?) of the popular sites on the web are heavier than that median. https://t.co/CsrOCFNkbm

That’s it for today. Stay safe and load fast!

You could also subscribe to this newsletter to receive a copy on your email.

Web Performance News, May 2020 was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey there,

We skipped March because it was crazy! Our priority was to keep ourselves and close ones safe. We hope that all the curves will be flattened soon!

We’ve got quite a few blogs and videos in our April edition. So, let’s check them out!

One of the biggest web performance events is #PerfMatters Conference and it happened in April! It was fully remote this year, and you could find pretty much every video on youtube using “#PerfMatters Conference 2020” search term. My favourites so far are

Responsive Images for the Web by @TheGreenGreek:

Understanding Cumulative Layout Shift by @anniesullie:

@robinrendle created a neat web performance checklist that you could find and use here. I found it quite comprehensive and detailed! Highly recommend using for your every web project!

A New major version of Lighthouse is coming, and things are going to change! Read this awesome blog by @fox about scoring algorithm changes.

@tunetheweb published a very detailed article on why you should set width and height on your images and how to avoid layout shifts.

This is not an article, but a new feature in Chrome Dev Tools, which I think is very important — you can now simulate different types of colour blindness!

Mathias Bynens on Twitter

New accessibility feature in @ChromeDevTools: simulate vision deficiencies, including blurred vision &amp; various types of color blindness. 🔥 Find out how people with vision deficiencies experience your web app, and resolve contrast issues you didn't even know you had! https://t.co/QKLQmEhhMM

That’s it for today. I hope you liked it. To not miss future releases subscribe on our email newsletter here.

Web Performance News, April 2020 was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi there,

I’m pleased to announce today a new feature that we released last week — connecting AWS S3 bucket to your Pixboost account!

So, why would you want to do that? Before we implemented this feature, the way to use Pixboost with S3 bucket was to make S3 bucket public and use public URLs with Pixboost API. For instance, if all your images are in a bucket called “bucket-with-images” in the Australian region (ap-southeast-2) then Pixboost API call would look like:

https://pixboost.com/api/2/img/https://s3-ap-southeast-2.amazonaws.com/bucket-with-images/image.png/optimise?auth=your-api-key

And this is a fine way of doing so. However, there could be some legitimate security concerns with the approach above:

• An attacker could see a bucket name from the URL
• The bucket must have public access turned on

In many enterprise organisations, there is a taboo on public S3 buckets. And that’s a good thing — there is no “too much” security if you deal with personal or financial data! So, let’s draw the solution we came up with:

Using the schema from the picture above, we solved both problems that we had:

• We use an alias instead of direct URL, so the name of the bucket is not a part of API call
• Pixboost is using separate IAM user to access the bucket, so it doesn’t need to have public access

Now let’s see how to connect S3 to your Pixboost account.

Setting up

AWS

We assume that you already have S3 bucket with your images stored there. If not, then you can read how to do that here.

To set up a new user that you’ll integrate with Pixboost:

• Create a new IAM user
• Add new credentials for the user.
• Update or create a bucket policy and give the user s3:ListBucket and s3:GetObject permissions.

Below is an example of a bucket policy:

Pixboost

1. Once you log in, there is a new panel called “Images Sources”. That’s where all your integrations will be! Click on “Add source”.

2. Select “Amazon AWS S3 Bucket” in “Type” dropdown and fill in the details

Let’s quickly go through each field and see what it’s for:

• Alias is a unique identifier of the source that will be used in the URL when calling API
• Bucket name is the name of a bucket
• Region is an AWS region ID of the bucket
• Path Prefix is an optional prefix that will be used for all requests. It could be used if all your images in the bucket stored in one folder. In that case, you could set “Path prefix”, and you won’t need to add it to each API call.
• Access Key is an AWS IAM user’s access key created in the step above.
• Secret Key is an AWS IAM user’s secret key created in the step above

3. Click “Add”, and you are done!

Testing

The last but not least step is testing! So, let’s fire up an API call and check that integration works:

https://pixboost.com/api/2/img/bucket/<PATH_TO_THE_IMAGE>/optimise?auth=<API_KEY>

In response we should see our optimised image.

What’s next?

It’s worth mentioning that we developed not just S3 integration but “Images Source“ abstraction that allows us to easily plugin other types of sources. Stay tuned as we are going to release more integrations very soon!

Connect private AWS S3 bucket to Pixboost was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey there,

February was a real storm of exciting things around web performance. So, let’s go straight to it!

Performance Budgets, Pragmatically- @csswizardry wrote a short, but very practical guide about where to start with performance budgeting and how to come up with the initial numbers.

Should you self-host Google Fonts? — That’s a very detailed guide written by @tunetheweb on how Google Web Fonts loading works and all pros and cons around self-hosting those and cutting on their load time. We are currently thinking of doing so on Pixboost website, but in the “test test test” phase right now :)

Web Performance: 11 Must-Read Tips to Give Your Site a Speed Boost — @oliverlindberg wrote a perfect practical intro about what to look at when starting to deal with web performance. And guess what? Optimizing images and lazy load images are on 3rd and 4th places. I would recommend going through the article if you’d like to speed up your website.

Videos from FOSDEM Web Performance Dev Room — FOSDEM 2020 took place on 1st and 2nd of February this year, and there was a separate dev room for web performance! All the videos are available! I would highly recommend watching all of them. My favourites are on OpenSpeedMonitor (it’s fantastic, check it out!) and HTTP resource prioritization.

HTTP/3 for everyone — @bagder published a video, slides and wrote a quick intro from his awesome talk at Fosdem this year. HTTP/3 is coming, and I would recommend everyone in the Web industry to start looking and understanding what it is.

Six web performance resolutions for the new year — if you work in a big organization and wondering how to justify spending money on web performance then this article from @SpeedCurve is for you!

Innovation Can’t Keep the Web Fast — @malchata wrote an excellent post on how technologies are getting better and yet we are still building slower websites and hoping that 5G and HTTP/3 will fix them.

Demystifying Browsers — if you ever wondered how web browsers work, where their source code is who is building them then @ericlaw got you covered! This post has all the links starting with comics about Chrome and ending up with a list of twitter accounts of core developers.

SSL certificates and web performance — @TheRealNooshu and @aaronpeters wrote two blogs about SSL certificates and how they affect web performance. You’ll find what types of certificates are used now and how they are different when browsers are verifying them — “The impact of SSL certificate revocation on web performance” and EV Certificates Make The Web Slow and Unreliable

And here is some browser updates from the trenches:

Safari will support width/height based aspect ratio for images — the change has already landed into WebKit, so should be available soon in Safari. The change will allow avoiding unnecessary layout reflows on the page. Watch this video for more information about the feature — https://www.youtube.com/watch?v=4-d_SoCHeWE

This is it for today, stay tuned and subscribe to our email newsletter here.

Web Performance News, February 2020 was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aloha everyone!

While some of us were resting during the festive season (totally me), others were writing blog posts! December and start of January were hot on good content. So, let’s get ball rolling:

Google planning a new ‘Badge of Shame’ for slow websites — MachMetrics wrote about plans that Google has in regards to introduce an indicator for slow/fast websites. In this blog, you’ll find the author’s thoughts and links to the various discussions in the community.

Getting Started with Web Performance — @fox wrote a fantastic intro to “Web Performance”. If you are new to the subject and wondering what it is all about, then you should check it out.

Front-End Performance Checklist 2020 — Smashing Magazine released its front end performance checklist 2020 editions. It covers all aspects of web performance from A to Z. I would recommend reading the whole thing for anyone who is touching web dev.

How to read a WebPageTest Waterfall View chart — @TheRealNooshy wrote an in-depth guide on waterfall charts that you get from WebPageTest. If you haven’t used webpagetest.org before, it’s a good time to start! It’s the essential tool in the web performance toolbox.

High Performance Web Apps — @orenciorodolfo wrote a blog about how browsers are rendering the page, what is “Critical Rendering Path” and what you could do to start showing your page faster. I found this one to be very explanatory with amazing illustrations. It describes complex things in a straightforward and clear way.

Improving third-party web performance — @digitalclubb shared slides from the presentation he did. You’ll find out what processes you need to introduce in your project to get 3rd party dependencies under control.

Some other news:

Correct Image Orientation in Chrome — @Paul_Kinlan announced that image orientation bug got fixed and will be shipped in version 81 of the browser. Long story short, Chrome will use orientation from an image EXIF metadata to show if it’s not set in image-orientation CSS attribute.

This is it for now. Follow us on Medium or subscribe to the email newsletter to not miss new episodes!

Stay safe and load fast!

Web Performance News, January 2020 was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.

The festive season is on its way, so, to save you from boredom while away from a keyboard, we are sending you a December edition of our Web Performance Newsletter.

Important update — to not miss a new edition of this newsletter you can now subscribe to it. We are planning to send a new one every month or two.

We don’t have much experience with newsletters and your feedback is very important for us. If you have any suggestion or found a typo, please drop me a line at dmitry.pokidov@pixboost.com.

And here we go!

• @simonhearne wrote his #webperf prediction for 2020: https://simonhearne.com/2019/2020-predictions/. Definitely, have a look, there are some surprises there! I could only guess Web Assembly :)
• @stoyanstefanov published 2019 Web Performance Calendar again! I would like to recommend to read each and every post from it, including previous years — https://calendar.perfplanet.com/2019/. My favourite is about images, of course — https://calendar.perfplanet.com/2019/the-ugly-truth-about-optimising-beautiful-images/.
• Instagram Engineer @mr_sharpoblunto wrote a series of posts about making instagram.com faster: Part 1, Part 2, Part 3, Part 4.
• HTTPArchive published the 2019 edition of their Web Alamanac. They tested 5.8 millions of websites and collected all the facts about them. For instance, did you know that almost half of the requests are still using HTTP/1.1?

Some industry news that we found important:

• This one is a biggie — Safari now supports Intersection Observer! Intersection Observer is a relatively new Web API for lazy loading content on the page. At Pixboost we are using it in our pixboost.js and pixboost-react libraries. My biggest problem with Intersection Observer was a polyfill that is quite buggy and most of the time we preferred to not use lazy loading at all if Intersection Observer was not available on the browser.

• Safari has just implemented Intersection Observer API, but there is a new version of spec coming: https://developers.google.com/web/updates/2019/02/intersectionobserver-v2. The latest version is not a full rewrite, but adding some additional functionality to better track visibility of the elements.
• Chrome is implementing a change to calculate image dimensions before loading it so that page layout won’t be affected. Worth to mention that Firefox already has this upgrade. To be ready just add width and height attributes to your <img> and <video> elements. Google Group discussion and explanation from @jensimmons:
• In case you missed it, Google is using page speed as a ranking factor on the mobile search since 2018. Here is a quick summary of how that decision influenced the Web so far.

Web Performance News, December 2019 was originally published in pixboost on Medium, where people are continuing the conversation by highlighting and responding to this story.