WordPress Image Optimization for Speed and SEO

Images are usually the heaviest part of a web page, and on a blog they are often the element that decides how fast the page feels. This guide is for bloggers, marketers and small business owners who run WordPress and want faster pages and better image search visibility without learning to code. It covers sizing, formats, responsive images, lazy loading, compression, and the alt text and file names that help search engines understand what a picture shows.

Contents

Start with the right dimensions
Choose a format: JPEG, PNG, WebP or AVIF
Compress without ruining quality
Let responsive images do their job
Lazy loading, and why the LCP image is the exception
1. What WordPress does automatically
2. When you need to step in
Image SEO: alt text, file names and context
A simple workflow for every new post
Common mistakes
Key takeaways
FAQ
Sources

Start with the right dimensions

The most common image mistake is uploading a file far larger than the space it fills. A 4,000-pixel-wide photo displayed in an 800-pixel content column forces visitors to download data they never see.

WordPress helps a little. Since version 5.3, if an uploaded image is taller or wider than a threshold, WordPress scales it down. The default threshold is 2560px and it can be changed with the big_image_size_threshold filter. The scaled copy becomes the largest available size, and the original is kept in the uploads folder (WordPress core dev note on big images). That safety net is generous, though. Resizing before upload is still better.

Check your theme’s content width and the widest place the image will appear.
Resize to roughly that width, allowing extra room if you want sharp results on high-density screens.

Choose a format: JPEG, PNG, WebP or AVIF

WordPress core has accepted newer formats for some time. According to the core dev notes:

Enjoying this? Get our best tips by email

Practical SEO, link building and content strategies, straight to your inbox.

Format	Core support from	Conditions
WebP	WordPress 5.8	Your host’s image library (Imagick or LibGD) must support WebP, or uploads show an error.
AVIF	WordPress 6.5	Your host’s image library must support AVIF.

To check your own server, go to Tools > Site Health, open the Info tab, expand Media Handling, and look for AVIF (or WebP) in the list of supported formats. The AVIF announcement describes exactly this check.

Both announcements say the formats are supported in all major or modern browsers, and suggest avoiding them or using a polyfill if many of your visitors use unsupported browsers. On multisite, allowed file types are stored when each site is created, so existing sites do not automatically gain the new formats and a network admin may need to add them.

A practical rule: photos usually suit JPEG, WebP or AVIF; flat graphics with sharp edges or transparency suit PNG or WebP. Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG and AVIF, so choosing a modern format does not cost you image search eligibility. Make sure the file extension matches the real file type.

Compress without ruining quality

Compression is where the largest byte savings usually come from. Lossy compression discards detail the eye rarely notices; lossless keeps every pixel but saves less. For blog photos, lossy at a moderate quality setting is normally the right trade-off, but preview the result at actual display size before you publish.

You can compress before upload with any image editor, or let a plugin do it on upload or in bulk. Generic plugin features to look for are bulk optimisation of existing media, automatic conversion on upload, and the ability to keep or restore originals. Back up your media library before running any bulk job. WordPress itself exposes the wp_editor_set_quality filter for developers; the AVIF dev note says a compression level of 100 gives lossless AVIF.

Let responsive images do their job

When you upload an image, WordPress creates several sizes and outputs them with srcset so the browser can pick a size that fits the screen. You mostly need to avoid breaking this. Insert images through the block editor or media library rather than hard-coding a single file in custom HTML, and do not remove registered image sizes unless you know why.

Google’s image guidance recommends <picture> or srcset for different screen sizes and densities, and says to always include an <img> with a src fallback because some browsers and crawlers do not understand those attributes. Standard WordPress output already follows that pattern.

Also set width and height on every image. Core normally does this for you, and it lets the browser reserve space so the page does not jump as pictures load (web.dev).

Lazy loading, and why the LCP image is the exception

