The navigation is visible, but the product’s main image is still an empty rectangle. A lower image appears first; the hero arrives later. A buyer experiences a slow store. The developer needs a more precise question: which resource was allowed to load and display first?
Source: this analysis starts from Nuvemshop’s public web.dev case, published on 24 June 2026. It is not a GoogleAsk client project. The WordPress and Shopify investigation below is our recommended application of the lesson.
The clue: a small image can still appear late
The published case connects dynamic storefront sections with transitions, above-the-fold lazy loading and missing priority hints. The team had to identify the actual LCP element instead of optimising an assumed hero. It reported good-LCP coverage moving from 57% to 96%. That population result does not promise the same improvement from one attribute change. Read the original case.
For a project team, the useful distinction is between a small file and an early image. Compressing a resource cannot remove time spent waiting for its request to start. If the resource is already downloaded but hidden behind animation or component state, reducing bytes tackles the wrong stage again.
First, preserve the timeline
Choose a specific product page rather than installing another optimisation plugin across the site. Hold device, network conditions and entry URL consistent. Capture the first-screen filmstrip, the reported LCP element, and the times at which its request begins, completes and becomes visible.
These observations separate discovery, transfer and presentation. A late request points toward discovery or deferral. A long transfer suggests resource size or response conditions. A downloaded but invisible image points toward rendering, layout or component state. The distinction gives the intervention a testable target.
| Observation | Initial hypothesis | Evidence to inspect |
|---|---|---|
| Image request starts after scrolling | Critical image deferred | Rendered loading attribute and script trigger |
| Early request, long transfer | Resource or response problem | Delivered dimensions, format and timing |
| Download complete, frame empty | Visibility or initialisation delay | Animation and component state |
| Desktop works, mobile waits | Different first-screen element | Mobile layout and selected image |
Second, prioritise the critical image rather than the whole gallery
If the evidence shows delayed discovery, make the critical resource discoverable in the initial page and review whether its lazy-loading treatment is appropriate. Consider a priority hint for the confirmed key image. Keep offscreen resources deferred where that benefits the journey.
Marking every carousel frame high priority can create competition rather than clarity. The unit of investigation is the element that matters in the current viewport, not every asset belonging to an important component. The official LCP optimisation guide provides a framework for separating request and rendering delays.
Third, follow the platform’s output chain
In WordPress, a theme, page builder, image plugin and cache may all modify the same image. A disabled setting in the editor does not prove that the public response has changed. Inspect the final output, find the last transformation and change one layer at a time. Keep the previous configuration so the test can be reversed.
In Shopify, review the first section, mobile image selection and applications that modify carousel behaviour. Built-in optimisation does not establish that every theme combination passes. Test in an unpublished theme copy before arranging production changes.
For either platform, inspect the logged-out buyer experience. Editor previews, authenticated responses and cached image variants may differ. The browser image lazy-loading documentation helps establish where deferral is appropriate.
Prove that the waiting changed
Repeat the timeline on the same page and conditions. Confirm that the key resource is discovered and displayed sooner without introducing layout movement, stale commerce data or broken interaction. A lab test establishes whether the implementation moves in the intended direction; field observations help assess the experience after release.
Then sample a category page and a product using another layout. A homepage fix does not prove that a shared component behaves correctly elsewhere. If caching is part of the intervention, verify price, stock and authentication behaviour as well as speed.
Turn the case into a delivery requirement
Ask for a short record containing the page, critical element, delayed stage, actual change and repeat test. A site owner need not know every performance term to ask what specific waiting was removed and what evidence demonstrates it.
A fast first screen is only one part of the purchasing journey. Buyers still need useful product information and a functioning enquiry path. Combine these tests with the website delivery scope and the qualified-lead measurement case.
Questions after the case
Would a more expensive server solve it faster?
Only prioritise that option when evidence points to server or transfer delays. An undiscovered request or a hidden image can remain a problem after a hosting upgrade.
Should every first-screen image bypass lazy loading?
Confirm the actual viewport and critical element. Do not apply an untested rule to every template or carousel frame; validate request and display behaviour.
