DEV Community: Manu Chaudhary

Extending Lighthouse for custom image and video optimization analysis

Manu Chaudhary — Tue, 26 Nov 2024 04:57:20 +0000

Optimizing website performance is critical for delivering seamless user experiences and achieving better search rankings.

While tools like Google PageSpeed Insights and Lighthouse are popular choices for performance analysis, they often fall short in addressing video content, offering only generic recommendations such as "Avoid enormous network payloads".

We faced this challenge when we wanted to develop a tool that could evaluate both images and videos. Specifically, we aimed to detect whether videos were encoded using next-generation codecs like VP9 or AV1.

So, we extended Lighthouse by creating a custom audit—and surprisingly, the process was quite straightforward.

Before diving into the details of the custom audit, let’s explore how ImageKit’s Website Performance Analyzer simplifies media performance evaluation.

How Website Performance Analyzer Works

The ImageKit Website Performance Analyzer is a free tool designed to evaluate both image and video content on your website. It generates detailed audit reports for both mobile and desktop versions, scoring websites based on key performance metrics.

Key Features

Device Emulation: Simulates real-world performance by replicating both mobile (e.g., Moto G Power) and desktop environments, allowing for accurate assessment across different devices and screen sizes.
Comprehensive Overall Media Audit: Analyzes images and videos on your site to uncover issues such as missing size attributes, non-responsive or improperly sized media, lack of lazy loading, and the absence of next-generation formats like AVIF or WebP. Provides actionable insights to optimize media performance.
Video-Specific Analysis: Identifies whether videos are encoded using advanced codecs like VP9 or AV1 to enhance playback efficiency, reduce bandwidth usage, and improve performance across modern browsers.
Performance Scoring: Assigns detailed performance scores based on weighted factors, helping prioritize key areas for optimization.
Automated Monitoring with Weekly Alerts: Sends weekly email reports that summarize your website’s media performance. Quickly fix potential issues with these automated alerts.
Historical Data Tracking: Tracks and analyzes your site's performance metrics over a 90-day period, offering insights into trends and enabling continuous improvement for a better user experience.

Here’s what a sample report looks like:

The analyzer’s detailed feedback empowers you to make targeted optimizations, resulting in faster websites and better user experiences.

Internals of ImageKit's Website Performance Analyzer

To evaluate media performance, the analyzer uses weighted scoring for the following audits:

Audit	Weightage	Why It Matters
Unsized Images	5	Prevents layout shifts by ensuring explicit `width` and `height` attributes.
Responsive Image Sizing	5	Ensures sharp images by serving sizes proportional to display dimensions and DPR.
Properly Sized Images	25	Avoids oversized images, reducing bandwidth usage and load times.
Deferring Offscreen Images	10	Lazy-loads non-critical images to improve perceived page load speed.
Modern Image Formats	20	Promotes WebP and AVIF, which reduce file sizes without quality loss.
Optimized Image Encoding	15	Efficient compression accelerates load times and saves data.
Efficient Animated Content	10	Encourages replacing GIFs with video for better performance.
Modern Video Formats	10	Detects VP9/AV1 codecs to ensure optimized playback and bandwidth efficiency.

Most of the audits listed above are standard, except for Modern Video Formats.

Creating a Custom Lighthouse Audit for Video Performance

Lighthouse allows extending its capabilities with custom audits. We leveraged this to create an audit that detects whether videos are encoded in next-generation formats like VP9 or AV1.

How It Works

The audit examines network requests to identify video files and checks if their MIME types match modern formats (e.g., WebM). If outdated formats are detected, the audit flags them and provides actionable feedback.

Here’s how you can implement it:

Step 1: Define the Audit Class

The audit class extends Lighthouse's Audit class. It defines metadata and the evaluation logic.

const { Audit } = await import('lighthouse');

class VideoOptimizationAudit extends Audit {
    static get meta() {
        return {
            id: 'modern-video-formats',
            title: 'Serve videos in modern formats',
            description: 'VP9 and AV1 offer better compression compared to H.264.',
            requiredArtifacts: ['devtoolsLogs'],
            scoreDisplayMode: Audit.SCORING_MODES.BINARY,
        };
    }

    static audit(artifacts) {
        // Audit logic goes here
    }
}

module.exports = VideoOptimizationAudit;

Step 2: Implement Audit Logic

The audit evaluates network requests to find videos and checks their MIME types.

static audit(artifacts) {
    const networkRequests = artifacts?.devtoolsLogs?.defaultPass?.filter(item => item.method === "Network.responseReceived") ?? [];

    const videoRequests = networkRequests.filter(item => {
      return item.params.response.mimeType.includes("video");
    });

    // Analyze if video mimeType is not webm
    const _nonOptimizedVideos = networkRequests.filter(item => {
      return item.params.response.mimeType.includes("video") && !item.params.response.mimeType.includes("webm");
    });

    // Unique videos based on item?.params?.response?.url because of multiple range requests for same video
    const nonOptimizedVideos = _nonOptimizedVideos.reduce((acc, item) => {
      if (!acc.find(video => video?.params?.response?.url === item?.params?.response?.url)) {
        acc.push(item);
      }
      return acc;
    }, []);

    const score = nonOptimizedVideos.length === 0 ? 1 : 0;

    let displayMessage;

    if (videoRequests.length && nonOptimizedVideos.length) {
      displayMessage = `${nonOptimizedVideos.length} non-optimized videos found`;
    } else if (videoRequests.length && !nonOptimizedVideos.length) {
      displayMessage = "All videos are optimized";
    } else {
      displayMessage = "No videos found";
    }

    return {
      score,
      displayValue: displayMessage,
      details: Audit.makeTableDetails(
        [
          { key: 'url', label: 'Video URL' }
        ],
        nonOptimizedVideos.map(video => ({
          url: video?.params?.response?.url,
        }))),
    };
  }
}

Step 3: Register the Audit

Include the custom audit in the Lighthouse configuration.

module.exports = {
    extends: 'lighthouse:default',
    audits: ['modern-video-formats'],
};

Save the file as modern-video-formats.js and run Lighthouse to generate a report with your new custom audit.

We now have video-specific audit results, which include a list of all videos on the page that are not encoded in next-generation codecs like AV1 or VP9. You can see the full report here.

Conclusion

By extending Lighthouse with a custom audit, you can bridge gaps in performance analysis for videos.

🚀 Try it yourself! Analyze your website’s media performance and discover actionable insights today.

Image Optimization - A Practical Guide for Web Developers to Optimize Images

Manu Chaudhary — Sat, 04 May 2024 08:06:06 +0000

This guide primarily targets web developers who want to optimize images for media-heavy web and mobile applications. While we will cover some essential theories to solidify your understanding of the core concepts, the main focus of this guide is on practical tips and techniques.

Based on our extensive experience working with thousands of developers, we have compiled a set of opinionated, actionable recommendations and a checklist to enhance your applications' image performance.

Ready to dive in? Let's get started!

Chapter 1 - What is image optimization?

Image optimization is a set of techniques to reduce image file size without compromising "perceived" image quality. The goal is to make images load faster on web and mobile applications. Techniques that are used for image optimization include:

Image compression - Reducing the file size of an image while maintaining visual quality using lossy compression techniques.
Image resizing - Changing the dimensions of an image on the server side to fit the application layout on the front end.
Image format selection - Choosing the right output image format based on the image content and device.
Lazy loading - Loading images only when the user is about to see them on the screen.
Content Delivery Network (CDN) - Using a CDN to deliver images faster to users around the world.

We will cover each of these techniques in detail in the following chapters. But first, let's see an example and understand why image optimization is important.

Quick example of image optimization

Let's take this 1.2MB JPEG image as an example and see how we can optimize it using image compression and format selection.

<!-- Using q to control compression on a scale of 1 to 100 -->

<!-- Original image - 1.2MB -->
<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=f-jpg,q-100" />

<!-- Webp with compression - 72 KB -->
<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=f-webp,q-80" />

<!-- AVIF with compression - 43 KB -->
<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=f-avif,q-80" />

We have put a screenshot instead of rendering actual images because your browser might not support AVIF or WebP format.

Chapter 2 - Importance of image optimization

It is a no-brainer that images are the most engaging content on the web after video. They help convey information, create visual interest, and improve user engagement. But what if those images are not loaded quickly enough?

Slow-loading images on a website leads to -

Poor user experience - Users are less likely to engage with a website that takes too long to load images.
Higher bounce rates - Users are more likely to leave a website if images take too long to load.
Lower conversion rates - Slow-loading images will negatively impact conversion rates on e-commerce websites.

But what is quick enough?

The answer to this question has been very subjective until recently. The performance is relative, what is fast for one user might be slow for another. For example:

What is fast on a high-speed internet connection might be slow on a poor connection.
What is fast on a high-end desktop might be slow on a low-end mobile device.
What is fast for a user in the US might be slow for a user in India.

Often, the methods used by engineering teams to measure "speed" are not always accurate. Most of the time, what we measure in a controlled and simulated environment doesn't match the real-world performance.

This led to the creation of standard user-centric performance metrics that website developers can use to answer the questions confidently - "Is my website fast enough?" and "Are my images loading quickly enough?".

This is what core web vitals are all about. They are a set of metrics that Google has introduced to measure the user experience on a website. They are based on real-world data and are designed to help developers understand how fast their website is loading for users.

Chapter 3 - Core web vitals for image performance

Core Web Vitals are the most crucial user-centric performance metrics that site owners should continuously measure and improve. Google has simplified the measurement of these metrics by providing the Google PageSpeed Insights tool.

A typical report of Google PageSpeed Insights looks like this:

Many metrics are part of Core Web Vitals, but image optimization has a direct impact on Largest Contentful Paint (LCP) and First Contentful Paint (FCP).

Largest Contentful Paint (LCP)

It represents how quickly the main content of a web page loads, specifically, the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading. Fast-loading images will have a direct positive impact on this metric.

First Contentful Paint (FCP)

It marks the time at which the first content is painted. It is the first impression of the website. For this metric, "content" refers to text, images (including background images), elements, or non-white elements. If you have an image like a banner at the top of the page, its loading time will directly impact the FCP. To provide a good user experience, pages should have a FCP of less than 1.8 seconds.

Chapter 4 - Image optimization Checklist

Here is a checklist for your team to ensure that images on your website are optimized for performance. This checklist is based on the best practices and techniques we will cover in the following chapters.

