THE SHORT ANSWER

Record the specific movement and trace the geometry change that caused it. Reserve the actual component shape and verify both loading and longer reader journeys.

Primary sources + editorial analysisSources & scope →
Reserved page space for images, fonts and a late-loading widget.

A page that jumps while somebody reads or tries to press a button has a layout-stability problem. Start by recording when the movement happens and which component changes the geometry. Compressing an image or changing a font-loading option does not, by itself, establish that the jump has been fixed.

This guide covers Cumulative Layout Shift, or CLS: interpreting the metric, finding the actual cause, reserving space and verifying the result. Official sources were checked on 13 October 2026. The examples are illustrative, with no measured scores or claimed tests on a particular website.

Read CLS as a stability measure, not a loading time

The official CLS definition measures unexpected movement of visible elements. Its score is unitless. An individual shift combines the affected viewport area with how far elements move; it is not a count of pixels or seconds.

Current CLS uses the highest-scoring burst of shifts during the page visit. Within a session window, successive shifts are less than one second apart and the window lasts at most five seconds. It is no longer simply the total of every shift over the entire visit.

At the 75th percentile of field page loads, evaluated separately for mobile and desktop, 0.1 or less is good; more than 0.1 through 0.25 needs improvement; more than 0.25 is poor. Movement closely following qualifying user input can be excluded by the metric. That does not make every excluded movement comfortable or every animation accessible.

Check whether the warning concerns loading or later use

PageSpeed Insights presents laboratory diagnostics and real-user experience as different evidence. The field view covers the previous 28 days and may describe the URL or the wider origin. Confirm the scope and device group before using it to assess one template.

A reload-only test can miss a banner inserted after a delay, a widget expanding lower down the page or content revealed during a longer reading session. The CLS optimization guide explains why post-load shifts can produce a gap between laboratory and field results.

Write down the visible symptom before changing settings. For a fictional recipe site, it might be: “after scrolling to the ingredient list, a related-video panel appears above it and moves the heading.” That is a much better diagnostic target than “the page has a bad score.”

Do not confuse a shifted element with the cause

The element named in an audit can be the victim of movement. A heading may jump because a previously empty image slot above it gains height. Shrinking the heading or hiding it would treat the symptom while leaving the source of the geometry change intact.

Chrome’s Performance panel reference documents the Layout shifts track and its clusters. Record a reload and a separate reading journey. Select the shift or cluster, examine the timing and highlighted elements, then inspect what changed immediately before the movement.

Capture enough context to reproduce the result: page, viewport, browser, cache state, consent choice and interaction sequence. A returning administrator with cached fonts may not reproduce what a first-time public reader sees. Use representative conditions without pretending that one simulation describes every device.

Observed movementCandidate cause to confirmFirst check
Text falls below an arriving pictureThe image slot did not reserve the intended heightActual dimensions and computed layout before loading
Menu wraps from one row to twoFont metrics or late style changes alter the available geometryFont arrival and CSS changes around the shift
Article moves after a widget arrivesA new component is inserted above existing contentContainer size and insertion timing
Lower content jumps during readingA deferred element changes size near the viewportLonger interaction recording, not only a reload

Give images a useful geometry before their files arrive

Mozilla’s image-element reference explains that width and height attributes allow the browser to calculate an aspect ratio before the image downloads. The values describe the image’s dimensions; responsive CSS can still adapt its displayed size.

For an illustrative photograph that is 1200 pixels wide and 800 pixels high, preserve that 3:2 relationship in the markup and responsive presentation. Do not assign a square placeholder to the landscape image and expect the content beneath it to remain still when the natural shape appears.

Check the public output, not just the selected image inside the editor. A theme, remote-image integration or generated card may output a different element from the one you inspected. Confirm the actual source and dimensions at each affected breakpoint.

Use our Media Library image workflow for choosing and managing assets. This stability check concerns reserved geometry; a smaller file with an undefined slot can still move the page.

Use aspect ratios and reserved slots deliberately

The CSS aspect-ratio property defines a preferred width-to-height relationship. At least one box dimension must be automatic for the ratio to influence sizing. A conflicting fixed width and fixed height will not be corrected merely by adding a ratio.

For a video embed, establish the intended responsive wrapper before the player loads. For a card image, confirm whether the design preserves the whole image or crops it into a deliberate frame. Reserve the same frame that the loaded component actually uses, while keeping meaningful image content visible.

Ads and variable-height third-party widgets need their own supported layout strategy. Decide where a slot belongs, which sizes it can take and what happens when it has no content. Collapsing an empty reserved area after the reader reaches it can create another jump. Do not introduce an oversized blank block everywhere without reviewing the resulting page.

Treat font swapping as a geometry question

A fallback font and the eventual web font can fit different amounts of text on a line. A navigation label that wraps, a heading gaining a line or a paragraph changing height can move surrounding content even when the font file itself is small.

