How to Find the Elements Causing Layout Shifts

When a page jumps as it loads or responds to an interaction, the movement can make it hard to read or click the control you intended. Search and performance tools measure these shifts with Cumulative Layout Shift (CLS), a Core Web Vital that scores qualifying movements of visible content. Google uses Core Web Vitals in its ranking systems, but good scores do not guarantee higher rankings.

To find the cause, reproduce the jump and inspect a browser trace, a record of what happened on the page. The trace identifies elements that moved. Work backward from them to find what pushed or resized them. The reported element is often the one affected, not the one that triggered the movement.

What CLS captures

A layout shift occurs when a visible element changes position between rendered frames without a recent qualifying user action, such as a click or tap. A keypress also qualifies for the exception. Adding an element or changing its size alone does not count. The change counts when it moves other visible content.

CLS measures the largest cluster of qualifying shifts during a visit. Each cluster includes shifts less than one second apart and lasts no more than five seconds. A CLS of 0.1 or lower is considered good; a score above 0.25 is poor. These thresholds apply at the 75th percentile, measured separately for mobile and desktop. The CLS definition describes how the score and session windows work.

The score thresholds show how severe the shifts are, but they do not identify the cause. The browser’s Layout Instability API, which records changes in page layout, can report moved elements and their previous and current positions. It reports up to five sources for a shift, and may omit the element that caused the movement. Treat a reported element as a clue, then inspect the surrounding layout.

Reproduce the shift in Chrome DevTools

Recreate the conditions under which the jump occurs. Reload the page, then repeat the action linked to the problem, such as scrolling, opening a menu, changing a product option, or returning to the page. Use the same viewport where you saw the shift. If timing affects the result, test with a slower connection too.

In Chrome DevTools, open the Performance panel and record the page while reproducing the shift. The Layout shifts track marks individual events and groups them into clusters. Select the largest relevant event. Check its score and timing, then review the screenshots and affected elements. The Performance panel reference explains the available trace details.

Chrome’s Rendering tools also include Layout Shift Regions, which briefly highlight areas that move after a refresh. Use the highlighting to spot where movement occurs; it does not explain what caused it. Follow up with a Performance recording to connect the visual change to the page’s activity.

For a reproducible shift, a console observer can log the browser’s layout-shift entries:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log({
      score: entry.value,
      recentInput: entry.hadRecentInput,
      sources: entry.sources
    });
  }
}).observe({ type: "layout-shift", buffered: true });

This API-based check works in Chromium browsers, not as a cross-browser measurement method. The buffered: true option includes entries recorded before the observer started, so the first log entries may describe earlier shifts. The observer helps inspect individual events; its logged scores do not, by themselves, calculate the page’s final CLS.

Trace the movement back to its trigger

Start with the element the trace says moved. Note which way it moved and compare its position in the screenshots before and after the shift. Then inspect nearby content, especially the element above it. If that element appeared, grew, or moved, it may have pushed the reported element down.

The element that moved is not always the one to fix. For example, a paragraph may shift because an ad slot above it expanded. Changing the paragraph’s styling would address the symptom but leave the trigger in place. Inspect the shifted element itself too: its own styles or position may have changed.

Use the trace timeline to see what happened just before the jump. Check for styles, images, fonts, ads, embeds, banners, or script-driven updates that loaded late. These are common causes, but timing and direction alone do not prove the cause. A large downward movement suggests that something above the affected content may have appeared or grown. A small movement as text appears suggests checking whether a font change altered line wrapping.

Test the suspected cause in a controlled way. For example, reserve space for an image or embed and repeat the same load. If the movement disappears, that supports the diagnosis. If it remains, return to the trace and inspect other nearby elements or changes.

Compare the trace with field data

A local trace helps explain an event you can reproduce. Field data shows whether users encounter the problem and how widespread it is. PageSpeed Insights reports field measurements separately from its lab test, so check which result you are reading.

Field CLS can be worse than a lab result when shifts happen after the initial load, such as when content appears during scrolling. Compare the conditions before concluding that the local test is wrong. Chrome UX Report (CrUX) data uses a rolling 28-day window that updates daily. Search Console groups similar URLs, so its reports can show a broader pattern without naming the exact element on one page. The CrUX tools documentation describes how its data is reported.

Field data shows impact, but it may not reveal the trigger. Real-user monitoring that relies on browser APIs also cannot measure shifts inside iframes in the same way CrUX does. Different results from those sources do not automatically mean one is incorrect.

Avoid common diagnostic mistakes

Do not assume that every visible jump affects CLS. The metric focuses on position changes of existing elements, and some unstable-looking experiences fall outside what it records. A click or tap qualifies as discrete input, as does a keypress. Shifts occurring within 500 milliseconds of that input are excluded. Scrolling, dragging, and pinch-to-zoom do not count as that kind of input.

One Lighthouse run cannot rule out a problem that occurs later. If the shift happens during scrolling or after an interaction, record the page while repeating that action, or compare the result with field data. The CLS optimization guidance explains why shifts after the page loads matter.

A “culprit” label or selector does not prove the root cause: attribution can omit the trigger and reports only a limited number of shifted sources. The layout instability proposal describes the API’s limits. Follow the movement through the surrounding layout, then test whether changing the suspected trigger changes the result.

For SEO, fix CLS when it creates a poor experience or contributes to weak Core Web Vitals. Google says these metrics are used by its ranking systems, while also stating that good scores do not guarantee top rankings. Public documentation does not establish that a CLS improvement directly increases a page’s chance of appearing in AI-generated search answers.

Key Takeaways

• Reproduce the jump under the viewport and interaction conditions where it occurs; a reload-only test can miss shifts that happen later.
• Use a Performance trace to identify when content moved, then inspect the screenshots and nearby layout for the change that triggered it.
• Treat attribution as a clue: the reported element may be the one pushed out of place, while the cause sits elsewhere.
• Compare lab and field evidence to distinguish a repeatable local event from a problem users encounter across visits.
• Fix and retest the suspected trigger; if the same shift changes predictably, that supports the diagnosis.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com