Largest Contentful Paint (LCP) is the Core Web Vital most directly tied to how fast a page feels to load, since it measures when the largest visible element actually renders. It’s also the metric where WordPress sites most commonly fail, since a single slow server response, a poorly handled hero image, or a stack of render-blocking assets can each push LCP into the “poor” range on their own. This guide walks through identifying the specific LCP element on a page and diagnosing exactly which part of the loading sequence is responsible.
What LCP measures, and its thresholds
LCP records the render time of the largest image, text block, or video visible within the viewport, measured from when the browser began navigating to the page. Google classifies LCP of 2.5 seconds or less as “good” and LCP above 4 seconds as “poor,” assessed at the 75th percentile of real visits for a given page or origin. An element can only be considered the largest contentful element once it has actually rendered and is visible; an image that hasn’t finished loading isn’t counted as rendered, even if space for it has already been reserved in the layout.
Field LCP versus lab LCP
As with other Core Web Vitals, LCP has both a field measurement (from real visitors, aggregated via the Chrome User Experience Report) and a lab measurement (from a single synthetic test run in a tool like Lighthouse or PageSpeed Insights’ lab section). The two frequently disagree, since field data reflects a distribution of real devices and connections, while lab data reflects one specific, controlled scenario. When diagnosing a problem, field data (via Search Console or PageSpeed Insights’ field data section) tells you whether real visitors are actually experiencing a problem, while lab data and its detailed breakdown are what let you reproduce and investigate that problem in detail. A fuller explanation of this distinction, along with how to record both consistently, is covered in How to Measure WordPress Speed Before Making Any Changes.
Identifying the actual LCP element
Before attempting any fix, confirm exactly which element on the page is being measured as the LCP element, since it is not always the element you would assume. In Chrome DevTools, the Performance panel’s LCP entry (visible after recording a page load, or in the “Performance insights” panel) identifies and highlights the specific element responsible. PageSpeed Insights similarly reports the LCP element under its diagnostics section for a tested page. It’s common to discover that the actual LCP element is not the intended hero image, but rather a heading, a different image further up the layout, or, on some page-builder templates, an unexpected background element, and the correct fix depends entirely on which of these it turns out to be.
The four LCP subparts
Google’s current guidance breaks LCP down into four sequential subparts, which together explain the full time between navigation and the LCP render:
- Time to First Byte (TTFB): how long the server takes to begin responding to the initial document request.
- Resource load delay: the time between TTFB and when the browser actually begins downloading the LCP resource (if the LCP element requires one, such as an image). This delay exists because the browser has to first parse enough of the HTML and CSS to discover that the resource is needed.
- Resource load duration: the time spent actually downloading that resource.
- Element render delay: the time between the resource finishing its download and the element actually being rendered on screen, which can be affected by main-thread work competing for the browser’s attention.
If the LCP element is a text node rather than an image (for example, a large heading rendered in a system font with no external resource needed), the resource load delay and resource load duration subparts are both effectively zero, and the entire LCP time is made up of TTFB and element render delay. This is one reason a text-based LCP element and an image-based LCP element require entirely different fixes.
Server response delay (TTFB)
TTFB is often the least visible but most foundational subpart, since nothing else can begin until the browser receives the first byte of the HTML document. A slow TTFB caps every subsequent subpart, since a fast image download and fast rendering still can’t compensate for the browser waiting an extended time just to receive the document itself. Common causes include an under-resourced hosting plan, an uncached dynamic page being rebuilt on every request, a slow database query, or a chain of redirects before the final page is reached. This overlaps directly with the hosting and server topics covered in WordPress Hosting, PHP Version, and the Server Performance Floor, since TTFB is fundamentally a server-side measurement.
Resource load delay
This subpart is frequently a larger contributor than expected, since it reflects the gap between the server responding and the browser actually discovering it needs to fetch the LCP resource. On WordPress sites, common causes include the LCP image being lazy-loaded (deferring its discovery until scroll position makes it eligible), the image being defined via a CSS background rather than a standard <img> tag (delaying discovery until CSS is parsed), or the image being inserted by JavaScript rather than present in the initial HTML. Preloading the resource and ensuring it is not lazy-loaded, both covered in more detail in How to Optimize Images and the LCP Element in WordPress, directly target this subpart.
Resource load duration
This is the straightforward download time for the resource itself, most directly affected by file size (compression and correct dimensions), file format (WebP or AVIF versus older formats), server/CDN proximity to the visitor, and competing network traffic from other simultaneously loading resources on the page. Google’s own research on this subpart has generally found that, for most sites, load duration tends not to be as significant a bottleneck as the delay-based subparts, though this varies by site and image size.
Element render delay
Even after a resource finishes downloading, rendering it can be delayed by other work competing for the browser’s main thread, render-blocking CSS still being parsed, or JavaScript execution that happens to be running at that moment. Since browsers render images on the main thread, anything blocking that thread can extend this delay. Reducing render-blocking CSS and unnecessary JavaScript execution, covered in WordPress Fonts, CSS, Scripts, and Plugin Weight Explained, is the most direct way to address this subpart specifically.
Different LCP element types need different fixes
If the LCP element is an image, focus on the image-specific fixes: correct dimensions, compression, format, avoiding lazy-loading, and preloading where appropriate. If it’s a text block, focus instead on TTFB and render delay, since resource load subparts don’t apply; render-blocking CSS and font-loading behavior (particularly a font-display setting that blocks text rendering) are the more relevant levers here. If it’s a video (specifically, the video’s poster image or first frame, since Core Web Vitals measure the rendered visual element), similar image-style principles generally apply to the poster/preview frame, along with confirming the video itself isn’t set to autoplay in a way that delays the visible frame.
Diagnosing with PageSpeed Insights and Chrome DevTools
PageSpeed Insights provides both field data (if sufficient traffic exists for the tested URL or origin) and a lab-based diagnostic breakdown, including the identified LCP element and specific improvement suggestions. Chrome DevTools’ Performance panel provides a more detailed timeline view, allowing the LCP subparts to be inspected directly against the browser’s actual network and rendering activity for that specific test run. Using both together, field data to confirm whether a real problem exists, and lab/DevTools data to pinpoint exactly where the time is going, is more effective than relying on either alone.
WordPress-specific causes worth checking first
- The featured image or hero image carrying
loading="lazy", either because WordPress’s automatic LCP-detection heuristic misidentified the element, or because a theme/plugin is applying lazy-loading in a way that overrides that heuristic - A page-builder template rendering its hero section as a CSS background image rather than a standard image tag
- A caching layer not actually active on the tested page (test as a logged-out visitor to confirm), leaving every request rebuilding the page from scratch and inflating TTFB
- Render-blocking plugin stylesheets loading in the document head ahead of the LCP element’s own styling
- A slow database query or uncached dynamic content (related posts widgets, live comment counts, and similar features) delaying TTFB specifically on content-heavy templates
Prioritized fixes
Because TTFB caps every subsequent subpart, it’s generally the most productive starting point if it is elevated: confirm caching is active, check hosting resources, and rule out slow database queries before investing time elsewhere. If TTFB is already reasonable, move to whichever remaining subpart is largest in the DevTools breakdown, generally resource load delay first (since it is often the largest and cheapest to fix, by removing lazy-loading and adding preload/fetchpriority hints where appropriate), then render delay (by reducing render-blocking CSS and JavaScript), then resource load duration (through compression, correct dimensions, and modern formats) last, since Google’s own guidance suggests this subpart is typically the smallest contributor for most sites.
Verifying a fix actually worked
After making a change, re-test using the same page, device type, and cache state as the original baseline measurement, and check the lab-based LCP subpart breakdown to confirm the specific subpart you targeted actually improved. Field data will take longer to reflect the change, since CrUX aggregates over a rolling 28-day window; treat lab data as the immediate confirmation and field data as the longer-term validation once enough time and traffic have passed.
Common mistakes
- Assuming the LCP element without confirming it directly in DevTools or PageSpeed Insights
- Applying image-specific fixes to a page whose actual LCP element is a text block, and vice versa
- Ignoring TTFB and focusing only on front-end fixes, when a slow server response is capping every other improvement
- Testing while logged in, which can bypass caching and produce misleading results
- Preloading multiple resources indiscriminately, which can compete with the actual LCP resource for bandwidth and priority
- Only checking lab data and never confirming the improvement in field data once enough time has passed
Practical checklist
- Confirm the actual LCP element using DevTools or PageSpeed Insights before making any change
- Check the four LCP subparts (TTFB, resource load delay, resource load duration, element render delay) to see where time is actually going
- If TTFB is elevated, address caching and hosting before front-end fixes
- If the LCP element is an image, confirm it is not lazy-loaded and consider preload/fetchpriority
- If the LCP element is text, focus on render-blocking CSS and font-display behavior instead
- Re-test using the same conditions as your original baseline after each change
- Confirm improvement in field data once enough time has passed, not just in the initial lab test
Key Takeaways
- LCP breaks down into four subparts, TTFB, resource load delay, resource load duration, and element render delay, each with different causes and fixes.
- Identifying the actual LCP element first is essential, since image-based and text-based LCP elements require different optimization approaches.
- TTFB caps every other subpart, making server-side and caching issues the most productive place to start when TTFB is elevated.
- WordPress-specific causes often include lazy-loaded hero images, CSS background images used as hero visuals, and inactive caching during testing.
- Confirm fixes using the same lab test conditions as your baseline, then validate with field data once enough time has passed.
FAQs
How do I find out which element is my page’s LCP element?
Use Chrome DevTools’ Performance panel (or Performance insights) after recording a page load, or check the diagnostics section of a PageSpeed Insights report; both identify the specific element responsible for the LCP measurement.
Why is my LCP slow even though my images are already compressed?
Compression only affects the resource load duration subpart. If TTFB, resource load delay, or element render delay are the larger contributors, image compression alone won’t meaningfully improve LCP; check the subpart breakdown to confirm where the time is actually going.
Is LCP always caused by an image?
No. The LCP element can be a text block, an image, or a video’s visible frame. Text-based LCP elements are affected mainly by TTFB, render-blocking CSS, and font loading rather than image-specific factors.
Why does my lab test show a good LCP but Search Console shows a poor one?
Lab tests reflect one controlled scenario, while Search Console’s field data reflects the real distribution of visitor devices, connections, and locations over a rolling 28-day window. It’s expected for these to disagree; both are still worth checking together.
Should I preload every image on my homepage to be safe?
No. Preloading is most effective when applied selectively to the actual LCP resource. Preloading many resources at once competes for the same bandwidth and priority, which can slow down the resource you actually need to prioritize.
Sources and further reading
- Google web.dev — Largest Contentful Paint (LCP); Optimize Largest Contentful Paint
- Chrome for Developers — LCP breakdown (Performance insights)
- Make WordPress Core — Image performance enhancements in WordPress 6.3 (fetchpriority and LCP detection)
- Google Search Central — Core Web Vitals report documentation
