Why does the buy button move when a product photo finishes loading?

Watch the pending interaction

Open a draft product with a cold load and observe the gallery before its full image appears. Choose a purchase task: selecting a size, adjusting quantity or reaching the cart button. Record which control moves and whether focus, selection or pointer position now refers to something unexpected. A final screenshot alone cannot show this transition.

web.dev explains that image dimensions or reserved aspect-ratio space let the browser allocate room before loading. That principle is a starting point; your maintainer must identify the actual shifting element, which could also be a late caption, badge or application block.

Record a change with a real consequence

In this fictional lamp store, the gallery begins as a shallow placeholder. Its portrait photo then extends the page, moving the quantity control while a shopper is approaching it. Switching to the desk-context photo repeats the movement. Both images are approved; their different ratios expose an unstable presentation slot.

Request a stable slot without damaging the photo

Ask the maintainer to reserve appropriate media space for the intended gallery design and account for captions that arrive later. Different ratios may need a deliberate presentation policy, with the whole product retained. Do not solve movement by stretching the lamp or cutting off its base. Discuss whether the slot should remain stable through view changes and how smaller layouts should behave.

If using a performance trace, have the maintainer distinguish measured layout-shift events from deliberate interaction changes. A control moving during a user action can still be inconvenient even when it does not contribute to a reported CLS score.

Classify the event with its timing and trigger. CLS excludes qualifying shifts shortly after user input; not every inconvenient move is therefore a CLS contribution. Conversely, a later asynchronous image, caption or app update can still produce a qualifying unexpected shift. Do not label a whole variant flow “CLS-free” from the fact that its first step was a click.

Repeat the timing that caused the failure

Retest a cold arrival, a slower image response and the exact view-change sequence. Compare target positions and retained selection, not just the final page. Include narrow and wide layouts because a stable desktop slot may still collapse before mobile media loads. Ask a reviewer to complete the purchase task without chasing a moving control.

Use the gallery interaction review as a manual review record. Sample rows are fictional. It does not connect to, import into or modify an external store or production machine.

CartVisual can supply consistently framed candidate images for review. It does not reserve theme layout space, measure your live CLS or deploy the repair. Keep asset approval and the external store’s transition test separate.

Keep a short before/after sequence or trace showing the selected view, media/caption bounds, purchase-control position and triggering action. A stable final frame does not show whether a pending target moved earlier. Judge the specific buyer task separately from a measured performance metric. Recheck retained option state and the actual rendition budget after a slot repair.

The shared gallery CSV currently contains only two fictional pending examples: keyboard-dialog return and mobile-source selection. It is a reusable column template, not coverage of every test here. Copy a row, replace its page/variant/view and test_condition with your actual case, and use observed_result for the before/after control positions, trigger and timing rather than a final screenshot alone. Keep review_status pending until the actual check is performed.