WordPress Image Optimization: WebP, AVIF and a Workflow That Sticks

WordPress image optimization is the highest-leverage performance work on almost every site I audit, because images are usually half to two thirds of the bytes a page ships. Not the theme, not the plugins, not the hosting – the photos, hero banners and product shots that someone uploaded straight from a phone or a stock library at 4000 pixels wide. I have measured hundreds of WordPress sites over twelve years, and the pattern barely changes: a page that weighs 4 MB is carrying 2.5-3 MB of images, and most of that weight is avoidable without anyone noticing a difference in quality.

The mistake most owners make is treating this as a one-off job: install a compression plugin, run it once, feel good about the “saved 46%” banner, and then upload next month’s images exactly as before. Six months later the media library is heavy again. This guide is the version I actually implement for clients: what the formats do in plain language, what sizes and kilobyte targets to aim for by image role, which conversion plugins and CDN approaches are worth paying for, how lazy-loading goes wrong, and – the part that matters most – a permanent workflow from design export to monthly audit, so the site stays fast after I leave.

Table of contents

• Why images dominate page weight
• Image formats explained plainly: JPEG, PNG, WebP, AVIF, SVG
• Serve the size you display: srcset without the mystery
• Compression targets by image role, in kilobytes
• Step one of the workflow: export properly from design tools
• Step two: on-upload conversion plugins, compared honestly
• Lazy-loading done right – and the LCP image exception
• Alt text: accessibility and SEO in one field
• Image CDNs: when they are worth it
• WooCommerce product images: the special case
• The monthly audit routine and real before/after numbers
• Frequently asked questions

Why images dominate page weight

Open the network tab on any typical business site and sort by size. The HTML is 30-80 KB. CSS and JavaScript together are usually 300-800 KB on a plugin-heavy site. The images are the rest, and “the rest” is routinely 60-70% of the total. On WooCommerce category pages I have seen images account for 85% of the transferred bytes. This is not a WordPress flaw – it is simply what happens when a CMS makes uploading effortless and nobody sets rules.

Three habits cause almost all of it:

• Uploading originals. A modern phone photo is 3-8 MB and 4000+ pixels wide. WordPress generates smaller sizes, but themes and page builders frequently request the full-size file for hero sections and backgrounds, so the original gets served.
• Old formats. A JPEG that looks fine at 350 KB is usually 180 KB as a WebP and 120 KB as an AVIF at the same visual quality. Multiply that across 40 images on a home page and the difference is measured in seconds on a mid-range phone.
• Serving desktop images to phones. A 1920 pixel hero sent to a 390 pixel viewport wastes around 90% of its pixels. Responsive images fix this automatically – when the theme lets them work.

The good news: because images are the biggest slice, they are also the biggest win. In a typical speed project the image work alone recovers more load time than every other change combined, which is why it is the first chapter of my complete WordPress speed guide in practice, whatever order the table of contents suggests.

Image formats explained plainly: JPEG, PNG, WebP, AVIF, SVG

You do not need to understand compression algorithms. You need one sentence per format and a rule for when each applies.

• JPEG is the old default for photographs. It compresses well, every browser and tool on earth supports it, and it remains a perfectly good source format. Its only sin is being 30-50% larger than WebP at the same quality.
• PNG is lossless and supports transparency. It is the right source for screenshots, UI graphics and anything with sharp text – and the wrong delivery format for photos, where it produces absurd file sizes. A photographic PNG is the single most common image mistake I find.
• WebP is the sensible modern default. Roughly 25-35% smaller than JPEG at equal quality, supports transparency (replacing heavy PNGs) and animation (replacing monstrous GIFs), and has effectively universal browser support. WordPress has accepted WebP uploads since version 5.8.
• AVIF is the newer, stronger option: typically another 20-30% smaller than WebP, dramatically better at low quality settings, supported by all current major browsers, and accepted as an upload format since WordPress 6.5. Its trade-offs are slower encoding (irrelevant if a plugin or CDN does it in the background) and patchy support in older tools and some email clients – which does not matter for your website.
• SVG is not a photo format at all – it is vector code, perfect for logos and icons at 2-10 KB and sharp at any size. WordPress blocks SVG uploads by default for a good reason: SVG files can contain scripts. Allow them only via a plugin that sanitises on upload (Safe SVG is the standard choice), and only for trusted users.

