Should the first product image use lazy loading?

Identify what is visible at arrival

Open the product page at a representative phone width and record the image visible before scrolling. Include a variant-specific landing link if the campaign selects an option. A desktop layout may place the main image high on the page while a mobile layout puts a large header above it. Use the actual layout rather than the source-file order.

web.dev advises against lazy-loading images that are already in the initial viewport. Applying this advice requires knowing which image the browser actually presents, especially when galleries, sliders or theme apps change that choice.

Write a loading-role handoff

This worksheet does not prescribe theme code. The developer should inspect the storefront’s markup, requested files and layout before changing behavior.

web.dev distinguishes deferral from fetch priority: default/eager loading avoids lazy deferral, while fetch priority is a separate hint. Adding fetchpriority="high" to a still-deferred image does not cancel its lazy-loading condition. Ask the developer to inspect the actual initial image’s loading attribute, when its source becomes discoverable and when its request starts. If a script inserts the source late, changing an export preset does not resolve that discovery step.

Keep a separate row for a carousel’s later slide rather than label every gallery image “below the fold.” A hidden next slide and a later image down the page are different viewing states. Browser lazy loading can fetch images before they become visible; do not promise it will wait for a click. After changing a loading role, retest the default arrival and a variant-specific landing link so the prompt request belongs to the correct product, not an old placeholder.

Preserve a useful placeholder

Reserve the image’s layout space so the page does not jump when it arrives. A low-detail placeholder should not be mistaken for the final product quality. If the selected variant changes, confirm that the new image is displayed clearly rather than leaving an old placeholder over it.

Test both arrival and interaction

Review a fresh page load, a scroll to later images and an option change on a phone. Separate a network delay from a blurred delivered file. CartVisual creates media; it does not configure your storefront loading strategy. Use catalog planning for the asset set and cache verification when the wrong version appears.

A loading-priority conversation

A fictional store places a product gallery beside its description on desktop and above it on mobile. Ask the developer which file appears first for each layout and whether it is requested immediately. Then check a later detail view after scrolling. Do not remove all deferral simply because the hero was delayed: later images may have a different role. Save an arrival screenshot and the observed loading sequence with the handoff. The useful result is an implementation requirement tied to actual viewing roles, while the approved creative files remain separately identified.

Save a before/after record for the same page URL, initial option, viewport and cache condition. Capture the requested image identity, request start and visible completion separately from any measured LCP result. A warm repeat can hide the original delay; use a defined fresh-load check and state what was cleared or disabled. Without a performance trace, report “observed arrival delay” rather than claim an LCP score or improvement.

Approve the change only when the intended initial product appears, later images still become available through scroll/selection, zoom remains usable and the reserved layout does not move the purchase controls. Use layout-shift review for that last check. This proposed handoff has not been executed on a merchant store and supplies no universal loading-time threshold.