The goal of this module is to provide a mechanism to help improve the Largest Contentful Paint web vital metric.

This module requires careful research, testing, and configuration to be effective!

There are a vast number of variables to consider when attempting to optimize the LCP metric. As such, it is highly recommended to conduct experimentation prior to enabling this module.

  1. Determine if there are eligible images that are also the LCP bottleneck. The investigation scope should encompass every page of the site that is exposed to search engines. Remember, by optimizing one type of page, another may backslide. Always make data-driven decisions when navigating performance problems.

    1. Is "mobile" or "desktop" LCP metric in need of improvement?
    2. Is there an opportunity to improve LCP by improving infrastructure, such as implementing a globally distributed CDN or enabling HTTP/2?
    3. Are there any image optimizations that can be made such as reducing quality or trying out the webp module?
  2. Confirm that the proper breakpoints are configured for the responsive image module. Preload media queries work differently than srcset or <picture> element media queries. Refer to the preload specification for comprehensive details, but the essential difference is that preloads will not automatically choose the most appropriate derivative to load. Rather, all media queries that resolve true will be loaded.
  3. Most importantly, confirm that turning this module on actually reduces the LCP metric! Do not assume that it will without any other configuration tweaks!

How does it work?

This module provides a mechanism that attaches to the core responsive image field formatter plugin that is capable of generating a set of preload links that can cause the proper image derivatives to be downloaded much earlier in the rendering process. It does not otherwise change the behavior of the core formatter plugin.

What can it do?

Sometimes browsers can use a helping hand prioritizing asset downloads. By preloading an asset, it is able to jump to the front of the line. Take the following example:

Before

An image that is the LCP element is stuck in 'queueing' for 600 milliseconds

After

An image that is the LCP element is queued very quickly

What's the difference?

Before, there was a period of roughly 600 milliseconds where the asset that determines the LCP timing was in limbo waiting for the HTTP/2 socket to become available. There seems to be a much better chance of the asset downloading quicker if it is the first asset to use the socket.

As can be seen in the second image, there is no queueing period anymore.

Installation

Install this module via composer composer require drupal/responsive_image_preload

Configuration

This module provides a third party setting for the core Responsive Image formatter. Configure it on the entity view displays that need to be preloaded. It is highly recommended to check out the configuration guide for more details and recommendations.

AttachmentSize
before.png171.54 KB
after.png174.57 KB

Project information

Releases