How to fix the “Properly size images” issue

“Properly size images” is among the most frequent recommendations suggested by Google’s web performance analysis tools. Does this advice appear when you test your page with PageSpeed Insights or Google Lighthouse? This guide will help you estimate the priority of this issue — and explain how it should be addressed.

Let’s take a concrete example: a category page on the official e-commerce website of Jimmy Choo, a major luxury fashion brand from the UK.

The Google PageSpeed Insights analysis shows that the page has failed the Core Web Vitals assessment based on field data from real users.

The tool then provides a report of the page’s synthetic testing. This helps identify the performance killers. (This part of the audit is powered by Lighthouse - Google’s open-source solution for synthetic website testing).

Here is the audit for the mobile experience:

The tool detected 6 opportunities to improve web performance:

According to Google Lighthouse, the greatest potential improvement is fixing the “properly size images” problem. The tool’s estimation of 5.7 seconds of potential savings of load time should be taken with a grain of salt. But qualitatively, this relatively high estimate is a strong indication that this aspect is the top priority to improve the page’s user experience.

The “Properly size images” warning tells that some of the page’s images are served with significantly larger dimensions than needed for rendering on the user’s screen. It is a bad thing because:

• The image takes a longer time to load, as it is too heavy
• The browser would spend additional time to resize the image (the lag depends on the CPU power of the user’s device)
• The resulting visual quality might suffer, as the resizing algorithms of the browsers are usually optimized for speed at the detriment of quality

In our case, the tool signals a problem with the four category images. We will take the first one as an example for the rest of this guide.

What triggers the “Properly size images” warning?

To be more precise, Google Lighthouse analyzes the page experience on a typical mid-tier mobile. As of January 2023, the emulated device is a Moto G4 smartphone. Its screen has a device pixel ratio of 3. This means that its logical CSS pixel consists of 3x3 physical pixels. The screen is 360 CSS pixels wide.

Our page’s CSS context implies that on mobile devices each category image occupies 100% of the viewport with a 1:1 aspect ratio.

On a Moto G4 the category image occupies the space of 360 x 360 logical pixels. This is called the image’s rendered size.

The DPR 3 screen has enough physical pixels to display fine detail of an image dimensioned up to 3 times the rendered size. Anything above this resolution would waste bandwidth without improving quality.

Therefore, a 1080 x 1080 pixels resolution is the maximum recommended for a category image for Moto G4.

(Please note that in practice, even this “maximum recommended size” might be overshot. Over 90% of humans don’t see a difference between DPR 3 and DPR 2 on mobiles. It makes sense to cap the adjustment for density pixel ratio to DPR 2).

A quick look on the page with Chrome Developer Tools shows that Jimmy Choo makes mobile users load a 1904 x 1904 pixels category image.

To see that:

1. Open the page in Chrome browser
2. Right click on the image you want to check
3. Click on Inspect
4. You see the Chrome Developer tools interface where you can check how the page renders on different devices. Choose the desired device. It’s Moto G4 in our context.
5. The right part displays the page’s HTML code. Hover on the src attribute of the image to see its rendered and intrinsic sizes on this device)
6. The rendered size 360 x 360 pixels (marked with red underline), and the intrinsic size is 1904 x 1904 pixels (yellow underline)

This 1904 x 1904 pixels intrinsic size of the category image is way larger than the maximum recommended size of 1080 x 1080 pixels.

Other things being equal, this difference in pixel count makes the larger image 3.1 times heavier. The audit reports the culprit image weight as 421.3 KiB, out of which at least 317.6 KiB could be saved by serving an adequately-sized version to the mobile devices.

More generally, the “Properly size images” warning is issued each time Google Lighthouse detects a discrepancy between the maximum recommended and the intrinsic sizes of the image of over 4%.

What should be done?

The solution to the “properly size images” problem lies in serving differently sized versions of the image for mobiles, tablets, and desktops. Ideally, you’d need to prepare for the modern diversity of screens with the resolution ranging from 320px to 4K, as well as varying density pixel ratios.

Your goal is to make the intrinsic size of the image version to be loaded as close as possible to the rendered size, corrected for the DPR.

There are multiple ways to implement such responsive image optimization.

You could use the srcset and sizes attributes of the <img> tag to let the browser choose the most appropriate version of the responsive image to load. Such native responsive images are best for images above the fold (so-called "critical images"). This optimization technique is described here.

The more variants you specify, the more efficient the responsive image optimization would be — but this comes at a cost of additional complexity. This complexity might increase exponentially as you also need to comply with the other best practices (conditional delivery in next-gen formats, etc), and art direction.

Below we will propose an approach that sets the developers free from this error-prone and time-consuming task.

Use TwicPics for hands-free and pixel-perfect optimization of responsive images.

This approach is hassle-free — and yet the most precise one. You can achieve automatic pixel-perfect resizing of your responsive images by delegating their optimization and delivery to TwicPics.

It is enough to specify a single high-resolution master image and makeTwicPics take care of the rest. The lightweight frontend script by TwicPics understands each user's device context (screen size and aspect ratio, DPR, formats supported by the browser) and sizes the images to the pixel according to any responsive behavior implemented in your HTML and CSS.

This is as simple as replacing the initial code of our example’s image:

<img src="bag.jpg" alt=”bag”/>

with:

<img data-twic-src="image:bag.jpg" alt=”bag”/>

The optimizations are also available out-of-the-box with TwicPics Components for Angular, React, Gatsby, Next.js, Svelte, Vue.js, Nuxt.js, or native Web Components.

In the case of our example, TwicPics would serve:

• A 540 x 540 image to a user on Samsung Galaxy S4 (360 pixels wide screen, DPR 1.5)
• A 720 x 720 image to Moto G4 user (360 pixels wide, high-DPR screen)
• An 820 x 820 image to a user on an iPad Air (820 pixel wide DPR 2 screen; the page’s template makes the image occupy half of the viewport on tablets and desktops)
• A 1440x1440 image to a Macbook Pro (a 1440px screen, DPR 2). Note that, by default, the solution caps the adjustment for device pixel ratio to DPR 2, although you can specify otherwise.

Moreover, TwicPics helps you comply with the other web image best practices suggested by PageSpeed Insights:

• Serve images in next-gen formats. TwicPics converts the image and serves it in the webp format whenever it is supported by the user’s browser. This lossless compression saves around 20% more bandwidth
• Defer offscreen images. By default, TwicPics will load marked images only when needed. You’ll be able to achieve a particularly fluid experience by combining lazy-loading with the out-of-the-box implementation of lightweight image placeholders.
• Efficiently encode images
• Avoid enormous network payloads
• Serve static assets with an efficient caching policy