Image optimization for the web: formats, responsive sizes and loading priorities
A smaller file helps only when the browser receives the right image at the right time.
Tools
Estimate the byte savings from image variants you have already created or measured.
Transfer savings do not translate directly into load-time savings. Images that load in parallel, caching, and network speed all change the result. Use this to prioritize, not to promise.
The calculator does not compress images, upload files or fetch a page. It works with the numbers you enter in your browser. Compare equivalent visual content and quality requirements; a much smaller thumbnail is not necessarily an appropriate replacement for a large product photograph.
For each image, bytes saved equal the original size minus the optimized size. Percentage reduction equals that difference divided by the original size, multiplied by 100. Use a positive original size; a zero-size original does not provide a meaningful denominator for percentage reduction.
The page total combines the entered image savings. The monthly estimate multiplies that total by the page-view count you supply. These are arithmetic estimates, not observed traffic or bandwidth measurements. The interface's unit convention should be used consistently for every input.
The estimate assumes the listed images are downloaded for each counted view. Real transfer depends on browser and edge caching, responsive selection, lazy loading, repeat visits and whether a visitor reaches the relevant image. Some pages will request only a subset of the files represented in your inputs.
If the optimized file is larger, inspect the export settings and the source. A different format is not automatically smaller for every image. Keep the result as evidence rather than replacing a valid negative saving with a positive marketing claim.
No. Resource discovery, network conditions, parallel downloads, decoding and rendering all affect timing. The largest visible image can arrive late because the browser discovers it late, even when the file is small.
Use the LCP guide to identify which stage needs work. The calculator is useful for comparing transfer changes, but it cannot predict the resulting LCP or Lighthouse score from file sizes alone.
Compare the resource selected for the same viewport and device conditions before and after the change. A page may offer several candidates through srcset, and the browser may choose different files on a high-density display.
Inspect the actual request in browser tools. The image optimization guide explains how sizes, candidate widths and the rendered slot work together. Keep separate calculations where mobile and desktop pages download materially different assets.
Use it as a planning scenario. Record the assumed page views, the image set and whether caching or partial loading makes the full-download assumption unrealistic. Do not describe the estimate as a measured bill reduction or a guaranteed business saving.
After deployment, compare actual transfer and user-experience measurements where available. Preserve image quality, informative alternative text and stable dimensions while making the delivery more efficient.
A smaller file helps only when the browser receives the right image at the right time.
The largest image is not always the problem; the delay before it starts loading can matter more.