Largest Contentful Paint (LCP)
What is the Largest Contentful Paint and why does it matter? Learn how to improve the Largest Contentful Paint
Largest Contentful Paint (LCP) - In short
The Largest Contentful Paint (LCP) measures the time in milliseconds from when the user initiates loading the page until the largest video, image or text block is rendered within the viewport before user input on a web page.
Since 2020 the Largest Contentful Paint (LCP) is one of the three Core Web Vitals metrics. The LCP represents the loading part of the Core Web Vitals and determines how quickly the main content of a web page is loaded.
In simple terms: a good LCP score will make a visitor think the page loads fast!
What is the Largest Contentful Paint (LCP)?
The largest Contentful paint is a largest content element that has content of the type image, video or text that has been painted on the visible part of the screen. The LCP timing indicates the time in milliseconds between requesting the page and when the largest contentful (DOM) element is displayed on the visible part of the web page (above the fold).
Table of Contents!
- Largest Contentful Paint (LCP) - In short
- What is the Largest Contentful Paint (LCP)?
- History of the Largest Contentful Paint
- Which Elements are considered LCP elements?
- The importance of the LCP
- What is a good LCP score?
- How to measure the Largest Contentful Paint?
- Break down the LCP into it's sub components
- Improving the Largest Contentful Paint
- Your Core Web Vitals questions answered
History of the Largest Contentful Paint
When you think about it, the LCP might seem a trivial metric to represent the the loading part of the Core Web Vitals. Why not measure loading speed as 'the time it takes for the page to load'.
That is because it is hard (or even impossible) in most modern website to define when the page has loaded. More and more websites use techniques such as lazy loading or progressive loading where the page basically can keep loading forever. That means page speed cannot be measured by a single point in time.
There are several moments when loading the page that can cause a user to experience the page as fast or slow. For example the server delay (Time to First Byte), the first time that content is visible (First Contentful Paint), the time that the visible viewport may seem complete (Largest Contentful Paint) and when the page becomes interactive (when clicking on a link becomes possible) are all points during the loading process where the site may seem slow or fast!
The Largest Contentful Paint (LCP) is chosen because it focused on a visitor's user experience. When the LCP occurs you can assume that a visitor thinks the page is finished loading (even if behind-the-scenes processes are still running). The LCP was created to answer the question: 'When is the content of a page visible?'. This is why LCP is recognized as a core indicator of user-centric performance.
Which Elements are considered LCP elements?
Not all elements are considered as an LCP element. The largest Contentful has to be painted on the visible part of the screen (the viewport) before the user has interacted with the page.
The element has to be an image (normal image or background image), a video (the poster image or first video frame, whichever happens earlier, is used) or a text element (in case of inline text elements like <span>
the nearest block level element <div>
or <p>
is considered).
Currently, certain elements are excluded as LCP candidates, such as elements hidden with opacity: 0
, images that match 100% of the the viewport size (cover images), and placeholders (low-entropy images). Keep in mind, this can change as the spec evolves!
Getting technical: measuring LCP Element Size
LCP identifies the largest visible content element in the viewport and calculates its size based on a set of precise rules. These rules ensure consistency and accuracy, even in complex layouts:.
- ViewPort only - Only the visible part of the page is considered. If an element is only partially in the visible viewport the considered size will be clipped.
- No Border, padding or margin. For all elements, text and image borders, padding and margins are completely ignored.
- Text size - text elements size get's reported as the smallest rectangle that can be painted around the text node(s).
- Image size - for images the smallest of the intrinsic dimensions (the original width and height) and the display size (the size on screen) is used to calculate LCP element size
- First size counts - when layout changes or when an element size changes only the first size is considered for the LCP
- Removed elements are included - when an element is removed from the DOM it is still an LCP candidate
Dynamic Nature of LCP
Largest Contentful Paint (LCP) is a dynamic metric. While rendering can be complex and occur in stages, it's normal for the LCP element to change during page load. Before the first user interaction, the browser's performance observer identifies all element that could be considered LCP candidates. These candidates include images, text blocks, and videos. If an element is both visible within the viewport and larger than the previously identified LCP element, it becomes the new LCP.
Take-aways from LCP field data: At CoreDash we track millions of LCP entries per day. As it turn out for mobile pageviews the LCP element is often a text based element, either a paragraph or a heading. On average (or at the 75th percentile to be precise) the Core Web Vitals will pass when the LCP element is a text node or even a normal image. When the LCP element is a background image, video (or a lazy loaded image) the Core Web Vitals tend to fail.
The importance of the LCP
The Largest Contentful Paint is one of the 3 Core Web Vitals. As a Core Web Vitals the Largest Contentful Paint is important for SEO but more importantly the LCP is important for UX. Visitors do not like to be kept waiting and with more and more mobile traffic (that tends to be slower them desktop traffic) optimizing the Largest Contentful Paint seems to make a lot of sense.
- For SEO. Yes, Google focuses on serving the best pages in its search results. LCP is part of Google's Core Web Vitals. Google clearly states that site speed is a factor in search results.
- For Visitors: According to recent research by Google itself, the probability of a user leaving the site doubles with a loading time of 3 seconds. You will probably recognize that for yourself. While surfing the internet almost nothing seems as annoying as a slow loading website. Chances are that you will quickly leave a slow loading page.
- Other reasons: Page Speed is a factor in your Google Ad Score. This means you can buy your ads cheaper and finally passing the Core Web Vitals is one one of the prerequisites for Google's top Story box.
A fast LCP gives the visitor the idea that the page loads quickly. As a result, a visitor is less likely to navigate away from the page.
What is a good LCP score?
To pass the Core Web Vitals for the Largest Contentful Paint at least 75% of your visitors need to have a 'good' LCP score. A LCP score between 0 and 2.5 seconds is considered a good LCP score, a LCP score between 2.5 and 4 seconds needs improvement and a LCP score above 4 seconds is considered poor.
Good | Needs Improvement | Poor | |
---|---|---|---|
Largest Contentful Paint | < 2500ms | 2500ms - 4000ms | > 4000+ms |
How to measure the Largest Contentful Paint?
The Largest Contentful Paint (LCP) can be measured with pure JavaScript, Lab data and Field tools. Both have their advantages and disadvantages.
Measure the Largest Contentful Paint with JavaScript
To measure Largest Contentful Paint (LCP) using JavaScript, the Performance Observer API offers a quick solution. The following code snippet demonstrates how to capture the LCP timing and element information:
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
console.log('LCP value: ', lcpEntry.startTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });
This snippet tracks the LCP entry as it’s reported, displaying its timestamp and element details in the console. For more extensive insights, consider using the Web Vitals Library. This library provides tools for measuring Core Web Vitals across devices and platforms and includes additional data such as LCP attribution information, which can be valuable for targeted optimization.
Measure Largest Contentful Paint (LCP) in Chrome DevTools
- Open Chrome DevTools by pressing Ctrl+Shift+I (or Cmd+Option+I on Mac).
- Navigate to the Performance tab.
- Reload the page to view the Core Web Vitals.
The devtools performance tab now displays information about Core Web Vitals, including the timing and element of the Largest Contentful Paint.
Measure the Largest Contentful Paint with Lab tools
Lab tools can measure the Largest Contentful Paint. Since the Core Web Vitals represent real life (or field) aspects of user experience lighthouse or lab results are not used by Google to measure the largest contentful paint. That means you should not use them either to determine if you are passing the Core Web Vitals!
Lab tools are best for comparing "before and after" snapshots of your LCP after making performance tweaks. Their strength lies in consistency. Browser factors like RTT (network speed and round trip time), CPU power, and other browser factors are standardized, so lab results are always comparable.
Some well know online lab tests can be found here:
- Lighthouse - LightHouse can also be used standalone (through NodeJS) for automated testing or in chrome devtools for a manual run.
- PageSpeed Insights - PageSpeed insights is a google-hosted tool that will give you the CrUX and LightHouse results for any webpage.
- WebPageTest - WebPageTest is probably the oldest and best know PageSpeed testing tool there is. It will give you pagespeed insights from your location of choice.
Measure the Largest Contentful Paint with Field data
Field data is the only data that actually matters for the Largest Contention Paint. Google uses real user metrics from their CrUX dataset to determine whether of not you pass or fail the Core Web Vitals.
The CrUX dataset is highly anonymized. This means that the CrUX data does not give you much detail on a page or device level. That is Why RUM monitoring is a great alternative for the CrUX data.
- PageSpeed Insights - PageSpeed insights can be used for both CrUX and LightHouse results for any webpage.
- Looker Studio - With the Looker Studio report you can connect to Google BigQuery and get a more detailed and historic overview of the Largest Contentful Paint CrUX real user data.
- CoreDash - CoreDash is Real User Metric (RUM) tracker that will give you complete unfiltered and real-time information about the Largest Contentful Paint
Break down the LCP into it's sub components
According to Google the Largest Contentful Paint can be broken down into 4 sub parts.
Here's a breakdown of key areas to focus on:
- Time to first byte - LCP is directly affected by TTFB, which measures the time it takes for the browser to receive the first byte of data from your server.
- Resource load delay - Minimize render-blocking resources like styles and scripts that delay the painting of content. Ensure the LCP element is prioritized during page load..
- Resource load time - Optimize the LCP element (often an image) for faster loading by using modern image formats and responsive images.
- Render delay - Even with optimized resources, the browser might be occupied with other tasks, especially JavaScript processing, which can delay LCP rendering.
Each of those focus areas can be optimized to improve the Largest Contentful Paint. To understand the steps you need to take please read Fix & Identify Largest Contentful Paint (LCP) issues
Improving the Largest Contentful Paint
Optimizing Largest Contentful Paint (LCP) requires addressing several factors that can slow down the rendering of the largest content element on your page. During page load different resources compete for network bandwidth and CPU processing power. Basically anything that happens before the LCP element is painted, whether network-related or CPU-intensive, can impact the LCP score
Need your site lightning fast?
Join 500+ sites that now load faster and excel in Core Web Vitals.
- Fast on 1 or 2 sprints.
- 17+ years experience & over 500 fast sites
- Get fast and stay fast!
Your Core Web Vitals questions answered
Improving the Largest Contentful Paint
How can lazy loading images improve or worsen LCP?
Lazy loading can optimize LCP by deferring the load of images until they are in the viewport, reducing the load on critical resources. However, if the LCP element itself is a lazy-loaded image, it can cause delays, as the browser must wait until the image comes into view. For critical images, avoid lazy loading or consider setting them to load earlier.
Are there any situations where optimizing for LCP might negatively impact user experience?
In some cases, aggressively optimizing for LCP (e.g., by loading a low-quality placeholder image quickly) might result in a good LCP score but a poor user experience. It's important to balance speed with quality.
Why is server response time critical for LCP?
Server response time is foundational for LCP because it determines how quickly the browser can start loading HTML and other resources. High Time to First Byte (TTFB) leads to delays in resource retrieval and page rendering, directly impacting LCP. Optimizing server response, caching HTML on a CDN, and reducing redirection chains can significantly enhance LCP by minimizing the wait before the page begins to load.
Do Core Web Vitals plugins work?
There are a lot of plugins and tools out there that try to improve the Core Web Vitals. For example wp-rocket.I can talk for hours about how I feel about those tools. I will spare you the details for now. The fact of the matter is that they sometimes improve the Core Web Vitals and sometimes they have very little effect.
It all depends on the nature of the 'Core Web Vitals mistakes' that you are trying to fix. Did you forget to lazy-load your images or forget to defer your scripts? Those tools might then improve the Core Web Vitals considerably. On the other hand, if your slowness is caused by 'critical scripts that change the layout of your page' (like a slider plugin) or 'a large DOM size' those plugins will often do more harm than good.
Basically a plugin will fix the issues that any good programmer could fix in a matter of hours. They won't fix and might even worsen the more complicated issues.
How can preloading and preconnecting resources help LCP, and what should be prioritized?
Preloading crucial resources (like CSS, JavaScript, and fonts) signals to the browser to prioritize them, which reduces initial rendering time and enhances LCP. Preconnect to important third-party origins, such as CDNs, to minimize DNS lookup and connection times. Prioritize preloading images or fonts that contribute to LCP directly.
Should I focus on mobile or desktop?
That is a great question. As a rule of the thumb you should focus on mobile.
When you manage to pass mobile Core Web Vitals it will become a lot easier to also pass the Desktop Core Web Vitals (if you are not passing them already). This is because your average mobile device is slower because of lower bandwidth, less memory and less CPU power then your average desktop.
There are a few exceptions though. On a desktop the visible viewport is larger. It is common for a mobile LCP element to be a text based element while on a Desktop a lower placed image will become the largest Contentful Paint element. On desktop the possibility for (smaller) layout shift also increases because there is just more screen and more visible elements to shift..
What are common pitfalls with image format optimization for LCP, and how can they be avoided?
Choosing the wrong image format can lead to longer load times and a slower LCP. Formats like JPEG are generally best for photographs, while SVG or PNG work well for icons and logos. Additionally, modern formats like WebP can improve compression. Make sure the browser fallback settings are correct when using formats that may not be universally supported.
Largest Contentful Paint in General
How does LCP differ from other loading metrics like First Contentful Paint (FCP)
LCP measures the loading time of the largest content element visible in the viewport, while FCP measures when the first piece of content is rendered. LCP is generally considered a better indicator of when a page is ready for interaction, as it focuses on the main content rather than potentially small, less significant elements.
How does the position of the LCP element on a page affect its load time?
The position of an element affects its priority in the rendering process. Content “above the fold” (visible upon loading without scrolling) is prioritized by the browser, while content below this line is often deprioritized. For LCP, this means that elements close to or above the fold should be optimized, as they’re most likely the ones browsers focus on during load. If a slow-loading element is positioned here, it can drastically impact LCP.
Can LCP elements change during page load?
Yes, the LCP element can change as the page loads. The browser reports a new LCP candidate when a larger content element is rendered. This means the final LCP element might not be the first large element to appear on the page
How does LCP measurement differ between lab and field data?
Lab data (from tools like Lighthouse) measures LCP in a controlled environment, while field data (from real user metrics) can vary based on network conditions, devices, and other factors. Field data is generally considered more representative of actual user experience
Measuring the Largest Contentful Paint
Why does my LCP vary between page loads?
LCP variation is often due to differences in network conditions, device capabilities, caching, and server response times. When the LCP element depends on an image or resource loaded via a CDN or third-party source, fluctuations in response times from these services can also lead to inconsistent LCP. In these cases, consider preloading critical resources, implementing a Content Delivery Network (CDN) with edge caching, or self-hosting assets to minimize variability.
How do JavaScript-heavy pages impact LCP, and what can be done about it?
JavaScript (JS) affects LCP because JS execution often blocks the rendering of other elements. For pages with heavy JS, the browser may delay rendering the LCP element until JS execution is complete. Minimizing, deferring, or asynchronously loading non-critical JS can free up the main thread, allowing for faster rendering of the LCP element.
Is there a specific size threshold where images impact LCP more heavily?
While there isn’t a set threshold, large images generally increase load time and can slow down LCP. For images above the fold, strive to keep dimensions and file sizes optimized. This includes resizing images for the appropriate device, compressing files, and using responsive image formats like WebP to reduce data load.
How can font loading delay affect LCP, and what are ways to mitigate this?
If an LCP element uses custom web fonts, the browser might delay rendering it until the font is fully loaded. This is known as "Flash of Invisible Text" (FOIT) or "Flash of Unstyled Text" (FOUT). To avoid delays, consider font-display: swap to allow fallback fonts, or preloading key fonts to make them available sooner.
How does CLS (Cumulative Layout Shift) interact with LCP, especially on dynamic pages?
On dynamic or interactive pages, layout shifts can push down LCP elements, affecting both CLS and LCP scores. A layout shift can delay the time when the LCP element is fully rendered. Reduce dynamic layout changes on load, reserve space for elements prone to layout shifts, and avoid late-loading advertisements or injected content.
What are the hidden costs of background images and their impact on LCP?
Background images in CSS may seem harmless, but if they're set to large, high-quality resolutions, they can heavily impact LCP, especially if used for above-the-fold content. Background images load differently than HTML image tags, and the browser might deprioritize them. Consider using tags for critical visual content to ensure faster loading.
How does viewport size impact the LCP element, and should this be accounted for in testing?
The LCP element can change based on viewport size; for example, on mobile, the LCP might be the header image, while on desktop, it could be a hero banner. Test LCP at different viewport sizes to identify which element is rendered and optimized for each view, as this will vary based on device and can affect performance metrics.