Preloading the main image (above the fold image) helps reduce the maximum content paint (LCP) time in Core Web Vitals. These are usually images such as logos, featured images on blog posts, Hero images on landing pages, etc. By preloading them, you move them to the top of the waterfall and basically tell the browser that these have priority and should load immediately.
It’s important to understand that Chrome has a limit of two image preloads that will appear at the very top of the waterfall. Anything after these two images will still show up higher in the waterfall, but won’t be considered high priority, it’s all up to Chrome. We generally recommend preloading 2-3 images. This usually preloads your logo and displays a featured image in the blog post.
If you have manual image preloads on the page, this will take precedence over the automatic one.
The preload key images feature will also automatically exclude these images from lazy loading.
Starting in Chrome 73, links and responsive images can be combined for faster image loading.
Preload lets you tell the browser which critical resources you want to load as quickly as possible, before they are found in the HTML. This is especially useful for resources that are not easily discovered, such as fonts contained in style sheets, background images, or resources loaded from scripts.
Responsive Images + Preloading = Faster Image Loading
Responsive images and preloading have been available for the past few years, but at the same time something is missing: the inability to preload responsive images. Since Chrome 73, the browser can preload the correct variant of the response image specified by srcset before discovering the tag img!
All modern browsers support responsive images, while preloading them is only supported in Chromium-based browsers.
Preload dynamically injected response images
Suppose you are dynamically loading the main image as part of a slideshow and you know which image will be displayed first. In this case, you may want to avoid waiting for the script before loading the relevant image, as this will delay the time the user sees it.
You can check this on a website with a dynamically loaded image gallery:
Open this sample website in a new tab.
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
In the Throttling drop-down list, select Fast 3G.
Disable the Disable cache checkbox.
Reload the page.
In theory, preloading responsive images can speed things up, but what does it actually do?
This gives me the following results for no preload and image preload. Looking at the raw data, we see that Start Render remains the same, with a slight increase in the speed index (273 ms, because the image arrives faster, but doesn’t take up a lot of pixel area), but the real metric that captures the difference is the last drawn Hero metric, Improved by 1.2 seconds.