Largest Contentful Paint (LCP) Metric: A Guide to Faster Web Loading

The world of the Largest Contentful Paint (LCP) metric could be likened to the adrenaline-fueled environment of car racing – it’s an endless race against time. Let's navigate through all the twists and turns of our track to be best prepared. So, what will we learn?

• What is the LCP metric?
• What are its recommended values?
• Why is it important?
• How is the LCP metric calculated?
• How and where do we recommend measuring it?
• What are common mistakes and optimization opportunities?

Meet the LCP Metric#

The LCP metric measures the time it takes for the largest element on a page to become visible. This helps users assess the usefulness of the page.

This metric is part of the Core Web Vitals, used for measuring the speed of web page loading. Core Web Vitals metrics are also one of the signals considered by Google when ranking search results.

Keep LCP Under 2.5 Seconds#

If you want the Largest Contentful Paint to be in the green, compliant zone, the value must be under 2.5 seconds. LCP between 2.5 and 4 seconds is in the orange zone and requires adjustments. An LCP time above 4 seconds is deemed unsatisfactory by Google.

	Good	Needs Improvement	Poor
LCP	≤ 2.5 s	2.5 - 4 s	> 4 s

The Largest Contentful Paint (LCP) metric is important for several key reasons that significantly impact the overall user experience and the success of websites.

These include reducing the bounce rate, influencing e-commerce conversions, brand trustworthiness, or placement in search results.

The LCP metric on our clients' websites often correlates with the conversion rate. We do this as part of conversion analysis.

What is an LCP Element?#

Simply put, it’s the largest visual element on the page displayed during the loading process in the user's main viewport. The LCP element is the one the browser monitors, measuring the time it takes for it to display.

You can identify the LCP element using developer tools such as Lighthouse, the Performance Tab in DevTools, or the Web Vitals extension for Chrome. You can read more about finding and testing (not just) LCP in my article Key Developer Skill: Testing Web Vitals in the Browser.

The following elements can be considered as LCP elements:

• <img> elements
• <image> elements inside <svg> elements
• <video> elements with a "poster" image
• Background images using the background-image property (CSS gradient is ignored)
• Block-level elements containing text or other inline-level text descendants

Conversely, the following elements cannot be LCP elements:

• Elements with the opacity: 0 property and others that are invisible to the user.
• Elements that fill the entire viewport. These are considered illustrative rather than content.
• Placeholder images with low informational content. This is a safeguard against LCP hacks where developers inserted a large image without information. If you have doubts about the informational content of your images, you can test them with the Image BPP Calculator (bits per pixel).

The key is to identify the "LCP element". Be cautious, as it may differ across resolutions.

See how to find the LCP element.

How is the LCP Element Assessed?#

To properly assess and optimize, it's essential to understand how the LCP metric is calculated. For the LCP element, its size visible on the user's screen is usually evaluated. Cropped parts, parts hidden using overflow:hidden, or properties like padding, margin, border, and others are not considered. For a deeper dive into LCP evaluation, there’s an excellent article on web.dev.

Measuring LCP on Your Own Website#

A reliable source of Core Web Vitals metric data is the datasets from the Chrome UX Report (CrUX). You can work with this data for both the entire domain and individual URLs. A detailed distribution of LCP values for users at the origin level is shown in a histogram.

Working with raw CrUX data, however, requires quite a bit of technical skill. Fortunately, we already have tools that process this data and display it in graphs automatically. These include PageSpeed.ONE or Pagespeed Insights.

Basic data on the LCP metric status can be provided by our web speed test or PageSpeed Insights. For a time-trend overview, try our web speed test.

If the limitation to Chrome users is too restrictive for you, you can always resort to your own measurements using RUM (real user monitoring), or write your own data collection using JavaScript and the Performance Observer API.

Google Search Console is one of the sources that provide us with vital information on LCP optimization priorities.

Another option is synthetic measurements, which you can obtain using tools like SpeedCurve, Google Lighthouse, WebPageTest, and others.

We discuss the differences between measurements on a dedicated page: synth vs. CrUX vs. RUM.

LCP Errors and Optimization Opportunities#

The LCP metric is rather complex. It’s important to realize that numerous factors can affect it. Firstly, it involves resources critical for the first render:

• Backend time speed (the TTFB metric).
• HTML size and complexity.
• Size of CSS and other critical resources.

Backend time optimization (TTFB) often helps improve the LCP metric.

LCP also accounts for asynchronous resources, such as images or web fonts, which can constitute the LCP element. Thus, LCP can also be influenced by the following:

• Format, physical, and data size of the image itself.
• Size of font files, etc.
• Presence of an image in the poster attribute of the <video> tag.

In general, keep all times and sizes as low as possible. Our secret tip? Use lazy loading for images and use it well.

Here you’ll find additional tips for optimizing web images.

Here, lazy loading would help. Lazily loaded images (all except the first) would prioritize the first image, affecting the LCP.

You can also improve LCP with more complex modifications, which we’ll describe below:

Lazy Loading Can Harm LCP#

The rule is that images without lazy loading are downloaded first in the browser. Images with lazy loading are downloaded later, even if they are visible in the viewport. If you have lazy loading on an image that is also the LCP element, it will download much later, increasing the LCP time. Therefore, remove lazy loading from LCP elements on your website and add lazy loading to all other elements:

<img src="image-non-lcp.webp" loading="lazy" alt="Image" />

Fetch Priority Boosts File Downloading#

A complex HTML structure or too many files being downloaded can cause the LCP element to download too late. The fetchpriority attribute can increase the priority of a selected file download. This improves the LCP metric. However, this technique should be used cautiously and its impact thoroughly tested.

<img src="image.webp" fetchpriority="high" alt="" />

Preload Web Font Resources for LCP Elements#

If you find that a text element is identified as the LCP element on the page, you must ensure the fastest possible download and display of web font files. To achieve this, you can use preload techniques. A small note: Use preload sparingly, so only preload the exact font cut that affects LCP:

<link rel="preload" href="font-1.woff2" as="font" type="font/woff2" crossorigin />

Check out our article on LCP optimization.

Key Takeaways on LCP#

• Largest Contentful Paint (LCP) is a metric that measures the time it takes for the largest visual element to display on a page.
• Recommended values for LCP are under 2.5 seconds, 2.5 - 4 seconds requires adjustments, and above 4 seconds is unsatisfactory.
• LCP is a key component of Core Web Vitals, affecting user experience and often bounce rates, e-commerce conversions, or search engine rankings.
• When optimizing LCP, focus on improving the loading speed of critical resources, proper use of lazy loading, or utilizing the fetchpriority attribute to increase file download priority.

The LCP metric is part of our unified speed metric, PageSpeed.ONE Score (SPS).

Years of Experience in LCP Optimization#

Our long-term collaboration with the Footshop.cz project kicked off with LCP optimizations. Here, among other things, we fine-tuned the transition from client-side rendering cached with a Service Worker to server-side rendering. The result is 2.5⨉ better LCP speed on mobile devices.

Illustration from the main image: Unsplash.