Image Format Migration to WebP/AVIF: A Speed Optimization Case Study

Last year I did a site-wide image format migration, and the thing that stuck with me was the homepage product image — an 180KB PNG that dropped to 62KB as WebP, then just 28KB as AVIF. Total image weight on the page went from 2.4MB down to 800KB, and LCP fell from 3.2 seconds to 2.1. No caching added, no server changes — just switching formats cut the weight in half. This article walks through the full migration steps and a few pitfalls that are easy to step in. Follow along, and you can shave down your site’s image weight in a day.

Here’s the bottom line up front: photos go to WebP or AVIF, images with transparency try WebP first, and screenshots or solid-color graphics get the biggest savings from AVIF. Migration is three steps: assess where you stand, batch convert, and use the <picture> element for multi-format fallback. Don’t use one quality setting for everything — around 80 for photos, 75 or even lower for screenshots and icons where you can’t tell the difference. After converting, you must keep alt text and filenames, and re-test LCP with Lighthouse — the two goals are simple: cut image weight in half, and improve LCP by 0.5 seconds or more.

How to choose among the four formats

The rule of thumb: photos use WebP or AVIF, graphics with alpha channels try WebP first (it supports transparency), and simple-color images like screenshots get the biggest savings from AVIF. If your site is still on HTTP (not HTTPS), fix the mixed content issue first — browsers will block HTTP images on HTTPS pages, so if you don’t clear that hurdle before converting formats, the images won’t even load (we have an article on fixing mixed content on the site).

A common misconception is “newer formats are always better.” It’s true that AVIF has the smallest file size, but it puts more encoding pressure on the server, and some older Android devices decode it slowly — which can actually slow down the first paint. The safe approach: roll out WebP site-wide first to bring LCP down, then pick the top 20 largest images and convert those to AVIF for an A/B test — whichever gives lower LCP, use that. Don’t blindly go all-AVIF. I’ve seen a site where after full AVIF rollout, LCP on mid-to-low-end Android devices actually went up by 0.3 seconds, and only went back to normal after reverting to WebP. Real-world testing always beats theory.

Three-step migration

Step 1: Assess where you stand. Run a site-wide scan first, tally up the format distribution and weight breakdown, and find the top 50 largest images — usually 20% of images account for 80% of the weight, so tackle the big ones first. For WordPress sites, you can filter directly in the media library, or write a small script to scan the uploads directory and sort by size. A practical baseline: any image over 100KB is worth converting, and anything over 300KB should be priority. This step doesn’t need to be rushed — you can identify what to convert first in half an hour.

Step 2: Batch convert. Small sites can use a WordPress image optimization plugin (ShortPixel, Imagify — both work, they handle auto format conversion at the CDN layer and can even generate <picture> fallbacks); larger sites or technical teams can use command-line tools to batch convert, cwebp for WebP and avifenc for AVIF, one command to process a whole directory, with quality settings around 75-80 where the difference is basically unnoticeable. The advantage of the command-line approach is control and reproducibility — write the migration script once, and run it directly whenever you add new images. The commands look like this:

# WebP: quality 80, iterate over directory
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done
# AVIF: quality 75
for f in *.jpg; do avifenc --min 75 --max 75 "$f" "${f%.jpg}.avif"; done

Before running it on everything, pick 3 representative images from the same directory (one photo, one screenshot, one image with text), convert them manually, zoom in to find the quality inflection point, and confirm the quality setting works before going full-scale. Don’t throw the entire uploads directory in at once — if the batch script has a bug, rolling back can be exhausting. Convert this year’s and last quarter’s images first (those are usually the highest-traffic ones), and put historical archive images in the second batch.

Step 3: Graceful degradation. Older browsers don’t recognize WebP/AVIF, so use the <picture> element for multi-format fallback:

<picture>
  <source srcset="img.avif" type="image/avif">
  <source srcset="img.webp" type="image/webp">
  <img src="img.jpg" alt="description">
</picture>

Browsers load AVIF first, fall back to WebP if unsupported, and use JPEG if neither works. The img tag must stay — it’s how crawlers read images, and it guarantees the image is visible in the worst case. If you use a plugin for conversion, this fallback layer is usually generated automatically, no hand-writing needed; but if you’re wiring up your own CDN, double-check that the fallback chain is complete. For a systematic look at how images relate to frontend performance, check the Core Web Vitals section in the Technical SEO Handbook.

How to tune quality settings

Don’t just use the defaults across the board. Photos have complex source material, so quality around 80 is safe; for solid colors, icons, and screenshots, 75 or even lower shows no visible difference and saves another chunk of size. After converting, spot-check images on key pages one by one, zoom in to see if there’s color banding at edges or blurry text. The biggest risk with batch conversion is “one size fits all” — ten minutes of spot-checking can prevent a batch of blurry images going live. A practical tip: convert the same batch at 3 different quality levels (70/75/80), compare them zoomed in yourself, pick the value at the quality/size inflection point, then run the batch.

Details not to overlook

• Keep alt text and image filenames after conversion — this is the foundation of image SEO, and switching formats doesn’t mean you can lose the attributes.
• If your CDN has image compression enabled, make sure you’re not double-compressing with local conversion — two layers of compression will produce visibly blurry images.
• After converting, run PageSpeed or Lighthouse again and compare weight and LCP before and after.

Set realistic goals: cutting image weight in half and improving LCP by 0.5 seconds or more counts as a successful migration. Once you’ve done this, go back and look at the LCP item in Core Web Vitals — you’ll find this is the highest-ROI move in site-wide speed optimization, faster than changing servers or adding caching, because images are usually the biggest chunk of weight.

How to monitor after migration

Converting isn’t the end. Within a week, check the Core Web Vitals report in Google Search Console and confirm both lab and field data have come down; if a certain template (like article header images) shows no LCP improvement, it’s likely that image wasn’t covered by the conversion — go back and convert it. Also keep a before/after weight comparison table, so next time you report speed optimization results you can pull it out directly, which is more convincing than saying “it seems faster.”

Next action items

• Run the assessment today, export the site’s top 50 images by weight, and identify which large PNGs can be converted.
• Small sites: install an image optimization plugin and enable WebP/AVIF auto-conversion; large sites: write the command-line batch script.
• Confirm key pages use <picture> for fallback, so older browsers don’t get blank screens.
• Spot-check quality after conversion, set quality parameters by image type, don’t use one global value.
• Re-test LCP with Lighthouse, record before/after numbers, and only roll out fully when targets are met (weight halved, LCP +0.5s).