How to Optimize Images in WordPress

Why Image Optimization Matters

If you want to optimize images in WordPress, the first thing worth understanding is just how much of your page weight images are actually responsible for. On an ordinary blog post or product page, images are usually the single heaviest type of asset the browser has to download, ahead of your JavaScript, your CSS and your fonts combined. That single fact explains why so many WordPress sites feel sluggish even after the owner has installed a caching plugin, picked a fast theme and paid for decent hosting.

Here is an illustrative look at how a typical page's weight breaks down. The exact split will differ from site to site, but the general shape holds true across most WordPress installs we look at.

This matters for three separate reasons, and it is worth being specific about each one rather than treating "page speed" as one vague goal.

Core Web Vitals and Largest Contentful Paint

Google's Core Web Vitals include a metric called Largest Contentful Paint, or LCP, which measures how long it takes the biggest visible element on the screen to render. On most pages, that biggest element is an image: a hero banner, a featured photo, a product shot. An oversized, uncompressed image sitting at the top of the page is one of the most common causes of a poor LCP score, and LCP is a ranking signal as well as a genuine user experience metric. If you are already working through a broader plan to speed up a WordPress website, image weight is usually the first and easiest win, because unlike server response time or JavaScript execution it does not require touching code.

Visitor experience and bounce rate

People do not wait around for a slow page, especially on mobile connections that are not always fast or stable. A page that takes several seconds to show its main image will lose a portion of visitors before they ever see your content, your offer or your calls to action. Every second of delay chips away at how many people stick around, scroll, and eventually convert.

Hosting cost and bandwidth

Every megabyte a visitor downloads is a megabyte your hosting plan has to serve, over and over, for every visitor, every day. A site with an unoptimized media library is paying, in bandwidth and server load, for the same waste again and again. Trimming that waste once tends to keep paying off for as long as the site exists.

Search visibility

Page experience signals feed into how search engines evaluate a site, and slow, image-heavy pages are simply less pleasant to recommend than fast ones. Image optimization will not replace good content or solid on-page SEO, but it removes a technical weakness that can otherwise hold back pages that are strong in every other respect.

The good news is that WordPress image optimization is one of the more mechanical, checklist-friendly parts of running a website. It does not require rewriting your theme or touching a line of PHP. It mostly comes down to choosing the right format, compressing properly, resizing sensibly, loading images at the right time, and letting a CDN do some of the heavy lifting. The rest of this guide walks through each of those pieces in order, and closes with a practical checklist you can run through on your own site.

If you would rather have a developer handle the technical side directly, our WordPress development services include performance work as a standard part of every build, or you can get a free quote and we will look at your current setup.

Choosing the Right Image Format

Before you touch a compression setting, it helps to pick the right format for each image in the first place. WordPress will happily accept JPEG, PNG, WebP, AVIF, GIF and SVG uploads, and each one behaves differently depending on what is actually in the image.

The short version: photographs generally belong in JPEG, WebP or AVIF. Logos, icons and screenshots with flat colour and sharp text generally belong in PNG or SVG. Short looping animations belong in GIF, though a muted looping video is often a better choice for anything longer than a couple of seconds. Here is a fuller comparison.

Photographs

A photo has continuous tone, subtle gradients and a huge number of unique colours. Formats built around lossy compression, like JPEG, WebP and AVIF, are designed exactly for this kind of content. They throw away visual information the human eye is unlikely to notice and keep the file small. PNG, by contrast, is lossless and was never designed for photography, which is why a photo saved as PNG is often several times larger than the same photo saved as a well-compressed JPEG or WebP, with no visible improvement in quality.

Logos, icons and screenshots

Flat colour, sharp edges and text behave differently under compression. Lossy formats can introduce visible artifacts around hard edges, which is why a logo saved as a heavily compressed JPEG often looks slightly smudged around the letters. PNG handles this kind of content well because its lossless compression is efficient on large areas of a single colour. For anything that is fundamentally a shape rather than a photo, an SVG is usually the better answer, since it describes the image as vector paths rather than pixels and can scale to any size from a file that is often only a few kilobytes.

