Today, Users face multiple problems when arriving or simply using a website or app. One of these problems is quite significant, namely, network instability, causing the website or app to load slower. LQIP, Low-Quality Image Placeholder, and Lazy Loading are two methods that can be implemented on the front end of websites and apps to create a greater User Experience even with network instability. With LQIP, implemented, a low-quality image of the final image version will initially load to fill in the image container until the high-resolution version will load. A more thorough introduction to LQIP can be found here. Another method to speed up a website’s load time is lazy loading. Lazy loading will delay the load or initialization of assets on the website until they’re actually needed.
Attached below is a Codepen.io example of LQIP and Lazy Loading being applied to a Product List Page using Cloudinary. The example below includes two parts, the first being the Hero Image (Background Image) that shows how the LQIP is rendered first, and then the final more detailed image is loaded second. The second part (At the bottom of the page) shows LQIP being used with Lazy Loading, meaning the LQIP isn’t loaded until you scroll down to view the Product List Page (PLP). Note, that with Cloudinary, JS is not required. When inspecting, be sure to throttle your network (3G should suffice) and empty the cache prior to reloading.
- Consider lazy loading when:
- Images are not yet visible
- Images are not as important as other content
- There are many images on a page, for example, a PLP
- Small File LQIPs (Small in terms of bytes) may be a subjective-performance win for the hero image. Large LQIPs will slow down the final, LCP image/score too much. A hero image is a large or oversized web banner image that is pinned to the header section of a webpage, usually towards the top of the page.
- Load LQIPs as soon as possible (ie Use Case: Carousel); try to ensure the LQIP source is in the src attribute sent with the HTML, and not added later with Javascript. Inlining (base64) or preloading are best.
- Prefer Progressive Loading to LQIPs. Unfortunately, until we get JXL, this won’t be possible for f_auto customers delivering large numbers of WebPs and AVIFs, which do not load progressively. To further expand, f_auto is a Cloudinary Transformation that detects the End-Users browser and transforms the asset into a different format that is best suited for the browser, reducing file size and maintaining quality.
- Never lazy load the LCP image (Largest Contentful Paint). LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport.
- Measure the cost of your LQIP implementation on LCP times (objective).
- Test your LQIPs – on a range of devices and network conditions – in order to judge the benefits of your LQIP implementation (subjective)
- Native lazy loading, unlike most Javascript lazy loading libraries, tries to be “invisible” – it tries to load images before they enter the viewport. This decreases the need for LQIPs (the worst possible LQIP is one that never gets seen — just a waste).
Should we generate LQIP for all images above the fold components when the page loads?
Unfortunately, because LQIPs provide subjective performance wins, this will require subjective testing. “LQIPs for everything” may lead to a large number of requests which slow down the rest of the page too much; a fast LQIP on the hero image is much, much more valuable than, say, an LQIP of the company logo. But it’s subjective and context-dependent.
Would it be right to generate LQIP for all images below the fold components when the page loads and before you scroll down?
Using Javascript libraries that are lazy-loaded when images enter the viewport, was *super* important. Now, using native Lazy Loading, it’s much less so… to the point that in many contexts it may not provide any value at all. Test!
In what cases shouldn’t I create LQIP images at all?
- When they slow down the objective metrics (LCP) too much.
- When they are not seen at all by a significant portion of viewers (just waste)
- When the subjective benefits they provide don’t outweigh the objective costs (this is a design decision!)
Many of these aspects are subjective, can depend on end-user preference, and implementing these features correctly can be found to be quite challenging. With that being said, being mindful of these best practices and constantly testing will inevitably lead to great results.
