LCP: Load Largest Contentful Paint elements faster

LCP is slow for most webpages
Most desktop and mobile webpages fail Google's LCP requirements.

According to a recent Twitter poll by Aleyda Solis improving Core Web Vitals continues to be a priority for SEO professionals in 2022. Many websites continue to struggle with the Largest Contentful Paint with about 40% of desktop and 55% of mobile URLs failing the requirement.

Pages need to load in 2.5 seconds

The required loading time for the Largest Contentful Paint continues to be 2.5 seconds for 2022 It measures how fast the largest element loads inside the viewable frame of the browser. To meet this requirement, it is recommended that the time-to-first byte is under 1.5 seconds and First Contentful Paint is under 1.8 seconds.

Identify LCP elements

So your page is failing LCP, but how do you identify which component of your page is slow? You are looking for what is called the LCP element. According to the 2021 httpArchive Almanac the most common is an img followed by div and p elements.

Images make sense and are fairly easy to address. The div and p block elements can be more challenging. I am going to help you resolve both. But first, you need to identify your LCP element.

  • Using PageSpeed Insights, you can view the component being measured under Diagnostics > The largest contentful paint element.
  • Using Webpage Test, you can see the LCP element with a Core Web Vitals test.
  • Using my Waterfaller app, you can view the LCP element using the "Screenshot" tab where I show a full-size image with the LCP element outlined.

Implement a performance budget

When the LCP element is an image, a long-term strategy is to reduce the total number of files loaded before LCP. The fastest request is one not made. So load fewer files. For example, if your image is the 47th file loaded in the waterfall, then I recommend doing an inventory of all the files loaded before LCP. My research shows that a fast webpage should load no more than 35 files and have no more than 15 images before LCP.

My Waterfaller app helps web professionals understand and implement a performance budget to improve LCP.

Load the LCP image element faster

It is a good start to make fewer requests, but the next step is to load the LCP image as fast as possible. The first step is to preload the correct LCP image so the browser prioritizes loading it. Here is how you correctly preload a responsive image in the <head>.

1<link rel="preload" href="/image_mobile/post.png" as="image"
2  media="(max-width: 500px)">
3<link rel="preload" href="/image_tablet/post.png" as="image"
4  media="(min-width: 500.1px) and [max-width: 768px)">
5<link rel="preload" href="/desktop/post.png" as="image"
6  media="(min-width: 768.1px)">

And then do something like this in the <body>.

 1<picture>
 2  <source srcset="/image_desktop/post.png" media="(min-width: 992px)">
 3  <source srcset="/image_tablet/post.png" media="(min-width: 768px)">
 4  <source srcset="/image_mobile/post.png" media="(min-width: 0px)">
 5  <img src="/image_mobile/post.png"
 6    height="480" width="640"
 7    class="img-responsive no-lazy"
 8    loading="eager"
 9    decoding="async"
10    alt="Featured Blog Image">
11</picture>

Avoid common mistakes

Fixes must be implemented correctly or the problem will get worse. The most common mistake is using 'loading="lazy"' on the image tag. I recommend using loading=eager and then also using the new decoding="async".

Another mistake is preloading the wrong image. Often images are responsive, but the preload code is not responsive causing the browser to download 2 images. Another way to mess this up is to just preload the wrong image which can happen after a redesign.

Resolve slow loading block-level elements

If the LCP element is a div then the likely culprit is a background image that needs to be optimized. It should be responsive using media queries, so mobile image size is smaller than desktop. If possible consider improving readability on small screens by removing the background image for mobile and using a solid color.

If the element is a p then the likely culprit is a slow loading custom font. My budget research suggests using no more than 5 custom fonts. My goal is to use a single, variable custom font like Raleway. Then one font file can be used for all your font-weight declarations. I recommend self-hosting Google Fonts and deprecating the use of Font Awesome in favor of inline SVG icons like Hero Icons.

Invitation to try Waterfaller

Waterfaller is an app that is designed to help web professionals master Core Web Vitals. To use it, you enter your webpage URL and it will generate a step-by-step guidebook tailored to your situation. It also provides an online assistant helping you understand and implement improvements using a provide agile methodology.

In this case, the Waterfaller guidebook will create a performance budget tailored to your situation, write an agile Epic for Largest Contentful Paint, and write user stories that you can using in your next sprint planning meeting.