Transparency

If an image needs a transparent background, such as a logo that sits on top of different coloured sections of a page, your options are PNG, WebP or SVG. Standard JPEG does not support transparency at all.

Animated content

GIF is the format most people reach for by default, but it is genuinely outdated for anything beyond a very short, simple loop, because its colour palette is limited and file sizes climb quickly. A short muted video, or an animated WebP where supported, will usually look better and load faster.

A reasonable rule of thumb for most WordPress sites: default new photo uploads to WebP, keep PNG or SVG for logos and interface graphics, and avoid GIF except for the smallest, simplest animations. We cover format decisions like this as part of every project when we build a new WordPress website for a client, since getting the media library right from day one avoids a much bigger cleanup job later.

Lossy vs Lossless Compression Explained

Once you have picked a format, the next question is how hard to compress it. Compression comes in two broad families, and understanding the difference will save you from either wrecking your image quality or leaving easy file size savings on the table.

Lossy compression

Lossy compression permanently discards some visual information in exchange for a smaller file. JPEG, and the lossy modes of WebP and AVIF, all work this way. The trick is that a well-tuned lossy encoder throws away detail the human eye barely registers, particularly in areas of a photo with lots of fine texture or subtle colour variation, while keeping the parts of the image that actually carry visual meaning. Pushed too far, lossy compression produces visible blockiness, colour banding or a general soft, smeared look. Used sensibly, it can cut file size dramatically with no visible difference at all.

Here is an illustrative comparison of typical file size across formats for the same underlying photo, compressed to a similar visual quality.

Lossless compression

Lossless compression shrinks a file without throwing anything away. PNG uses lossless compression, and WebP and AVIF both support lossless modes too. The savings are smaller than what lossy compression can achieve, often by removing redundant data, tidying up metadata, and finding more efficient ways to represent the same pixel information. Lossless is the right call when you cannot afford any change in quality at all, such as certain screenshots, medical or technical imagery, or graphics where a client has explicitly asked for pixel-perfect reproduction.

Quality settings in practice

Most compression tools express lossy quality as a number, often somewhere from 0 to 100. There is rarely a single correct number, but a commonly used range for photographs sits somewhere in the area where the file is meaningfully smaller than the uncompressed original while still looking clean at normal viewing size. The practical approach is to compress an image, view it at the size it will actually appear on the page, and only back off the compression level if you can genuinely see a problem. Most people compress far less aggressively than they could get away with, simply because they never test the result at real-world size.

Metadata stripping

Photos straight out of a camera or phone often carry a surprising amount of embedded metadata: camera model, GPS coordinates, colour profile information, thumbnail previews. None of that does anything for a website visitor, and stripping it is a free, lossless size reduction that every decent optimization tool performs automatically. If you are compressing images by hand in an editor, make sure metadata stripping is switched on.

The practical takeaway is simple: use lossy compression for photos and accept a sensible quality setting rather than the absolute maximum, and reserve lossless compression for the smaller set of images where quality truly cannot be compromised.

Resize Images Before You Upload

Compression alone will not fix an image that is simply the wrong dimensions. One of the most common problems on WordPress sites is a photo straight from a phone or a stock photo library, several thousand pixels wide, uploaded directly into a content area that will only ever display it at a few hundred pixels wide. WordPress will resize that image for display in the browser, but it still has to download the full original file to do it, unless you have taken steps to serve a properly sized version.

Match the image to its container

Before uploading, it is worth knowing roughly how wide the image will actually render on the page. A featured image in a blog post might display at somewhere around 1200 to 1600 pixels wide at most, even though the underlying file could be 4000 pixels wide or more straight out of a camera. There is no visual benefit to uploading at a resolution the design will never use, only extra weight to download.

Let WordPress generate the sizes you need

WordPress automatically creates several resized copies of every image you upload, based on the sizes your theme and blocks register, and it serves the right one using srcset, which we cover in more detail later in this guide. This system works well, but it works from whatever you upload as the source. If the original file you upload is already excessively large, every generated size inherits that waste in the amount of detail it has to compress, and the largest generated size is still bigger than it needs to be.

