How to Optimize Images for Google PageSpeed

Record a clear starting point

Open PageSpeed Insights, enter the public URL of the page you want to test, and run a mobile or desktop test.

1. Test the published page URL, including the exact path.
2. Record whether you are looking at mobile or desktop.
3. Note the image named in the relevant finding and its current URL.
4. Save its dimensions and file size alongside the report.
5. Identify what a successful change would improve: bytes, discovery, display stability or another issue.

Choose a representative page before changing a whole site. For a shop, that might be one product page with the usual gallery. For a publication, choose an article with a typical cover image. A homepage result does not automatically describe every template.

Choose a targeted fix

If the delivered image is oversized for its display area, prepare appropriately sized variants. If encoding is the issue, compare a WebP copy with the current file. Use JPG to WebP or PNG to WebP according to your source.

If a layout moves when an image appears, reserve its space rather than merely compressing it. If the opening image starts late, inspect how the page discovers it. The Core Web Vitals guide explains how those cases differ.

Understand the two kinds of evidence

PageSpeed Insights combines a Lighthouse lab test with real-user field data when available. Field data summarizes real visits over a rolling 28-day period. A small site can lack enough field data; that is not itself a failed test. See Google’s PageSpeed Insights documentation.

A new image can affect the next lab test, but field data still includes visits made before the change. Record which section of the report you are comparing so an immediate lab improvement is not confused with an improvement experienced by all visitors.

Check whether the field-data panel represents this URL or the whole origin. Origin data combines visits to pages sharing the same protocol, hostname and port; it cannot confirm that one edited product page improved. Keep page-level lab comparisons separate from that broader field view. Also distinguish an estimated byte saving in an audit from a measured LCP improvement: an image can become smaller without appearing earlier.

Confirm the change reached the page

Publish the new asset and update the page reference where needed. Check the browser’s image request to confirm the page serves it. A successful local export alone changes nothing for visitors. If the old URL or file persists, investigate the relevant cache or generated image variant.

Retest with the same device category and URL. Run again if the result varies unexpectedly, and compare the specific finding rather than attributing every score fluctuation to your image edit. Avoid changing hosting, scripts and all images at once if you want to understand which fix helped.

Know when to move beyond images

After the image-related findings are addressed, inspect the remaining bottlenecks. A slow response, extensive scripts or delayed rendering may dominate the experience. More compression can then make pictures worse without addressing the reason the page still feels slow.

Keep a simple record of the page, original file, replacement and observed outcome. That gives the next person a repeatable process and helps you catch a regression after a theme or layout change.

Example: turn a report finding into one change

Imagine a mobile report identifies the main product photograph as oversized. Save the report, page URL, image URL and displayed dimensions. Export a smaller version with the same crop and publish it on a test page. Confirm that the browser requests the replacement before repeating the measurement.

Use a comparison record with these fields: test date, device category, image dimensions, file size, reported LCP, layout shifts and visible quality. Run several comparable tests and note their range; do not compare the best new run with the worst old run. A lower image size with unchanged LCP is useful evidence that another part of loading may now dominate.

Decide whether to keep the change

Keep a change when it fixes the identified issue without making product detail, text or layout worse. If the request starts just as late as before, investigate discovery or loading settings. If the image downloads promptly but remains hidden, examine rendering or reveal effects. Compression cannot fix either delay by itself.