Use field data to confirm an LCP problem, then use a lab tool or DevTools to identify the exact LCP element. On many product pages the main image is the LCP element, but a large heading, price block or review summary can be the candidate instead. Optimize the element that actually renders last, not the one you assume is largest.
Why the LCP element is not always the product image
Largest Contentful Paint measures the time from when the user starts loading the page until the largest image or text block is rendered within the viewport. Google's guidance sets a good threshold at 2.5 seconds or less for at least 75% of page visits, measured at the 75th percentile of page loads segmented by mobile and desktop (web.dev LCP guide; Web Vitals).
The metric does not care whether the element is an image, a heading, a price, a review count or a cookie banner. It cares which candidate occupies the largest area in the viewport at the moment it renders. On a typical product page, the main product image is often the largest candidate, which is why image optimization gets attention. But if the image is small, lazy-loaded, below the fold, or replaced by a text-heavy hero, a text block can become the LCP element.
A common failure mode is optimizing images that are not the LCP element. The team compresses the gallery, adds a CDN, converts to next-gen formats, and the field LCP barely moves because the real bottleneck was a render-blocking font or a JavaScript-managed price block. The diagnostic step comes before the optimization step.
How do you confirm there is an LCP problem in the first place?
Start with real-user data, not a lab score. Lab tools such as Lighthouse or local testing can explain and help improve LCP, but they may not represent what actual users experience (web.dev LCP guide). Field data comes from Real User Monitoring or the Chrome User Experience Report. If the 75th percentile LCP for your product template is already under 2.5 seconds on mobile and desktop, you may not have a problem worth a redesign.
If field data shows a problem, segment by template and device. A product page with a large gallery and a heavy review widget will behave differently from a simple page with one image. The goal is to find which template and which device class are failing, then move to element identification.
How do you identify the LCP element on a product page?
Use a lab tool or Chrome DevTools to determine the LCP element, then match the element to the network request that loads it. The official guidance describes using lab tools such as PageSpeed Insights, Chrome DevTools or WebPageTest to identify the LCP element, then matching the URL loaded by that element on a network waterfall (web.dev LCP guide).
A practical sequence:
- Open the product page in Chrome DevTools with network throttling that resembles a mid-range mobile connection.
- Use the Performance panel to record a load and inspect the LCP marker.
- Note whether the LCP element is an image, a text block, or a background image.
- If it is an image, find the image request in the network waterfall and check when it starts and ends.
- If it is text, check whether the font is render-blocking and whether the text is in the initial HTML or injected by JavaScript.
This is a verification method, not a guarantee. Tools can disagree because they measure in different ways. Treat the lab result as a hypothesis to confirm against field data.
What the timing gaps tell you
The official guide describes two useful deltas. A large gap between Time to First Byte and First Contentful Paint can indicate render-blocking assets or heavy client-side rendering. A large gap between First Contentful Paint and LCP indicates that the LCP resource is not immediately available for the browser to prioritize, or that the browser is completing other work before displaying the LCP content (web.dev LCP guide).
On a product page, a large FCP-to-LCP gap often points to an image that is lazy-loaded, served from a slow origin, or discovered late in the HTML. A large TTFB-to-FCP gap points to server or render-blocking issues that image compression will not fix.
A decision table for product page teams
| Observation | Likely LCP element | First check |
|---|---|---|
| Main image is large, above the fold, in initial HTML | Image | Image request start and end times |
| Main image is lazy-loaded or below the fold | Text block or another image | Whether a heading or price renders first |
| Price or review count injected by JavaScript | Text block | When the script runs and renders |
| Custom font blocks text rendering | Text block | Font loading and font-display behaviour |
| Hero is a background image | Image | CSS background request and priority |
This table is a starting point, not a rule. The only reliable way to know is to inspect the actual page.
Example: a hypothetical product page
Consider a hypothetical product page for a jacket. The main image is 1200 by 1200 pixels and sits above the fold. The page also has a large heading, a price, and a review summary. In a lab test, the LCP element turns out to be the heading, not the image, because the heading renders after a custom font loads. The image is already well compressed. Optimizing the image further would not move LCP. The fix is to load the font without blocking text rendering or to use a system font fallback. This example is illustrative only and is not a real business metric.
What to do after you identify the element
If the LCP element is an image, check whether it is discoverable in the initial HTML, whether it is lazy-loaded unnecessarily, and whether the request starts early. If the LCP element is text, check font loading, render-blocking CSS, and whether the text is present in the initial HTML or injected by JavaScript. The official guide notes that a quick fix to a single part of a page rarely produces a meaningful LCP improvement; the whole loading process matters (web.dev LCP guide).
For product pages specifically, the buying information and image plan affect what the browser must load. A page that answers buyer questions with fewer, well-chosen images may have a different LCP profile than a page with a large gallery. See Product page SEO: the details buyers actually need and Ecommerce product photography: plan images that answer questions for the content side of that trade-off.
What remains uncertain
LCP thresholds and tool behaviour can change. The official guidance is updated over time, and the metrics that make up Core Web Vitals will evolve (Web Vitals). Field data may be sparse for low-traffic product pages, and lab data may not match real devices. The diagnostic method above is a way to reduce guesswork, not a guarantee of a specific score.
Follow-up questions
Does the LCP element change between mobile and desktop?
Yes, it can. A product image that dominates a mobile viewport may be smaller relative to a desktop layout, and a text block may become the largest candidate. Always check both device classes separately.
Should I optimize images before confirming the LCP element?
No. Confirm the LCP element first. If the element is text, image work will not address the bottleneck. If the element is an image, then image optimization is relevant and can be prioritized.