A sensible upload workflow

• Resize the image to a sensible maximum width before uploading, rather than relying entirely on WordPress to shrink it down after the fact.
• For a full-width hero image, a maximum width in the range of 1600 to 2000 pixels is usually more than enough for sharp display on modern screens.
• For in-content images, inline photos and thumbnails, there is rarely a good reason to upload anything wider than about 1200 pixels.
• Crop out empty space rather than shrinking a whole scene down, so the subject fills more of the frame at a smaller file size.
• Keep one folder of full-resolution originals outside WordPress if you might need them later for print or another use, and upload the web-sized version to the site itself.

Watch out for retina and high density screens

Modern phones and laptops often have high pixel density screens, which is why WordPress's srcset system typically offers versions at roughly 1.5x and 2x the display size, so images stay sharp without needing you to upload an enormous single file. You do not need to manually account for this if you let WordPress's responsive image system do its job, but it is another reason not to upload a file many times larger than the display size "just in case." The multiplier is already built into how WordPress serves images.

Getting dimensions right before upload is one of the simplest habits that makes every other optimization technique in this guide more effective, since compression and format choice both work on whatever size file you give them to start with.

Serving WebP and AVIF in WordPress

WebP has been supported by every major modern browser for some time now, and WordPress core added native support for uploading WebP files directly through the media library. AVIF support followed, and WordPress core can now handle AVIF uploads as well, with the caveat that not every server's image processing library has caught up equally, which occasionally affects whether WordPress can automatically generate the various resized versions of an AVIF file.

What WebP and AVIF actually offer

Both formats generally produce smaller files than JPEG or PNG at a similar visual quality, as the earlier chart illustrated. AVIF often edges out WebP on file size for the same visual quality, though encoding AVIF files can take longer and, at the time of writing, some editing tools and plugins support it less completely than WebP. For most WordPress sites, WebP is currently the safer default to standardize on, with AVIF worth adopting where your tools and hosting fully support it.

Two ways to get WebP or AVIF on your site

There are two broad approaches, and it helps to understand the difference:

• Convert at upload. Many optimization plugins can automatically convert JPEG and PNG uploads into WebP or AVIF versions, either replacing the original or creating alternate versions alongside it. This is straightforward and works well for new uploads going forward.
• Serve conditionally with a fallback. Because a small number of older browsers and tools still do not handle WebP or AVIF, well-built optimization plugins and CDNs use the HTML <picture> element or server-side content negotiation to serve the modern format to browsers that support it, and automatically fall back to JPEG or PNG for anything that does not. You do not need to build this yourself. It is a standard feature of most reputable image plugins and image CDNs.

Converting your existing media library

New uploads are the easy part. The bigger job on an established site is usually converting the existing media library, which can run into hundreds or thousands of images. Most optimization plugins include a bulk conversion tool for exactly this purpose, processing your existing library in batches so you are not stuck manually re-uploading years of content. This is one of the more time-consuming but genuinely worthwhile jobs on an older WordPress site, and it is exactly the kind of cleanup work we handle when we take over an existing site's performance through our WordPress development services.

A note on quality and re-encoding

Converting an already heavily compressed JPEG into WebP will still shrink the file, but you get better results converting from the original, higher quality source if you still have it, since re-encoding a file that has already lost detail compounds the quality loss. This is another good reason to keep a folder of original, unoptimized source images somewhere safe rather than only keeping the compressed versions that ended up on the site.

If your site has never touched WebP or AVIF, adopting either one is usually one of the highest-impact single changes you can make to your image pipeline, precisely because it applies to every photo on the site at once rather than requiring image-by-image decisions.

Lazy Loading Images the Right Way

Lazy loading delays the download of an image until it is about to scroll into view, rather than downloading every image on the page immediately when it loads. WordPress has included native lazy loading since version 5.5, automatically adding loading="lazy" to images in post content and widgets. For a long page with dozens of images, this can meaningfully cut down the amount of data the browser has to fetch immediately, since images far down the page simply are not requested until the visitor scrolls near them.