Here is the decision table I give clients:

One practical note: you rarely need to convert files by hand. The workflow below keeps JPEG and PNG as your upload formats and lets a plugin or CDN generate WebP/AVIF automatically, with the original as a fallback for the few environments that need one. That keeps your media library editable and your process simple.

Serve the size you display: srcset without the mystery

Format is half the battle; dimensions are the other half. An image displayed 800 pixels wide should not arrive 2400 pixels wide – that is nine times the pixel data for zero visible benefit on most screens.

WordPress has handled this automatically since version 4.4 through responsive images. On upload it generates several sizes (by default thumbnail, medium, large, plus theme-registered sizes), and when a theme prints an image it includes a srcset attribute listing all available widths and a sizes attribute describing how wide the image renders. The browser then picks the smallest adequate file for the actual viewport and screen density. A phone downloads the 480 pixel version; a desktop takes the 1024; nobody gets the 2400 original.

Where it breaks in real projects:

• CSS background images get no srcset. Page builders love background-image heroes, and those always serve one fixed file. Where performance matters, use a real image element positioned as a cover, or at minimum load a sensibly sized file.
• Wrong sizes attribute. Many themes declare sizes="100vw" for images that render in a 700 pixel column, so browsers download files twice as large as needed. Fixable with a small filter; worth checking in an audit.
• Builders requesting full size. Elementor, Divi and friends often default widgets to “Full” image size. Change the widget to an appropriate registered size – this one dropdown is worth hundreds of kilobytes per page.
• Retina overkill. Serving 2x images everywhere doubles bytes for a sharpness gain that is invisible in photos at normal compression. My rule: cap content images at 2x for logos and UI, 1.5x or plain 1x for photography.

Since version 5.3 WordPress also applies a “big image threshold”: uploads wider than 2560 pixels are scaled down, and the scaled file becomes the working original. Leave that in place. And when should you disable srcset? Almost never – the legitimate cases are fixed-size images like email-builder previews or strict print assets. If a developer tells you srcset itself is the performance problem, get a second opinion.

Compression targets by image role, in kilobytes

“Compress your images” is useless advice without numbers, so here are the budgets I hold my own projects to. They assume WebP or AVIF delivery at sensible quality (WebP quality 70-80, AVIF quality 45-60 – AVIF needs lower numbers for the same look).

Two principles behind the table. First, the hero earns the most budget because it is usually the Largest Contentful Paint element – but it also punishes waste the most, since nothing else renders as late as an oversized hero. Second, quality settings should vary by role: a decorative blurred background survives WebP quality 55 happily, while a product photo a customer will zoom deserves 80. Plugins that apply one global quality number to everything are leaving savings (or quality) on the table, which is why the better ones let you set quality per context or per image.

A useful sanity check for any page: total image weight for the initial viewport under 500 KB, and under 1.5 MB for the full page including lazy-loaded images. Most sites I audit start at three to six times those figures.

Step one of the workflow: export properly from design tools

The cheapest optimisation happens before the file ever reaches WordPress. When I build sites for agencies, the export rules are part of the handover documentation, because a perfect plugin setup cannot fully rescue a 6000 pixel TIFF-grade PNG.

• Export at 2x the largest display size, maximum. If the hero renders at 1600 pixels, export at 1920-2400 and stop. Figma, Photoshop and Affinity all export at chosen widths; there is no reason to ship the artboard original.
• Photos leave the design tool as JPEG quality 80-90 (or WebP if your tool exports it well). This is the source file – the plugin will make the delivery formats. Never export photos as PNG.
• Screenshots and UI graphics leave as PNG, cropped to the relevant area rather than the full 4K monitor.
• Logos and icons leave as SVG, run through an optimiser (SVGO or the export settings in the design tool) to strip editor metadata that can triple the file size.
• Name files descriptively before upload: blue-linen-sofa-three-seater.jpg beats IMG_4382.jpg for SEO, for the media library search, and for the alt text you will write in a minute.

