Largest Contentful Paint

W3C First Public Working Draft,

More details about this document
This version:
Latest published version:
Editor's Draft:
Test Suite:


This document defines an API that enables monitoring the largest paint an element triggered on screen.

Status of this document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

This document was published by the Web Performance Working Group as a First Public Working Draft using the Recommendation track. Publication as a First Public Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

GitHub Issues are preferred for discussion of this specification.

This document is governed by the 2 November 2021 W3C Process Document.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

1. Introduction

This section is non-normative. The LargestContentfulPaint API enables developers to gain visibility into the loading and rendering process of the web pages, in order for them to be able to optimize it.

Developers today don’t have a reliable metric that correlates with their user’s visual rendering experience. Existing metrics such as First Paint and First Contentful Paint focus on initial rendering, but don’t take into account the importance of the painted content, and therefore may indicate times in which the user still does not consider the page useful.

Largest Contentful Paint (LCP) aims to be a new page-load metric that:

The largest paint during the loading process of the page is likely to signify a meaningful event from the user’s perspective, and is therefore something we want to expose by default to developers, enabling performance teams, analytics providers and lab-based measurement tools to collect those metrics without requiring extra annotation work by the folks creating the content itself.

The API relies heavily on [ELEMENT-TIMING], which can be thought of as the low-level primitive that this high-level feature is built on top of. For cases where the content creators are willing to annotate their content and indicate the important points in the page’s loading cycle, Element Timing is the API that will provide them more control over the elements that get reported.

1.1. Elements exposed

The Largest Contentful Paint API will only expose element types that are already exposed by the Element Timing API. In this case, there is no need to annotate them with the elementtiming attribute.

1.2. Largest content

The algorithm used for this API keeps track of the content seen so far. Whenever a new largest content is found, a new entry is created for it. Content that is removed is still considered by the algorithm. In particular, if the content removed was the largest, then a new entry is created only if larger content is ever added. The algorithm terminates whenever scroll or input events occur, since those are likely to introduce new content into the website.

1.3. Usage example

The following example shows an image and a large body of text. The developer then registers an observer that gets candidate entries for the largest paint while the page is loading.

