How to Serve Scaled Images in WordPress and Fix PageSpeed Warnings

To serve scaled images in WordPress, make every image file roughly the size it is actually displayed at, then let WordPress hand smaller copies to smaller screens through srcset. On most sites the fix takes 20 to 60 minutes: find the flagged images in PageSpeed Insights, measure their rendered size, swap any “Full Size” inserts for a fitting size, and correct the theme or page-builder settings that force oversized files. You need admin access to WordPress and, for the code-based fixes, a child theme or a code snippets plugin plus a fresh backup.

The warning itself has changed names over the years. Older reports said “Serve scaled images”, Lighthouse later called it “Properly size images”, and the current version of the check lives inside a broader insight. Knowing exactly what the tool measures is what separates a quick fix from hours of re-uploading images that were never the problem.

What the “serve scaled images” warning actually measures

Google’s Lighthouse documentation explains that the check compares each image’s rendered size with its actual file dimensions, and the rendered size accounts for device pixel ratio. An image fails if the rendered size is at least 4 KiB smaller than what was downloaded. In plain terms: if the browser downloads a 2000-pixel-wide photo and shows it in a 600-pixel box, the pixels it threw away are wasted bytes, and Lighthouse reports those bytes as potential savings.

Device pixel ratio matters more than most tutorials admit. A phone with a 3x screen showing an image in a 360-pixel-wide slot genuinely benefits from a file around 1080 pixels wide. So “match the display size” does not mean “match the CSS width”. It means match the CSS width multiplied by the screen density the visitor actually has. That is the job srcset does, and it is why a single hand-resized file rarely clears the warning on both mobile and desktop.

The warning now lives inside “Improve image delivery”

According to the Chrome for Developers page on properly sizing images, the audit moved into the “Improve image delivery” insight as of Lighthouse 13. DebugBear’s breakdown of that insight lists the thresholds it uses: potential savings above 4 KB by default, or above 12 KB for images that already use responsive syntax such as srcset or <picture>. The same insight also flags poorly compressed images and large animated GIFs, so one PageSpeed line can now mix sizing problems with compression problems.

That has a practical consequence. If an image appears under “Improve image delivery”, read the per-image recommendation before acting. A file flagged for compression needs re-encoding or a modern format, not resizing, and resizing it will barely move the score.

What the check ignores

DebugBear notes that the insight excludes CSS background images, SVGs, and images that are not rendered. This explains a common frustration: a huge hero background set in the theme’s CSS slows the page down but never shows up in the image list. It still hurts loading, especially Largest Contentful Paint, so it needs fixing by hand even though PageSpeed stays silent about it.

What WordPress already does for you

Before installing anything, understand the image handling built into WordPress core, because most “serve scaled images” warnings on WordPress sites come from code that bypasses it.

• Responsive images since WordPress 4.4. The official WordPress developer documentation confirms that native srcset and sizes support has existed since version 4.4, and that it needs no settings to configure.
• A 2048-pixel ceiling in srcset. The max_srcset_image_width filter caps the widest file WordPress lists in srcset; its default is 2048 pixels.
• A default sizes attribute. Unless a theme overrides it, WordPress outputs a sizes value equivalent to (max-width: {image-width}px) 100vw, {image-width}px.
• A hidden 768-pixel size. The medium_large size defaults to 768 pixels wide and does not appear in the media settings screen.
• Big-image scaling since WordPress 5.3. The make.wordpress.org core announcement explains that uploads taller or wider than 2560 pixels are scaled down to fit that threshold, and the scaled copy becomes the largest available size. Commenters on that announcement report the resulting file gets “-scaled” added to its name.

The weak point is the default sizes value. It tells the browser an image may be as wide as the whole viewport up to its own width. In a typical blog layout with a sidebar, the content column is much narrower than the viewport, so a desktop browser often picks a larger file than the slot needs. Lighthouse sees the gap and flags it.

How to serve scaled images in WordPress, step by step

Work through these in order. The early steps fix most warnings without code; the later steps handle what’s left.

