A commerce site's layout shift metric worsens sharply after a release and the team cannot reproduce it locally. How do you find it?

Why it does not reproduce

Layout shift is caused by content arriving after paint and displacing what is already visible. Locally, everything loads instantly from cache on a fast connection, so the late-arriving content arrives before the user could have seen anything move.

The bug exists only under real network conditions, which is why local testing shows nothing and why field data is the only reliable source.

The usual causes

• Images without dimensions, so the browser reserves no space and content jumps when they load.
• Ads or embeds injected into the flow, which is the single most common cause on commercial sites.
• Web fonts swapping, where fallback and web font have different metrics and every line reflows.
• Content inserted above the viewport — a banner, a notification bar — pushing everything down.
• Client-side personalisation replacing placeholder content after paint.

The diagnostic path

1. Field data with element attribution. Real user monitoring that reports which element shifted turns this from a hunt into a lookup — and if that attribution is not being collected, adding it is the first fix.
2. Segment by page, device and connection, since the cause is frequently specific to one route or to slow connections.
3. Throttle aggressively in the lab once you know where to look, since the effect only appears when loading is slow enough for the user to see the intermediate state.
4. Correlate with the release contents — a new third-party tag or a personalisation change is the usual answer.

The structural prevention

Reserve space for anything that arrives late: explicit dimensions on media, fixed containers for ads and embeds, font metric matching, and skeletons sized to the content they will be replaced by. Transform and opacity animations do not cause shift; animating layout properties does.