For client-uploaded content the rule is simpler, because clients will not follow export settings: pick a plugin setup (next section) that resizes and converts on upload, set the maximum width to 2560 or lower, and let the machinery absorb whatever the client throws at it. Design discipline for the build, automation for daily life.

Step two: on-upload conversion plugins, compared honestly

This is where most of the confusion – and most of the marketing – lives. Every optimisation plugin does three jobs to some degree: compress, convert to WebP/AVIF, and deliver the right format to the right browser. The differences that matter are where the work happens and how delivery is implemented.

The three approaches

• API-based services (ShortPixel, Imagify, TinyPNG’s plugin): images are sent to the vendor’s servers, optimised versions come back. Best compression quality per byte, zero load on your hosting, but priced in credits or quotas. ShortPixel and Imagify both do AVIF; ShortPixel’s per-image credit model suits libraries you optimise once, Imagify’s monthly quota suits sites uploading continuously.
• On-server plugins (EWWW’s local mode, Converter for Media, Performance Lab’s modern-formats module): conversion runs on your own hosting. No ongoing fees, complete privacy, but it needs the right PHP libraries (a GD or Imagick build with WebP/AVIF support – cheap shared hosts sometimes lack AVIF), and bulk-converting thousands of images can hammer a small server. Fine on decent hosting, my default recommendation for budget-conscious clients.
• CDN-based optimisation (Cloudflare Polish and Mirage on paid plans, Bunny Optimizer, Jetpack’s image CDN): originals stay untouched and the CDN converts, resizes and caches at the edge. The most maintenance-free option and my preference for high-traffic sites – the trade-off is a monthly cost and less granular control per image. Cloudflare Polish in particular is a genuine one-checkbox win if the site is already behind Cloudflare Pro.

Delivery: the detail that decides whether it works

Generating WebP files is easy; serving them correctly is where cheap setups fail. There are two sound methods. Rewrite rules (via .htaccess or nginx config) serve the WebP file under the original URL when the browser’s Accept header allows it – clean, but it breaks if the CDN caches one variant for everyone, so the CDN must vary its cache on the Accept header. The alternative is rewriting the markup to <picture> elements with explicit WebP/AVIF sources and the JPEG as fallback – more robust across CDNs but touches your HTML. Any serious plugin offers both; the wrong choice shows up as “I installed the plugin and my PageSpeed score did not move”, usually because the browser never actually received the converted files. Always verify in the network tab: the content-type column should say image/webp or image/avif.

What I actually install

On a typical small business site: Converter for Media or EWWW converting to WebP (AVIF too when the server supports it) with picture-tag delivery, maximum upload width 2560, quality 75. On WooCommerce or high-traffic sites: ShortPixel or the CDN approach, because the volume justifies it. What I do not install is two optimisation plugins at once – they fight over the same files, and I have untangled that mess for more than one new client.

Lazy-loading done right – and the LCP image exception

Lazy-loading defers offscreen images until the visitor scrolls near them, and WordPress has done it natively since version 5.5 by adding loading="lazy" to images. For a long page with twenty images, that is a large, free saving – the browser fetches perhaps six images instead of twenty.

The catch is that lazy-loading the wrong image is one of the most common self-inflicted performance wounds I see. If the hero image – almost always the Largest Contentful Paint element – is lazy-loaded, the browser deliberately deprioritises the one file the page’s perceived speed depends on. LCP gets worse, not better. WordPress core is sensible about this (it skips the first content image and adds fetchpriority="high" to the likely LCP image since version 6.3), but themes, sliders and page builders regularly override it with their own JavaScript lazy-loading applied to everything.

The rules that survive contact with real projects:

• Never lazy-load the LCP image. The hero, the featured image at the top of a post, the first product image. Give it fetchpriority="high" instead, and consider a preload tag if the theme loads it via CSS.
• Lazy-load everything below the fold – gallery items, related posts, footer logos, Instagram feeds.
• Prefer native lazy-loading over JavaScript libraries. The browser’s implementation needs no script, works with JS disabled, and cooperates with the preload scanner. JS-based lazy loading (still bundled in some themes and sliders) hides every image from the scanner and starts loading only after the script runs.
• Reserve space with width and height attributes so lazy-loaded images do not shove the layout around as they arrive – that shove is Cumulative Layout Shift, the third Core Web Vital. The mechanics of LCP and CLS are covered properly in my Core Web Vitals guide.

Quick self-test: load your home page with the network tab open and do not scroll. If every image on the page downloads anyway, your lazy-loading is decorative.

Alt text: accessibility and SEO in one field

Alt text is not a performance feature, but it belongs in the image workflow because it is written at the same moment – upload – and skipping it costs twice. Screen reader users get “image” read aloud forty times, and search engines index your images as anonymous rectangles. Google Images still drives meaningful traffic for product and how-to queries, and image alt text feeds it directly.

Writing it takes ten seconds per image once you have the habit:

• Describe what the image shows, specifically: “three-seater blue linen sofa in a bright living room” – not “sofa”, not “image123”, not a keyword list.
• Include the keyword only when it is honestly descriptive. If the image genuinely shows the product or concept the page targets, naming it is natural. Stuffing is obvious to readers and algorithms alike.
• Decorative images get empty alt (alt="") so screen readers skip them – background flourishes and divider graphics carry no information.
• Do not start with “image of” – the screen reader announces it is an image already.

For libraries with thousands of unnamed images, AI-assisted alt text plugins produce serviceable first drafts, and they are genuinely useful for e-commerce backlogs – but review anything on money pages by hand. The model describes what it sees; it does not know that the “grey chair” is your bestselling ergonomic model and the page’s whole reason to exist.

Image CDNs: when they are worth it

A CDN stores copies of your files on servers around the world, so a visitor in Sydney fetches images from Sydney rather than your Frankfurt hosting. For image-heavy sites with international visitors, this is the difference between a 40 ms and a 300 ms round trip – per image.

An image CDN adds transformation: it resizes, converts and compresses on the fly at the edge. Request the same photo as a 400 pixel AVIF thumbnail or a 1600 pixel WebP hero and it generates and caches each variant. That collapses the entire plugin conversation from the previous section into infrastructure.

When it is worth it, in my experience:

• Clearly yes: WooCommerce stores with hundreds of products, sites with audiences on several continents, high-traffic content sites, and anyone already paying for Cloudflare Pro (turn on Polish) or hosting with Bunny (Optimizer is cheap and effective).
• Nice but optional: local business sites serving one country from in-country hosting with a good plugin setup – the CDN gain exists but is modest.
• Not a substitute for the workflow: a CDN will happily deliver your 4 MB original slightly faster. Sizing discipline and sensible originals still matter, because the first (uncached) request pays full price and your storage and backups carry the weight forever.

One warning from client work: when you enable any CDN-level image optimisation, switch off the equivalent feature in your plugin. Double conversion produces visible quality loss – each generation of lossy compression compounds – and I have been called in to diagnose “why do our photos look muddy” more than once, with exactly this cause.

WooCommerce product images: the special case

Product images work harder than any other image on a website: they carry the buying decision, they appear dozens at a time on category pages, and customers zoom into them. That combination changes the rules slightly, and it is why image work features heavily in my WooCommerce optimisation tips.

• Standardise before upload. Same aspect ratio (square is the safe default), same background style, consistent margins. Mixed ratios make category grids ragged and cause layout shift; WooCommerce’s Customizer settings can crop, but cropping a badly framed photo makes a bad crop.
• Category thumbnails are the volume problem. Twenty-four products per page times one thumbnail each – these must be small (15-40 KB) and lazy-loaded below the first row. The first row of products should not be lazy-loaded; on category pages one of those images is often the LCP element.
• Zoom needs one big file, not all big files. The gallery shows an 800 pixel image; the zoom or lightbox loads the 1600-2000 pixel version on demand. That is the correct pattern – what I regularly find instead is the 2000 pixel file serving as the gallery image itself.
• Keep quality higher for products. WebP quality 80 rather than 70. Compression artefacts on fabric texture or product edges cost trust, and trust costs conversions. The extra 15 KB is the cheapest sales insurance you will buy.
• Variation images multiply everything. A product with eight colour variations has eight galleries; a 500-product store easily holds 10,000+ images. This is the scale where an image CDN or API service stops being a luxury and where a monthly audit becomes non-negotiable.