Why lazy loading everything is a mistake

Here is the part that trips up a lot of site owners: lazy loading is genuinely bad for the one image that matters most for perceived speed, the largest image visible without scrolling, often called the hero image or the LCP element. If that image is set to lazy load, the browser deliberately delays fetching it, which can directly worsen your Largest Contentful Paint score, the exact opposite of what you are trying to achieve. Lazy loading is a tool for images the visitor has not scrolled to yet, not for the image sitting front and centre the moment the page opens.

How to handle the above-the-fold image correctly

• Identify the single largest image that appears without scrolling, on both mobile and desktop layouts if they differ.
• Make sure that image does not carry loading="lazy". WordPress generally handles this automatically for the featured image and the first content image in newer versions, but it is worth checking manually, especially on custom-built page layouts or sliders.
• Consider adding a preload hint for that specific image, which tells the browser to start fetching it as early as possible, even before the browser has parsed the rest of the page. This is a more advanced technique best handled by a developer or a well-built performance plugin.
• Every other image further down the page should keep native lazy loading switched on. There is no downside to lazy loading content the visitor has not scrolled to yet.

Lazy loading and sliders or carousels

Image sliders and carousels deserve a specific mention, because they often load every slide's image at once even though only the first slide is visible. Depending on how the slider plugin is built, this can quietly undo a lot of your lazy loading gains. A well-built slider should only load the current and next slide's image eagerly, lazy loading the rest.

Background images set via CSS

Native lazy loading only applies to actual <img> elements. Background images set through CSS do not get the same automatic treatment, and large CSS background images used for section headers or banners are a common blind spot. If a section is far down the page, consider whether it needs a large background image at all, or whether a smaller, well-compressed one would do the job with less weight.

Lazy loading is a genuinely simple win once you understand the one exception that matters. Get the above-the-fold image right, leave the rest on native lazy loading, and check any slider or carousel plugin behaves the way you expect.

Responsive Images and Srcset

Responsive images solve a different problem than compression or lazy loading. Even a perfectly compressed image is still wasteful if you send the full desktop-sized version to a visitor on a small phone screen who only needs a fraction of those pixels. Responsive images let the browser choose the most appropriately sized version of an image for the screen it is actually displaying on.

How WordPress handles this automatically

WordPress has generated multiple sizes of every uploaded image, and served them through the srcset and sizes attributes, since version 4.4, entirely automatically, with no configuration required in most cases. When you insert an image into a post, WordPress core writes out markup similar to this pattern behind the scenes:

• srcset lists several versions of the image at different widths, each with its actual pixel width noted.
• sizes tells the browser roughly how wide the image will actually display at different viewport widths.
• The browser combines this information with its own screen size and pixel density to request only the single most appropriate file, ignoring the rest.

The practical result is that a visitor on a phone downloads a phone-appropriate file, and a visitor on a large desktop monitor downloads a larger one, all from the same piece of content, without you doing anything extra.

Why this still depends on you

This system only works well if the sizes WordPress generates are actually useful. A theme that registers sensible image sizes, matching the widths content actually renders at across common breakpoints, gets real value from responsive images. A theme with poorly configured image sizes, or a source image that was too small to begin with, limits how much the browser can actually choose from. This is one of the reasons image performance and theme quality are connected, and it is a detail we check whenever we build a WordPress site from scratch or take over an existing one.

Art direction with the picture element

Occasionally you want more than just a smaller version of the same crop, for example showing a tightly cropped portrait on mobile and a wider landscape crop on desktop. This is a different technique, called art direction, and it uses the HTML <picture> element with explicit media conditions rather than relying on the browser's automatic size selection. It is a more advanced, developer-level technique, generally reserved for a handful of key hero images rather than applied across an entire site.

Checking it is actually working