Lazy loading delays images that are off-screen until the visitor scrolls near them. web.dev advises using loading="lazy" only for images outside the initial viewport and keeping above-the-fold images on default eager loading. On the Largest Contentful Paint (LCP) image, its LCP guide is blunt: never lazy-load it, because the browser waits until layout confirms the image is in the viewport before requesting it.

The same guide recommends fetchpriority="high" on the image likely to be the LCP element, warns that setting high priority on more than one or two images makes the hint unhelpful, and cites an LCP target of 2.5 seconds or less for at least 75% of visits.

What WordPress does automatically

WordPress 6.3 added fetchpriority="high" to the image it judges most likely to be the LCP image. The dev note says this typically improves LCP by 5-10%.
The image must meet a size threshold (width times height of 50,000 by default; a 300×200 image qualifies, a 200×200 one does not). The wp_min_priority_img_pixels filter changes it.
Core never outputs fetchpriority="high" and loading="lazy" on the same image.
The wp_omit_loading_attr_threshold filter default changed from 1 to 3 in 6.3, so more of the first images on a page skip lazy loading.

When you need to step in

Core uses a heuristic, so it can guess wrong. Use your browser’s developer tools or a speed test to see which element is the LCP, then check that image’s HTML. If a lazy-load plugin or a page builder adds loading="lazy" to your hero image, exclude it in that tool’s settings. The AVIF note adds that AVIF images get the same responsive-image, fetchpriority and lazy-loading treatment as other formats. For help reading the report, see our guide to reading a PageSpeed Insights report.

Image SEO: alt text, file names and context

Google’s image best practices are practical and short:

Alt text: Google calls it the most important metadata attribute for images. Describe the picture in context, and do not stuff keywords. It also helps accessibility.
File names: Use short, descriptive names rather than image1.jpg. Renaming the file before upload is the simplest way to get this right.
Placement: Put images near relevant text on relevant pages.
Real image elements: Use standard <img> elements. Google can find images in <picture> but does not index CSS background images.
Sitemaps: Submit an image sitemap if Google might otherwise miss images, such as when a CDN hosts them.

For a representative image on each page, Google also points to an og:image tag or structured data, and advises against generic logos, text-heavy images or extreme aspect ratios. Many SEO plugins set og:image from your featured image, so choose that carefully. To follow how images show up in search reporting, read our Search Console image SEO piece.

A simple workflow for every new post

Rename the file with a short, descriptive name.
Resize it to the widest size it will be displayed at.
Export as JPEG, WebP or AVIF (if your host supports it) and compress.
Upload through Media > Add New or the Image block and write alt text.
Preview the page and confirm the top image is not lazy-loaded.

Common mistakes

Lazy-loading every image, including the hero.
Uploading a WebP or AVIF file that your server cannot process, then seeing an error or missing sizes.
Assuming smaller files always fix LCP. web.dev notes that if the image is still held back, the saved time just moves into render delay, so check real data before chasing file size alone.

Images are one lever among several. For the rest, see how to speed up your WordPress website.

Key takeaways

Resize before upload; WordPress only scales images above 2560px by default.
WebP works in core from 5.8 and AVIF from 6.5, if your server’s image library supports them.
Keep the LCP image eager and give it high fetch priority; lazy-load the rest.
Write descriptive alt text and file names, without keyword stuffing.
Verify with Site Health and a speed test rather than assuming.

FAQ

Should I use WebP or AVIF?

Either can work if Site Health lists it as supported on your server and your audience’s browsers handle it. The AVIF dev note advises that if many of your visitors use an unsupported browser, you should avoid AVIF or add a polyfill, so consider your audience before switching everything.

Does WordPress lazy-load images by default?

Yes, core adds lazy loading with logic that skips the first few images, and since 6.3 it adds fetchpriority="high" to the likely LCP image. Themes and plugins can change this, so inspect your key pages.

How long should alt text be?

Google’s guidance does not give a length. It asks for useful, context-appropriate text without keyword stuffing, so describe what the image shows in a natural phrase.

Do I need an image sitemap?

Not always. Google suggests one for images it might otherwise miss, for instance images hosted on a CDN.