How to Find What Delays Largest Contentful Paint

When a web page feels slow, Largest Contentful Paint (LCP) measures how long it takes for the largest visible image or block of text to appear. To find the delay, identify that element and check which step on its way to the screen took the longest.

LCP is one of Google’s Core Web Vitals, a set of measures for key aspects of page experience. A slow result does not tell you the cause by itself. The delay might come from the initial HTML response, a late image request, a long download, or work the browser must finish before it can display the element. Comparing real-user data with a browser performance trace helps narrow down which one to investigate.

Break LCP into four phases

For an image LCP, Google’s diagnostic model divides the time into four phases: time to first byte (TTFB), resource load delay, resource load duration, and element render delay. Together, those phases account for the LCP time.

A text LCP has no separate LCP image request, so the resource-load phases do not apply in the same way. Fonts and styles can still delay when the browser displays the text. The LCP optimization guidance explains these phases and how to inspect them.

These categories help locate a delay, but they do not guarantee that one fix will reduce the overall score by the same amount. For example, a faster image download will not help much if page code still prevents the browser from displaying the image.

Compare field data with a browser trace

Start with PageSpeed Insights and check whether its field data applies to the URL or to the whole site origin. Field data comes from real Chrome visits collected over the previous 28 days. If a page does not have enough data, PageSpeed Insights may show data for the site as a whole instead of for that specific page. The PageSpeed Insights documentation explains how field data and its simulated lab test differ.

For Core Web Vitals, Google assesses LCP using field data across visits rather than a single test run. An LCP of 2.5 seconds or less is considered good; above 2.5 seconds and up to 4 seconds needs improvement; above 4 seconds is poor. These are field-data thresholds, not a pass-or-fail rule for a single test run. See Google’s explanation of how the thresholds were defined.

Next, record a page load in Chrome DevTools’ Performance panel. Find the LCP marker and the element it identifies. If it is an image, note the image URL, then compare its request in the performance trace or Network panel with the HTML document request. Chrome’s Performance insights can help connect LCP timings with activity in the trace.

Match the test to the problem you are investigating. Use the relevant page, browser window size (the viewport), and page state. Repeat the test when results vary. A lab test simulates a particular set of conditions; real visitors use different devices, networks, and locations. A difference between lab and field data does not by itself show that either result is wrong.

Use the longest phase to choose what to check

When TTFB takes the most time, the browser is waiting for the HTML response. Check whether redirects add extra requests, whether caching serves the page, and whether the response is slow across different locations or only in certain conditions. TTFB includes connection and network time as well as server response time, so a high number alone does not prove the origin server is the cause.

When resource load delay dominates, find out when the browser first learned about the LCP image. The browser usually finds an image sooner when the initial HTML refers to it than when JavaScript adds it later or CSS refers to it. Check whether the image is lazy-loaded, whether a script must run before the browser requests it, and whether its request priority is appropriate. For a confirmed LCP image, early discovery or a priority adjustment may help. Preloading or assigning high priority indiscriminately can make other resources wait, so check the trace before changing priorities.

When resource load duration is long, inspect the exact image the browser selected at the tested viewport. Check its dimensions and format, then note how much data the browser downloaded. A smaller image for that screen size or a more efficient file format is worth considering when the trace shows that downloading the image takes a substantial share of LCP. If the download is already short, compression is unlikely to address the largest delay.

When element render delay is long, check what the browser does after the image arrives. Look for CSS that blocks the browser from displaying the page, JavaScript that keeps the browser busy, or code that hides the element until another task finishes. For a text LCP, inspect whether font loading or styling prevents the text from appearing. A trace points to activity worth investigating; it does not always identify the specific rule or script responsible.

The analysis of common LCP misconceptions discusses why image download is not always the main source of LCP delay.

Avoid conclusions a single test cannot support

A lab trace shows what happened during one simulated page load. It does not show which cause explains every real visit. If the field problem persists but the trace looks fast, collect data from real users or compare more visits under conditions that match the affected audience.

Also check that the trace shows the right LCP element. The browser can report different largest candidates as the page renders, and different page layouts or viewports can produce different candidates. The Largest Contentful Paint specification also describes cases where user input or scrolling affects candidate reporting. A trace recorded after interacting with the page may not represent a clean initial load.

A script, stylesheet, or third-party request that runs near the delay is a lead, not proof of the cause. Check the timing and what the request depends on. Make one relevant change, then compare repeated loads. A convincing fix reduces the suspected phase and improves LCP under comparable conditions.

For SEO, Google says Core Web Vitals are used by its ranking systems, while also stating that a good report does not guarantee top rankings. LCP helps measure page experience; it does not predict a specific ranking outcome. The public guidance reviewed here also does not establish that a particular LCP score directly improves visibility in AI-generated search features.

Key Takeaways

• Identify the LCP element first: Confirm whether the browser is waiting to display an image or text before changing image settings or page code.
• Compare real-user data with a trace: Use PageSpeed Insights to understand field performance, then use Chrome DevTools to investigate a particular load.
• Fix the phase that takes the time: Check the HTML response for TTFB and image discovery for load delay. Check transfer size for load duration and browser work for render delay.
• Test changes under comparable conditions: Repeat the load and confirm that the expected phase and overall LCP improve.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com