You can confirm responsive images are functioning by inspecting an image element in your browser's developer tools and looking for a populated srcset attribute with multiple width values. If an image only has a single plain src attribute and no srcset, it is either a very small image WordPress decided did not need multiple sizes, or it was inserted in a way that bypassed the standard image block, such as through certain page builder modules or a raw HTML embed.

Responsive images are one of the parts of WordPress image optimization that mostly happen for you already. The job is less about switching anything on and more about not accidentally switching it off through a page builder, a badly configured theme, or a source image that was undersized to begin with.

Best WordPress Image Optimization Plugins

You do not need to compress every image manually in an editor before uploading. A good image optimization plugin can compress on upload, convert to WebP or AVIF, resize oversized originals, and in some cases handle a bulk pass across your entire existing media library. Most of the well-known plugins in this space fall into one of two broad approaches, and it is worth understanding the difference before picking one.

Cloud-based optimization

Cloud-based plugins send each image to the plugin provider's own servers, compress it there using their own engine, and send back the optimized file. This approach tends to produce strong, consistent compression without loading your own server's CPU, and it is usually the simpler option to set up. The tradeoff is that your images briefly pass through a third party's servers during processing, which is worth knowing even though it is standard practice and generally covered by the provider's own privacy policy.

Server-side, local optimization

Local optimization plugins compress images using tools running directly on your own hosting server, without sending them anywhere else. This keeps everything in-house, which some agencies and privacy-conscious clients prefer, but it depends on your hosting environment having the right image processing libraries installed, and it uses your own server's resources during bulk processing rather than someone else's.

Here is a general comparison of some of the more established plugins in this category, without vendor-specific figures, since actual compression results vary by image and by settings.

What to actually look for

• Automatic compression on upload, so you are not relying on remembering to run a manual step every time.
• WebP and ideally AVIF conversion, with an automatic fallback for browsers that need it.
• A bulk optimization tool for cleaning up images already in your media library, not just new uploads.
• Adjustable compression levels, so you can dial quality up or down for specific cases rather than being stuck with one fixed setting.
• Backup of originals, so a compression pass is reversible if a setting turns out too aggressive.

Plugins are not the only piece

A common mistake is treating an optimization plugin as the entire solution. A plugin compresses and converts what you give it, but it will not fix an image that was uploaded at ten times the resolution it needs to display at, and it will not fix a slider that eagerly loads every slide's image regardless of lazy loading settings. Plugins handle compression and format conversion very well. Resizing habits, lazy loading behaviour and overall page structure are still worth checking separately, which is part of why we cover them as their own sections in this guide. For a broader look at what else is worth having installed, our guide to the best WordPress plugins for business sites covers the categories that tend to matter most beyond just images.

If picking through plugin settings is not something you want to spend an afternoon on, get in touch and we can set up and configure the right optimization plugin as part of a broader performance pass on your site.

Using a CDN to Deliver Images

A content delivery network, or CDN, stores copies of your site's files, including images, on servers spread across many geographic locations, and serves each visitor from whichever location is closest to them. For images specifically, this matters more than it might first appear, because images are usually the largest files a browser downloads, and the physical distance data has to travel has a real effect on how quickly it arrives.

Why distance matters for images

If your WordPress hosting is located in one region and a visitor is browsing from somewhere else entirely, every request has to travel that physical distance and back before the image even starts downloading. A CDN keeps a cached copy near the visitor, cutting that round trip dramatically. This effect compounds across a page with many images, since each one benefits from the shorter distance.

Image-specific CDN features

Beyond simple geographic caching, many image-focused CDN services add extra capabilities on top:

• On-the-fly resizing, generating the exact dimensions a specific page needs from a single stored original, rather than you needing to pre-generate every possible size.
• Automatic format conversion, detecting whether a visitor's browser supports WebP or AVIF and serving the best available format without you managing multiple versions yourself.
• Automatic quality adjustment, sometimes factoring in the visitor's connection speed to serve a lighter version on a slow mobile connection.
• Offloading storage, moving your media library off your own hosting server entirely, which can help keep backups smaller and hosting storage costs down on media-heavy sites.

General CDN vs image-specific CDN