1. Run the page through PageSpeed Insights. Test the mobile result first, since smaller viewports expose sizing mistakes fastest. Open the “Improve image delivery” item (or “Properly size images” on older reports) and note each image URL and its estimated savings.
2. Measure the rendered size. Open the page in Chrome, right-click the flagged image and choose Inspect. Hovering the <img> element shows its rendered dimensions next to its intrinsic ones. Check the same image at a phone width using the device toolbar, because a theme may display it at different sizes per breakpoint.
3. Check which file was inserted. In the HTML you are inspecting, look at the file name in src. A name ending in “-scaled” or with no dimension suffix usually means the full-size image was inserted. Lighthouse’s own WordPress guidance is to upload through the media library and avoid “Full Size” images unless their dimensions fit.
4. Swap the size in the editor. In the block editor, select the Image block and change the resolution option in the block settings sidebar to a size close to the content width, such as Large. Update the post and re-test.
5. Confirm srcset is present. Inspect the image again. A WordPress-inserted image should carry srcset and sizes attributes. If they are missing, the image was added by something that bypasses core functions: a page builder widget, a slider, hard-coded HTML in a theme template, or an image pasted as an external URL.
6. Fix the source that bypasses srcset. For page builders and sliders, look for an image size or resolution option inside the widget itself and choose a size close to the display width. For theme templates, the developer should output images with wp_get_attachment_image(), which adds srcset and sizes automatically.
7. Tighten the sizes attribute if needed. If srcset is present but desktop still downloads a file far wider than the content column, apply the snippet in the next section.
8. Re-test and clear caches. Purge your caching plugin and any CDN cache, then run PageSpeed Insights again. Results vary between runs, so judge by whether the specific image disappears from the list rather than by the overall score.

Code fixes for themes that send the wrong size

Back up the site and add these snippets to a child theme’s functions.php or a code snippets plugin, never to a parent theme that updates will overwrite. Each snippet uses a filter documented on developer.wordpress.org.

Tell the browser how wide the content column really is

This example assumes a content column that never exceeds 800 pixels. Replace 800 with your theme’s measured content width from step 2.

add_filter( 'wp_calculate_image_sizes', function ( $sizes, $size ) {
    $width = $size[0];
    if ( $width > 800 ) {
        return '(max-width: 800px) 100vw, 800px';
    }
    return $sizes;
}, 10, 2 );

The filter receives the current sizes string and an array whose first value is the image width. For any image wider than the column, the function replaces the default “up to the full viewport” hint with an honest one: full viewport width on small screens, never more than 800 pixels otherwise. Smaller images keep WordPress’s default. The browser combines this hint with the screen’s pixel density, so high-density phones still get a sharp file.

Lower the big-image threshold

If editors routinely upload camera photos and no layout on the site displays images anywhere near 2560 pixels wide, lowering the threshold makes the largest stored copy smaller. The big_image_size_threshold filter controls it:

add_filter( 'big_image_size_threshold', function () {
    return 1920;
} );

This only affects images uploaded after the change. The original upload is still kept in the uploads folder; WordPress records its filename in the image metadata under original_image, and wp_get_original_image_path() returns its path. Returning false from this filter disables scaling entirely, which is the opposite of what a speed fix needs, so avoid copying that variant from older tutorials.

Cap the widest file in srcset

On layouts that never display images wider than about 1200 pixels, there is little reason for srcset to offer 2048-pixel files to high-density desktop screens. The max_srcset_image_width filter lowers that ceiling:

add_filter( 'max_srcset_image_width', function () {
    return 1600;
} );

Treat this one carefully. Set it too low and full-width images look soft on large, high-density monitors. Choose a value at least double your widest content image if a sharp result on retina screens matters.

Which fix to use: decision guidance

Different causes need different fixes, and picking the wrong one wastes an afternoon. This table maps what you see in the inspector to the fix that works.

What you see	Likely cause	Fix
File name ends in “-scaled”, srcset present	“Full Size” chosen in the editor	Change the block’s resolution to a smaller size
srcset present, desktop still picks a huge file	Default sizes attribute too generous	wp_calculate_image_sizes snippet
No srcset at all	Page builder, slider, or hard-coded template	Widget size setting or wp_get_attachment_image()
Image hosted on another domain	Pasted external URL	Upload to the media library and re-insert
Flagged for compression, not size	Heavy encoding or old format	Re-encode or convert; resizing won’t help

When should you leave a warning alone? If the reported saving is a few kilobytes on an image below the fold, the effort rarely pays back. Spend the time on the largest image above the fold instead, since that is usually the Largest Contentful Paint element and the one visitors actually wait for.

Common mistakes that keep the warning coming back

Resizing with CSS only. Setting width: 400px on a 2000-pixel image changes how it looks, not what it weighs. The browser still downloads every byte, which is precisely what the check measures.

