how to debug LCP as CLS with web vitals js sdk?

Question

I have fixed all my CLS issues thanks to the web vitals js sdk.

I can collect all the elements on my page that affect CLS score. It's very easy to fix by adding min-height or aspect-ratio.

However, is there any similar way to debug LCP? I don't know what's the root-cause for my bad LCP score.

Answer 1

LCP is typically directly related to the load order. It is therefore usually fairly accurately measured using testing tools - unlike CLS which can be affected by user interaction and elements that appear later, so is much more difficult to synthesis and so is best measured using real user monitoring (RUM) like the web vitals script.

I find WebPageTest one of the best tools to measure and understand LCP. Plug in your website and it will create a waterfall graph - and also tell you your LCP/CLS numbers and if the test numbers match what Google has collected from real users or if the test settings are off.

You can then look at the waterfall and see why the LCP element is loaded later than you want:

• Is it a large image, that just takes a long time to download? If so can you optimise it?
• Is it a late discovered resource (e.g. an image in CSS, or dependent on JavaScript running) so could you use resource hints (preload or preconnect) to help here?
• Is there contention for loading the LCP content, and could you lazy load off screen content to reduce this contention?
• Is it text that needs a custom font and it takes a while to download? There’s lots of good resources out there in optimising font downloads.
• Is there just too much JavaScript blocking the initial render?
• … etc.

PageSpeed Insights is another useful tool (provided by Google) which is a bit simpler than WebPageTest which runs a performance audit on a page (using the popular Lighthouse tool) and gives you a score, various stats and suggested improvements. Again they give the RUM numbers so you can see if the test is representative of what your users are seeing. They also recently added the ability to filter on Core Web Vitals so you can look at the suggestions that should impact your LCP score for example.

With either of the above tools you should still correlate with your web vitals script to make sure they are representative and you’re not optimising the wrong thing or concentrating on the wrong pages. As I said, the tools do try to show you the RUM stats they have but they don’t tell you if you should be concentrating on another page instead of this one, or if your users are picking up different LCP elements than they are highlighting (for example they are on different screen sizes and so get different content than these tests show).

Answer 2

There are some things you should log to your analytics in addition to the LCP value itself: information about the element that contributed to the LCP, related Web Vitals, and user metadata.

LCP element info

It'd be useful to differentiate between LCP element types: images, headings, paragraphs, etc. web-vitals.js reports the full LCP entry, so you can extract the type using a script like this: lcpEntry.element.tagName. See also Debugging LCP in the field.

When you look at your analytics data, you can use this debug info to understand what you need to be optimizing. If 20% of page views have image-based LCP and the remaining page views are based on the H1, that helps you put into perspective how much image optimization will help the overall story. It's also a useful way to validate that your lab tests are measuring the same thing as your users.

Related Web Vitals

LCP is directly affected by the loading performance of the page. By definition, LCP happens after the FCP (first contentful paint). FCP also happens after the TTFB (time to first byte). Both FCP and TTFB are Web Vitals available in the library, so you should be logging them as well.

TTFB is especially useful for diagnosing whether slow LCP times are caused by backend or frontend issues. When TTFB is slower than 2.5 seconds, it's impossible for LCP to be "fast" (<= 2.5 seconds). No amount of frontend optimization will help you get a fast LCP; you must also fix the network issues.

User metadata

The user's viewport size will affect what content is displayed and eligible to be counted as the LCP. You can measure this using window.innerHeight and window.innerWidth.

Similarly, the initial scroll position of the page may not be set to the top, for example when a user clicks a link with a URL fragment like #example. The contents of the viewport will be different, and therefore so will the LCP element. You could measure window.pageYOffset when the DOM is ready to determine whether the page was scrolled and/or you could log location.hash.

The Network Information API can tell you about the user's network connection. Large images load more slowly over slow connections, so it'd be wise to have an idea of the speeds at which users are accessing your site. For example: navigator.connection.effectiveType.

Per web.dev/lcp/:

The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what's visible to the user (which is especially true with scrolling).

So for example, if a user scrolls before a large hero image finishes loading, it won't be the LCP. You could keep track of the times at which the hero image loads using the Element Timing API. If the element you expect to be the LCP loads at a different time than the reported LCP value, you know that something like a user interaction caused it to change.

Each of these user-specific access and behavior characteristics could be simulated in lab testing to ensure that you're testing your pages under realistic conditions.