WordPress Image Optimization

Images are the heaviest thing most WordPress sites serve and the most automatable fix in the speed stack: one optimizer configured once turns every future upload into compressed, modern-format, correctly-sized assets — and a bulk pass rehabilitates years of 4MB camera uploads already in the library. This guide covers the pipeline setup, the WordPress-specific mechanics (sizes, srcset, lazy-load defaults), and the image-SEO layer that makes pictures earn search traffic besides.

The pipeline: what the optimizer must do

The plugin class (ShortPixel/Imagify/Smush-tier, or increasingly the CDN/host image service): compression at upload (lossy at sane quality — the visually-lossless settings; retest your own photography rather than trusting defaults), WebP/AVIF generation with proper serving (picture-element or CDN content-negotiation — verify delivery in dev-tools, since generating without serving is the common half-config), resize ceilings (cap originals at the largest size any layout renders — the 6000px camera original has no business in the library), and the bulk pass over existing media, run once, off-peak. One optimizer only, per the stack rules — stacked optimizers re-compress each other's output into artifacts.

The WordPress mechanics worth understanding

1. Registered sizes and srcset: WordPress generates multiple sizes per upload and emits srcset automatically — which works when the theme requests sensible sizes: audit what your templates actually render (the thumbnail-vs-hero crime happens here — grids rendering full-size images scaled by CSS) and prune unused registered sizes bloating the uploads folder.
2. Native lazy-loading, with the exemption: core lazy-loads by default; the LCP image must escape it (recent cores attempt this automatically; verify on your hero templates — the eager-plus-preload treatment for the one image that decides LCP).
3. Dimensions always: width/height attributes present (core handles this for library images; builder-inserted and hardcoded images are where CLS creeps back).
4. Attachment pages redirected — the standing toggle, because every upload otherwise mints a thin URL.

The SEO layer (traffic, not just weight)

Per the full image-SEO guide, the WordPress rendering: filenames descriptive before upload (the library doesn't rename retroactively without plugins — waterproof-hiking-boots.jpg beats IMG_4032.jpg forever), alt text as workflow (the media library's alt field, filled at upload, enforced editorially — accessibility first, image-search relevance second), captions where they serve readers, and original images over stock wherever possible — originals earn embeds-with-credit and image-SERP positions that recycled stock never will. For image-heavy niches, the image sitemap extension via the SEO plugin completes the plumbing.

Frequently asked questions

WebP or AVIF — and what about browser support?

Serve modern formats with automatic fallback (the optimizer/CDN's job — picture-element or negotiation handles old browsers transparently): WebP is the safe universal upgrade, AVIF the deeper compression where your pipeline supports it. The setting to avoid is the manual either/or — let the delivery layer negotiate.

Should I offload the media library to a CDN or external storage?

CDN delivery: yes for everyone, per the standard stack. Offloaded storage (media living off-server): a scale decision for huge libraries and multi-server setups, with migration lock-in worth reading about first — most sites just need delivery, not relocation.

Does image optimization actually move rankings?

Through two doors: the speed thresholds (image weight is most sites' LCP story — the baseline shows yours) and image search itself, which for visual niches is a real traffic channel most competitors ignore. Both doors opened by the same afternoon of configuration — after which the compounding work resumes: content worth illustrating and the authority that ranks it (our darkroom).