A slow first screen: diagnose Largest Contentful Paint before changing images

Start with the customer page

Choose one journey before opening a performance tool: a visitor lands on a product page from a message, sees the item, then decides whether to continue. The first useful question is when that page's main visible content appears. Largest Contentful Paint, or LCP, records when the largest image or text block in the viewport is rendered. It is a page-load signal, not a measurement of how long payment authorization or a later button tap takes. Record the exact URL, mobile or desktop view, login state, and whether the visitor arrives through a redirect. Those details determine which page load you are discussing. If the team mixes the home page, a product detail page and a cached internal visit, the resulting average cannot tell anyone what to fix.

Google's LCP guidance uses 2.5 seconds or less at the seventy-fifth percentile of page visits as the good-experience target. That is a published benchmark, not an observation about this business. A single fast office test does not show that most customers meet it; a single slow trace does not prove a site-wide problem. If PageSpeed Insights has page-level real-user data, compare the matching URL and device class first. If it falls back to origin-level data, label the result honestly because pages on the same origin can load very differently. A low-traffic page may have no public page-level data. In that case collect privacy-conscious real-user timing for the relevant page or use a laboratory trace to diagnose a plausible problem while keeping the evidence category clear.

Find what actually became largest

Open a performance trace for the selected URL at a realistic viewport. Identify the LCP element instead of assuming it is the product photograph. It might be a heading, a hero image, or another visible text block, and a different viewport can produce a different winner. Note the element and its resource URL if it needs one. Then compare the start and end of the document request with the resource's request and its eventual rendering. A screenshot alone is weak evidence because it hides the request sequence. When a heading is the LCP element, sending a smaller product photo may save bytes but leave the measured problem intact. When the product image is LCP, optimizing a footer script first may have no useful effect.

Separate LCP into time to first byte, resource load delay, resource load duration, and element render delay. The four parts add to the measured LCP for that load; a text element without a required resource can have zero resource-load portions. Time to first byte covers the navigation until the first HTML bytes arrive. Resource load delay covers the wait before the relevant resource begins. Duration is the download itself. Render delay is the wait after the resource is available and before the element is fully displayed. Record the actual parts from the tool rather than assigning an attractive percentage to each. This breakdown gives a decision rule: work on the dominant avoidable delay and check that the total LCP changes, rather than only making one subpart look better.

Match the fix to the delay

If time to first byte dominates, inspect redirects, server response and the path to the page before editing images. A product page that waits for an unnecessary redirect or a slow HTML response cannot show its largest content early, however small the final image becomes. If resource load delay dominates, ask why the browser did not discover the LCP resource earlier. An image hidden behind JavaScript, a CSS background discovered late, or a lazy-loading pattern on a visible hero can delay its request. Make the critical resource discoverable in initial HTML where practical. If the image is truly the LCP element, consider appropriate priority after examining the network waterfall; marking many resources high priority defeats the point. Keep other visible content and buying information intact.

If the resource download itself dominates, examine transferred bytes, dimensions, format and delivery, but keep enough detail for a buying decision. This is where responsive image work belongs, with the actual LCP candidate in mind. If render delay dominates, an image may have finished downloading while a script, stylesheet, font or hidden container still prevents display. Google explicitly warns that compressing such an image can shorten the download yet simply move the saved time into render delay, leaving total LCP unchanged. Investigate the dependency that gates rendering. For a text LCP element, font and stylesheet behavior may be more relevant than image files. Every proposed change should state the observed bottleneck and the expected movement of the total, so the team can tell a useful fix from a cosmetic score change.

A worked triage example

Consider a hypothetical shop page, not a measured client result. Its LCP element in a mobile trace is the main product photograph. The HTML response arrives, then the browser waits for a script before it learns the image address; the image downloads reasonably quickly, but a page transition keeps it hidden until another script finishes. The first fix should not automatically be a more aggressive image compressor. Move the image address into discoverable markup, remove inappropriate lazy loading from this above-the-fold image, and examine the transition that delays display. After one small change, record the new request start, image finish and final LCP. If total LCP does not improve, the remaining render delay is the next hypothesis; reverting a change that only shifts time between subparts may be sensible.

Now imagine a second trace where the LCP element is the product title rather than the photograph. The same image changes may improve data use and still be worthwhile for another reason, but they are no longer a targeted LCP remedy. Check when the title enters the document, whether a stylesheet blocks the first rendering, and whether a web font delays readable text. This is why the team should save the element identity alongside the result. A change in layout, language, promotional banner or viewport can switch the LCP candidate, so repeat the check on the English and Traditional Chinese versions where they have different text length or templates. Do not report one language's measurement as if it covered both.

A useful exception is a page whose first screen contains a promotional carousel. The largest element may change as slides appear, and prioritizing every slide can crowd out the first one. Identify what the initial visitor actually sees, check whether later slides are requested before they are needed, and decide whether the rotating presentation helps the buying decision at all. A simpler static first view may be easier to understand and measure, but only adopt it after checking the content need. If the campaign team changes the first slide, repeat the trace; the old LCP element and resource priority assumptions may no longer apply. This is a content and loading decision together, not just a developer setting.

Test the page after the change

Use the same URL, viewport, connection assumptions and visit state for a before-and-after laboratory comparison, and make several runs because individual traces vary. Then monitor relevant field data over time if enough traffic exists. Distinguish page-level data from origin-level aggregates and mobile from desktop. A local improvement is a reason to observe real visits, not a claim that all visitors now meet the benchmark. Review the visual result too: the product name, price, availability and purchase route must remain understandable while content loads. A faster metric achieved by hiding useful information or replacing a meaningful image with an empty box is not a better customer experience.

Write a small decision record for the owner: page and device tested; source of evidence; LCP element; four timing parts; change made; and what improved or stayed uncertain. This lets a future release detect a regression without guessing why the previous change was made. If the real-user signal is absent, say so rather than treating missing measurement as zero. If the laboratory trace and field data disagree, investigate the user mix, cache state and device conditions before choosing another fix. Stop when the page has a defensible result for its actual visitors and the buying task still works. The next page can then be assessed on its own evidence rather than inheriting a blanket site-wide prescription.

Make one person responsible for deciding whether a change is ready. The developer can show a trace and explain its timing, but the product owner should also check the page on an ordinary phone and confirm that the first visible screen answers the customer's immediate question. For a product page that may mean the item name, meaningful photograph, price and a route to further details. If a high-priority image competes with essential text or scripts, the owner can ask for another design rather than accepting a metric in isolation. Document the actual device and language tested, because a desktop screenshot cannot demonstrate the mobile first screen. Keep this as a release decision supported by evidence, not a claim that a universal score has been achieved.