WordPress powers a huge share of the web, and WordPress sites share one chronic weakness: images uploaded straight from the camera. A single 6 MB upload becomes half a dozen generated sizes (thumbnail, medium, large, retina variants), multiplying the bloat across your media library and dragging down Core Web Vitals. Here's the workflow that keeps a WordPress site fast without stacking five optimization plugins on top of each other.

The habit that fixes 90% of it: run every image through the compressor before it touches the WordPress uploader.

Compress before uploading

Compress before you upload

The cheapest place to optimize an image is on your own machine, before it enters WordPress. Plugin-based compression happens on your server — consuming CPU on shared hosting, queuing batches, and often storing a second copy of every file. Pre-compressing instead means the media library only ever holds lean files:

  1. Run the image through the JpegDiet compressor (WebP output, target 100–200 KB for content images, hero images up to 250 KB).
  2. Upload the compressed file to WordPress as usual.
  3. Done — no plugin processing, no server load, no quality arguments with an automated algorithm.

Set sane dimensions once

Under Settings → Media, WordPress defines thumbnail, medium, and large sizes; your theme adds its own. Two rules keep them useful:

  • Match "large" to your content column. If your article column renders at 800 px, a 1024 px large size is right; 2560 px is wasted storage.
  • Cover Retina with srcset, not with uploads. WordPress generates srcset automatically from your image sizes — upload at ~2× the column width once, and smaller devices get smaller files automatically.

What to do about a bloated existing library

If the damage is already done, a bulk compression plugin is the pragmatic cleanup tool — it re-encodes the library server-side and typically cuts total media weight by half or more. Run it once, verify a sample of images visually, then switch to the compress-before-upload habit so it never needs to run again. Note that plugins can also convert existing JPG/PNG to WebP copies served to capable browsers — useful, though native WebP uploads make even that unnecessary.

Deliver with the basics done right

  • Lazy loading is built into WordPress since 5.5 — verify your theme hasn't disabled it, and keep the hero image eager (it's usually the LCP element).
  • Explicit dimensions: WordPress adds width/height automatically for media library images; the problems come from images pasted into blocks with CSS overrides that drop them — check your Largest Contentful Paint and CLS in PageSpeed Insights.
  • A page caching layer (host-level or plugin) makes the byte savings compound — fast images plus cached HTML is what turns CWV scores green.

Format notes for WordPress

WordPress accepts WebP uploads natively in current versions, and every mainstream CDN/browser path serves it correctly. For most sites the simple 2026 policy is: WebP for everything photographic, PNG only for screenshots and graphics with text. Keep JPG for the rare external system that pulls images from your library and demands it.

A checklist you can repeat weekly

  1. Compress each new image to target size before upload (WebP, ≤200 KB).
  2. Insert via the media library so srcset and dimensions are generated.
  3. Quarterly: PageSpeed Insights on your heaviest post; fix whatever LCP image it flags.

Related guides