This article is translated, focusing on Web Vitals Metrics, into 01 articles in the series


Original link:
Largest Contentful Paint (LCP)

preface

It has always been difficult for developers to measure the speed at which major content loads and displays during page loads. Because Load and DOMContentLoaded are not necessarily related to what the user sees on the screen, they are not good enough (they are not user-facing metrics). FCP (First Contentful Paint) is an indicator based on the user dimension, but it only focuses on the initial stage of page loading. If there is a flash or loading component on the page, it cannot reflect when the main content of the user’s concern is loaded. Later we recommended using FMP and SI (one of the six lighthousemetrics), but they are also complex, ambiguous, and even wrong, and do not accurately identify when the main content of the page is loaded. Simplicity is king. Research shows that:

The most important part of the page load phase is often the largest part of the page render area.

1 LCP definitions and standards

What is the LCP? LCP reflects the time it took to render the largest image or text block from the page loading to the page viewport.LCP<2.5s means the score is GOOD.

1.1 What are the Contentful elements in the LCP?

What elements might be candidates for LC? , ,

1.2 How to measure the element size?

The size of the LCP element is the size of the element visible on the viewport (excluding the size of the element beyond the viewport, elements that have been clipped, and elements that are not visible). For images that have changed their inherent size, the size is either the visible size of the image or the inherent size of the image. For example, the size of a reduced image counts only its displayed size, while the size of an enlarged image counts only its inherent size. For a text element, only the size of its text node is calculated. For all elements, the margin, padding, and border set in the CSS are not counted.

1.3 When does LCP occur? (About the details of it)

Web page loading is done step by step, so LC changes. To counter this, the browser distributes a PerformanceEntry of type Larse-Contentful-Paint to identify LC elements when the browser draws the first frame. Later, when subsequent frames are rendered, the browser will distribute additional PerformanceEntry whenever the LC element changes. For example, if there is text and a hero image on the page, the browser may render the text at first. At this point, the browser will distribute an element reference that points to a

or

PerformanceEntry. Later, once the Hero image is loaded, the browser will distribute an Element reference to an Entry of type larger-contentful-paint that points to .

LC elements can only be visible elements that have already been rendered, so other smaller elements may initially be detected as LC elements, but as soon as the larger elements are rendered, they will be updated to the latest through the PerformanceEntry object. If an element that has been detected as LC is removed from the viewport, it will remain LC as long as no larger element is rendered. When the user interacts with the page, the browser stops distributing new Entry.

Load time and render time: For security reasons, the render timestamp of an image without a Time-Allow-Origin response header will not be exposed to cross-domain images. Only the render time is exposed. The following example shows the processing of elements for which render time is not available. We recommend adding Timing-Allow-Origin response headers to make the results more accurate.

In addition to the timing of the LC elements mentioned above, the layout and size of the elements can also change. To reduce the performance penalty associated with calculating and distributing PerformanceEntry,Changes in element size or position do not result in new LC candidatesOnly the initial size and position of the element on the viewport is considered. This means that images that are not initially rendered on screen but later rendered will not be flagged and detected. This also means that elements that were initially loaded on the viewport and are no longer displayed will still be marked with their initial viewport size.

Example:



The LC element has changed in both timelines in the above figure. In the first example, the largest LC at the beginning was eclipsed by the larger LC that later appeared; In the second example, the previous largest LC no longer exists and is replaced by a new one.

It is not uncommon for later loads to be larger than the previous ones during the page load, and the following figure shows the LCP before the page load is complete.



First example: Logo loads early and remains an LC element even as other elements load gradually. Second example: Text paragraphs are LC elements until the image and logo are fully loaded. Since a single image is still smaller than a paragraph, it remains an LC element throughout the load.

What are the tools for measuring LCP?

We divide the analysis tools into Field tools and Lab development tools. The Field instruments

Chrome User Experience Report


PageSpeed Insights


Search Consol


JS lib: web-vitals

Lab tools

Chrome DevTool


LightHouse


WebPageTest

JavaScript (1) Largest Contentful Paint API + PerformanceObserver

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

The example in the code is logged out for each LCP candidate. In general, the startTime of the final entry is just LCP, but there are some exceptions. Examples are background TAB pages, forward and back caching, and the LCP in the iframe is ignored. (2) The use of developed JavaScript libraries can help us to mask these details, as follows:

import {getLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
getLCP(console.log);

4 What if the largest element is not the most important?

This is where you need the Element Timing API for custom metrics. No analysis is done here.

5 Four factors affecting LCP,

Subsequent chapters will provide targeted optimization schemes. The four aspects that affect the LCP include: (1) slow server response during the request phase; (2) JS and CSS blocked during rendering; (3) Resource loading time; (4) client-side rendering.

How to tune the LCP, see Tuning the LCP. Additional optimization guidelines for improving the LCP can be found in: 1. Optimize the Critical Render Path 2. Optimize CSS 3. Optimize JavaScript 4. Optimize Images 5. 6. Use PRPL mode