Task	Description
Compress images `HIGH IMPORTANCE`	Choosing the correct compression settings allows for a balance between image quality and file size, which speeds up image loading without compromising visual clarity.
Adopt WebP/AVIF `HIGH IMPORTANCE`	Modern image formats like WebP or AVIF can significantly reduce file size while maintaining high-quality visuals, leading to faster loading times.
Correctly resize images on server-side `HIGH IMPORTANCE`	Serving images at the correct dimensions reduces unnecessary data overhead, enhancing speed and efficiency in image delivery
Utilize a CDN `HIGH IMPORTANCE`	A Content Delivery Network (CDN) enhances image delivery by serving them from a server closest to the user. This proximity significantly reduces load times and improves response rates, optimizing the user experience across different global locations.
Implement responsive images `MEDIUM IMPORTANCE`	Ensure that your application loads the right image. Consider implementing responsive images using srcset and size attributes.
Replace GIFs with video `MEDIUM IMPORTANCE`	Replacing GIFs with videos or animated WebP reduces file size and load times while saving bandwidth costs.
Set image dimensions `MEDIUM IMPORTANCE`	Specifying width and height on images prevents layout shifts during loading, improving user experience and Cumulative Layout Shift scores.
Use SVGs for icons `MEDIUM IMPORTANCE`	Vector images like SVGs are ideal for logos and icons as they scale without losing quality, are smaller in file size, and render sharply on all screen resolutions.
Implement lazy loading `MEDIUM IMPORTANCE`	Lazy loading defers loading of images until they are in or near the viewport, reducing initial load time and saving bandwidth costs.
Use preconnect and priority hints `LOW IMPORTANCE`	Preconnect hints enable the browser to establish early connections to domains hosting images, which accelerates image loading when accessed by users. Additionally, using priority hint to prioritize images at the top of the page can enhance the Largest Contentful Paint (LCP), significantly improving the perceived load speed of the page.
Monitor relevant Core Web Vitals `HIGH IMPORTANCE`	Tracking relevant Core Web Vitals helps identify areas for improvement, ensuring optimal user experience and SEO rankings.

Chapter 5 - Compress images

Image compression is the process of reducing the file size of an image without significantly affecting its visual quality. There are two types of image compression techniques:

Lossy Compression

Lossy compression reduces file sizes by permanently removing certain information and details from image files. While this can affect image quality, the degree of quality loss can be controlled and is often imperceptible, making the trade-off in size reduction very advantageous for web usage.

Predominantly used in web applications, lossy compression is ideal for balancing image quality with load speed, thereby enhancing user experience and reducing data costs. Formats such as JPEG and WebP are commonly used for lossy compression. These are suitable for photographs and detailed images where a slight loss of quality is acceptable in exchange for significantly smaller file sizes.

Why does lossy compression work really well for web use cases?

Let's compress a 1.2MB JPEG image at different compression levels and see the difference:

You won't notice any difference between the original image (leftmost) and the compressed images, although the file sizes vary significantly. This demonstrates the effectiveness of lossy compression for web use, as it reduces file size dramatically without a noticeable change in "perceived" quality to the human eye.

You should avoid extreme image compression, as there is an optimal balance between file size and quality. Excessive compression results in poor visual quality, negatively impacting user experience. An image CDN like ImageKit.io is valuable for its real-time optimization capabilities. It automatically compresses images to the appropriate level, which balances visual quality & size and allows you to control this compression based on your business requirements.

Lossless Compression

Lossless compression reduces file size without any loss of information. It optimizes the image data by repackaging redundant data and removing unnecessary metadata, ensuring that the original data can be perfectly reconstructed from the compressed data. Lossless compression is crucial for archiving images where preserving the original quality is essential. It is also recommended for images that undergo multiple edits, as it prevents the quality degradation that can occur with repeated saving.

PNG and TIFF are typical formats that employ lossless compression. They are preferred for images requiring high precision and clarity, such as digital graphics, logos, and line art.

We don't recommend using lossless compression for web use cases.

How to compress images?

There are many online and offline tools available to compress images. We highly recommend using only the online tools or an Image CDN as they don't require installation.

Depending on the use case, you can choose the right tool for compressing images:

Use-case	Tool
Very few images. One-time optimization is required.	TinyPNG and Squoosh.
E-commerce website	Depending on the platform, there could be some built-in optimizations. However, platforms like Magento, WordPress, and Shopify often result in poor visual quality of the images. We recommend using an image CDN like ImageKit.io. For more details on how to display high-quality e-commerce product images, checkout this blog. Learn how Nykaa simplified image management and optimization for their websites and apps. Case study. Lenskart leveraged better visual experience to improve conversion and global expansion. Case study.
Custom media-heavy web application	Use an image CDN to automate image optimization. This allows your engineering team to focus on building an engaging visual experience without dealing with its technical complexities. Checkout how Swiggy enhanced performance, personalized UX, and saved costs across platforms. Case study. Learn how Curtsy improved customer engagement and transactions with personalized banners. Case study.
User-generated content	To manage user-generated content effectively, you have two options for image compression: compress at the time of upload and store the compressed images, or use on-the-fly compression via an image CDN. For storage, consider using cloud-based object storage like S3 or opt for ImageKit's Media Library. ImageKit's storage API allows you to compress images and apply various transformations during uploading. You can use the generated media file URLs directly in your application.

You should always store high-quality master images at the largest resolution needed for desktop use, typically around 1920px wide and under 5MB. This approach lets you tweak compression settings later without losing the original image quality. Having an image CDN that can compress images on the fly is recommended, as it gives your engineering team the flexibility to adjust compression settings without altering the original image.

Chapter 6 - Optimizing image format

Optimizing image format means converting the input image to the right output format before delivering it to the user.

What is the right image format?

Well, it depends on a lot of things. You should consider the following factors -

Browser and device support - Does the browser support modern image formats like WebP and AVIF?
Transparency - Does the image require transparency? JPEG doesn't support transparency, so possible options are PNG, WebP, and AVIF.
Animation - Does the image require animation? GIF and WebP support animation.
Compression/File size - AVIF is the clear winner in terms of compression and file size. WebP is also good. JPEG is the worst relatively.
Quality - At similar compression levels, which format delivers superior quality? AVIF leads in quality, with WebP also performing well.

So, the definition of the right image format becomes:

The right image format is the one that provides high quality and the smallest file size based on the image content and device support. This means that AVIF may be suitable for some users, and JPEG may be the better choice for others.

It is easy to get overwhelmed by these factors. But don't worry; follow these guidelines, and you will be good:

Use SVG for icons, simple graphics, and logos. A vector image is resolution-independent, so it can be scaled to any size without losing quality. All modern browsers support it.
For photographs and images with complex color gradients, i.e., typical real-world images, AVIF should be preferred. Use WebP as a decent fallback because it is now widely supported. Use JPEG as a last resort for very older browsers and devices.
For images requiring transparency, use AVIF or WebP. PNG should be your last preference.
Avoid using GIFs altogether. Convert GIF to MP4 video or animated WebP.
If you use a content delivery network (CDN), which you should be, then correctly configure caching rules so images are not delivered in unsupported image format from polluted CDN cache. We will talk more about this in the coming chapters.
Above all, make sure your application logic is simple. Handle complexity on the server-side.

If you're setting up an in-house image processing service, consider the high infrastructure costs, especially for computationally intensive tasks like encoding images in AVIF format. An image CDN like ImageKit.io can streamline image processing for you and efficiently handle scaling during traffic spikes.

How to handle browser support and serve image in the best possible format?

We talked about serving different image formats based on the browser support. But how do you do that?

Technically, you can do it in two ways:

Using HTML picture element - The picture element allows you to define multiple sources for an image based on different conditions. You can use it to serve different format images based on browser support.

<picture>
 <source srcset="image.avif" type="image/avif">
 <source srcset="image.webp" type="image/webp">
 <img src="image.jpg" alt="An awesome image">
</picture>

Using ImageKit.io - ImageKit.io is an image CDN that can automatically convert images to the right format based on the factors we discussed above. You don't have to change the image URL. This is done by changing the format on the fly and correctly setting the Content-Type response header based on format support declared by the browser in the Accept request header.

<img src="https://ik.imagekit.io/ikmedia/example_image.jpg" />

What's wrong with using picture element?

The problem with using the picture element to serve different formats is that it increases the HTML markup. If you are doing server-side rendering, all users will have to download this extra markup when every page loads.
Another problem is generating and storing multiple variants for the same image. What if a new format comes up tomorrow? You will have to update all the images. This needs to be more scalable.

The second approach is using an image CDN. It always delivers an image in the right format, considering all the above factors. You don't have to change the image URL. In addition, you can control the output format via URL parameters.

How to convert GIF to video or animated WebP?

GIF is not an ideal web format due to its large file size and limited color palette, which supports only 256 colors. It also lack modern features like transparency. For better performance and quality, it is recommended that GIFs be converted to video formats or animated WebP.

Let's convert this GIF - https://ik.imagekit.io/demo/gif-test.gif to webm video and animated WebP to compare sizes.

Stark difference in file sizes, right? 2.3MB Gif vs 165KB WebM video vs 1.4MB Animated WebP.

Convert GIF to video using ImageKit

Use ImageKit GIF to video conversion feature to convert GIF to video. You can then use the HTML5 video tag for playback. ImageKit will automatically take care of video codec and serve VP9 or AV1 encoded video if browser supports it.

<video autoplay loop muted playsinline>
 <source src="https://ik.imagekit.io/demo/gif-test.gif/ik-gif-video.mp4">
</video>

Convert GIF to animated WebP

When images are delivered using ImageKit, a GIF is automatically converted to animated WebP for supported browsers. You don't have to do anything.

<img src="https://ik.imagekit.io/demo/gif-test.gif">

Chapter 7 - Resizing images to fit the layout

Resizing an image means changing its dimensions on the server-side per layout requirements before delivering it to the user. Many of us have inadvertently uploaded full-size images directly onto web pages. This is an easy mistake to make, especially when fast internet speeds make large images appear to load swiftly and display properly. However, in practical scenarios, this can significantly degrade performance as users are forced to download excessive data, impacting their experience negatively.

Why resize images on server-side?

Simply put, resizing images to fit the layout is important because it reduces the image's resolution, meaning there are fewer pixels to encode, which results in a smaller file size. Serving a 2000x2000 image in a 200x200 container is inefficient, wasting bandwidth and slowing down image loading times for your users.

How to resize images?

No matter how your media workflow looks, there are only two ways to serve correctly resized images: either you generate and store the correct-size image in advance, or you generate it on the fly.

Pre-emptive resizing - In this approach, you generate and store multiple variants of the image based on the current application layout (and future needs). This is a good approach if you have a static layout that won't change. However, it is not scalable, and you will end up storing multiple copies of the same image.
On-the-fly resizing - With this approach, you only store the original image and resize it on the fly based on the application layout. This method is highly scalable and recommended for most use cases because it adapts to varying UI changes and device targets without the need to pre-generate and store every possible image variation. This saves on storage and ensures images are optimally sized in real time, catering to the high variability in user devices.

Pre-emptive resizing using ImageMagick

If there are only a handful of images, use any online image resizing tool. For media-heavy use use-cases, you can programmatically resize images at the time of ingestion and store multiple variants.

To resize all images in a folder to specific dimensions using ImageMagick from the command line, you can use the mogrify command. mogrify is part of the ImageMagick suite of tools, and it is used for batch processing of image files. Here's how you can do it:

cd /path/to/your/images
mogrify -resize 200x200 *.jpg

The mogrify command modifies images in place, meaning it will overwrite the original files. It's a good practice to back up your images before running the command, especially if you are not sure about the changes.

How to resize images on the fly?

On-the-fly resizing is the most scalable approach. You don't have to worry about storing multiple variants of the same image. You can resize images on the fly using an image CDN like ImageKit.io or by implementing an image resizing service yourself.

Basic resizing 200x200 thumbnail

<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=w-200,h-200" />

AI-based smart cropping to generate meaningful thumbnails

<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=w-200,h-200,fo-auto" />

See the different image transformations available in ImageKit.

How to load the correct image in your application?

We've discussed resizing images to make them suitable for your application. But how do you ensure the correct image loads on each device?

If your application's layout is simple and consistent across different screen sizes, you can load the image using the src attribute. This technique also works on single-page applications (SPAs) where JavaScript generates the layout.
If the layout is complex and adjusts based on screen size and display density, you should use the srcset attribute. This lets you specify multiple image options, ensuring the most suitable one is loaded based on the device's screen size. This technique is part of implementing responsive images.

Implementing responsive images

Responsive images are the set of techniques used to load the right image based on device resolution, orientation, screen size, network connection, and page layout. The browser should load an image that fits the layout, and loading it shouldn't result in time & bandwidth wastage. It improves user experience as images load fast and looks crisp to the human eye.

We have written an end-to-end guide on responsive images, but here is what you need to know -

Use srcset with sizes to let the browser load the right image based on the device's screen size and application layout. This forces you to consider layout and image dimensions.
Avoid using the picture element and Client Hints to automate responsive image implementation. This method looks promising on the surface, but it will end up creating too many close variants of the same image.
In most cases, the human eye cannot discern the benefits of a Device Pixel Ratio (DPR) of 3, allowing for the use of smaller images without noticeably reducing quality for the majority of users. Limit serving only 2x images for high-density screens like Retina displays.
Regardless of the chosen method, select breakpoints thoughtfully and maintain straightforward logic. Focus on your users' most common screen sizes and tailor your images to those dimensions. Creating too many variants of the same image can hinder CDN caching and unnecessarily burden the server.

What is wrong with resizing in HTML using width and height attribute?

Resizing images in HTML using the width and height attributes is not recommended. It is a bad practice because the browser downloads the full-size image and then resizes it to fit the layout. This wastes bandwidth and slows down page load times. Always resize images on the server-side before delivering them to the user. Furthermore, a browser-resized image might not look as good and sharp as a server-resized image.

Chapter 8 - Lazy loading images

Lazy Loading Images is a set of techniques in web and application development that defer the loading of images on a page to a later point in time - when those images are actually needed, instead of loading them upfront. These techniques help improve performance, better utilize the device's resources, and reduce associated delivery costs.

We have written a detailed guide on lazy loading images, but here is the gist in the context of image performance.

Primarily, there are two advantages of lazy loading images:

Performance improvement - This one is obvious. If a page loads fewer resources, then the important resources like CSS, JS, and images on the top will load faster, improving the overall user experience.
Cost reduction - Serving images from a CDN, S3, web-server or any other provider costs money. If the user never scrolls to the bottom of the page, then why load those images? Lazy-loading images will save you money.

How to lazy load images?

There are multiple ways to lazy load images, but we will suggest you go with the following two:

Native Lazy Loading

The loading attribute on the img tag is a native browser feature that allows you to lazy load images without any JavaScript. It is supported in Chrome, Edge, and Firefox.

Here is how you can use it:

<img src="example.jpg" loading="lazy" alt="..." />

lazy - Deferring the loading of assets till it reaches a certain distance from the viewport.
eager - loading the assets as soon as the page loads, irrespective of where they are placed on the page, whether above or below the page fold.
auto - This value triggers default lazy loading. Basically, it's the same as not including the loading attribute.

Intersection Observer API

Intersection Observer API is a JavaScript API that allows you to observe changes in the intersection of a target element with an ancestor element or with a top-level document's viewport. It is supported in all modern browsers.

Here is a working CodePen example taken from our blog post:

See the Pen
Lazy loading images using IntersectionObserver - example code by ImageKit.io (@imagekit_io)
on CodePen.

We recommend using the native lazy loading attribute as it is supported in most modern browsers. If you need more control, then use the Intersection Observer API. Loading extra JavaScript for lazy loading images is no longer recommended.

If you are using ImageKit front-end SDKs (React, Angular, Vue.js), check the following getting-started guides:

Lazy loading images in React
Lazy loading images in Angular
Lazy loading images in Vue.js

Chapter 9 - Using CDN for fast download

A Content Delivery Network (CDN) is a network of servers distributed across the globe that cache and deliver content to users based on their geographic location. CDNs are used to deliver content, including images, videos, and other static assets, faster to users around the world.

Why use a CDN for images?

Faster delivery - CDNs cache images on servers closer to the user, reducing latency and improving load times.
Scalability - CDNs can handle large volumes of traffic and scale automatically to meet demand.
Reliability - CDNs provide redundancy and failover protection, ensuring that images are always available.
Security - CDNs offer security features like DDoS protection and SSL encryption to protect your web server from common attacks.

How to configure CDN for images?

Configuring a CDN for images depends on the CDN provider and your image server configuration. In general, here are the factors to keep in mind:

If your server changes format on the same URL based on the request Accept header, then send the Vary: Accept response header to cache a different image copy on the CDN. This is important if you serve WebP, AVIF, and JPEG images on the same resource URL. Most CDN providers support this standard except Akamai and Azure CDN from Microsoft.
Use the Cache-Control header to set the cache duration for images. You can set it to a year for images that don't change frequently.
Correctly set the Content-Type header based on the image format.
Avoid modifying content based on the User-Agent request header. First, it is not 100% reliable, and second, it will hit the cache-hit ratio adversely.
If possible, use CloudFront functions or something similar to normalize the image URL and cache key before caching. This will help in the cache-hit ratio.

The exact steps to configure a CDN for images could vary from provider to provider, and it can be tricky to get it right. We recommend using an image CDN like ImageKit.io, which automatically takes care of these things for you. It comes with CloudFront CDN.

Chapter 10 - Platform-specific image optimization

Most site generators and e-commerce platforms have built-in image optimization features. However, they all lack the control and flexibility you need as a web developer to ensure the best image performance. Let's compare some popular platforms and the ideal way to automate image encoding and optimization.

Image optimization in Next.js

Next.js is a popular React framework that provides server-side rendering and static site generation. The Next.js Image component extends the HTML <img> element with features for automatic image optimization:

Format Optimization: Automatically deliver images in the optimal format for each device, utilizing modern formats such as WebP and AVIF.
Visual Stability: Automatically prevent layout shifts during image loading.
Lazy Loading: Images load only when they become visible in the viewport, utilizing native browser lazy loading techniques, complemented by optional blur-up placeholders.
Server-Side Resizing: Perform on-demand resizing of images using the width and height attributes.

You can use Next.js built-in optimizations for a small site. For a media-heavy site, you should use an image CDN like ImageKit.io to automate image optimization. Next.js provides custom loader support, so you can use ImageKit.io as a custom loader to serve optimized images.

Here is an example of using ImageKit as a custom loader in Next.js:

import Image from "next/image";

const imageKitLoader = ({ src, width, quality }) => {
  if(src[0] === "/") src = src.slice(1);
  const params = [`w-${width}`];
  if (quality) {
    params.push(`q-${quality}`);
  }
  const paramsString = params.join(",");
  var urlEndpoint = "https://ik.imagekit.io/your_imagekit_id";
  if(urlEndpoint[urlEndpoint.length-1] === "/") urlEndpoint = urlEndpoint.substring(0, urlEndpoint.length - 1);
  return `${urlEndpoint}/${src}?tr=${paramsString}`
}

const MyImage = (props) => {
  return (
    <Image
      loader={imageKitLoader}
      src="default-image.jpg"
      alt="Sample image"
      width={400}
      height={400}
    />
  );
};

Other useful resources:

Next.js image optimization blog post and getting started guide.
Automate image optimization in WordPress using ImageKit plugin.
Load high-quality compressed product images on Shopify and Magento using ImageKit.

Conclusion - Why use an image CDN like ImageKit?

To complete image optimization checklist, your engineering team needs a powerful media API to automate most image optimization and transformation tasks. This is where an image CDN comes into play.

Automate image format selection and compression

ImageKit's automatic format conversion and optimal compression reduce significant complexity for your web developers. Based on multiple factors, including browser support, ImageKit can deliver WebP, AVIF, and JPEG images on the same image URL.

This means you don't have to worry about how to modify HTML to request the correct image or how to store multiple variants of the same image. ImageKit takes care of it for you.

On-the-fly resizing for responsive images

Implementing responsive images using srcset and sizes is a relatively complex task. Your team also has to worry about the generation and storage of all the variants. ImageKit can resize images on the fly based on URL parameters, making it easy to serve correctly sized images.

For example, to resize an image to 200x200 pixels, you can use the following URL:

<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=w-200,h-200" />

To resize an image to 200x200 pixels and apply smart cropping, you can use the following URL:

<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=w-200,h-200,fo-auto" />

To add a text overlay on the image, you can use the following URL:

<img src="https://ik.imagekit.io/ikmedia/example_image.jpg?tr=w-200,h-200,l-text,i-hello,l-end" />

An example picked from our text overlay blog.

This is just the tip of the iceberg. ImageKit provides a wide range of image transformations that can be applied on the fly. Bonus: The same API works on videos, making it a one-stop solution for all your media needs.

FAQs

How to monitor image performance?

We recommend using Google PageSpeed Insights to monitor image performance. It provides a detailed report on how images are affecting your website's performance. You can also use Lighthouse for a more in-depth analysis. Optimize large contentful paint (LCP) and first contentful paint (FCP) to improve image performance.

How to optimize images for SEO?

Use sensible file names and alt text for images. Use descriptive file names that include relevant keywords. Add alt text to images to describe the content of the image. This helps search engines understand the context of the image and improves SEO.

What is Data-Saver mode in Chrome?

Mobile browsers like Chrome Mobile and Opera Mobile allow users to activate a Data Saver mode. With this mode enabled, the browser sends a Save-data header within the request. By identifying this header, a web page can customize and deliver an optimized user experience to cost—and performance-constrained users.

ImageKit supports Data Saver mode to further optimize images for users on slow connections.

Image resizing in Java

Manu Chaudhary — Sun, 20 Dec 2020 05:59:31 +0000

There are a couple of ways to resize & crop images in Java. This article will briefly compare different methods of resizing images in Java, along with pros and cons.

More importantly, after you finish reading, you will learn a novel approach to resizing images in Java applications, which doesn’t require writing any image resizing code or maintaining servers to handle a large volume of image manipulation requests.

