For teams looking to benchmark and improve how their page performance impacts customer experience, there is a new metric to focus on: Largest Contentful Paint (LCP).
Developed by Google and introduced in Chrome 77, LCP measures how fast the main content of a webpage is displayed to the user.
New Relic is already reporting this metric as part of real user monitoring (RUM), and we’ll walk through why and how to use it below. It’s also a major contributor to Google’s algorithm in recent years, making it a high priority for web teams.
Traditional measurements of webpage speed
Because today’s webpages are so dynamic, when it comes to measuring how fast a page loads, there is no single metric that can totally capture and convey end-user experience. Webpages load in pieces—first the main HTML document, followed by resources such as images, CSS, scripts, and AJAX calls. Browsers render parts of a webpage as they become available, which means that content is presented to the user in stages.
When it comes to measuring the speed of a web page, we need to ask what exactly is important to measure:
- Is it the complete webpage with all its resources?
- Is it specific content that should be presented as quickly as possible?
- Or perhaps is it simply enough content to keep the user engaged?
Here at New Relic, we’ve carefully added essential metrics needed to measure end-user performance, including paint timing metrics, interactivity metrics, and long-running tasks for your lab data (Synthetics). And that’s why we’re now excited to introduce you to LCP.
Existing modern metrics
Let’s quickly review today’s main performance metrics:
Window Load Event
Webpage has been completely loaded and rendered
First Paint (FP)
First visual change after navigation change (typically blank screen)
First Contentful Paint (FCP)
First content painted to the screen
First Meaningful Paint (FMP)
When the main layout change occurred (most elements rendered)
A score of how quickly content is rendered to the screen (start to finish)
Measures when a specific element is displayed
FP and FCP represent the time when the browser started rendering something (anything) to the screen. They are important to measure but don't tell us when the important content is displayed to the user.
FMP, speed index, and hero elements are the standout past attempts to measure when important content is displayed. FMP and speed index are not available in RUM, and the hero element requires custom instrumentation and is focused on a specific element only.
What is Largest Contentful Paint?
LCP measures when the largest element visible to the user was rendered. The elements that are included in LCP include images, blocks of text, and videos. Elements outside of the viewport and background images are not included. For a more detailed explanation, see this post from Google.
The nice thing about LCP is that it is easy to understand, works consistently for most websites, and it can be used in RUM.
Below is an example timeline from Google, which shows what is displayed to the user when FCP and LCP are measured:
The image in the middle of the page (in the last screenshot) is considered LCP, in this case, since it is the biggest element in the visible part of the webpage.
How to Measure LCP
There are several ways of measuring LCP, some of the common methods are highlighted below. Note that the LCP score for one method may be slightly different from another. But generally, each method will give you insight into whether your LCP is good, poor, or needs improvement.
Google search console report
Google’s search console leverages real world usage data to generate a report of how your pages perform. On the console, navigate to see a chart of general trends, drill down by platform and click Open report. Next, toggle the Poor, Need improvement, or Good tabs to see how the URLs on your website perform. An LCP score <=2.5s is Good, <=4s Needs improvement and >4s is Poor.
Using webpagetest, you can carry out a core web vitals’ test. All you need to do is to enter your site URL and click start test. Your webpage performance test report will be generated within a short period and you can see the LCP score under observed web vitals metrics.
Google lighthouse (Chrome DevTools)
Chrome DevTools has a Lighthouse tab that you can use to measure the LCP score. While on the tab, you simply need to hit the “generate report” button and you can check your score as well as other metrics once the test is complete.
All of these tools are great for just quick check ins, but if you want to really get in the weeds of what is causing slow loading time for your critical content, you’ll need something more robust- Ideally, an observability platform with extensive monitoring functions.
New Relic’s browser agent is the best option for measuring LCP, especially if you’re already using New Relic to measure other aspects of your site.
The latest version of the New Relic Browser agent script (v1167) captures LCP out of the box and takes into account a few intricacies of how this metric is reported by a browser.
What makes our tool different
For one, a browser reports multiple values as it observes them. As a result, it is important to wait long enough to capture the element that is actually the largest while the page is loading. The New Relic Browser script does this for you automatically by capturing the latest reported LCP value up to one minute since the start of navigation.
Another thing to consider is that Google Chrome will stop reporting the LCP values after the user started interacting with the page. This is due to the fact that user interaction may affect what is rendered to the page. The New Relic script takes all this into account as well.
How to improve Largest Contentful Paint
Query Largest Contentful values
To get started, you’ll need to first understand and benchmark where your LCP is now and what is impacting it the most.
The collected LCP values are stored as a new type of the PageViewTiming event with the name attribute set to “largest-contentful-paint.” This extends our existing set of timing metrics, such as first paint, first contentful paint, first interaction, and window unload.
Here is an example of a query to chart LCP in comparison with FCP over the last 24 hours:
FROM PageViewTiming SELECT percentile(largestContentfulPaint, 90), percentile(firstContentfulPaint, 90) TIMESERIES SINCE 1 DAY AGO
And here is a query to display a histogram of LCP values from the last hour, showing the number of collected events with values between 0 to 1s in 10 buckets (each 100ms):
FROM PageViewTiming SELECT histogram(largestContentfulPaint, 1000, 10) SINCE 1 hours ago
In addition to the timing value, we also collect the id of the element that was considered the largest and its size. This can be used, for example, to show which elements are contributing to LCP values for cases where the content is dynamic and varies in size. This query shows LCP grouped by element ID and its size:
FROM PageViewTiming SELECT percentile(largestContentfulPaint, 90) WHERE elementId != '' FACET elementId, elementSize
Lastly, the PageViewTiming events include common attributes such as the page URL, geo attributes (country, region, city), and browser (user agent) information. These attributes can be used to filter and group queries. This example query shows how to display 90th percentile LCP values for a specific page, grouped by country:
FROM PageViewTiming SELECT percentile(largestContentfulPaint, 90) WHERE pageUrl LIKE 'https://rpm.newrelic.com/accounts/%/browser' FACET countryCode
It’s worth noting that similar to FP and FCP, not all browsers support LCP. Currently, it is only available in Chrome 77 and higher. At New Relic, we see about 50% of all user requests coming from the Chrome versions that support LCP.
This is similar to the other two existing paint timing metrics (FP and FCP). Chrome is the only browser that currently captures these three metrics.
While LCP is not currently standardized across browsers, Google Chrome represents the largest percentage of browser traffic and is in many ways setting the standards for web performance monitoring. It is likely that this metric becomes a standard.
Understand your best opportunities for improvement
Now that you have your LCP benchmark and understand what aspects of your site have a less efficient LCP than you’d like (Google recommends 2.5 seconds or less for 75% of visits), you can prioritize possible fixes.
There are some basic steps to help improve your LCP at this point. Generally best practices include optimizing load times, reducing load delays, and improving time to first byte.
- Render LCP elements immediately after resource loading: You certainly want to avoid a situation where LCP starts loading later than other resources on your web page. Asynchronous loading is the ideal. To do this, first, you must ensure that your LCP resource can be discovered by the browser’s preload scanner in the initial HTML document response. Second, you can optimize the priority of the LCP resource using the fetchpriority attribute.
- Optimize resource load time: You can optimize resource load time through minification or modernization of resources as well as optimization of resource serving format. In particular, minification will help reduce file size by reducing lines of code. This can be done manually or via the use of plugins. Also, you can optimize images by preloading hero images and ensuring all images are in the right size and format.
- Improve time-to-first byte: To do this, you must ensure you have a proper web hosting service. Typically, the quality of web hosting has impacts on the overall user experience of your site, not just your LCP. Therefore, it is worth getting a reliable hosting service. In addition, it is imperative to ensure that your web servers function efficiently. You can do this by implementing server-side caching and upgrading to a server with better storage and CPU capabilities. Another way to improve time-to-first byte is to ensure that your database is configured correctly.
The impact of Large Contentful Paint going forward
When looking at page load performance, no one metric tells the whole story. The newly available metric LCP is probably the most representative metric for measuring the perceived performance of a webpage in RUM. It is reliable, consistent, easy to understand, and available in real user monitoring.
Not only has this metric become vital for improving how a user experiences your site (and whether or not they stay on the site), it’s also now a metric under Google’s watchful radar. This means that your site’s LCP will likely impact how many visitors are coming to your site from valuable search engines.
New Relic is now collecting this metric and makes it very easy to chart, filter, group, and compare to other existing timing metrics. We encourage our customers to use this new metric as part of an expanding toolbox in Browser.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.