Broad, general-purpose CDNs cache your whole site, images included, and are a solid general performance improvement on their own. Image-specific CDN services, often offered as WordPress plugins in their own right, go further by actively transforming images rather than just caching them as-is. Many sites end up using both together: a general CDN for overall delivery, and an image-specific layer for the transformation features above. Which combination makes sense depends on your hosting, your theme, and how much of this you want to manage yourself versus hand off.

Setting expectations

A CDN improves how quickly an already-optimized image reaches a visitor. It is not a substitute for the compression, format and resizing work covered earlier in this guide. Sending an unoptimized four-megabyte photo through a CDN still means downloading a four-megabyte photo, just from a server that happens to be closer. The two approaches work together, not as alternatives to each other.

Setting up a CDN correctly, including cache invalidation rules and making sure it plays nicely with your existing caching plugin, is one of the more technical steps in this guide. If you are not confident configuring DNS records and cache rules, reach out to our team and we can handle the setup as part of a full performance review, alongside the caching and speed work covered in our guide to speeding up a WordPress website.

Testing Results and a Practical Checklist

Every technique in this guide is worth confirming with a real test rather than assuming it worked. The good news is that testing image optimization does not require anything specialized.

Tools worth using

• Google PageSpeed Insights, which reports Core Web Vitals including Largest Contentful Paint, and specifically flags oversized or unoptimized images with a suggested savings figure.
• Lighthouse, built directly into Chrome's developer tools, running the same underlying tests locally with a detailed breakdown of exactly which images are flagged and why.
• The Network tab in your browser's developer tools, which lets you watch every image request load in real time, see its actual file size, and confirm whether it is being served as WebP or AVIF and whether it is genuinely lazy loading.

Here is an illustrative example of the kind of total page weight reduction a thorough pass through compression, format conversion and resizing can produce on a page that had never been touched before.

What to look for in a Lighthouse report

A Lighthouse audit specifically checks for oversized images relative to their display size, images that are not served in a modern format, images that lack proper width and height attributes, and images that could benefit from lazy loading. Each flagged item usually comes with a specific file and an estimated saving, which makes it easy to prioritize the worst offenders first rather than trying to fix everything at once.

Do not forget accessibility while you are in there

While you are reviewing images for performance, it is worth checking alt text at the same time, since you are already looking at every image on the page. Alt text describes an image for visitors using screen readers and for search engines that cannot see the image itself. Every meaningful image should have descriptive alt text; purely decorative images, such as background flourishes with no informational content, should have an empty alt attribute rather than no attribute at all, so assistive technology correctly skips over them. This has nothing to do with file size, but it is a genuine part of doing image optimization properly rather than only chasing speed metrics.

A practical checklist

• Resize images to sensible dimensions before uploading, rather than relying entirely on WordPress or a plugin to shrink them after the fact.
• Choose the right format for each image: photos as JPEG, WebP or AVIF; logos and icons as PNG or SVG; short animations as WebP or video rather than GIF.
• Compress every photo with sensible lossy settings, testing the result at real display size before accepting it.
• Convert your media library to WebP, with AVIF where your tools support it, including a bulk pass over existing images, not only new uploads.
• Confirm the largest above-the-fold image is not lazy loaded, and everything else on the page is.
• Check that responsive images are working by inspecting the srcset attribute on a few key images.
• Install and configure a reputable image optimization plugin so this keeps happening automatically for future uploads.
• Set up a CDN, general purpose or image-specific, to shorten the physical distance images travel to reach each visitor.
• Write meaningful alt text for every informational image, and leave decorative images with an empty alt attribute.
• Re-run PageSpeed Insights or Lighthouse after making changes to confirm the improvement and catch anything you missed.

Working through this list once on an established site is usually the biggest single jump in image performance you will see. After that, the ongoing job is much smaller: keep the optimization plugin switched on, keep uploading reasonably sized originals, and re-check occasionally as your media library grows. If you would rather have someone run through this checklist on your actual site rather than doing it yourself, get a free quote and we will tell you honestly what is worth fixing first.