There are broadly four ways to resize images in Java:-

Native Java -It does not require any third-party libraries.
Open-source image manipulation libraries - For example, ImageMagick.
Open-source imaging service like Thumbor.
Free and paid Image CDN e.g. ImageKit.io.

Method	Pros	Cons
Native Java functions	- No third party library is required.	You will have to deal with a lot of low-level image processing and file operation.
Open source image processing libraries	- High image quality. - More control over resizing and cropping options. - Advance features e.g. watermarking and text overlay.	You will have to install third-party libraries and find relevant options to get the desired results.
Open source thumbnail general service	- Expressive API to resize & crop images for web pages. - High image quality. - More control over resizing and cropping options.	You will have to install a third-party service and maintain the infrastructure.
Free or paid image CDN	- No third party image processing library required. - Since you are not running the service, you don’t have to maintain the infrastructure. - Get started within a few minutes. - Expressive API to resize & crop images for web pages. - Advance features such as smart cropping and face detection. - More control over resizing and cropping options. - High image quality.	An overkill if you want to resize a handful of images. If you are serving images on the web, then you should be using an image CDN.

In this post, we will deep dive into different methods of resizing and cropping using ImageKit.io URL-parameters.

Image resizing in Java using ImageKit.io

We will learn the following image manipulation in Java using ImageKit.io. It doesn’t require you to install any third-party image processing library. You can scale from zero to millions of image requests per minute without having to worry about scaling or maintaining infrastructure.

Basic image resizing, height and width manipulation
Cropping & preserving aspect ratio while resizing images
Add watermark in images
Adding text over images
Generating encrypted secured image URLs
Converting image format

Basic image resizing in Java

You can manipulate the height and width of an image using simple URL parameters. Your backend can generate these URLs in Java or in the frontend itself.

For example, the original image is 1280x853px.

https://ik.imagekit.io/ikmedia/woman.jpg

Original 1280x853 image

To get a 200px wide image, use tr=w-200 query parameter

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-200

200px wide image

To resize an image to 400 width and 200 height, you can use tr=w-400,h-200

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-400,h-200

400x200 image

Using ImageKit.io Java SDK, you can quickly generate image URLs like this:

List<Map<String, String>> transformation = new ArrayList<Map<String, String>>();
Map<String, String> scale = new HashMap<>();
scale.put("height","200");
scale.put("width","400");
transformation.add(scale);

Map<String, Object> options = new HashMap();
options.put("urlEndpoint","https://ik.imagekit.io/ikmedia/");
options.put("path","/woman.jpg");
options.put("transformation", transformation);

String url = ImageKit.getInstance().getUrl(options);
// https://ik.imagekit.io/ikmedia/tr:w-400,h-200/woman.jpg?ik-sdk-version=java-VERSION

Cropping & preserving aspect ratio while resizing images in Java

If only one of the height(h) or width(w) is specified, then ImageKit.io adjusts the other dimension accordingly to preserve the aspect ratio, and no cropping occurs.

But when you specify both height(h) and width(w) dimension and want to preserve the aspect ratio - you have the following three options:

Crop some part of the image. You can choose which area to crop, where to focus etc.
Add padding around the image. You can control the background color of the padding to match the layout.
Let ImageKit change either height or width so that the whole image is visible. In this case, only one of the height or width matches the request dimension.

Let’s understand different cropping options with examples.

No cropping, force-fit image in requested dimensions

If you need an image in exact dimension as requested even if the aspect ratio is not preserved, use forced crop strategy.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-200,h-200,c-force

Force fit

Default center cropping

If you don’t choose any cropping strategy, ImageKit.io will crop the edges by default and show the center of the image.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-200,h-200

Default center crop

Fit inside the container (no cropping)

If you want the image to fit inside the container as per request height and width, use c-at_max. The full image content is preserved (no cropping), the aspect ratio is maintained, but the resulting height & width might differ from what is requested.

The output image is less than or equal to the dimensions specified in the URL, i.e., at least one dimension will exactly match the output dimension requested, and the other dimension will be equal to or smaller than the corresponding output dimension requested.

It is equivalent to object-fit:contain or background-size:contain CSS properties.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-400,h-200,c-at_max

300x200 image fits inside 400x200 container

Fill container (no cropping)

If you want the image to cover the whole container as per the requested height and width, use c-at_least. The entire image content is preserved i.e. no cropping, the aspect ratio is maintained, but the resulting height & width might be different from what is requested.

One of the dimensions will be the same as what is requested, while the other dimension will be equal to or larger than what is asked for.

It is roughly equivalent to object-fit:cover or background-size:cover CSS properties.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-400,h-200,c-at_max

400x267 image covers 400x200 container

No cropping, add padding around the image

If you don’t want the image to be cropped while maintaining the aspect ratio, you can add padding around the edges to get the desired dimension. You can also control the background color of this padding.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-200,h-100,cm-pad_resize,bg-DDDDDD

200x100 image with padding

Smart cropping

ImageKit.io can intelligently crop image such that the object of interest remains in the center using smart cropping. In the thumbnail generated below, the woman is kept in the center.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-200,h-200,fo-auto

Smart crop

Face cropping

You can crop and focus around the human face using the fo-face parameter.

Face crop

Add watermark in images in Java

You can protect your images by adding your logo over them. If you try to achieve this in Java or using open-source image processing libraries, you will have to deal with low-level file operations and library-specific technicalities.

With ImageKit, it is straightforward to add a watermark in images in Java. Let’s say we want to put our logo on an image.

Logo can be accessed at -

https://ik.imagekit.io/ikmedia/logo/light-icon_GTyhLlWNX-.svg

The image we want to watermark -

https://ik.imagekit.io/ikmedia/woman.jpg?tr=w-600

Using the overlay image (oi) transformation, we can generate a watermarked image.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=oi-logo@@light-icon_GTyhLlWNX-.svg

Watermarked image

You can also control the position, size, and other manipulation options of the overlay image. Learn more about image overlay from the docs.

Adding text over images in Java

You can add text over images in Java using ImageKit.io text overlay. You can create engaging visuals in Java using URL-based parameters to add watermark and text on images dynamically.

For example - We have added ot-Sky is the limit in the URL to add a string “Sky is the limit” over the image.

https://ik.imagekit.io/ikmedia/backlit.jpg?tr=ot-Sky is the limit,otbg-FFFFFF90,otp-20,ots-70,otc-00000,ox-N0,oy-30

Text overlay

You can generate photo collage in Java using the same methods. Learn more about how to create a photo collage using ImageKit.

You can use Java SDK to simplify URL generation in your backend application.

List<Map<String, String>> transformation = new ArrayList<Map<String, String>>();
Map<String, String> overlay = new HashMap<>();
overlay.put("overlay_text","Sky is the limit");
overlay.put("otbg","FFFFFF90");
overlay.put("otp","20");
overlay.put("overlay_text_font_size","70");
overlay.put("overlay_text_color","00000");
overlay.put("overlay_x","N0");
overlay.put("overlay_y","30");
transformation.add(overlay);

Map<String, Object> options = new HashMap();
options.put("urlEndpoint","https://ik.imagekit.io/ikmedia/");
options.put("path","/backlit.jpg");
options.put("transformation", transformation);

String url = ImageKit.getInstance().getUrl(options);
// https://ik.imagekit.io/ikmedia/tr:ot-Sky is the limit,otbg-FFFFFF90,otp-20,ots-70,otc-00000,ox-N0,oy-30/woman.jpg?ik-sdk-version=java-VERSION

Generating encrypted secured image URLs in Java

At times, you might want to secure access to your media assets to limit misuse. Or you might want to set a time-based expiry on the image URLs to make it hard for web scarpers to use your image URLs.

To solve this, you can create signed image URLs in your backend application written in Java. A signed URL is a secure URL that can be generated only by you using your account's private key.

For example, let’s create a signed URL that expires in 300 seconds with the default URL endpoint and other query parameters:

List<Map<String, String>> transformation=new ArrayList<Map<String, String>>();
Map<String, String> scale=new HashMap<>();
scale.put("height","600");
scale.put("width","400");

transformation.add(format);

Map<String, Object> options=new HashMap();
options.put("path","/default-image.jpg");
options.put("signed",true);
options.put("expireSeconds",300);
String url = ImageKit.getInstance().getUrl(options);
// https://ik.imagekit.io/your_imagekit_id/tr:h-600,w-400/default-image.jpg?ik-t=1567358667&ik-s=f2c7cdacbe7707b71a83d49cf1c6110e3d701054&ik-sdk-version=java-VERSION

If someone tries to modify the image transformation or use it beyond its intended expiry time of 300 seconds, a 401 Unauthorised response is returned instead of the image.

Converting image format in Java

In Java, you can convert image format using write() function provided by the class ImageIO under javax.imageio package. The supported output formats are JPG, JPEG, PNG, BMP, WBMP, and GIF.

However, you will have to deal with low-level file operations and image buffer. There is a different and easy way to convert image format in Java. Using an image CDN like ImageKit, you can easily convert image format using URL based transformation.

For example - The actual format of the following image is JPG.

https://ik.imagekit.io/ikmedia/woman.jpg

You can convert it to PNG using tr=f-png transformation.

https://ik.imagekit.io/ikmedia/woman.jpg?tr=f-png

You can covert it to WebP using tr=f-webp

https://ik.imagekit.io/ikmedia/woman.jpg?tr=f-webp

ImageKit also offers features such as automatic best format selection, quality optimization, and metadata manipulation out of the box. This reduces the final size of the output image and improves your website's images load time while maintaining visual quality.

Summary

Here is what you need to know:

If you only have a handful of images, use Java’s native image manipulation using the native Java ImageIO class.
If you need easy to use image resizing capabilities, go for a free image CDN like ImageKit.io. With a forever free plan, you get 20GB of viewing bandwidth every month. It is sufficient for small scale businesses.

Responsive Images - A Reference Guide from A to Z

Manu Chaudhary — Tue, 24 Nov 2020 06:26:15 +0000

Chapter 1 - What is responsive images?

In this guide, we will learn everything related to responsive images along with sample code. Basic knowledge of HTML and CSS is required to understand the concepts discussed here. After you finish reading, you will know the latest tools & techniques to implement responsive images correctly.

Responsive images are the set of techniques used to load the right image based on device resolution, orientation, screen size, network connection, and page layout. The browser should not stretch the image to fit the page layout, and loading it shouldn’t result in time & bandwidth wastage. It improves user experience as images load fast and look crisp to the human eye.

Quick example of the responsive images in HTML

The best way to understand responsive images is with a quick example. For simplicity, we will load a 2200px wide image on different devices. Everything else remains the same except the viewport size.

The markup would be:

<!-- The width of the orignal image is 2200px -->
<img src="image.jpg" />

For desktop (iMac), the image is optimal because the width of the viewport and image matches.

