Core Web Vitals Part 1: Largest Contentful Paint (LCP)

Since LCP tests rendering time, the lower your ratings, the better, because your users can see the required content faster.

Having said that, Google has listed the following LCP value thresholds:

The categories of elements considered for Largest Contentful Paint are currently defined in the Largest Contentful Paint API:

• elements with 
• elements contained within an element
• An element with a background image that was obtained using the url() function (as opposed to a CSS gradient)
• Block-level elements containing text nodes or other inline-level text elements children.

 

 

LCP, along with Cumulative Layout Shift and First Input Delay, will be used as a minor ranking element in mobile search when the Page Experience upgrade goes live in June 2021.

Even more specifically, hitting the recommended benchmarks for all three measures will decide whether or not a badge is shown next to your site in search results, which would almost certainly affect your clickthrough performance!

Google can use the field data obtained from Google Chrome users on your website. These usage statistics are saved in the Chrome User Experience Report, allowing you to optimise your site using the same data as Google uses for rating.

Even if you aren’t concerned about Core Web Vitals being a ranking consideration, I suggest concentrating on LCP when optimizing your web performance.

Google used this measure for a reason: it correlates well with metrics measuring user behavior.

If you’re struggling to improve your conversion rates, time spent on-page, or any other behavior indicators that have a direct effect on your business, optimizing your render performance would undoubtedly help. It was deliberate to reduce the elements to this small number in order to keep things simple at first. If further research is conducted, additional elements (e.g. svg>, video>) can be included in the future.

The size recorded for Largest Contentful Paint is usually the size noticeable to the user inside the viewport. Whether an element stretches outside the viewport, or if any part of it is clipped or has non-visible excess, those parts are not included in the element’s size.

The size that is registered for image elements that have been resized from their intrinsic size is either the observable size or the intrinsic size, whichever is smaller. Images that have been compressed to a scale that is much less than their intrinsic size, for example, will only report the size at which they are viewed, while images that have been enlarged or increased to a greater size will only report their intrinsic sizes.

Only the size of the text nodes is taken into account for text elements (the smallest rectangle that encompasses all text nodes).

Any margin, padding, or border added through CSS is ignored for all elements.

Since web pages always load in stages, it’s possible that the largest element on the website will change.

To deal with this possibility of change, the browser sends a PerformanceEntry of type largest-contentful-paint defining the largest contentful element as soon as the browser has painted the first frame. However, after making subsequent frames, it will dispatch another PerformanceEntry if the largest contentful entity shifts.

For eg, on a page with text and a hero image, the browser may initially only render the text, at which point the browser may dispatch a largest-contentful-paint entry, the element property of which will most likely reference a
or

. After the hero picture has finished loading, a second largest-contentful-paint entry will be dispatched, with its element property referencing the

It’s worth noting that an entity can only be called the largest contentful element until it’s rendered and accessible to the user. Images that have not yet loaded are not regarded as “rendered.” Neither text nodes nor web fonts are used during the font block period . In such instances, a smaller element will be reported as the largest contentful element, but once the larger element has finished rendering, it will be reported by a different PerformanceEntry object

A page can add new elements to the DOM when new content becomes available, in addition to late-loading images and fonts. A new PerformanceEntry will be recorded if any of these new elements is greater than the previous largest contentful element.

If the largest contentful element in the viewport is omitted (or even removed from the DOM), it will remain the largest contentful element until a larger element is rendered. Since user activity often affects what is available to the user, the browser may stop reporting new entries as soon as the user communicates with the page (via a tap, scroll, or keypress) (which is especially true with scrolling).

Changes to an element’s size or position do not produce new LCP candidates to maintain the performance overhead of measuring and dispatching new performance entries down. The element’s original size and position in the viewport are the only factors taken into account.

Photos that are rendered off-screen and then transition on-screen may not be reported as a result. It also ensures that elements rendered in the viewport but then pulled out of view can still report their original in-viewport size.

Here are a few examples of when the Largest Contentful Paint appears on a few well-known websites:

You can calculate the site’s LCP using both lab and field data, and both forms of data have their uses.

It is advised to examine the Field Data recorded by Google because this is the data that is used to influence the rankings.

• Chrome User Experience Report
• PageSpeed Insights
• Search Console (Core Web Vitals report)
• web-vitals JavaScript library

• Chrome DevTools
• Lighthouse
• WebPageTest

In certain cases, the most significant element (or elements) on the website are not the largest, and developers might be more interested in calculating the render times of these other elements. This is possible with the Element Timing API , as defined in the custom metrics article .