Largest Contentful Paint or LCP, is a crucial metric for the user experience as it measures the time a page takes to load the larger content element into the visible area following a user’s request. With the countdown to the Google Page Experience update still continuing, today we focus on the third cornerstone of this revolution in the calculation and evaluation of the experience offered by the pages.

What is the Largest Contentful Paint metric

LCP is an important and user-centric indicator to measure the loading speed perceived by users, because it “marks the point in the loading timeline of the page where the main content of the page is probably loaded“, says Philip Walton inside the precious guide on web.dev.

Basically, the Largest Contentful Paint indicates the time it takes a page to load its more challenging content from the window taken into account by the device; usually, the larger content is an image, a video or a large text element at the block level.

Thus, the LCP measures the wait needed for the user to render the larger and more visible element, and a quick data “helps to reassure the user that the page is useful”, because it is a signal that the URL is being uploaded.

An indicator of perceived loading’s real speed

Measuring the speed with which the main content of a web page is loaded and is visible to users is one of the most challenging challenges for developers, who have tried various paths: as Walton tells, older metrics “as load or Domcontentloaded are not good because they do not necessarily correspond to what the user sees on their screen”, and the same First Contentful Paint (FCP), while being user-focused, “only captures the beginning of the loading experience” and is therefore too generic, because “if a page shows a home screen or an upload indicator, this time is not very relevant to the user”.

This is why the LCP value has been imposed which, by calculating the loading time of the largest and most problematic element on the page, it demonstrates a more accurate way to measure when the main content of a page is actually loaded for how it is perceived by the user.

LCP and Core Web Vitals

It is therefore not surprising that Google chose to include the Largest Contentful Paint among the Core Web Vitals, the essential web signals that allow to measure concretely the experience provided by the pages and that from May will become a ranking factor together with other technical signals, as we know well.

Next to the indicator to know the visual stability (Cumulative Shift Layout) and that of interactivity (First input delay), then, Google adds the measurement of loading as a discriminating for pages that offer positive experiences and those that, instead, are lacking.

How to measure the LCP: scores and meaning

The Largest Contentful Paint metric then shows the rendering time needed for the largest image or text block visible within the window.

An LCP score is good when less than 2.5 seconds, while a value greater than 4 seconds is very low and “everything in the middle needs to be improved”, according to the expert.

La rappresentazione dei valori di LCPTo provide a good user experience, sites should strive to secure the LCP within the first 2.5 seconds from the start of page loading; to be sure to achieve this goal for most of our users, A good threshold to measure is the 75 % percentage of page uploads in a certain range (aggregated Lcps), segmented between mobile devices and desktops.

In practical terms, to provide this value, the Google Search Console monitors loading times and orders them increasingly, from the smallest to the largest, taking as a measure the value of time that corresponds to the 75th percentile, the first 75% of times measured. This choice is explained by the need to understand the largest majority of times recorded so as to have a reliable reference that for most users the loading experience was positive.

Which elements are taken into account

As currently specified in the Largest Contentful Paint API, the types of elements considered for Largest Contentful Paint are few by choice (to keep things simple at the beginning, with the possibility of adding more elements in the future), namely:

  • <img> elements
  • <image> elements inside an <svg> element
  • <video> elements (the poster image is used)
  • An element with a background image loaded via the url() function (as opposed to a CSS gradient)
  • Block-level elements containing text nodes or other secondary text elements at the line level.

How the size of an element is calculated

The size of the item reported for Largest Contentful Paint is typically “the size visible to the user within the window”. If the element extends outside the viewport, or if any of the elements are cut or overflow is not visible, those parts are not counted for the size of the element.

For image elements that have been resized from their intrinsic size (that is, the original one, in Google’s language), the visible size or the intrinsic size is reported “depending on which is the smallest”. For example, images “reduced to a size much smaller than the intrinsic one will report only the sizes in which they are displayed, while images stretched or expanded to a larger size will report only their intrinsic dimensions”.