However, in mobile, as we can see, the viewport is only 375 CSS pixels wide. The same is valid for the tablet. The viewport is only 1024 CSS pixels wide. We are wasting time and bandwidth downloading this overly large file.

What’s happening?

This is a simplified version of responsive images in action. 🙌

We used srcset (source set) to provide the browser with three different size images. The browser picked the right option based on the actual viewport size of the device. We will soon discover more about srcset and other options in great detail.

Note that we are still using the old src attribute as a fallback if the browser doesn’t support the srcset attribute. As of Oct 2020, all browsers support srcset except Opera mini and IE.

Chapter 2 - Why do we need responsive images?

As you saw in the above example, one size doesn’t fit all. A responsive design should adapt based on user screen size, pixel density, and device orientation to ensure a great user experience.

Here are three main reasons why we need to implement responsive images:

Render a high-quality image on different devices
Loading the right image - Art direction
Faster loading web pages

1. Render a high-quality image on different devices

An image without perceptible artifacts looks crisp and contributes towards a great user experience. This is especially important on retail sites where users expect to view high-resolution closeups of product images to better look at texture & details.

For an image to look good, it must adapt based on viewport width and screen pixel density. Let’s understand these:

Different viewport width case

If your layout changes based on the device viewport, the loaded image dimension should match the container CSS/HTML width. If the browser stretches a smaller image to fit the design, the rendered image will look blurred, and if you load a bigger image on a device with small viewport width, it results in bandwidth and time wastage.

Different pixel density case

High-resolution displays have a higher pixel density. This means more pixels in the same amount of physical space. As a result, high-resolution displays demand images with more pixels. In simple terms, a large image is required to fit the same physical image.

Consider an iPhone8:

CSS viewport size: 375px by 667px
Pixel density: 2
Effective device resolution: 750px by 1334px

It means if we want to render a 100 CSS pixels wide image, we will have to load a 200px wide image for it to look sharp.

For a device with pixel density 3, we will have to load a 300px wide image.

However, note that it does not always mean that we have to load a large file size. On a device, with DPR (device pixel ratio) 2, a 2x wide image with low-quality (50) will look better than a 1x wide image with high-quality(90). Despite being similar in terms of file-size, the 2x image will give a sharper appearance. You can learn more about this technique.

2. Loading the right image - Art direction

When a large image is resized to fit a small area, it can lose its relevance, usefulness, and legibility. The most important part might get cropped.

For example, consider this screenshot of a dashboard on a product landing page. It is highlighting different elements of the user interface to a potential user.

On the desktop, the above image is perfect. However, if we downscale the same image to fit a mobile viewport, we are losing many essential elements of the page.

In this case, an altogether different image might have been more appropriate, for example:

It is called art direction. By "art directing", you can explicitly decide which image should be shown based on the image's size on the page. We will cover this technique in more detail soon.

You can also use this to show different images in a mobile device based on orientation - landscape vs portrait mode.

3. Faster loading web pages

According to the HTTP archive data, 64% of a website’s page weight, on an average, is made up of images. With mobile traffic surpassing desktop traffic, it has become even more crucial to optimize images for different device sizes.

Ideally, you would like to serve images that are resized to match the user’s viewport dimensions. Without a means to do this, you will have to send an overly large image to all users. This means that the user on a mobile device with a small viewport width has to download that extra data, which slows down the page load. This is a wastage of time, bandwidth, and money and degrades the overall user experience.

Chapter 3 - How to make images responsive?

There are many methods for implementing responsive images. We have come a long way from using hacky javascript based solutions to having native support in modern browsers.

In this chapter, we will cover the latest methods for implementing responsive images.

Let’s have a quick comparison before discussing each of these techniques in more details:

Srcset
Srcset with sizes
Picture element
Client-hints
Responsive images in CSS

Method	When to use	Markup complexity
Using srcset	For fixed-size images that take roughly whole viewport width, e.g., full-width promotional banner.	Simple
Using srcset + sizes	For flexible images. When the layout & image size changes based on the viewport width. For e.g., a three-column layout on desktop vs a two-column layout on the mobile device.	Slightly complex
Using picture element	When you want to load an entirely different image based on screen size i.e. art direction. Or you want to use the latest image formats like `webp` or `avif` on a supported device.	Highly complex.
Using client-hints	When you don’t want to make major changes in the HTML markup.	No major code change
Responsive images in CSS	When you are loading images via CSS styles as a background image.	Simple

Chapter 4 - Srcset

The standard <img> tag allows us to define a single image source. As a web developer, it becomes our responsibility to make sure that the right source is defined. But since we don’t have all the information about the device beforehand, it becomes tricky to create a bulletproof markup that loads optimal images for all resolutions.

Remember the little conversation between a web developer and a browser?

srcset allows you to define a list of different image resources along with size information so that browser can pick the most appropriate image based on the actual device’s resolution.

Each comma-separated item in srcset has:

Image URL, e.g. http://ik.imagekit.io/demo/default-image.jpg or relative path /demo/default-image.jpg
An empty space
The actual width of the image or display density:
- Either using display density descriptor, for example, 1.5x, 2x etc.
- Or, using width descriptors, for example, 450w. This is the width of the image in pixels.

Using display density descriptor

The syntax for display density descriptors is straightforward. srcset provides a comma-separated list of image resources along with display density it should be used, for example1x, 2x etc.

<img src="image.jpg" 
     srcset="image.jpg,
             image_2x.jpg 2x"
/>

If a display density descriptor isn’t provided, it is assumed to be 1x.

Demo - srcset with density descriptor

Let’s see this in action with a live demo - https://imagekitio.github.io/responsive-images-guide/srcset-density.html.

Using device emulator in Chrome, at DPR 1, the image currentSrc is https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-300

Similarly, if we consider different DPR values:

DPR value	Image picked by browser (currentSrc)
1	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-300
2	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-600
3	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-900

When to use display density descriptors

Use display density descriptors if your images are of fixed width, and the only thing that varies is display density. It is never that simple though 😉

Challenges in using display density descriptor

As per pixensity.com, there are more than 300 different types of phones, tablets, laptops, and desktop devices with varying screen sizes and display density.

The critical question becomes, do you want to track different display densities available, for example, 1x, 1.5x, 2x, 2.5x, 3x 4x, etc. More often, you will need to go beyond taking care of display density, so this method won’t be sufficient.

Using width descriptor

The syntax is similar to the display density descriptor, but instead of display density values, we provide the actual width of the image.

<img src="image.jpg" 
     srcset="small.jpg 300w,
             medium.jpg 600w,
             large.jpg 900w"
/>

This lets the browser pick the best image

Using width descriptor allows the browser to pick the best candidate from srcset based on the actual width needed to render that image on that particular display at runtime.

Note that display pixel density is also taken into account by the browser while calculating the required width. 😎

For example, assuming an image takes up the whole viewport width - On a 300px wide screen with DPR 2, the browser will pick medium.jpg because it needs a 300x2=600px wide image. On a 300px wide screen with DPR value 3, the browser will select large.jpg because it needs a 300x3=900px wide image.

Demo - srcset with width descriptor

Let see this in action with a live demo - https://imagekitio.github.io/responsive-images-guide/srcset-width.html.

Using the device emulator, let’s resize the screen to 250px and set DPR at 1. The image loaded in this case is https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-300

Similarly, if we consider combinations with different viewport width and DPR values:

Viewport width	DPR value	Final width of the image required (width × DPR)	Image picked by the browser (currentSrc)
250px	1	250 × 1 = 250px	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-300
250px	2	250 × 2 = 500px	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-600
250px	3	250 × 3 = 750px	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-900
300px	1	300 × 1 = 300px	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-300
300px	2	300 × 2 = 600px	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-600
300px	3	300 × 3 = 900px	https://ik.imagekit.io/ikmedia/paddy.jpg?tr=w-900

Notice how the browser is taking display density and viewport width into account while calculating the required image's final width.

Challenges with using only srcset

If you are loading a fixed-width image that will take up almost full viewport width, then use srcset along with width descriptors.

However, in the below cases using srcset alone won’t be sufficient:

When you are loading flexible images i.e. when the size of your image changes based on the size of the viewport. For example, a single-column layout on the mobile and a three-column layout on desktop devices will need different dize images.
Or when the image is only taking a fraction of viewport width. Since the browser is not aware of the layout, it will assume the image will take up the whole viewport width and download a much bigger image than required.

Wait. What? The browser is not aware of the layout!

It is logical to think that browser has stylesheets to find our required size of the image element but note that those stylesheets are not parsed yet. If the browser waits till all stylesheets are parsed & executed, it will inevitably delay the downloading of images.

To understand this better, let’s first look at how the browser loads a page.

How browser loads a webpage — the old way

A web page is made up of text, CSS, JS, and fonts. A lot happens in the background once you hit enter, and a page is finally rendered on your screen.

First, the HTML is downloaded, and the browser starts parsing it. If it comes across an external style sheet, it starts downloading it in parallel and continue parsing HTML.
If it comes across an inline <script> tags, it pauses the HTML parsing and executes the script right away.
If it comes across a <script> tag (one without defer or async attribute) that points to an external URL, it pauses the HTML parsing and first download and executes that Javascript resource.
If it comes across an <img> tag, it starts downloading the image resource in parallel and continues parsing HTML.
Once all blocking external style sheets and Javascript is downloaded, parsed, and executed, the page is rendered.

For example, if we have a HTML like this:

<script src="vendor.js"></script>
<script src="app.js"></script>
<script src="zoom.js"></script>
<img src="image1.png">
<img src="image2.jpg">

– the browser loads resources like this:

Pausing the parser whenever a script is encountered results in sub-optimal use of the browser’s ability to download multiple external resources over the network in parallel. This method is delaying the download of resources required to render the page.

Pre-loaders or speculative parsing to rescue - the new way

Internet Explorer, WebKit, and Mozilla all implemented pre-loaders in 2008 to improve the low network utilization problem that we just discussed.

Essentially, the idea is that the browser cannot build DOM while executing a script but can still parse the rest of the markup looking for other resources, for example, stylesheets, javascript files, or images that are linked. These files are added to a list and start downloading in the background. By the time all scripts execute and HTML parsing finishes, hopefully, the browser has already downloaded these resources, and there won’t be any further delay.

The waterfall chart for the example above now looks like this:

Now we understand why srcset alone is not sufficient for the browser to understand the image's required size. To overcome this problem, we have the sizes attribute.

Chapter 5 - Srcset with sizes

sizes attribute contains a comma-separated list. Each item in the list describes the size of the image in relation to the viewport.

Using the sizes attribute with srcset provides the browser with enough information to start downloading the right image as soon as it sees an <img> tag in HTML without waiting for styles sheets to complete downloading and parsing.

Why do we need sizes?
If you scrolled here directly and wondering why the browser is not aware of how big the image will render, checkout how the browser loads a web page.

The syntax:

