What the LCP Element Analyzer does
This analyzer finds the element behind your Largest Contentful Paint and tells you what is slowing it down. Paste the JSON from a short console snippet and it reads the browser's own LCP entry, splits the time into TTFB, resource load delay, resource load duration and element render delay, and names the phase to fix. Paste HTML or enter a URL instead and it estimates the likely LCP element from the markup and checks it for the classic mistakes - lazy-loading, late discovery, missing priority hints and render-blocking resources.
The two routes give different kinds of evidence, and the result says which one you are looking at: a lab measurement of one load, or a static estimate from HTML and server-side timings. Neither is the field LCP that Google assesses.
How to use it
- For a real measurement, open your page in Chrome or Edge, open the DevTools Console, paste the snippet from the "Measure the real LCP" section and press Enter.
- Wait for the page to finish loading (do not click - input stops LCP reporting), run
a2zDump()and paste the copied JSON into the box. - For a quick static check, paste the page's HTML or leave the box empty and enter a public URL. The a2z.tools server fetches the HTML and its images once.
- Press Find the LCP element. For a measurement, read the four-phase bar and the phase furthest over its share; for an estimate, read the ranked candidates and the fix list.
- Fix the top finding, then measure again with the snippet on a throttled connection to confirm the change.
Reading the results
The subparts add up to LCP: TTFB is server and network time for the HTML; load delay is the gap before the LCP image request starts; load duration is the download itself; render delay is the time from the image arriving to it being painted. web.dev suggests roughly 40 / 10 / 40 / 10 per cent.
A large load delay almost always means the image is discovered late - lazy-loaded, injected by script, referenced only in CSS, or queued behind other requests. It is usually the cheapest phase to fix.
The static candidate is an A2Z heuristic: images score higher than text, larger declared sizes and earlier positions score higher, logos and icons score lower. The browser picks the real LCP element after layout, so treat the estimate as a strong hint, not a fact.
Server-measured timings (TTFB and image fetch time from our server) show how fast your server and files are from one location. They are not your visitors' network, and they cannot reveal load delay or render delay.
Worked example: a lazy-loaded hero image on a shop landing page
The sample recording reports two LCP candidates: the h1 text at 1,180 ms, then the hero image img.hero-img at 3,020 ms, which is the final LCP - needs improvement if field data matched. Navigation timing gives a TTFB of 640 ms, and resource timing shows the image request starting at 1,590 ms and finishing at 2,700 ms.
The subparts are therefore 640 ms TTFB, 950 ms load delay (1,590 - 640), 1,110 ms load duration (2,700 - 1,590) and 320 ms render delay (3,020 - 2,700), adding up to 3,020 ms. Load delay is 31% of LCP against a recommended share under 10%.
The HTML example shows why: the hero <img> carries loading="lazy" and sits on another origin with no preconnect, behind a synchronous script and two stylesheets. Removing lazy-loading and adding fetchpriority="high" lets the request start with the HTML, which would remove most of the 950 ms.
Formulas and scoring rules
- TTFB
ttfb = navigation responseStart- Resource load delay
load_delay = max(requestStart, ttfb) - ttfb0 for text LCP. A request that started before TTFB (early hints, cache) is clamped to TTFB.- Resource load duration
load_duration = responseEnd - max(requestStart, ttfb)- Element render delay
render_delay = LCP time - responseEndFor text, render_delay = LCP time - ttfb.- Phase over its share
over = phase - LCP x share (0.40, 0.10, 0.40, 0.10)The phase with the largest positive value is reported first.
What the static check looks for
For the most likely LCP image: loading="lazy" (the most common self-inflicted LCP delay), a real URL only in data-src so JavaScript must run first, a CSS background the preload scanner cannot see, no fetchpriority="high", missing width and height, an origin without preconnect, and - when a URL is fetched - a transfer size over 200 KB or a legacy format.
For the page: synchronous scripts and stylesheets in the <head>, which block the first render and add element render delay, and a slow server response. If the body contains no images or text at all, the page is probably rendered on the client, which delays LCP until the scripts have run.
Limitations: what the result does not prove
- Neither route measures field LCP. Use CrUX or real-user monitoring for the 75th percentile Google assesses.
- The static estimate cannot know the viewport, CSS or JavaScript, so it may pick the wrong element on pages that restyle or hide content.
- Cross-origin images without a Timing-Allow-Origin header hide their request times from the snippet; their load time then appears as render delay.
- A URL check reads at most 2 MB of HTML and the images referenced in it, from the a2z.tools server's location. Pages behind logins, bot protection or geo-blocking may be unavailable.
Privacy: where your data goes
The analysis runs in your browser. If you choose to load a public URL instead of pasting, a2z.tools fetches that address read-only and returns the text to your tab; private and internal addresses are refused and nothing is stored. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- web.dev - Optimize Largest Contentful Paint - checked 19 Sep 2026
- web.dev - Web Vitals and thresholds - checked 19 Sep 2026
- web.dev - Largest Contentful Paint (LCP)
- W3C Largest Contentful Paint API
Frequently asked questions
How do I find which element is my LCP?
Run the snippet in the DevTools Console on your page and paste the result here: the last largest-contentful-paint entry is the element the browser settled on. The Performance panel in DevTools also marks it. The HTML route only estimates it.
What does resource load delay mean in LCP?
It is the time between the first byte of HTML arriving and the browser starting to download the LCP image. Ideally it is close to zero; a long delay means the image was found late, for example because it was lazy-loaded or only referenced in CSS or JavaScript.
Should I lazy-load my hero image?
No. Lazy-loading tells the browser to wait until layout shows the image is in the viewport, which delays the request. Keep loading="lazy" for images further down the page and give the hero fetchpriority="high" instead.
Why can't a URL check measure my LCP?
LCP is a paint timing inside a browser, depending on the viewport, CSS, fonts, scripts and the visitor's device and network. Our server downloads the HTML and images, which reveals markup mistakes and file sizes, but it never renders the page.
Why did my LCP element change during loading?
The browser reports a new candidate each time a larger element paints. Text often paints first, then a hero image replaces it as the LCP. The final entry before the first interaction is the one that counts.
Can text be the LCP element?
Yes - headings and paragraphs often are, especially on articles. Text LCP has no resource to download, so it is TTFB plus render delay; web fonts with font-display: block and render-blocking CSS are the usual causes of a slow one.
Last reviewed by the A2Z.Tools team against the sources listed above.