Hand-resizing every image to the desktop width. An 800-pixel file is perfect for an 800-pixel desktop column and still flagged on a 360-pixel phone, because one file cannot fit every screen. Upload a reasonably sized original and let WordPress generate the smaller copies for srcset.

Changing image sizes without regenerating old ones. Adding or changing registered sizes only affects new uploads. Existing images keep the files created when they were first uploaded until thumbnails are regenerated with a regeneration plugin or WP-CLI. Large libraries take a while, and every new size adds files to the server, so check disk space first.

Testing a cached page. A caching plugin or CDN may keep serving the old HTML with the old image after you fix it. Purge caches before re-testing, or the “fix” appears not to work.

Ignoring CSS background images. Because the insight excludes them, a theme hero set as a background can be the heaviest asset on the page while the report shows nothing. Check its file size in DevTools’ Network panel and provide smaller versions through media queries.

Troubleshooting stubborn cases

The same image is flagged after switching to Large

Large may still be wider than the slot on mobile. If srcset is present, the cause is usually the sizes attribute; apply the content-width snippet. If the theme adds its own sizes through wp_get_attachment_image_attributes, your filter may be overridden, so check with the theme developer.

Featured images and archive thumbnails are oversized

Themes often register a featured image size larger than its display slot, or output the full image in grids. Look in the theme’s customizer for a thumbnail or featured image size option first. If none exists, a developer can register a smaller size with add_image_size() and call it in the template.

WooCommerce product images

Product galleries and shop grids use their own image sizes. Mismatches here usually come from a theme displaying a size at a different width than WooCommerce generates. After any change to product image dimensions, regenerate thumbnails so existing products get the new files.

Logos and icons

A logo uploaded at 1000 pixels and shown at 180 is a classic offender. Upload it at roughly two times its display width for sharp results on high-density screens, or use SVG where the theme allows, since SVGs scale without extra bytes and fall outside this check.

Frequently asked questions

How do I fix “properly size images” in WordPress without a plugin?

Change “Full Size” image inserts to a size close to the display width, make sure images carry srcset, and correct the sizes attribute with the wp_calculate_image_sizes filter if the content column is narrower than the viewport. Those core features handle most cases without any extra plugin.

Why does PageSpeed still flag images after I resized them?

Usually because the page is still cached, the image has no srcset, or the sizes hint tells the browser to pick a bigger file. Another possibility is that the image is flagged for compression rather than dimensions under the “Improve image delivery” insight. Read the per-image recommendation before resizing again.

What is the “-scaled” image WordPress creates?

Since WordPress 5.3, uploads larger than 2560 pixels in width or height are scaled down to that threshold, and the scaled copy becomes the largest available size. The original file stays in the uploads folder and is recorded in the image metadata, so nothing is lost.

Should I disable big image scaling in WordPress?

For page speed, no. Disabling it means the largest available file is your untouched original, often a multi-megabyte camera photo. Lower the threshold with the big_image_size_threshold filter instead if your layouts never need images that wide. Photographers who need full-resolution downloads are the exception.

Do I need to regenerate thumbnails after changing image sizes?

Yes. New or changed image sizes apply only to images uploaded afterwards. Existing images keep the files created at upload until thumbnails are regenerated with a plugin or WP-CLI. Back up first and check server storage, since each size adds a file per image.

Does serving scaled images improve SEO?

Indirectly. Smaller image downloads speed up loading, and the main image is often the Largest Contentful Paint element measured in Core Web Vitals. Faster pages also keep mobile visitors from abandoning the page. The score itself is a diagnostic, not a ranking factor on its own.

Next steps

Most “serve scaled images” warnings on WordPress come from one of three things: a “Full Size” insert, a theme or builder that skips srcset, or a sizes attribute that assumes the image fills the screen. Fix them in that order, re-test the specific images rather than chasing the overall score, and leave tiny below-the-fold savings for last.

Once sizing is under control, the bigger gains usually come from the main image itself. The guide to fixing LCP by optimizing images covers compression, preloading, and lazy-loading choices, and the comparison of JPEG vs PNG helps pick the right format before upload. For inserting images correctly in the first place, see how to add images in WordPress, and if regenerating thumbnails fills the server, freeing up WordPress disk space walks through the cleanup. Official references: Lighthouse: Properly size images, WordPress responsive images API, and big image handling in WordPress 5.3.