Simplifying with an example: if we load an image of 2048 pixels wide and 1152 pixels high, 2048 x 1152 are considered “intrinsic” dimensions. If we resize the image to 640 x 360 pixels, 640 360 will be the visible size; for the purpose of calculating the image size, Google uses the smaller size among the images of intrinsic and visible size, and it is considered a best practice to make sure that the intrinsic size of the image corresponds to the visible size, because so the recurring will be downloaded faster and the LCP score will increase.

For text elements, only the size of their text nodes is considered (the smallest rectangle that encloses all text nodes).

For all elements, any margin, fill or edge applied via CSS is not considered.

Tools to measure the Largest Contentful Paint

LCP is an easy metric to understand: just look at the web page and determine which is the largest text block or image and then optimize it, making it smaller or removing anything that can prevent a quick download.

The LCP data can be measured in the laboratory or on the field and is available in several instruments:

  1. Field tools (actual measurement of a site).
  • Chrome User Experience Report
  • PageSpeed ​​Insights
  • Search Console (Core Web Vitals report)
  • JavaScript web-vitals library
  1. Lab tools (provide a virtual score based on a simulated scan using algorithms that approximate the Internet conditions that a typical user might encounter on a smartphone).
  • Chrome DevTools
  • Lighthouse
  • WebPageTest

Optimizing the Largest Contentful Paint

Having clarified the main descriptive aspects of this metric, let’s find out what we can do in practice to improve the performance on LCP and then speed up the rendering on the screen of the main content of the page to provide a better user experience.

According to Google, the most common causes of a poor LCP are:

  • Slow server response times
  • Javascript and CSS that block the rendering
  • Slow Resource Loading Times
  • Client side rendering

For each of these fronts, Houssein Djirdeh (still on web.dev) offers a detailed guide to fix the issue and optimize the Largest Contentful Paint.

Solving the server delay issues

The longer it takes a browser to receive content from the server, the more time it will take to view anything on the screen, and then increase the server response time “directly improves every single page loading metric, including LCP”.

The expert recommends that you first focus on improving “how and where your server manages your content“, using the Time to First Byte (TTFB) metric to measure server response times and improve the data in one of the following ways:

  • Optimize the server, analyzing and improving the efficiency of the server-side code to directly influence the time needed for the browser to receive data (and solving any overloaded server problem).
  • Direct users to a nearby CDN network (to avoid users having to wait for network requests to distant servers).
  • Cache asset: cache storage is suitable for sites with static HTML code, which should not be changed at every request, and prevents its unnecessary recreation, minimizing the use of resources.
  • Serve cache-first HTML pages: through a service worker executed in the background of the browser it is possible to intercept the requests from the server, storing in the cache part or all the contents of the HTML page and updating the cache only when the content has changed.
  • Establishing third-party connections in advance: Server requests originating from third parties may also have an impact on LCP, especially if they are needed to view critical content on the page.

Intervening on JavaScript and CSS rendering blocks

Scripts and stylesheets are both render blocking resources that delay FCP and consequently LCP; Google invites you to “defer any non-critical Javascript and CSS so to speed up the loading of your webpage’s main content”.

More precisely, the net advice is to “completely remove any unused CSS or move it to another stylesheet if used on a separate page of your site”. One way to do this is to use loadCSS to load files asynchronously for any CSS not needed for initial rendering, using rel = “preload” and onload.

Similar work must be done to optimize Javascript, starting with “downloading and offering users the minimum amount of Javascript needed“, because “reducing the amount of Javascript blocks results in faster rendering and, consequently, a better LCP”.

Improving the loading time of slow resources

There are some ways to ensure that critical files are uploaded as quickly as possible, such as:

  • Optimize images.
  • Preload important resources (such as fonts, images or videos above the fold and CSS or Javascript for critical paths).
  • Compress text files.
  • Provide different resources based on network connection (Adaptive serving)
  • Cache assets using a service worker

Optimizing client-side rendering

Many sites use client-side Javascript logic to render pages directly in the browser, but this may have a negative effect on LCP when using a large Javascript package.

In particular, if no optimizations are in place to prevent it, users may not see or interact with any content on the page until all critical Javascript has finished downloading and running.

When creating a client-side rendering site, Djirdeh suggests making three types of optimization:

  • Minimize critical Javascript.
  • Use server side rendering.
  • Use the pre-rendering.

Call to action