Why This Happens In WordPress 6
Cumulative layout shift from images usually happens when the browser cannot reserve the correct space before an image finishes loading. In WordPress 6, that problem often shows up around the Gutenberg Image block when the rendered markup loses reliable dimensions, when a theme overrides image sizing badly, or when externally inserted images bypass the normal attachment workflow.
Google’s CLS guidance is blunt about the main cause: images without stable dimensions are one of the most common reasons pages jump during load. WordPress itself already tries to help here. Its responsive images documentation explains that core generates `srcset` and `sizes` so the browser can choose an appropriate file, and the Image block documentation shows that the block is designed to work best with Media Library assets rather than fragile hotlinked images.
That means the fix is usually not a mystery. You need to make sure the Gutenberg image block outputs predictable dimensions, preserves the image aspect ratio, and does not defer above-the-fold images in a way that causes late reflow.
Quick Diagnosis Table
| Symptom | Likely Cause | Best Fix |
|---|---|---|
| Text jumps down when an image appears | Missing width and height or no reserved ratio | Ensure the image is a Media Library attachment and preserve intrinsic dimensions |
| Hero image shifts on first paint | Theme CSS overrides height or width incorrectly | Use `height: auto` and avoid fixed height without a matching ratio |
| Only some images shift | Images inserted from external URLs or custom block output | Re-upload to Media Library or fix custom rendering |
| Shift happens while scrolling | Lazy-loaded images have no reserved space | Keep dimensions intact and only lazy-load below-the-fold images |
| Shift starts after cropping or custom styling | CSS or block style breaks aspect ratio | Add an explicit `aspect-ratio` fallback where needed |
How To Fix Cumulative Layout Shift From Images In Gutenberg
Use Media Library Images Instead Of External URLs
The safest path is to use images that exist in the WordPress Media Library. According to the Image block documentation, WordPress can insert images from a URL, but it also warns that external images may later fail or behave unpredictably. For performance and layout stability, Media Library images are better because WordPress knows their metadata and can generate the responsive image markup it needs.
If a shifting image was added with **Insert From URL**, replace it with a locally uploaded attachment. That gives WordPress access to the file dimensions and its generated intermediate sizes.
Do Not Strip Core Image Attributes
WordPress responsive image support depends on generated markup. The responsive images API docs note that WordPress adds `srcset` and `sizes` automatically, but it will not modify content HTML that already contains those attributes. In practice, that means layout problems often come from filters, page builders, optimization plugins, or custom template code that rewrites image markup after core has generated it.
Check whether your theme or plugin stack is removing or replacing:
- intrinsic width and height values
- responsive `srcset`
- calculated `sizes`
- attachment-based image rendering
If you are calling images in templates, prefer core functions that keep attachment metadata intact instead of hand-rolled markup.
Preserve Aspect Ratio In CSS
Google’s Optimize CLS guide recommends always setting image dimensions or reserving space with CSS `aspect-ratio`. MDN’s aspect-ratio reference explains why this works: the browser can calculate space before the image file fully loads.
A common Gutenberg-related mistake is theme CSS like this:
.wp-block-image img {
width: 100%;
height: 100%;
}That pattern can break intrinsic sizing and produce unstable rendering. A safer baseline is:
.wp-block-image img {
max-width: 100%;
height: auto;
}If your design deliberately crops images to a fixed frame, reserve that frame explicitly instead of letting the browser guess:
.wp-block-image.is-style-framed img {
width: 100%;
aspect-ratio: 16 / 9;
object-fit: cover;
}Use that kind of rule only when the same visual ratio is intentional. If the source images vary wildly, a hard-coded ratio can solve one CLS issue while creating awkward crops.
Avoid Breaking The Default `sizes` Logic
WordPress documents its default `sizes` behavior as roughly equivalent to `(max-width: image-width) 100vw, image-width`. That default is usually sensible, but custom themes sometimes force narrow content columns, oversized wrappers, or mismatched CSS widths without updating the responsive image calculation.
When the rendered layout and the generated `sizes` attribute disagree, the browser may fetch an unnecessarily large candidate or swap visual calculations later in the render path. That is more of a delivery inefficiency than a direct CLS trigger, but it often travels with image instability problems.
If your theme uses unusual content widths, review any custom filters on image sizing and make sure the displayed width in CSS matches the intent of the generated responsive markup.
Be Careful With Lazy Loading On Important Images
WordPress core added native lazy loading for many images, as described in the WordPress core note on lazy-loading images. That is usually a win, but it is not a free pass. Google’s CLS guidance still says you must reserve image space even for lazy-loaded media.
For above-the-fold images, the safest pattern is:
- do not lazy-load the main hero image
- keep width and height intact
- avoid JavaScript lazy-load systems that swap placeholders too late
- make sure any placeholder matches the final ratio
If an optimization plugin rewrites Gutenberg output with its own lazy-load markup, inspect the frontend HTML. The plugin may be replacing a stable core image with a delayed wrapper that has no reserved height.
Recheck Cropped And Styled Block Variants
The WordPress Image block supports alignment, captions, linking, cropping, and style variations. Those features are useful, but custom CSS around them is a frequent source of layout drift. Problems often appear when:
- captions load in a font or size that expands after first paint
- floated images are resized inconsistently between breakpoints
- full-width or wide-width images receive conflicting height rules
- theme styles target `.wp-block-image` and nested `img` differently across mobile and desktop
Inspect the computed styles for any shifting image and look for:
- fixed heights without a matching ratio
- `position` changes after hydration or script execution
- margin or padding injected late by scripts
- placeholder wrappers with different final dimensions
A Practical Repair Workflow
Step 1: Identify The Exact Shifting Image
Use PageSpeed Insights or Chrome DevTools, following the debugging approach described in Google’s Optimize CLS article. Start with the URL that shows the worst field or lab CLS.
Step 2: Inspect The Frontend Markup
Check whether the affected Gutenberg image block outputs:
- an attachment-based image URL
- width and height attributes
- `srcset`
- `sizes`
- any lazy-loading attribute
If the image came from an external URL or has been rewritten by a plugin, that is your first fix candidate.
Step 3: Compare Markup Against CSS
Make sure theme CSS does not override the image with:
- `height: 100%`
- fixed heights on responsive images
- inconsistent wrapper dimensions
- late-loading classes that change layout after paint
Step 4: Add A Ratio Fallback Only Where Needed
If your design uses consistent cards, banners, or editorial crops, add `aspect-ratio` to the wrapper or image style. Do not blanket-force one ratio across every Gutenberg image on the site unless your content model actually supports that.
Step 5: Retest The Page
After changes, rerun Lighthouse or PageSpeed Insights and confirm the affected block no longer shifts. For broader media tuning, the Flux article on web image performance is useful background on how image delivery choices affect Core Web Vitals beyond CLS alone.
Example Of A Safe Direction For Theme Developers
If you are fixing this in theme code, the goal is usually to leave WordPress core image markup alone and only normalize layout behavior:
.wp-block-image img {
display: block;
max-width: 100%;
height: auto;
}
.wp-block-image.alignwide img,
.wp-block-image.alignfull img {
width: 100%;
}That will not solve every case, but it avoids the common mistake of fighting the browser’s intrinsic image sizing.
What Usually Solves It Fastest
In most WordPress 6 sites, the fastest reliable fix for cumulative layout shift from images is this combination:
- Replace hotlinked or custom-rendered images with Media Library attachments.
- Keep WordPress-generated image attributes intact.
- Remove CSS that forces unstable image heights.
- Add `aspect-ratio` only where your design requires a fixed visual frame.
- Exclude above-the-fold images from aggressive lazy-loading rewrites.
Conclusion
If the Gutenberg Image block seems to be causing cumulative layout shift from images, the block itself is usually not the real problem. The real issue is almost always broken dimension data, CSS that overrides intrinsic sizing, or a lazy-loading layer that removes reserved space. WordPress core already gives you solid foundations through the Image block, Media Library metadata, and responsive image markup. The cleanest fix is to preserve those defaults, correct any theme or plugin overrides, and reserve space explicitly when your layout needs a fixed ratio.