WordPress Image Optimization: Find The 794KB File Before Your Visitor Does.

Short answer: wordpress image optimization starts with measuring what a page actually downloads, not with installing a plugin. Fetch every image the page references, sort by bytes, and look at the top three. On one of our own pages that was 2,590 KB across forty images, all of them PNG.

What the audit found

the dates: images uploaded in 2021 are still being served on a 2026 page.*

That last point is the part people miss. A media library is append-only in practice. Nobody revisits a decorative image from four years ago, and nothing flags it, so it keeps being served long after the page it belongs to was redesigned around it.

Running a WordPress image optimization audit yourself

You do not need a tool. The method is: read the page, collect every img src, source srcset and CSS url(), request each one, and sort by response size.

curl -s https://example.com/ \
  | grep -oE 'src="[^"]+\.(jpe?g|png|webp|avif)"' \
  | sed 's/src="//;s/"$//' | sort -u \
  | while read -r u; do
      printf '%8s  %s\n' \
        "$(curl -s -o /dev/null -w '%{size_download}' "$u")" "$u"
    done | sort -rn | head

Two refinements that matter in practice.

Request as a browser would. Send an Accept header including image/webp and image/avif. Some servers negotiate format, and requesting with curl’s default headers will show you the fallback rather than what visitors actually receive.

Follow srcset, not just src. Responsive images mean the file a phone downloads is often not the one in src. Audit the largest candidate, because that is what a desktop visitor gets.

Format is only half of it

more image weight, including a single 1.4 MB WebP.*

Converting to a modern format shrinks a file. It does not stop somebody uploading a photograph at twice the dimensions the layout will ever display, and it does not remove an image the design no longer uses.

is no WebP sibling to fall back to. woocommerce.com serves WebP from URLs that still end in .jpg, because something in front converts per request.*

So the audit has three questions, in this order:

Is this image needed at all? The cheapest image is the one you removed.

Are the dimensions sane? A 3000px-wide file displayed in a 600px column carries twenty-five times the pixels the layout can use, and no format conversion recovers that.

Is the format modern? This is the last question, not the first, and it is covered separately in the piece on WebP and AVIF.

Where this fits

Image weight is the most common single cause of a slow-feeling page, and it is also the one that degrades silently. Nobody ships a 794 KB image deliberately. Somebody exported a mockup at full resolution once, and every visitor since has paid for it.

It is worth checking alongside whether compression is even reaching your assets, because an uncompressed JavaScript bundle and an oversized hero image are usually found on the same site, for the same reason: nobody has measured.

And measure the page, not the server. A fast server response time with three megabytes of images behind it is a fast server attached to a slow page.

Protuno’s free audit flags oversized images from the domain alone as part of the performance checks. Straight with you as on every post here: Dash, the Performance agent that would re-run this after every content change, is built and named but not live yet.

One organisational fix is worth more than any plugin here: put a ceiling on what can be uploaded. Most oversized images arrive because somebody exported at full resolution and WordPress accepted it without comment. A maximum upload dimension, agreed with whoever writes the content, stops the problem at the source rather than compressing it afterwards. Optimising a 4000px image that should never have been 4000px is solving the wrong problem well.

Run the loop above on your client’s homepage. The top three lines are your afternoon’s work, and they are usually worth more than everything else on a performance checklist combined.