The monthly audit routine and real before/after numbers

Everything above sets the system up; this keeps it honest. Once a month, fifteen minutes, usually alongside the general maintenance pass:

1. Check the five heaviest recent uploads. Sort the media library or the optimisation plugin’s report by size for the last month. Anything over the alarm levels in the targets table gets investigated – usually it is a new editor uploading originals, which is a training conversation, not a technical one.
2. Spot-check delivery. Open the home page and one key template in a private window, network tab filtered to images: are WebP/AVIF actually being served, are dimensions sensible, is anything above the fold lazy-loaded that should not be?
3. Run one PageSpeed test on the same URL every month and note the image-related opportunities. Trends matter more than single scores.
4. Check the plugin/CDN status. Credits remaining, queue not stuck, no failed conversions piling up. A stuck queue fails silently – the site slowly reverts to originals and nobody notices for months.
5. Delete what you do not need. Unattached duplicate uploads and abandoned page-builder imports bloat backups and migrations. Be careful with automated “remove unused images” tools – verify before bulk-deleting, because builders reference images in ways detection tools miss.

What this delivers, from recent client work (generic, but real measurements): a services company’s home page went from 5.8 MB to 1.4 MB – the hero alone from 2.1 MB PNG to a 148 KB WebP – and mobile LCP from 4.9 s to 2.2 s, with no other changes. A store I look after for a German agency cut category page weight from 3.9 MB to 1.1 MB with AVIF thumbnails and correct lazy-loading, and mobile PageSpeed moved from 54 to 88. Neither project touched the theme’s code beyond a sizes-attribute fix. The pattern repeats because the starting point repeats: good sites carrying heavy images, one workflow away from being fast.

Want your images – and your whole site – properly fast?

I do this workflow as part of a fixed-price speed package: full audit, format and sizing overhaul, plugin or CDN setup, lazy-loading and LCP fixes, and a report with before/after numbers you can verify yourself. See the WordPress speed optimisation service and the portfolio, or send me your URL – I reply with an honest assessment within 24 hours.

Frequently asked questions

What is WordPress image optimization?

It is the combination of serving images in modern formats (WebP or AVIF), at the dimensions actually displayed, compressed to sensible quality, and loaded in the right order – plus a workflow that keeps new uploads following the same rules automatically.

Should I use WebP or AVIF on WordPress?

Both, ideally: AVIF first (20-30% smaller than WebP), WebP as the broad fallback. If your plugin or hosting only supports WebP, that alone captures most of the saving over JPEG and PNG.

What is the best image size for WordPress?

There is no single size – match the display: 1600-1920 pixels for full-width heroes, 800-1200 for content and product images, 400-600 for thumbnails, and let srcset serve smaller versions to phones automatically.

Do image optimization plugins slow down my site?

The optimisation itself runs in the background or on external servers, so visitors never wait for it. On weak shared hosting, avoid bulk-converting thousands of images at peak hours, or use an API or CDN-based service that does the work off-server.

How do I convert my existing images to WebP or AVIF?

Install a conversion plugin (Converter for Media, EWWW, ShortPixel or Imagify), run its bulk optimisation over the media library, and verify in the browser’s network tab that pages actually serve image/webp or image/avif afterwards.

Why is my site still slow after compressing images?

Usually one of three things: the converted files are not actually being delivered (a rewrite or CDN configuration issue), the LCP image is lazy-loaded or oversized, or the bottleneck was never images – test with PageSpeed Insights and read what it names.

Should I lazy-load every image?

No. Lazy-load everything below the fold, but never the hero or first visible image – lazy-loading the LCP element makes the page feel slower. WordPress handles this correctly by default; sliders and builder settings are the usual culprits when it goes wrong.