Why This Oversized Image Issue Happens
An oversized image problem in a WordPress 6 Gutenberg image block usually means the page is shipping a larger file than the layout actually needs. That hurts load time, wastes bandwidth, and can weaken Core Web Vitals. In practice, the problem often comes from one of three places: the block was inserted at full size, the theme is forcing a large rendered width, or the site is bypassing WordPress responsive image markup.
WordPress already generates multiple image sizes and adds `srcset` and `sizes` to core image output so the browser can pick an appropriately sized file. The trouble starts when editors select the wrong image size, themes override the block output, or templates print raw image URLs instead of using core image functions. The fix is usually straightforward once you isolate which layer is responsible.
Quick Diagnosis Table
| Check | What To Look For | Why It Matters | Fastest Fix |
|---|---|---|---|
| Block setting | Image block set to Full Size | Full-size originals are often much larger than the rendered area | Switch to Large, Medium Large, or a custom content width size |
| Front-end markup | Missing `srcset` or `sizes` | Browser cannot choose a smaller candidate | Use core image output instead of hardcoded image URLs |
| Uploaded source | Original image is far larger than needed | WordPress can still carry a heavy source through the workflow | Resize before upload or use upload thresholds |
| Theme CSS | Image displayed much smaller than source | Large file gets downloaded only to be shrunk in the browser | Match registered image sizes to real layout widths |
| Old media library | Legacy posts use oversized assets | Historical content keeps failing audits | Regenerate and replace where needed |
What WordPress 6 Already Does Correctly
WordPress has supported responsive images for years. According to the Responsive Images documentation, core adds `srcset` and `sizes` to generated image markup so browsers can select a more appropriate file for the viewport. The same documentation also notes that WordPress creates several intermediate sizes on upload, including the default `medium_large` size that exists specifically to improve responsive image delivery.
That means a standard Gutenberg image block is not inherently the problem. The block can work well if the image was inserted with a sensible size and the theme keeps WordPress core markup intact.
The wp_get_attachment_image() reference is also important here. It recommends using registered image sizes rather than arbitrary width and height arrays, because cropped or pre-generated image variants are more efficient than sending a larger file and letting the browser shrink it visually.
How The Gutenberg Image Block Triggers Oversized Images
Full-Size Selection In The Editor
The most common cause is simple: the image block is inserted as Full Size when the content area only displays it at 700 to 900 pixels wide. If the original upload is 3000 pixels wide, the page may still expose an unnecessarily large source candidate.
In the editor, check the image block settings and confirm the selected size. For most article layouts, a content-width image rarely needs the original upload. A large pre-generated size is usually enough.
Theme Or Template Output Bypasses Core Functions
If a theme or custom block template prints a raw attachment URL, WordPress cannot add the responsive `srcset` and `sizes` logic that core normally provides. That leads to oversized image delivery even when smaller variants exist in the Media Library.
For custom templates, use `wp_get_attachment_image()` or equivalent block rendering that preserves core image attributes.
Layout Width And Image Size Do Not Match
WordPress uses a default `sizes` value based on the image width, but the Responsive Images documentation explicitly says themes should customize that value when needed with the `wp_calculate_image_sizes` filter. If your theme has a narrow content column, a wide default size hint can encourage the browser to fetch a larger file than necessary.
The Best Fixes In Order
Choose The Correct Block Size First
Start inside Gutenberg. Open the affected image block and review the selected image size. If it is set to Full Size, test Large or Medium Large instead. This is the cleanest fix because it does not depend on extra plugins or risky code changes.
A good rule is to match the chosen size to the actual maximum rendered width of the content column.
- Use Medium Large for standard article images when the layout is modest.
- Use Large for wide featured visuals inside the content area.
- Use Full Size only when the layout genuinely needs the original dimensions.
Register Sizes That Match Your Real Layout
If your content area is 820 pixels wide but your closest generated image is much larger, create a custom image size near that width. Core guidance around `wp_get_attachment_image()` makes this the efficient route because WordPress can serve a pre-generated file rather than relying on the browser to scale down a bigger one.
add_action('after_setup_theme', function () {
add_image_size('content-width', 900, 0, false);
});Then make sure your templates or editorial workflow actually use that size.
Limit Overly Large Uploads
Large originals create problems upstream. Even if WordPress scales them later, editors can still insert inefficient media choices, and storage grows quickly.
WordPress supports the `big_image_size_threshold` filter, which can scale down very large uploads automatically.
add_filter('big_image_size_threshold', function () {
return 2048;
});For many editorial sites, 2048 pixels on the long edge is a practical ceiling. It preserves quality for normal content while reducing the risk of oversized image warnings.
Keep Responsive Markup Intact
If your site uses custom PHP templates, audit how images are rendered. Avoid hardcoded `<img>` tags built from raw file URLs when an attachment ID is available.
Use code like this instead:
echo wp_get_attachment_image($attachment_id, 'content-width', false, [
'class' => 'article-image'
]);That allows WordPress to attach width, height, `srcset`, `sizes`, loading behavior, and other optimization attributes automatically.
Tune The Source Set When Needed
WordPress includes a safeguard for very large source candidates. The max_srcset_image_width hook filters the maximum image width included in a `srcset`, and the documented default is 2048 pixels.
If your site routinely generates very large derivatives that are never useful in the layout, reviewing this limit can help keep responsive candidates sane. This is more of a developer-level refinement than a first fix, but it is useful on media-heavy sites.
add_filter('max_srcset_image_width', function ($max_width) {
return 1600;
});Only do this after checking your real layout requirements, especially for large hero areas.
Audit Theme CSS And Container Widths
Sometimes the file is not technically wrong, but the layout makes it wasteful. If the theme renders a 1600-pixel asset inside a 720-pixel column on desktop, Lighthouse may still flag it as oversized.
Check these items:
- The actual rendered width of the image block on desktop and mobile.
- Whether the theme applies `width: 100%` inside a narrow wrapper.
- Whether the block alignment options such as Wide or Full are being used correctly.
- Whether old CSS is forcing images into a smaller space than the selected WordPress size assumed.
How To Verify The Fix
After changing the block size or template output, verify the result instead of assuming it worked.
- Open the page in Chrome.
- Inspect the image element.
- Confirm the markup contains `srcset` and `sizes`.
- Check the actual requested image in the Network panel.
- Compare its intrinsic dimensions with the rendered dimensions.
- Re-run Lighthouse or PageSpeed Insights.
If the browser still downloads a file much larger than the rendered area, the theme hinting or source size choices still need work.
Google's guidance on optimizing layout shift is also relevant because images should include width and height attributes. WordPress core generally adds those when you use standard image functions, which is another reason not to bypass native image output.
A Sensible Workflow For Existing Sites
If this issue appears across many posts, fix it in layers rather than editing one article at a time.
- Set an upload ceiling for new images.
- Register image sizes that match the site layout.
- Update custom templates to use core image functions.
- Review Gutenberg editorial defaults so editors stop choosing Full Size unnecessarily.
- Regenerate image sizes if your theme or size definitions changed.
- Revisit high-traffic legacy posts first.
For broader background on image efficiency in WordPress, the related Flux Plugins article on fixing oversized image files is a useful companion because it covers the same performance problem from the media workflow side rather than the Gutenberg block angle.
Recommendation
The best fix for oversized images caused by the WordPress 6 Gutenberg image block is usually not replacing Gutenberg. It is making Gutenberg use the right image size, preserving WordPress responsive image markup, and aligning generated sizes with the real front-end layout.
If you want the shortest path, do this first:
- Stop using Full Size for normal in-content images.
- Add a custom image size that matches your content width.
- Render images through core WordPress functions so `srcset`, `sizes`, width, and height stay intact.
- Limit very large uploads before they enter the library.
That combination addresses the root cause, keeps the editor workflow simple, and gives you a durable fix instead of a one-off patch.