Start with one page that real visitors use. A site-wide pass makes it harder to trace a bad result back to a particular file. Find a few heavy images, estimate the likely saving, and widen the scope only after you have checked the first changes.
Inspect one page
Enter a public URL in the image analyzer. It samples accessible images in the HTML and estimates potential savings from WebP. This is a useful starting point, not an exhaustive audit.
Check the page at both desktop and mobile widths and compare the analyzer list with the images a visitor can actually see. Images inserted after an interaction and some CSS backgrounds may require a separate inspection. For each heavy file, note its URL, format, current bytes and page location. This small baseline makes it possible to measure the same assets again after publishing changes.
Prioritize heavy files
Large photographs and oversized hero images often deserve attention first. Check whether the browser is downloading a file with far more pixels than the layout needs.
Give first-screen images and repeated card thumbnails different priorities. For a hero image, both bytes and the start time of its request matter. For a thumbnail repeated across many cards, correct dimensions and caching also matter. If a 400-pixel slot downloads a source several thousand pixels wide, make a suitable size before comparing compression formats. Format conversion alone cannot remove the unnecessary dimensions.
Choose the first change
- A heavy fileRecord its bytes and compare formats at the same resolution.
- An oversized sourceCreate a suitable size before compressing it again.
- No change on the pageInspect caches and the URL the browser downloads.
Compare the finished versions
A smaller number is only helpful if the image still looks right. Review details, transparency and colors, then keep the original if you may need to restore it.
Inspect the finished image in the published layout, not only in the compressor preview. Compare texture, small text and color; put transparent edges against more than one background. Keep the original and record where to retrieve it if the result is questionable. A smaller number is not a win if the page loses a detail that helps the visitor understand the product or content.
Act on the result
- A heavy photograph
- Compare finished versions and inspect details in context.
- Excessive dimensions
- Fix the variant served to mobile and desktop blocks.
- A late download
- Inspect the HTML, scripts and image discovery time.
Check the live page again
After publishing, open the page on desktop and mobile, confirm the correct file loads and compare transferred bytes. Browser or CDN caches may need to be refreshed.
After publication, clear the relevant browser or CDN cache and check the network panel again. Confirm that the requested URL is the new file, compare transferred bytes and look at the image on a phone as well as a larger screen. If savings appear on disk but not in the browser, inspect the final HTML and responsive image candidates before running another batch.
A practical example
Suppose a homepage banner appears at 700 pixels wide while the browser downloads a 3,000-pixel original. Compression alone cannot remove all those unnecessary pixels. Serve a suitable size first, then compare WebP with the current format. After publishing, inspect the bytes transferred to the browser rather than relying only on the file size on disk.
Before you publish
- Record the original file URL and size before replacing it.
- Check one page at mobile and desktop widths.
- Keep the original and measure again after clearing caches.
Explore more
Check the result on your own website and keep an original when you may need to restore it.