<img src="image.jpg" 
     srcset="small.jpg 300w,
             medium.jpg 600w,
             large.jpg 900w"
     sizes="(max-width: 300px) 100vw, (max-width: 600px) 50vw, (max-width: 900px) 33vw, 900px"
/>

Each comma-separated item in sizes has:

Media conditions, for example, (max-width: 300px) - It describes a possible state that the screen can be in. (max-width: 300px) means when the viewport width is 300 CSS pixels or less. It is similar to media queries but with some limitations. You cannot use screen or print.
An empty space.
The width of the image element when the media condition is true. You can provide an absolute length (px, em) or a length relative to the viewport (vw), but not percentages.

Demo - srcset with sizes

Let’s see this in action with a live demo - https://imagekitio.github.io/responsive-images-guide/srcset-sizes.html

The layout is such that:

If viewport width is above 900px, each image takes a fix 225px width.
Upto 900px, each image takes up 33vw i.e. 33% width of total viewport width.
Upto 700px, each image takes up 50vw i.e. 50% width of total viewport width.
Upto 400px, each image takes up 100vw i.e. the whole viewport width.

HTML markup of a single image element looks like this:

<img src="https://ik.imagekit.io/ikmedia/women-dress-1.jpg" 
     srcset="https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-225 225w,
             https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-300 300w,
             https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-350 350w,
             https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-640 640w"
     sizes="(max-width: 400px) 100vw, (max-width: 700px) 50vw, (max-width: 900px) 33vw, 225px">

Let’s see what happens at different screen size and DPR values -

Viewport width	DPR value	Image size required (width × DPR)	Image picked by the browser (currentSrc)
350px	1	100vw i.e. 350 × 1 = 350px	https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-350
350px	2	100vw i.e. 350 × 2 = 700px	Closest candidate is https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-640
650px	1	50vw i.e. (650/2) × 1 = 325px	Closest candidate is https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-350
1024px	1	225 × 1 = 225px	https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-225
1024px	2	225 × 2 = 450px	Closest candidate is https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-350

How to choose breakpoints for srcset and define sizes?

When implementing responsive images, you will have to write the values for the srcset and sizes attributes. It can quickly get tricky. So let’s repeat the purpose of these two attributes so that it becomes easy to derive the values:

srcset - To define multiple image sources of different widths and let the browser pick the most appropriate candidate during HTML parsing.
sizes - To define the size of the image element. It could be a fixed size like 225px or relative to the viewport. You can use CSS media conditions here to provide different size values based on the viewport width.

Before you provide different image sources in srcset, you need to understand what all sizes do you need based on the layout. It is going to be site-specific, meaning it is closely tied to your CSS.

Here is a simple approach to this problem.

While calculating sizes, think in terms of image width relative to the viewport. For example - “My layout is such that my image is going to be roughly X percent of the viewport if the screen size is above Y px.”

Let’s understand this with a few examples.

sizes="(min-width 1024px) 33vw, 95vw)"

It means - “The image is in a three-column layout on a screen larger than 1024px. Otherwise, it is close to full viewport width leaving some space around it”.

Now, let’s pick the sizes from our demo - https://imagekitio.github.io/responsive-images-guide/srcset-sizes.html

sizes="(max-width: 400px) 100vw, (max-width: 700px) 50vw, (max-width: 900px) 33vw, 225px"

It means -

If viewport width is upto 400px, each image takes up 100vw i.e. the whole viewport width.
Upto 700px, each image takes up 50vw i.e. 50% width of total viewport width.
Upto 900px, each image takes up 33vw i.e. 33% width of total viewport width.
Above 900px, each image takes a fix 225px width.

Defining image width relative to viewport does not always provide the most optimal image considering many devices & corresponding viewport width & DPR values. However, it is a practical solution.

Once we know the value of sizes, it is easy to find out what all different size images we need to define in srcset -

Image size candidates from sizes	Effective size at different DPR values (width × DPR)
400px From the first media condition i.e. `max-width: 400px) 100vw`	400px at 1x 800px at 2x 1200px at 3x
350px From the second media condition i.e. `(max-width: 700px) 50vw`	350px at 1x 700px at 2x 1025px at 3x
300px From the third media condition i.e. `max-width: 900px) 33vw`	300px at 1x 600px at 2x 900px at 3x
225px From the fourth default media condition i.e. `225px`	225px at 1x 450px at 2x 675px at 3x

If you sort the effective sizes, here is what you will get -

225px, 300px, 350px, 400px, 450px, 600px, 675px, 700px, 800px, 900px, 1025px and 1200px.

If you are using an image CDN like ImageKit.io, it is easy to provide images in different dimension by addign URL parameters e.g.

225px wide image - https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-225
300px wide image - https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-300
600px wide image - https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-600

However, you don’t have to provide images at all required sizes in srcset. You can select a few candidates, and the browser will pick the closest one. This serves two purposes:

You don’t have to generate and store multiple variants of the same image.
If you are using a CDN for faster delivery and caching, then having a few variants will improve your cache hit ratio as the repeat request will increase.

So you can pick three or four candidates and write srcset like this:

srcset="https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-225 225w,
        https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-350 350w,
        https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-700 700w,
        https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-900 900w"

Tips for choosing breakpoints while writing srcset

You can look at your Google analytics device report to see what screen resolutions you should care about most. Accordingly, you will know which layout needs the most optimization. For example, assuming that 60% of the users on your website see a three-column layout and 20% see a single column layout. Then you can consider all size variations you need for these two layouts at multiple DPR values and write srcset.
To increase cache hit ratio on CDN, don’t try and provide srcset for all possible breakpoints and sizes. CDN cannot cache all your resources. Some resources have to evict to make space for others. This would cause more performance bottlenecks than gains.
When in doubt - First think about your layout, i.e. CSS ➡️ , then accordingly write sizes ➡️ And finally choose breakpoints for srcset considering different DPR values and effective image sizes you need 🙌.

Chapter 6 - Using picture element

srcset and sizes are useful to define multiple dimension variants of the same image. But if you need art direction - that is, to explicitly dictate browser to load an entirely different image based on browser viewport or image format support, you need <picture> element.

When to use the Picture element

Picture element should be used to achieve:

Art direction
Different format support
Color theme example

The syntax:

<picture>
  <source srcset="/large.jpg"
          media="(min-width: 800px)">
  <source srcset="/small.jpg"
          media="(min-width: 400px)">
  <img src="/large.jpg" />
</picture>

<picture> element consists of zero or more source and one img element. The browser will consider each source element to choose the best match based on device display and image format support.

Each source accepts media and type attributes in addition to well known srcset and sizes.

Media attribute

media attribute contains a media condition like CSS media query. If a source’s element media condition evaluates to false, the browser skips that source. If none of the source element’s media conditions evaluate to true, the browser loads the image specified in the img tag.

Example - Loading different based on screen size

<picture>
  <source srcset="/large.jpg"
          media="(min-width: 800px)">
  <source srcset="/small.jpg"
          media="(min-width: 400px)">
  <img src="/large.jpg" />
</picture>

The browser will pick one of the source elements based on the media condition.

Srcset attribute

The srcset attribute is the same as we discussed before. It contains a comma-separated list of different image resources.

Each comma-separated item in srcset has:

Image URL, e.g. http://ik.imagekit.io/demo/default-image.jpg or relative path /demo/default-image.jpg
An empty space
The real width of the image:
- Either using display density descriptor e.g. 1.5x, 2x etc.
- Or, using width descriptors e.g. 450w. This is the width of the image in pixels.

Example - Loading different based on device pixel ratio

<picture>
  <source srcset="large_1x.jpg 1x, large_2x.jpg 2x, large_3x.jpg 3x"
          media="(min-width: 800px)">
  <source srcset="small_1x.jpg 1x, small_2x.jpg 2x, small_1x.jpg 3x"
          media="(min-width: 400px)">
  <img src="large_3x.jpg" />
</picture>

Type attribute

type attribute specified the MIME type of the resource URL(s) in the source’s srcset. If the browser supports that MIME type, it will load the resource. Otherwise, it will skip that source and move to the next. If none of the source’s type is supported by the browser, the image in img is loaded.

Example - Loading different image format based on browser support

<picture>
  <source srcset="/image.webp"
          type="image/webp">
  <source srcset="/image.avif"
          type="image/avif">
  <img src="/image.jpg" />
</picture>

Live demo of using the picture element

Let’s see this in action with a live demo - https://imagekitio.github.io/responsive-images-guide/picture.html

There are two <picture> elements in this demo:

The first example contains a screenshot of the ImageKit media library to showcase different user interface elements. The interface varies based on screen size. So to depict the same, we are loading a different screenshot based on screen size. For screen size greater than or equal to 800px, you will see a desktop version of the user interface i.e. https://ik.imagekit.io/ikmedia/dashboard.png. Otherwise, you will see a mobile-friendly version i.e. https://ik.imagekit.io/ikmedia/dashboard-mobile.png.
The second example demonstrates loading a WebP format image if the browser has support for it. Otherwise, a JPG image is loaded.

Loading different image in dark mode vs light mode

Dark mode lets you change the background color of an app window to black. As a web developer, you can choose to load a different image if a user has turned on dark mode.

<picture>
  <source srcset="dark.jpg" media="(prefers-color-scheme: dark)">
  <img src="light.jpg">
</picture>

The browser will evaluate the media condition (prefers-color-scheme: dark), and if it is true, it will pick that source and load dark.jpg.

Here is how it looks, toggle the dark mode setting and refresh the page to see how the browser loads a different image.

Live demo - https://imagekitio.github.io/responsive-images-guide/dark-vs-light-mode.html

Chapter 7 - Using client hints

What are client hints?

As the name suggests, client hints are the hints provided by the client device to the server along with the request itself. These hints allow the server to fulfill a particular request with the most optimal resource. The latter is known as content negotiation.

Client hints provide this information via HTTP request headers. For example -

How to enable client hints?

Not every request has these HTTP headers. You will have to explicitly tell the browser to include these client hints using a meta tag.

<meta http-equiv="Accept-CH" content="DPR, Viewport-Width">

This allows the browser to send the DPR value (device pixel ratio) and Viewport-Width (device screen width in CSS pixels) along with image requests.

That’s great. But why do we need client hints in implementing responsive images when we already have srcset and picture?

Why do we need client hints?

To understand the need for client hints, let's take a closer look at what we have learned so far -

srcset and sizes to define URLs of different image variants and specify rendered image size so that browser can download the most appropriate image based on the size of the viewport on its own.
The picture element to dedicate how the browser should load a differently cropped or entirely different image, which is better suited for a smaller display.

While srcset and picture provides us with everything we need to implement responsive images use-cases, but it could be time-consuming to develop and maintain for complex use cases.

All of the above methods require you to modify markup so that as a web developer, you can pass the essential missing piece of information that the browser needs at runtime to be able to download the right image. Well, client-hints do the same but without the complex markup — they provide the missing link between the browser and the server when it comes to layout information and device capabilities.

