WordPress Image Optimization in 2026: AVIF, WebP, and the Real-World Difference

The short answer for any WordPress site in 2026 is to serve AVIF first, fall back to WebP for the small slice of browsers that need it, and keep a JPEG only as a last-resort archival fallback. AVIF compresses roughly 30 percent smaller than WebP at the same visual quality, and WebP compresses roughly 25 to 30 percent smaller than JPEG at the same visual quality, which means a typical 280 kilobyte hero JPEG drops to about 200 kilobytes in WebP and around 95 to 140 kilobytes in AVIF without a single visible pixel of degradation. On a real Core Web Vitals audit that swap usually shaves 600 to 900 milliseconds off Largest Contentful Paint on a mid-tier mobile connection, which is enough on its own to flip a failing LCP score into a passing one for most content sites we look at.

The longer answer is that most WordPress sites in 2026 still serve plain JPEGs, and the reason is rarely ignorance. It is that the WordPress image pipeline has three distinct tiers, the tiers compete with each other, and most site owners have never been told which tier their setup is actually using. This article is the comparison we wish existed. We cover the format math, the browser-support reality, the three tooling tiers and where each one breaks, and why the plugin you installed last year is probably converting nothing.

The format math, with real file sizes

Take a representative 2400 by 1600 pixel hero image of a product on a textured background, the kind of shot that lives at the top of a homepage or a long-form article. Saved as a quality 85 JPEG straight out of Lightroom, it lands at roughly 540 kilobytes. Run the same source through Sharp at WebP quality 80 and the file drops to about 380 kilobytes, a 30 percent reduction at a visual quality that is statistically indistinguishable from the JPEG when compared with SSIM or VMAF. Run the same source through libavif at AVIF quality 60, which targets the same SSIM band, and the file drops to roughly 240 kilobytes, another 37 percent reduction on top of the WebP and 56 percent off the JPEG.

The deltas hold across content types but the magnitudes shift. Photographs of faces and skin tones favour AVIF most heavily because of its better chroma handling. Flat illustrations and screenshots with sharp edges favour AVIF less and WebP more. Charts with text are a different conversation entirely and often belong in PNG or SVG, never in any lossy format.

Bytes still matter even on fast connections. TCP slow start and the LCP measurement window mean that the browser can only stream so much data into the first paint, and a hero image that fits inside the first congestion window paints noticeably faster than one that does not. Cutting hero weight by half is a measurable LCP win on any device.

Browser support is no longer a real argument

AVIF support landed in Chrome 85 in August 2020, in Firefox 93 in October 2021, and in Safari 16.4 in March 2023. Edge, Opera, Samsung Internet, and Chrome on Android have all supported it for years. As of 2026, the global support figure on caniuse sits comfortably above 95 percent, and the holdouts are archived browsers no commercial site optimises for in any other respect.

WebP is universal. Every browser shipped since early 2021 supports it, including Safari on iOS. The fallback chain is AVIF first, WebP second, and JPEG only as a final safety net for crawlers and email clients that strip modern formats. JPEG XL would have been an interesting fourth option but Chrome dropped it in 2023 and it remains effectively unusable for the open web.

The three pipeline tiers, ranked

Image optimisation on WordPress runs in one of three places, and the choice between them is the single most consequential decision in the whole stack. Pick the wrong tier and you can install three plugins, pay for two services, and still ship oversized JPEGs.

The plugin tier runs inside WordPress itself. The Imagify, ShortPixel, Smush, EWWW Image Optimizer, Optimole, and Converter for Media plugins all sit in this category. They hook into the upload pipeline, generate alternative formats, and serve them through filters or rewrite rules. They are the easiest to install, the easiest to demonstrate to a non-technical client, and the most likely to silently fail. Most of them depend on Imagick or GD with the right libraries compiled in, and most cheap shared hosts ship versions where AVIF encoding is missing entirely. The plugin claims to deliver AVIF, the encoder cannot produce AVIF, the plugin silently downgrades to WebP, and the site owner never knows.

The server or CDN tier runs at the edge, between the origin and the visitor. Cloudflare Polish on the Pro plan converts JPEG and PNG to WebP and AVIF on the fly and serves the right format based on the Accept header, with no WordPress involvement at all. Bunny Optimizer, Cloudflare Images, KeyCDN Image Processing, and Fastly Image Optimizer do the same job with different pricing and different caching guarantees. The advantage is that the WordPress origin keeps serving the original JPEG and the heavy lifting happens once at the edge cache. The disadvantage is the running cost and the fact that the conversion is generic, not tuned per asset.

The build-step tier runs before the image ever reaches WordPress. Run the source through squoosh.app, through a Sharp script, through cwebp and avifenc on the command line, or through any modern asset pipeline, and you upload the optimised AVIF and WebP directly. WordPress serves what you uploaded with no runtime cost, no plugin dependency, no encoder bug. This is what we use on every WitsCode build where the editorial team will tolerate a slightly higher upload-time effort, and the long-run performance is uncontested.

Plugin-tier reality check

