How to Build an Image Optimization Baseline Before You Convert

The easiest way to make an image optimization project messy is to start with conversion. A team points a tool at a folder, generates hundreds of WebP or AVIF files, and only then asks whether the new files improved the website. That order creates confusion. Some images get smaller because they were resized. Some get smaller because the format changed. Some look worse. Some were not used on the site at all.

A baseline prevents that. It gives you a simple record of the current state before any compression work begins. With a baseline, you can compare changes honestly, catch regressions, and explain the results to non-technical stakeholders without relying on vague claims.

"Audit images first" is only useful when the audit records are defined. A useful baseline names the page, the image role, the rendered size, the source size, the current transfer size, the planned resize step, and the conversion report that later proves what changed.

Choose the Pages That Matter#

Do not begin with every image in storage. Start with the pages that affect real users and business outcomes:

• homepage
• top landing pages
• product or service pages
• checkout or signup paths
• high-traffic blog posts
• documentation pages that receive organic search traffic

This matters because media folders often contain old exports, duplicate images, temporary design files, and assets that no template references anymore. Optimizing unused files may be harmless, but it does not improve the user experience.

For each selected page, record the URL, template type, primary audience, and page owner. That context helps later when you decide whether a visual tradeoff is acceptable.

Start with a small table:

page,template,owner,image_role,current_url,rendered_size,natural_size,current_bytes,above_fold
/pricing,landing,marketing,hero,/images/pricing-hero.jpg,1280x720,3200x1800,684212,true
/docs/install,docs,documentation,screenshot,/images/install-ui.png,860x520,1720x1040,412901,false

This table is not busywork. It tells you whether the project is solving a page problem, a dimension problem, a format problem, or an unused-asset problem.

Capture the Current Image Inventory#

Open each page and list the images that load in normal use. Include responsive variants if the page serves different images at different widths. For each image, record:

• image URL
• displayed width and height
• natural width and height
• file type
• file size
• whether it is above or below the fold
• role: hero, thumbnail, product photo, logo, screenshot, icon, or decoration

Browser DevTools can provide most of this information. A crawler can help, but manual review is still useful because it tells you which images are visually important.

The role field is especially important. A 300 KB hero image may deserve more attention than twenty tiny decorative icons, even if the total bytes look similar.

Separate Dimension Problems From Format Problems#

Many image audits discover that the biggest issue is not JPEG vs WebP. It is oversized source dimensions. A 3200-pixel image displayed at 720 pixels wide is wasting bytes before the encoder is even involved.

Mark images where the natural dimensions are far larger than the largest displayed size. Those files should be resized before format conversion is evaluated. Otherwise, the team may credit WebP for savings that actually came from resizing.

Keep the original file in your archive and generate a resized working copy. This gives you a clean chain of evidence:

1. original source
2. resized source
3. converted output
4. published asset

That structure makes it easier to compare results and recover if a setting is too aggressive.

Measure Current Page Behavior#

A useful baseline includes page behavior, not just file sizes. Record a small set of metrics before conversion:

• total image transfer size
• number of image requests
• largest visible image
• whether images are lazy-loaded correctly
• whether the likely LCP image is delayed
• any broken or duplicate image requests

Tools such as PageSpeed Insights and the browser Performance panel can help identify image-related opportunities. The web.dev guide to responsive images is also useful when the problem is delivery rather than compression.

Do not treat one lab score as the whole truth. Network conditions, cache state, device class, and layout can change what users actually experience.

Create a Small Approved Sample#

Before converting an entire folder, choose a small sample that represents the site:

• one hero image
• one product or portfolio image
• one image with text
• one transparent graphic
• one thumbnail
• one editorial image

Convert only that sample first. Review the outputs at the sizes users will see, then inspect high-risk details such as text, faces, gradients, shadows, and transparent edges.

This is where a local tool such as GetWebP fits well. You can keep the source files untouched, write outputs to a separate folder, and compare results without uploading client or product assets.

Run the sample conversion as a measured experiment:

mkdir -p ./baseline/reports

getwebp ./baseline/working-sample \
  --recursive \
  --output ./baseline/converted-webp \
  --dry-run

getwebp ./baseline/working-sample \
  --recursive \
  --output ./baseline/converted-webp \
  --json \
  --manifest ./baseline/reports/converted-manifest.json \
  > ./baseline/reports/converted.ndjson

Then turn the NDJSON report into a comparison table:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | [.status, .file, .outputPath, .originalSize, .newSize, .savedRatio, .quality, .qualityMode, (.error // "")]
  | @tsv
' ./baseline/reports/converted.ndjson

Use the report to separate compression evidence from page evidence. originalSize and newSize describe the files that entered and left the conversion step. They do not prove that the published page improved until the HTML, srcset, cache, and network behavior are checked.

The GetWebP CLI command reference documents --recursive, --output, --dry-run, --json, and --manifest; the JSON output guide explains convert.completed, outputPath, savedRatio, quality, and qualityMode.

Record the Decision#

Your baseline should end with a short decision log:

• which pages were reviewed
• which source files were tested
• which output settings passed visual review
• which settings failed and why
• which files should stay PNG, SVG, JPEG, WebP, or AVIF
• what will be checked after publishing

The decision log does not need to be formal. It only needs to be clear enough that another developer, designer, or content manager can repeat the work.

Add the evidence paths to the decision log:

Baseline inventory: baseline/images.tsv
Conversion report: baseline/reports/converted.ndjson
Manifest: baseline/reports/converted-manifest.json
Visual review: baseline/reports/visual-review.md
Post-publish check: compare network panel and LCP image on selected pages

A good image optimization baseline slows the first hour down and speeds the project up after that. It keeps the team focused on real user-facing files, shows which improvements came from which change, and reduces the chance that a bulk conversion creates quality problems nobody notices until after launch.