Let’s understand with an example

Suppose you have a simple resolution switching use cases where you want to load a different size variant of the same image based on the viewport width. The syntax would be -

<img src="image.jpg" 
     srcset="small.jpg 300w,
             medium.jpg 600w,
             large.jpg 900w"
     sizes="(max-width: 300px) 100vw, (max-width: 600px) 50vw, (max-width: 900px) 33vw, 225px"
/>

However, if you want to load a WebP image in a supported browser, your syntax becomes -

<picture>
  <!-- webp format for (max-width: 300px) 100vw -->
  <source media="(max-width: 300px) 100vw"
          srcset="small.webp 300w,
                  medium.webp 600w,
                  large.webp 900w"
            type="image/webp">
  <!-- jpg format for (max-width: 300px) 100vw -->
  <source media="(max-width: 300px) 100vw"
          srcset="small.jpg 300w,
                  medium.jpg 600w,
                  large.jpg 900w">
  <source srcset="/image.avif"
            type="image/avif">

  <!-- webp format for (max-width: 600px) 50vw -->
  <source media="(max-width: 300px) 100vw"
          srcset="small.webp 300w,
                  medium.webp 600w,
                  large.webp 900w"
            type="image/webp">
  <!-- jpg format for (max-width: 600px) 50vw -->
  <source media="(max-width: 300px) 100vw"
          srcset="small.jpg 300w,
                  medium.jpg 600w,
                  large.jpg 900w">
  <source srcset="/image.avif"
            type="image/avif">

  <!-- webp format for (max-width: 900px) 33vw -->
  <source media="(max-width: 300px) 100vw"
          srcset="small.webp 300w,
                  medium.webp 600w,
                  large.webp 900w"
            type="image/webp">
  <!-- jpg format for (max-width: 900px) 33vw -->
  <source media="(max-width: 300px) 100vw"
          srcset="small.jpg 300w,
                  medium.jpg 600w,
                  large.jpg 900w">

  <img src="large.jpg" />
</picture>

Yes! It quickly gets complex.

If we use client hints, the above syntax can be reduced to

<meta http-equiv="Accept-CH" content="DPR, Width">
...
<img src="/image.jpg" sizes="(max-width: 300px) 100vw, (max-width: 600px) 50vw, (max-width: 900px) 33vw, 225px" />

Pretty amazing, right! No srcset. But for this to work, the server should be capable of understanding client hints and respond appropriately.

We will discuss in detail how this is possible, but the bottom line is — when possible, you should aim to centralize image resizing & processing and automate as much as possible. This is precisely what client-hints do. ImageKit supports client hints out of the box.

Client hints for responsive images

Among others, one of the primary uses of client hints is to send information about the required size of the image in the current page layout. This simplifies the markup and automates a lot of information passing from browser to web server when implementing responsive images.

Let’s put that in perspective by taking a closer look at what all information does the browser need at runtime to be able to load an appropriate image -

Viewport width.
How big will the image render? It depends upon your layout, which might adapt based on the width of the viewport.
Device pixel ratio i.e. 1x, 2x, 3x or 4x.
URL of the image resource for different sizes.

You can opt-in the following client hints, which will be sent as request headers along with HTTP request -

Width - Final size of the required image in page layout considering device pixel ratio
DPR - Device pixel ratio
Viewport-Width - Viewport width in CSS pixels.
Accept - This header is always sent with every request by default.
Save-Data - on or off to indicate the user’s preference to receive less data.
ECT - Effective Connection Type e.g. **4g, 3g, 2g, and slow-2g.
RTT - Round Trip Time, in milliseconds, on the application layer.
Downlink - Approximate downstream speed of the user’s connection in megabits per second (Mbps).

Width, DPR, and Viewport-Width hints are most relevant to responsive images implementation as they allow the webserver to control the image size from the backend.

Accept hint can be used by the server to deliver images in next-generation format e.g. WebP or AVIF, without changing the image source URL or using the <picture> element.

The server can use network hints such as Save-Data, ECT, RTT, and Downlink to deliver a low-quality variant of the image, which will consume less data.

Width

It provides the final size of the image required as per page layout after factoring in the device pixel ratio. Width hint is sent with requests for image resources fired off by <img> or <source> tags using the sizes.

This is the most useful client hint with respect to implementing responsive images.

For example - Let’s say a page has an <img> element with the sizes attribute set to 300. This means the layout needs a 300 CSS pixel wide image.

<!-- Allow Width header to be sent -->
<meta http-equiv="Accept-CH" content="Width">
...
<img src="/image.jpg"sizes="300px" />

Now the browser takes 300 and multiplies it with the device pixel ratio. Assuming device pixel ratio (DPR) is 2, browser sets Width hint to 600, i.e. 300x2. This is the actual size of the image required for the current layout.

Request headers
GET: /image.jpg
width: 600

This allows the server to respond with an image, which is optimal for this device and the page's current layout.

DPR

This hint provides the device pixel ratio. It is equivalent to window.devicePixelRatio.

For example - when opted in

<!-- Allow DPR header to be sent -->
<meta http-equiv="Accept-CH" content="DPR">
...
<img src="/image.jpg" />

Assuming, device pixel ratio is 2, the browser will set the DPR hint to 2.

Request headers
GET: /image.jpg
dpr: 2

You can use this header on the server to send the right image variant e.g. 1x, 2x or 3x based on the actual device pixel ratio.

Viewport-Width

This hint provides the viewport width in CSS pixels. It is equivalent to window.innerWidth.

You can use this hint on the server-side to respond with an image that is suitable for a specific screen size. This is useful for implementing an art direction use-case.

For example - when opted in

<!-- Allow Viewport-Width header to be sent -->
<meta http-equiv="Accept-CH" content="Viewport-Width">
...
<img src="/image.jpg"sizes="300px" />

Assuming, device screen width is 300 CSS pixel wide, the browser will set Viewport-Width hint to 300.

Request headers
GET: /image.jpg
viewport-width: 300

Accept

It provides what all content type the browser supports, which can be leveraged by the server to send the most optimal response.

Example use case includes serving images in WebP or AVIF format when browser declares the support for it in Accept header. For example - Accept header value in an image resource request in Chrome is image/avif,image/webp,image/apng,image/*,*/*;q=0.8. It has image/webp in it, and the server can use this to respond with WebP format.

If you are using ImageKit, then it automatically converts image format based on Accept header value.

Save-Data

This hint indicates the client's preference for reduced data usage. When the value is on, the server should try to send an alternative smaller payload in the response. For example, in image requests, the server should respond with a lower quality image to reduce data usage if the value of Save-Data request header is on.

Mobile browsers such as Chrome Mobile and Opera Mobile allow the user to activate a data saver mode. With this mode enabled, the browsers send the Save-Data header with the request, with the on value. With this mode disabled, the Save-Data header is not sent at all.

For example, the right image is almost 33% smaller when accessed by a client with Save-Data enabled. You can test this on the Chrome desktop by installing this extension.

ImageKit supports Save-Data mode and when enabled, it will deliver a low-quality image to reduce data transfer.

ECT, RTT, and Downlink

Besides Save-Data hint, we also have ECT, RTT and Downlink client hints -

ECT - Effective Connection Type e.g. **4g, 3g, 2g, and slow-2g.
RTT - Round Trip Time, in milliseconds, on the application layer.
Downlink - Approximate downstream speed of the user’s connection in megabits per second (Mbps).

Jeremy Wagner wrote in Google Web Fundamentals -

Adaptive performance is the idea that we can adjust how we deliver resources based on the information client hints makes available to us; specifically, information surrounding the current state of the user’s network connection.

Time is the key — Taking forever to load a high-quality image on a slow network is more frustrating for your users than showing a low-quality variant that loads quickly. You can use these network client hints to calculate a score of client’s network connection quality and accordingly change your logic on server to help users on the slow network have decent experience.

Limitation of client hints

Client hints look pretty amazing. They automate responsive images without major markup changes. But there are some limitations with client hints -

Client hints don’t work in all browsers

At the moment, they are only supported in Chrome and Chromium-based browsers, Edge, and Opera.

Cross-origin client hints removed in Chrome 67 in the desktop version

After client hints landing in Chrome 35, there were concerns around tracking users across multiple websites because of the device-related information passed through client hints.

Essentially, sending highly granular data, such as image and viewport width, may help identify users across multiple requests. More importantly, there was no mechanism to control which origin should receive this. The moment you opt-in for client hints, all image resource type request will start sharing device-specific data with origins.

If your website is hosted on www.example.com and images are on www.example.com/image.jpg it is fine. But if images on www.images.third-party-service.com/image.jpg have the same data, it may reveal the same information about the user to other origins that may not have had access to it before.

As a result, the Chrome team removed cross-origin client hints in the desktop version of Chrome 67, but they still work in mobile. These restrictions will be removed soon when work on Feature Policy is complete.

Your server should support client hints

For client hints to work, your server should understand them and respond with an appropriate image.

For example, the servers should be able to -

Deliver the right size image based on the value of the Width client hint.
Serve images in WebP or AVIF format based on the value of the Accept client hint.
Select the right image variant based on the value of the DPR client hint.

Fortunately, you can automate all this using an image CDN like ImageKit.io, which supports client hints out of the box.

Caching on CDN can be tricky

You would want to cache your static resources like images to accelerate the download and decrease the load on your origin server. But with client hints in the mix, it can be tricky.

Usually, a CDN looks for the objects in the cache based on the resource URL. However, when the server changes the response based on other request HTTP headers i.e. client hints, the CDN has to be aware of how to respond to future requests. Essentially if we are changing the response based on the Accept request header value, we will have to configure the CDN to store seperate response in cache based on the value of the Accept request header.

You can use the Vary response header to indicate CDN and intermediate proxies to maintain different cache objects based on header names in Vary. For example -

Vary: Accept, DPR

This means that CDN and intermediate proxies should take the value of the Accept and DPR request header in account in addition to resource URL while storing and looking up objects in the cache. The cache lookup key should be Accept + DPR + resource URL.

It is important to note that you should not set Vary: User-agent because there could be a huge number of unique values for the User-Agent request header, resulting in a lower cache hit ratio on the CDN.

An image CDN like ImageKit.io already takes care of CDN caching while ensuring the cache hit ratio is high.

Chapter 8 - Responsive images in CSS

background-image is a very powerful CSS property that allows you to insert images on elements other than img. What you have learned so far about responsive images deals with only HTML markup. Let’s see how to implement responsive images in CSS.

We have the following use-cases to cover:

Art direction i.e. loading entirely different images based on screen width. In HTML, we used the picture element. In CSS, we can use old fashioned media queries.
Providing high-resolution image variants to let the browser make a choice. In HTML srcset attribute provides the browser with 1x, 2x, and 3x variants of the same image. In CSS, we have the option to use image-set.