Mozilla’s font-display reference describes the periods during which text can be blocked or use a fallback before the requested face is applied. The swap strategy makes fallback text available quickly but allows later replacement. It is not a promise of zero layout shift.

Choose a fallback with suitable proportions and verify the real navigation labels, long headings, bold text and supported languages. Changing font size solely to make one English heading fit can disturb the rest of the design. Recheck the narrowest layout where the component must work.

The size-adjust descriptor can scale a font’s outlines and metrics to help align a fallback with the intended face. Its value depends on the actual font pair. Have the maintainer derive and test it rather than copying a percentage from an unrelated example.

Improve font discovery without preloading everything

Official font guidance discusses stylesheet discovery, loading strategy and the costs of preload. Making a critical font available sooner may reduce the opportunity for a visible swap, but loading unnecessary fonts can compete with other important resources.

Inventory the faces and weights actually used on the affected template. Check whether the intended font is discovered late through a stylesheet chain, duplicated by several components or requested in unused variants. Fix the confirmed dependency with the theme’s supported mechanism and verify that the expected font still renders.

A system-font design is another option when it suits the brand. It is an editorial/design choice, not a mandatory performance rule. Keep the text readable and check the complete result; removing the web font does not repair unrelated injected content or image geometry.

Keep dynamic messages and motion usable

For the fictional recipe page, an ingredient filter might update a result count. Give the result area a clear design and avoid inserting an unexpected large notice above the reader’s current position. A required warning must remain visible and understandable; hiding it to reduce a score is not a repair.

Do not rely on the metric’s recent-input exclusion as permission for a disruptive interface. Compare before and after positions, retained focus and the reader’s ability to continue. Likewise, moving a component with a transform can avoid some layout effects without guaranteeing that its movement is comfortable.

Mozilla’s reduced-motion reference documents the user’s motion preference. Honour it for nonessential animation. Our readable typography guide covers a separate requirement: text still needs to work when people zoom or adjust spacing.

Verify the complete reading journey after the repair

  1. Repeat the original loading and reading sequences with the same diagnostic conditions.
  2. Inspect the recorded shifts and identify whether the original geometry change has disappeared.
  3. Check uncached resources and a returning-visitor state separately.
  4. Test narrow and wide layouts, long text, representative images and relevant consent states.
  5. Check late embeds, expandable sections and empty widget results.
  6. Confirm that no content is cropped, hidden or made unreachable to obtain a lower number.

Save the baseline, the focused change and the retest conditions. Use a protected staging copy for changes that can disturb a live template. When field data is available, monitor it after release while remembering its collection window and population.

A stable result means readers can follow the content and operate controls predictably in the tested journeys. It does not follow from a single screenshot, one green laboratory result or a universal promise that every later resource will arrive in the same order.

Sources and verification

Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.

View sources
  • web.dev: Cumulative Layout ShiftChecked Unitless impact/distance model, largest burst/session-window definition, one-second gaps/five-second duration, current 0.1/0.25 categories and qualifying-input exclusion.
    Limits: No score calculated or universal comfort/accessibility claim derived from an excluded shift. Metric thresholds are field assessment guidance.
  • Google: About PageSpeed InsightsChecked Field and lab separation, trailing 28-day field context and URL/origin/mobile/desktop scope.
    Limits: No report checked or assumption that a one-time test represents the whole site.
  • web.dev: Optimize Cumulative Layout ShiftChecked Post-load versus reload-only differences, shifted victims versus originating components, and planning geometry for deferred content.
    Limits: Examples and diagnostic worksheet are original editorial guidance; no complete widget/ad strategy or achieved CLS result claimed.
  • Chrome: Performance features referenceChecked Layout shifts track, cluster inspection and timing/element context.
    Limits: UI varies; no real recording or exact cause determined for the reader.
  • Mozilla: img elementChecked Width/height attributes permit pre-download aspect-ratio reservation and matter for deferred images; responsive presentation remains distinct.
    Limits: The 1200x800 example is fictional. The rendered public element and stylesheet must still be inspected.
  • Mozilla: aspect-ratioChecked Preferred box ratio, automatic-dimension condition and responsive sizing context.
    Limits: No universal crop or embed ratio; fixed dimensions and the actual asset can override expectations.
  • Mozilla: font-displayChecked Fallback/block/swap rendering periods; swap does not by itself guarantee equivalent text geometry.
    Limits: No single display value prescribed for every design or promise of zero layout shift.
  • Mozilla: size-adjustChecked Font outline/metric scaling and use in harmonizing a fallback with a primary face.
    Limits: No copied percentage suggested; actual font pair, languages and layout require testing.
  • web.dev: Best practices for fontsChecked Font discovery through stylesheets, used variants and preload competing with other resources.
    Limits: No automatic performance benefit promised for self-hosting or preloading all fonts; actual delivery not measured.
  • Mozilla: prefers-reduced-motionChecked User motion preference for adapting nonessential animations.
    Limits: No accessibility certification; avoiding layout score contributions does not by itself make motion appropriate.