How to optimize the Largest Contentful Paint (LCP) metric
Earlier this month, we covered the Cumulative Layout Shift (CLS) metric and why it matters for publishers. In the second article in this series, we’ll be looking at another, equally important UX metric known as Largest Contentful Paint (or LCP), what it means, and how to improve it.
LCP is part of the “Core Web Vitals”—a set of three metrics introduced by Google last year to help web publishers deliver a better on-page experience to their users across devices.
Site optimization is a continuous endeavor and making changes to improve these metrics, and consequently, the overall CWV score, pays off in the form of better search rankings, more organic traffic, and improved user engagement metrics.
So, without further ado, let’s dive right in.
What is Largest Contentful Paint?
The Largest Contentful Paint tracks the render time of the largest image or text block that is visible within the viewport, relative to when the webpage first started loading.
LCP is an important metric because it marks the point in the loading process when the main content of the webpage has most likely loaded. A good LCP score reassures users that the site is working as expected and that the webpage they are on is useful.
The metric was created based on Google’s internal research and discussions with the W3C Web Performance Working Group and chosen for its simplicity compared to older metrics like DOMContentLoaded, First Meaningful Paint (FMP), and Speed Index (IS).
How is Largest Contentful Paint measured?
According to the LCP API, the following elements are considered in determining the score:
<video>elements (the poster image is used<image>elements<image>elements inside an <svg> element- An element with the background image loaded via a
URL(as opposed to CSS gradient) - Block-level elements containing text nodes
The first step to reporting the LCP score is determining the element size. The size of the element used for reporting LCP has to be in the user’s viewport. If the element extends beyond the viewport or if the element is clipped, those portions do not count towards the element’s size. There are different rules for determining the render time of different asset types, such as images and text. For all elements, any padding, margin, or border applied using CSS does not count.
The actual measurement results can be recorded in the lab (measurement in controlled conditions) or in the field (how users actually experience your site) using the following tools:
Lab tools
Field tools
- Chrome User Experience Report
- PageSpeed Insights
- Search Console (Core Web Vitals report)
- web-vitals JavaScript library
What is a good LCP score?
The LCP score is measured in seconds and directly reflects the time taken by the largest visible element to render on the page. Therefore, a lower score is better.
- Great: Under 2.5s
- Needs improvement: Between 2.5s to 4s
- Poor: Above 4s
Factors that contribute to a poor LCP score
Since LCP measures the load time for specific elements, there are a lot of factors that can result in a suboptimal score, including how those elements are defined and network resources. Here are some specific factors that are known to cause poor LCP scores:
- Slow server response times (measured in Time to First Byte or TTFB)
- Presence of render-blocking JavaScript and CSS
- The time taken to load resources is too long
- Using client-side JS logic to render pages directly in the browser
How can you improve your LCP score?
- Choose a good web host: Hosting performance and server response times matter a lot when it comes to optimizing the LCP metric, so make sure you’re working with a reputable host and have adequate bandwidth and infrastructure to meet user needs.
- Route users to a nearby CDN: Content delivery networks create mirror copies of your content on servers across the globe and then serve files using the server that is physically closest to the user. Consider using a CDN to serve content and media faster.
- Cache assets: If your HTML is static, caching can prevent it from re-created unnecessarily for every single request. There are a lot of plugins and third-party services that can save a generated HTML on disk, reducing TTFB and resource loading time.
- Establish third-party connections early: Use
rel=”preconnect”to inform the browser that your page intends to establish a connection as soon as possible. You can usedns-prefetchas a fallback on browsers that don’t supportpreconnect. - Minify and defer non-critical JS and CSS: Minification is the process of removing extra characters like spaces, indentation, and comments, so that the browser can more quickly process JS/CSS files. By assigning a
deferstatus to non-critical scripts, you can inform the browser not to wait for those files and reduce their render blocking impact. - Optimize resource load time: There are many optimizations that can be implemented to reduce the resource load time, including appropriate image sizing and compression, preloading important resources, compressing text files, using adaptive loading for slower network connections, and caching assets using a service worker.
- User server-side rendering: For sites that are mostly rendered on the client-side, reducing the amount of JavaScript is the first step. That said, publishers should consider including a server rendering experience to further optimize LCP. This approach does have some drawbacks, but the basic idea is to first render the page on the server rather than the client.
Like most web performance metrics, measuring and optimizing LCP is an ongoing process. Every new change or addition made to the host, CMS, or content policies can potentially affect the score in a negative way. And with so many different factors affecting the final score, you’ll probably need to create an optimization plan that focuses on one thing at a time.
We recommended creating a performance budget, i.e., the ideal score that you want to achieve, making changes to achieve that goal, and then monitoring the score on an ongoing basis.