In CSS media query alone is enough to implement responsive images. However, image-set is similar to srcset because it provides the options and lets the browser choose the image. But it is not equivalent to srcset.

Art direction in CSS — loading an entirely different image based on screen size

In HTML, we have a picture element to load an image conditionally.

<picture>
  <source srcset="/large.jpg"
          media="(min-width: 800px)">
  <source srcset="/small.jpg"
          media="(min-width: 400px)">
  <img src="/large.jpg" />
</picture>

In CSS, we have media queries.

.element {
  background-image: url(small.jpg);
  background-repeat: no-repeat;
  background-size: contain;
  background-position-x: center;
}

.@media (min-width: 800px) {
  .element {
    background-image: url(large.jpg);
  }
}

In this example, on small screen background-image: url(small.jpg) is applied and when viewport width is greater than or equal to 800px, background-image: url(large.jpg) is applied.

Loading high-resolution images based on device pixel ratio

In HTML we have srcset

<img src="image.jpg" 
     srcset="image.jpg 1x,
             image_2x.jpg 2x"
/>

In CSS, we can use image-set and media queries.

Using image-set to provide high resolution images variants

.demo {
  background-image: url(image.jpg); // fallback
  background-image: -webkit-image-set(  
    url(image.jpg) 1x,  
    url(image_2x.jpg) 2x  
  );  
  background-image: image-set(  
    url(image.jpg) 1x,  
    url(image_2x.jpg) 2x
  );
}

If image-set is not supported, the fallback background-image: url(image.jpg) will be applied.

Using media queries

.demo {
  background-image: url(image.jpg);

  // Standard syntax supported in Chrome, Firefox, and Opera
  @media (min-resolution: 2dppx), 
  (-webkit-min-device-pixel-ratio: 2)  /* For Safari & Android Browser */ 
  {
    .demo {
      background-image: url(image_2x.jpg);
    }
  }
}

Chapter 9 - Lazy load responsive images

What is Lazy loading images?

As Rahul Nanwani wrote in lazy loading images guide -

Lazy Loading Images is a set of techniques in web and application development that defer the loading of images on a page to a later point in time - when those images are actually needed, instead of loading them upfront. These techniques help in improving performance, better utilization of the device’s resources, and reducing associated costs.

Usually, to implement lazy loading in HTML, instead of src or srcset attributes, we use data-src or data-srcset so that browser does not load images during speculative parsing. Later on, when Javascript is executed, and the user has scrolled near the image element, we load the actual image and update the src or srcset attribute’s value.

Two very popular lazy loading libraries lazysizes and vanilla-lazyload support responsive images out of the box. In this guide, we will share a few examples of lazysizes.

Lazy loading responsive images in srcset and sizes

<img
    sizes="(min-width: 1000px) 930px, 90vw"
    data-srcset="small.jpg 500w,
                 medium.jpg 640w,
                 big.jpg 1024w"
    data-src="medium.jpg"
    class="lazyload" />

Using low quality placeholder in lazy loading

<img
    src="low-quaity-placeholder.jpg"
    sizes="(min-width: 1000px) 930px, 90vw"
    data-srcset="small.jpg 500w,
                 medium.jpg 640w,
                 big.jpg 1024w"
    data-src="medium.jpg"
    class="lazyload" />

Lazy loading images in picture element

<picture>
      <source
          data-srcset="500.jpg"
          media="(max-width: 500px)" />
      <source
          data-srcset="1024.jpg"
          media="(max-width: 1024px)" />
      <source
          data-srcset="1200.jpg" />
      <img src="fallback-image.jpg"
          data-src="1024.jpg"
          class="lazyload"
          alt="image with artdirection" />
</picture>

Chapter 10 - How to verify responsive image implementation?

After you implement responsive images, it's essential to verify that the right image is being loaded on different devices. Let’s discuss how various tools and browser's developer console can help us.

Using ImageKit website analyzer

ImageKit website analyzer is a tailor-made tool to find our image related issues on the webpage. It loads the webpage in a headless browser. All the image requests are monitored and compared against the optimized version fetched from ImageKit.

You will get a report like below. Look under Properly resize images to see if images are in the right sizes.

This tool also provides an image by image explanation for all images on the webpage like this:

This tool provides image analysis reports for desktop and mobile. However, at the moment, it does not take into account the device pixel ratio, so you will have to consider that, especially while looking at the mobile report.

Using Lighthouse

You can use Lighthouse to verify responsive images are implemented correctly. Run the Lighthouse Performance Audit for Mobile & Desktop and look for the Properly size images audit results.

This will show all the images that aren't appropriately sized based on the page layout.

Manually verifying responsive images

You can use the Chrome device emulator to load a webpage on different devices and see the image requests in the network tab. Few points to note before starting:

Browser cache should be disabled - so that with subsequent reloads, we can see which image resources are being requested.
Ensure device pixel ratio is added, as shown in the screenshot below.

Now open the webpage and hover over the image element to see its required CSS pixel width. Multiple it with DPR value to get the required width of the image resource.

For example here,

DPR value - 2.6
CSS pixel width - 206
Required image size - 206 × 2.6 = 535.6

Available options based on srcset

srcset="https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-225 225w,
        https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-300 300w,
        https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-350 350w,
        https://ik.imagekit.io/ikmedia/women-dress-1.jpg?tr=w-640 640w"

So the nearest candidate is a 640px wide image, and the browser downloads this image. You can use the same technique to see if the right size images are loaded or not.

FAQs

Why can't we do this using CSS or JavaScript?

It's logical to think that we have all the information about browser, device, and layout and can use Javascript to load the right size image. However, this will delay the loading of image resources and defeat the whole purpose of rendering images quickly. Modern browsers don’t wait for Javascript and CSS to be parsed and executed before it triggers the image request. The browser scans the whole HTML and looks for image resources without waiting for Javascript to execute. That is why we need to use the srcset, sizes, and picture element to implement responsive images. Learn how the browser loads a webpage to understand this.

Can I use both density and width descriptor in srcset?

No. As per the specifications about how srcset is parsed - If an image candidate string for an element has the width descriptor specified, all other image candidate strings for that element must also have the width descriptor specified. Also, if an element has a size attribute present, all image candidate strings for that element must have the width descriptor specified.

Why do we need sizes attribute with srcset?

So that browser can trigger image load as part of preloading instead of waiting for CSS to download & parse. Learn how the browser loads a webpage to understand this.

Why do we use width and not a height in srcset?

We have been specifying only image widths in srcset and not height because the vast majority of responsive design is width constrained and not height, so to keep things simple, the specification only deals in widths.

What sizes values should I declare?

The value of the sizes attribute should specify the size of the rendered image in CSS pixel. It could be an absolute value e.g. 250px or relative to viewport size e.g. 33vw means 33% of viewport width. You can use comma-separated media conditions in the sizes attribute to tell how rendered image width changes based on viewport size. For example -

sizes="(max-width: 300px) 100vw, (max-width: 600px) 50vw, (max-width: 900px) 33vw, 900px"

What image sizes should I provide in srcset?

First, think about your layout i.e., CSS. Then accordingly, write sizes. And finally, choose breakpoints for srcset considering different DPR values and effective image sizes you need 🙌.

How should I generate different size image assets?

You will need to provide different size image variants to implement responsive images. On a typical e-commerce or news website, this could be a huge problem as we are dealing with thousands of photos. The solution is to use an image CDN. ImageKit.io is an image CDN that provides real-time image resizing, automatic image format conversion, and optimization. It offers a forever free plan with generous bandwidth limits.

How do you make an image responsive in HTML?

If you are wondering:

How to load different images based on screen size?
How to change image size for mobile devices?
How to display different images on mobile and desktop devices?

Then, know that all of these use-cases are related and can be solved using the latest responsive image techniques that we have discussed in this guide.

Often you will only need srcset attribute. In few cases you might want to use picture tag.

Srcset not working

You could face one problem while using srcset in responsive images is that the browser is always using the largest image available. There could be two things:

If you resized the window to test responsive image implementation and the browser has once loaded a high resolution bigger image, then it won’t load a smaller image again because it can use the largest one from the cache. It saves time & bandwidth. That is the whole point. It is specific to Chrome.
You need to consider the DPR value into account. On the retina display, the browser will go for a wider image based on options available in srcset. If 300px wide image is required and DPR is 2, the browser needs at-least 600px wide image. It might be confusing as you were expecting it to pick a 300px wide option from srcset.

Client hints not working

After client hints landing in Chrome 35, there were concerns around tracking users across multiple websites because of the device-related information passed through client hints. As a result, the Chrome team removed cross-origin client hints in the desktop version of Chrome 67, but they still work in mobile. These restrictions will be removed soon when work on Feature Policy is complete.

How to make a background image responsive?

Setting width and height is not enough when it comes to using background images. You can leverage the latest techniques to implement responsive images in CSS e.g. image-set and well-known media queries.

Responsive images srcset vs picture?

More often than not, you will only need srcset with sizes while implementing responsive images. That is because the primary use-case of responsive images is to load the right size image on different devices e.g. mobile or desktop. However, a picture tag is there if you need to implement art direction i.e. to load an entirely different image based on available screen width or device orientation.

Picture tag not working

If the picture element is not working, ensure that you have the img element inside the picture element. This acts as a fallback when the browser doesn’t support the picture element. You can also use a polyfill for picture element.

How to make images responsive in WordPress?

Responsive images landed in WordPress 4.4, making it easier for theme developers to implement responsive images in their themes. As soon as an image is uploaded in the media library, WordPress creates multiple different size variants and store them. When you embed the image in a post, the img element has srcset and sizes.

Default sizes attribute

By default, the value of the size attribute is equivalent to -

(max-width: {{image-width}}px) 100vw, {{image-width}}px

However, as a theme developer, you have the best knowledge of ideal image size, and you should override this default, as discussed below.

Configuring responsive images for your theme

Theme developers should use wp_calculate_image_sizes helper function to create the sizes attribute for an image.

For example, the below hook will apply to all content and featured/thumbnail images. Thanks to Tim Evko for the code snippet.

function adjust_image_sizes_attr( $sizes, $size ) {
    $sizes = '(max-width: 709px) 85vw, (max-width: 909px) 67vw, (max-width: 1362px) 62vw, 840px';
    return $sizes;
}
add_filter( 'wp_calculate_image_sizes', 'adjust_image_sizes_attr', 10 , 2 );

You can also hook into wp_calculate_image_srcset to calculate the image sources to include in a srcset attribute.

Responsive images in WordPress before 4.4

Before version 4.4, you have to use the RICG Responsive Images plugin. This plugin works by including all available image sizes for each image upload. Whenever WordPress outputs the image through the media uploader, or whenever a featured image is generated, those sizes will be included in the image tag via the srcset attribute. This plugin doesn’t add a sizes attribute, though.

Questions

We hope this guide helped you understand the responsive images in HTML and CSS. If you have a question, feel free to comment or email on support@imagekit.io.