Images are the single largest line item in most WordPress page weight. On a typical content or e-commerce page in 2026, imagery accounts for 50 to 70 percent of bytes transferred, and the hero image is almost always the element Google flags as your Largest Contentful Paint. Get images right and you usually clear the LCP < 2.5s threshold without touching anything else. Get them wrong and no amount of caching plugin tuning rescues the page. This is a workflow problem more than a tooling problem, so what follows is the actual sequence I run, from the moment a file lands on my desk to the moment I confirm the browser received the right bytes.

Decide the rendering pipeline before you touch a single image

The most consequential choice happens before optimization: who is allowed to generate the derivative images your visitors download. You have three architectures, and stacking them is how sites break.

WordPress + an optimization plugin (ShortPixel, Imagify, EWWW, Smush). WordPress generates the size variants, the plugin compresses them and writes WebP/AVIF copies to disk, then rewrites your markup to serve them. Everything lives on your origin.
A transformation CDN (Optimole, ImageKit, Cloudinary, Cloudflare Images/Polish, Bunny Optimizer). The CDN intercepts image requests and produces the right size, format, and quality on the fly at the edge. Your media library effectively holds masters only.
Hosting-bundled optimization. WP Engine, Kinsta, and Cloudways increasingly ship their own edge image service. Rocket.net and Cloudflare-fronted stacks do format conversion at the proxy.

Pick one to own format conversion and resizing. If your plugin writes AVIF to disk and Cloudflare Polish is re-encoding and your theme has a third lazy-load script, you get double-compressed mush, broken srcset on Safari, or images that vanish on older Android browsers. Decide the owner first; the rest of the workflow hangs off that decision.

Master file prep: do the lossy-to-lossless transition once

A 4.2 MB phone photo should never enter the media library at full size. Resize the master to the largest dimension the site will ever display, then hand a clean source to whatever does the automated work. For most editorial layouts that ceiling is 2048px on the long edge (it covers full-bleed heroes and 2x retina on a 1024px content column). For a boxed blog whose content width is 720px, 1600px is plenty.

Two prep rules that matter more than the tool:

Choose the format by image type, not habit. Photographs and anything with smooth gradients want JPEG/WebP/AVIF. Screenshots, logos, line art, and anything with hard edges and flat color want PNG masters or, better, SVG. Saving a logo as a JPEG bakes in compression haloes that no plugin can undo.
Strip the metadata. EXIF, GPS coordinates, and color profiles can add 30 to 60 KB per file and leak the location your photo was taken. Most plugins strip on import, but doing it at the source keeps the master clean.

For the actual squeeze, Squoosh is still the best free way to see the quality/size tradeoff with a live slider; ImageOptim (Mac) and Caesium (Windows/Linux) handle batches without a browser. This step costs maybe ten seconds per image and it is the difference between feeding your pipeline a 280 KB source and a 4 MB one.

Set quality and format delivery deliberately

Plugins ship conservative defaults because the vendor never wants to be blamed for visible artifacts. That caution costs you bandwidth. The settings I actually use:

Lossy, not lossless or "glossy." Glossy modes preserve detail you cannot see at web scale. Lossy at a sane quality wins almost every time.
JPEG/WebP quality around 72 to 78 for content sites. Below ~70 you start seeing banding in skies and skin tones; 80+ is wasted bytes for typical article imagery. Photography portfolios and product galleries are the exception — push those back to 82 to 85.
AVIF where the toolchain supports it, WebP as the universal fallback. AVIF typically lands 20 to 30 percent smaller than WebP at matched perceptual quality. Every current browser decodes AVIF, but generation is CPU-heavy, so on shared hosting WebP-first with AVIF as a progressive enhancement is the pragmatic call.

Equally important is how the modern format reaches the browser. There are two mechanisms and they fail differently. The <picture> element approach rewrites your HTML so each browser picks its own format — robust, cache-friendly, and the safest default. The .htaccess/content-negotiation approach serves a WebP under the same JPEG URL based on the Accept header — invisible in markup but it can poison a CDN cache that ignores the Vary header, sending WebP to a browser that asked for JPEG. If you front the site with a CDN, prefer the <picture> method or make absolutely sure Vary: Accept is honored.

Make WordPress's built-in responsive images actually fit your theme

Since 4.4, WordPress writes srcset and sizes automatically, generating multiple widths per upload. The system is good, but it only serves the right file if the registered sizes match your layout. Two checks under Settings → Media and your theme:

The registered widths should bracket your real display widths. If your content column renders images at 760px but your size set jumps from 600px to 1536px, every visitor downloads the 1536 and the browser shrinks it. Add an intermediate size that matches.
Fix the thumbnail aspect ratio before you upload, not after. The default 150×150 square is wrong for a 16:9 card grid. Change it first — WordPress does not retroactively regenerate. For an existing library, run Regenerate Thumbnails or WP-CLI's wp media regenerate.

One modern wrinkle: WordPress 6.x ships native loading="lazy" and fetchpriority. It tries to mark the LCP image with fetchpriority="high" and skip lazy-loading on it. Verify it picked the right element — if your hero is injected by a page builder, WordPress may lazy-load it by mistake and tank your LCP. Force fetchpriority="high" and remove loading="lazy" on the above-the-fold hero by hand if needed.

Verify in the browser — assume nothing worked

This is the step everyone skips and the reason "optimized" sites still ship 1920px JPEGs to phones. It takes five minutes. Open a real article in an incognito window, switch DevTools to a mobile profile, open the Network tab filtered to Img, and reload. For the hero and two body images, confirm:

Served dimensions match the display. A 400px-wide slot should pull a ~400–800px file, not the 2048 master. If it pulls the master, your sizes attribute or registered widths are wrong.
Format matches the browser. Modern browser should receive AVIF or WebP. If every browser gets JPEG, your delivery layer isn't doing its job.
The LCP image is what you think it is. Run a Lighthouse mobile pass and read the "Largest Contentful Paint element" — if it's a tracking pixel or a lazy-loaded background, your hero priority is misconfigured.
Total image weight is sane. A well-optimized article page should land image payload in the low hundreds of KB, not multiple megabytes.

Re-run this quarterly and after any theme or plugin update, because updates silently reorder which layer handles conversion.

The workflow, condensed

Image optimization on WordPress in 2026 is solved engineering wrapped in an operational discipline problem. The discipline is: one owner for format and resizing, masters capped at a sensible width and stripped of metadata, lossy quality tuned to the site's purpose rather than the plugin default, responsive sizes that bracket your real layout, the hero explicitly prioritized, and a five-minute Network-tab audit to prove the browser received what you intended. Do those six things and stop bolting on tools — a second "optimizer" almost always undoes the first. The fastest image is the one you sized correctly before it ever reached the media library.

WordPress Image Optimization: The Practical Workflow