If a plugin tier is the only realistic option, the choice is narrower than the marketing suggests. Imagify and ShortPixel both convert reliably when the host has a working encoder, and both fall back gracefully when it does not. Imagify is owned by the WP Rocket team and integrates cleanly with their cache layer. ShortPixel has the most aggressive AVIF defaults and the strongest bulk-conversion tooling for legacy media libraries. Optimole offloads to its own CDN and serves a per-request AVIF or WebP depending on the visitor's browser, which removes the host encoder problem but adds a third-party dependency to every page load. Smush by WPMU DEV is the most installed and most often misconfigured: the free tier does not convert to WebP without an add-on, and AVIF is gated behind Pro in a way that is easy to miss.

The diagnostic step we run before recommending any of them is to check the actual response. Open Chrome DevTools, load the page, look at the Network panel, click an image request, and read the response Content-Type. If the header says image jpeg even after the plugin has supposedly converted everything, the plugin is not doing what its dashboard claims. We see this on roughly a third of audited sites that arrive at WitsCode with a paid optimisation plugin already installed.

Server-tier reality check

Cloudflare Polish is the path of least resistance for any site already routing through Cloudflare, and on the Pro plan it adds AVIF conversion with a single toggle. The Vary header is correct, and the cache hit rate stays high because Cloudflare keys on the Accept header and stores both variants. The downside is that Polish does not resize, only reformats. A 4000 by 3000 pixel original gets converted to AVIF but stays 4000 by 3000 pixels, which is the wrong fix for a site whose real problem is that contributors upload phone-camera originals straight into posts.

Bunny Optimizer is the strongest competitor on price and adds responsive resizing through URL parameters, which means a single source image can be requested at multiple breakpoints without any work in WordPress. Cloudflare Images is the heavier-weight option that takes over storage as well as delivery. For a typical small-business or content site the choice usually comes down to Polish if Cloudflare is already in the stack, Bunny if it is not.

The server tier shines when editorial discipline cannot be enforced at upload time. If contributors will drop oversized originals into posts no matter how many times you ask them not to, the server tier saves you from the consequences without retraining anyone.

Build-step reality check

The build-step tier is the technical winner and the operational hardest sell. Squoosh.app, run by the Chrome team, is the simplest entry point: drag an image into the browser tab, tune AVIF quality with a live preview, download the result. For team workflows, a Sharp script in a pre-commit hook or a Node CLI handles bulk conversion in seconds. Sites with a static-site step in their stack already have this for free.

The reason it does not become the default for everyone is the WordPress media library. Once an image is uploaded, WordPress generates derivative sizes from the source, and those derivatives inherit the source format. Upload an AVIF as the source and every thumbnail is AVIF. Upload a WebP and you lose AVIF entirely. The cleanest workflow we have found is to upload AVIF as the primary, let WordPress generate AVIF derivatives, and lean on a small filter to also generate a WebP and a JPEG fallback for the picture element. That setup wins on every metric we track but it is more configuration than most teams will accept on day one.

Why most WordPress sites still serve JPEG

WordPress core added native WebP support in version 6.0, in May 2022, and added native AVIF support in version 6.5, in April 2024. Core does not auto-generate alternative formats from a JPEG upload. It serves what you upload. If the contributor uploads a JPEG, the site serves a JPEG forever, regardless of which optimisation plugin is installed, unless that plugin is actively rewriting the response.

Layer on top of that the fact that page builders cache rendered markup with hardcoded image URLs, that many caching plugins serve stale HTML pointing at the JPEG variant even after WebP exists, and that cheap shared hosts ship PHP without AVIF encoder support, and the picture clarifies. Most JPEG-serving WordPress sites in 2026 are not running a bad plugin. They are running a plugin whose preconditions were never met, on a host that cannot help, behind a cache that cements the wrong outcome.

The fix on a live site is rarely a new plugin. It is a diagnostic pass that reads the actual response headers, verifies the encoder availability on the host, checks that the cache is keyed correctly on the Accept header, and either repairs the existing pipeline or replaces it with one tier up. We pick the tier based on hosting reality and editorial workflow, not on what is fashionable.

What we ship by default at WitsCode

For client builds where editorial discipline is realistic, we go build-step first. Originals are processed through Sharp on upload, AVIF and WebP variants are generated alongside the JPEG fallback, and the picture element handles negotiation in the browser. For client builds where contributors will upload whatever is on their phone, we go server-tier with Cloudflare Polish or Bunny Optimizer and accept the running cost in exchange for a setup that survives editorial behaviour. Plugin tier is the third choice, used only when the host blocks both of the others, and even then we pick Imagify or ShortPixel and verify with the Network panel that conversion is actually happening.

The article you are reading does not need a plugin recommendation at the end. It needs an honest audit of the response headers your site is sending right now. If those headers show image jpeg when they should show image avif, the rest of the optimisation stack is irrelevant until that one fact changes. That is the audit we run as the opening step of any WitsCode image-pipeline engagement, and on most sites it is the cheapest LCP win available.