How to check LCP of a page

Record a load in the Chrome DevTools Performance panel and read the LCP marker, which gives both the time and the element that produced it. Then split that time into TTFB, load delay, load duration and render delay, because each subpart points at a different fix and a different owner.

Why check this

LCP is the vital that fails first, and a single number gives a developer nothing to act on. The subpart split turns "the page is slow" into a work item: a slow server, a late discovery of the image, a slow image transfer, or a render blocked by something else. Run it on staging before release, and after any change to the template, the CDN or the image pipeline.

Prerequisites

• Chrome with DevTools. Record your build from chrome://version.
• curl 8 or later. See the curl manual.
• Node 20 or later, for fetch inside node -e.
• The subpart definitions on web.dev, Optimize LCP.

Steps

1. 1

   Step 1.

   Measure the TTFB subpart from the command line, with the connection stages split out.

   curl -s -o /dev/null -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\n' https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
   

   dns 0.095920
   connect 0.095943
   tls 0.147849
   ttfb 0.195374

   TTFB here is 195 ms, of which 148 ms went on DNS, TCP and TLS. This is the floor of LCP from this network. No browser can beat it.

2. 2

   Step 2.

   Scan the served markup for preload hints, which decide how early the browser can start fetching an LCP image.

   node -e "const html = await (await fetch('https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS')).text(); const preload = html.match(/<link[^>]+rel=\"preload\"[^>]*>/g) || []; console.log('preload hints:', preload.length); for (const tag of preload) console.log(' ', (tag.match(/as=\"([^\"]+)\"/) || [])[1], (tag.match(/href=\"[^\"]*\/([^\"\/]+)\"/) || [])[1]); console.log('image preloads:', preload.filter(t => /as=\"image\"/.test(t)).length);"
   

   preload hints: 2
   font jetbrains-mono-latin.119994ed445212c7.woff2
   font inter-latin.9a3b1bc220d426ef.woff2
   image preloads: 0

   Steps 1 and 2 are the pre-filter. They read the wire and the markup. Neither can tell you which element is the LCP element, because that is decided during paint.

3. 3

   Step 3.

   Open the URL in Chrome, press F12, go to the Performance panel and click the reload and record button. Read the LCP marker, then the subpart breakdown beside it.

   LCP  375 ms
   TTFB          2 ms
   Render delay  374 ms

   The trace reported two subparts, not four. Load delay and load duration exist only when the LCP element is an image that has to be fetched.

4. 4

   Step 4.

   Read the field subparts for the same URL, in the field section of the panel or in PageSpeed Insights.

   LCP  1363 ms  (p75 of real Chrome users, scope: url)
   TTFB          336 ms
   Load delay    633 ms
   Load duration 299 ms
   Render delay  161 ms

How to read the result

| What you see | What it means | What to do | | --- | --- | --- | | TTFB is the largest subpart | The server or the network answers late | Take it to the backend or the CDN. No front end change moves it. | | Load delay is the largest subpart | The browser learned about the LCP image late | Reference the image in the HTML, or add a preload hint for it. | | Load duration is the largest subpart | The image itself is heavy or slow to transfer | Cut the bytes or serve a format the client accepts. | | Render delay is the largest subpart | Paint waited on something else, usually CSS or fonts | Go to the render blocking list for the same load. | | Lab TTFB 2 ms, field TTFB 336 ms | Your run was served from cache | Re-run with the cache disabled before believing the lab split. |

Common mistakes

Thresholds

What to check next

• How to test core web vitals: the full gate that LCP is one third of.
• How to check render blocking resources: what to read when render delay dominates.
• How to check if images are lazy loaded: a lazy attribute on the LCP image adds load delay.
• How to check CLS: the second load metric in the same trace, read from the same recording.
• How to check TTFB: the subpart that no front end change can move.
• How to check HTTP response headers with curl: the cache headers behind a 2 ms lab TTFB.

FAQ

How to test LCP?

Record a load in the Performance panel and read the LCP marker. Run it three times and keep the slowest, because one trace is one sample. Then confirm against the field value, which is the number that decides the gate.

How to find the LCP element of a page?

The LCP marker in the trace names the element and links to it in the Elements panel. Click the marker, then the node reference. Nothing in the served HTML tells you this, because the winner depends on viewport size and on paint order.

Why does LCP change on every run?

Cache state, CPU contention and network conditions all move it. The captured trace read a TTFB of 2 ms from cache, while curl on the same network read 195 ms for the same document. Fix the conditions before comparing two runs, or compare field values only.

Does a fast TTFB guarantee a fast LCP?

No. The captured trace had a 2 ms TTFB and a 374 ms render delay, so 99 percent of LCP happened after the first byte arrived. TTFB is a floor, not a prediction.

Verified

The browser figures above come from one Chrome DevTools capture of https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS on 2026-09-11, on one machine, with no CPU and no network throttling. One capture is not a benchmark. Read your own Chrome build from chrome://version and record it with your own numbers.