<img src="large_image.jpg">
<p id='large-paragraph'>This is large body of text.</p>
const observer = new PerformanceObserver((list) => {
  let perfEntries = list.getEntries();
  let lastEntry = perfEntries[perfEntries.length - 1];
  // Process the latest candidate for largest contentful paint
observer.observe({entryTypes: ['largest-contentful-paint']});

1.4. Limitations

The LargestContentfulPaint API is based on heuristics. As such, it is error prone. It has the following problems:

2. Largest Contentful Paint

Largest Contentful Paint involves the following new interface:

2.1. LargestContentfulPaint interface

interface LargestContentfulPaint : PerformanceEntry {
    readonly attribute DOMHighResTimeStamp renderTime;
    readonly attribute DOMHighResTimeStamp loadTime;
    readonly attribute unsigned long size;
    readonly attribute DOMString id;
    readonly attribute DOMString url;
    readonly attribute Element? element;
    [Default] object toJSON();

Each LargestContentfulPaint object has these associated concepts:

The entryType attribute’s getter must return the DOMString "largest-contentful-paint".

The name attribute’s getter must return the empty string.

The startTime attribute’s getter must return the value of this’s renderTime if it is not 0, and the value of this’s loadTime otherwise.

The duration attribute’s getter must return 0.

The renderTime attribute must return the value of this’s renderTime.

The loadTime attribute must return the value of this’s loadTime.

The size attribute must return the value of this’s size.

The id attribute must return the value of this’s id.

The url attribute must return the value of this’s url.

The element attribute’s getter must return the value returned by running the get an element algorithm with element and null as inputs.

Note: The above algorithm defines that an element that is no longer descendant of the Document will no longer be returned by element's attribute getter, including elements that are inside a shadow DOM.

This specification also extends Document by adding to it a largest contentful paint size concept, initially set to 0. It also adds an associated content set, which is initially an empty set. The content set will be filled with (Element, Request) tuples. This is used for performance, to enable the algorithm to only consider each content once.

Note: The user agent needs to maintain the content set so that removed content does not introduce memory leaks. In particular, it can tie the lifetime of the tuples to weak pointers to the Elements so that it can be cleaned up sometime after the Elements are removed. Since the set is not exposed to web developers, this does not expose garbage collection timing.

3. Processing model

3.1. Potentially add LargestContentfulPaint entry

Note: A user agent implementing the Largest Contentful Paint API would need to include "largest-contentful-paint" in supportedEntryTypes for Window contexts. This allows developers to detect support for the API.

In order to potentially add a LargestContentfulPaint entry, the user agent must run the following steps:


intersectionRect, a DOMRectReadOnly

imageRequest, a Request

renderTime, a DOMHighResTimestamp

loadTime, a DOMHighResTimestamp

element, an Element

document, a Document



  1. Let contentIdentifier be the tuple (element, imageRequest).

  2. If document’s content set contains contentIdentifier, return.

  3. Append contentIdentifier to document’s content set

  4. Let window be document’s relevant global object.

  5. If either of window’s has dispatched scroll event or has dispatched input event is true, return.

  6. Let url be the empty string.

  7. If imageRequest is not null, set url to be imageRequest’s request URL.

  8. Let id be element’s element id.

  9. Let width be intersectionRect’s width.

  10. Let height be intersectionRect’s height.

  11. Let size be width * height.

  12. Let root be document’s browsing context’s top-level browsing context’s active document.

  13. Let rootWidth be root’s viewport’s width, excluding any scrollbars.

  14. Let rootHeight be root’s viewport’s height, excluding any scrollbars.

  15. If size is equal to rootWidth times rootHeight, return.

  16. If imageRequest is not null, run the following steps:

    1. Let naturalWidth and naturalHeight be the outputs of running the same steps for an img's naturalWidth and naturalHeight attribute getters, but using imageRequest as the image.

    2. Let naturalSize be naturalWidth * naturalHeight.

    3. Let displayWidth and displayHeight be the outputs of running the same steps for an img's width and height attribute getters, but using imageRequest as the image.

    4. Let displaySize be displayWidth * displayHeight.

    5. Let penaltyFactor be min(displaySize, naturalSize) / displaySize.

    6. Multiply size by penaltyFactor.

  17. If size is less than or equal to document’s largest contentful paint size, return.

  18. Let contentInfo be a map with contentInfo["size"] = size, contentInfo["url"] = url, contentInfo["id"] = id, contentInfo["renderTime"] = renderTime, contentInfo["loadTime"] = loadTime, and contentInfo["element"] = element.

  19. Create a LargestContentfulPaint entry with contentInfo, and document as inputs.

3.2. Create a LargestContentfulPaint entry

In order to create a LargestContentfulPaint entry, the user agent must run the following steps:


contentInfo, a map

document, a Document



  1. Set document’s largest contentful paint size to contentInfo["size"].

  2. Let entry be a new LargestContentfulPaint entry with document’s relevant realm, with its

    • size set to contentInfo["size"],

    • url set to contentInfo["url"],

    • id set to contentInfo["id"],

    • renderTime set to contentInfo["renderTime"],

    • loadTime set to contentInfo["loadTime"],

    • and element set to contentInfo["element"].

  3. Queue the PerformanceEntry entry.

3.3. Modifications to the DOM specification

This section will be removed once the [DOM] specification has been modified.

We modify the event dispatch algorithm as follows.

Right after step 1, we add the following step:

3.4. Modifications to the HTML specification

This section will be removed once the [HTML] specification has been modified.

Each Window has has dispatched scroll event, a boolean which is initially set to false.

4. Security & privacy considerations

This API relies on Element Timing for its underlying primitives. LCP may expose some element not exposed by Element Timing in case that they are smaller than Element Timing’s limits, but are still the largest elements to be painted up until that point in the page’s loading. That does not seem to expose any sensitive information beyond what Element Timing already enables.


Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.


Terms defined by this specification

Terms defined by reference


Normative References

Simon Pieters. CSSOM View Module. 17 March 2016. WD. URL:
Anne van Kesteren. DOM Standard. Living Standard. URL:
Element Timing API. cg-draft. URL:
Nicolás Peña Moreno; Tim Dresser. Event Timing API. ED. URL:
Anne van Kesteren. Fetch Standard. Living Standard. URL:
Simon Pieters; Chris Harrelson. Geometry Interfaces Module Level 1. 4 December 2018. CR. URL:
Yoav Weiss. High Resolution Time. 28 January 2022. WD. URL:
Anne van Kesteren; et al. HTML Standard. Living Standard. URL:
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL:
Nicolas Pena Moreno. Performance Timeline. 2 December 2021. CR. URL:
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL:
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL:

IDL Index

interface LargestContentfulPaint : PerformanceEntry {
    readonly attribute DOMHighResTimeStamp renderTime;
    readonly attribute DOMHighResTimeStamp loadTime;
    readonly attribute unsigned long size;
    readonly attribute DOMString id;
    readonly attribute DOMString url;
    readonly attribute Element? element;
    [Default] object toJSON();