# Image optimization for the web: size, format, compression and loading

> Image optimization means sending each visitor the smallest image file that still looks right, at the right moment. The four levers, the order to use them and the tools to check.

Updated 2026-09-26 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/image-optimization

Image optimization is sending every visitor the smallest image file that still looks right on their screen, at the moment they need it. In practice that means four things: the right pixel size, the right format, sensible compression and the right loading behaviour. Images are usually the heaviest part of a web page and often the largest element on screen, so optimizing images for the web is one of the quickest ways to make a page faster. This guide is for site owners, marketers and developers: it explains each lever, the order to use them, how to check every image on a page, and how to make your CMS do the work so the problem does not come back.

## Quick answer

- **Size first:** export each image at the width it is displayed, times two for high-density screens at most. A 4000-pixel camera photo in an 800-pixel column is the most common waste.
- **Format second:** photos as WebP or AVIF, logos and icons as SVG, screenshots with sharp text as lossless WebP or PNG.
- **Compress third:** lossy at around quality 75–80 for WebP and JPEG looks the same as the original for most photos at the size they are shown.
- **Load at the right moment:** `loading="lazy"` on images below the fold, never on the main image at the top, and `width` and `height` on every `<img>`.
- **Serve several sizes** with `srcset` and `sizes`, so phones do not download the desktop file.
- **Automate it** with your CMS, an image plugin or an image CDN, then check the result with the free [image size checker](https://getreport.app/tools/image-size-checker).

## What is image optimization?

Image optimization is the set of changes that reduce the bytes an image costs a visitor, and the time it takes to appear, without a visible loss of quality. It is not one setting. Each of the four levers removes a different kind of waste:

| Lever | The waste it removes | Typical fix |
| --- | --- | --- |
| **Pixel size** | Pixels the screen never shows | Resize to the displayed width (×2 for sharp screens) |
| **Format** | An old encoding that stores the same picture less efficiently | WebP or AVIF for photos, SVG for line art |
| **Compression** | Detail the eye cannot see at that size | Lossy quality around 75–80, metadata stripped |
| **Delivery and loading** | Images fetched too early, too late or twice | `srcset`, lazy loading below the fold, `fetchpriority` on the hero, long cache lifetimes |

They multiply. A photo that is resized, converted and compressed can end up a small fraction of the original upload, and doing only one of the three leaves most of the saving on the table.

Image optimization for search engines, meaning alt text, file names and image sitemaps, is a related but separate job. It is covered briefly in the section on image SEO below.

## Why optimize images for your website?

**Speed.** On many pages the largest thing on screen is an image: the hero banner, the product photo, the article's lead picture. That makes it the Largest Contentful Paint element, the Core Web Vital Google uses for loading, where good is 2.5 seconds or less. A heavy hero image alone can push a page past that on a phone. The [page speed guide](https://getreport.app/guides/page-speed) shows where images sit among the other causes of a slow page.

**Stability.** An image without `width` and `height` has no reserved space, so the text below jumps when the file arrives. That jump counts towards Cumulative Layout Shift, another Core Web Vital.

**Your visitors' data and battery.** Every byte you send is paid for by someone on a mobile plan, and decoding a huge image costs processor time on older phones.

**Search.** Google ranks pages partly on Core Web Vitals from real visitors, and Google Images is a traffic source of its own for shops, recipes and travel sites. Google's image SEO documentation lists the formats it can index: BMP, GIF, JPEG, PNG, WebP, SVG and AVIF.

## How to check the images on a page

Start with numbers, not guesses. You want, for every image: the file size, the format, the real pixel dimensions, the size it is displayed at, and whether it has `width`, `height` and the right `loading` attribute.

> **Free tool:** [Image size checker: find heavy images on a page](https://getreport.app/tools/image-size-checker): Free image size checker: list every image on a page with file size, format, real and displayed dimensions, and find the heavy files that slow it down.

The image size checker requests up to 100 images from the page and lists each one with its file size, format, real and displayed dimensions. It flags files over 300 KB, images served at more than twice their displayed size, images without width and height, and images that fail to load. It also loads the page in Chromium to total the image weight, including CSS background images, and adds Lighthouse's estimates for modern formats and sizing.

> **Check: Heavy image files.** A single image over a few hundred kilobytes takes longer to download on mobile than the rest of the page. Uploading the original camera file is the usual cause.
>
> 1. Export each listed image at the size it is displayed and save it as WebP or AVIF at about 80 % quality.
> 2. Let your CMS or CDN resize on upload so this does not come back with the next photo.

> **Check: Every sized image is served close to its displayed size.** Sending a 1600-pixel photo for a 300-pixel slot downloads about 28 times more pixels than needed. The browser scales it down and the visitor pays for the difference.
>
> 1. Resize the listed images to the largest size they are shown at (twice that for high-density screens).
> 2. Use srcset with several sizes so phones get a smaller file than desktops.

> **Check: Every image declares width and height.** Without width and height the browser cannot reserve space, so the text jumps when each image arrives. That is the most common cause of a poor Cumulative Layout Shift score.
>
> 1. Add width and height attributes with the image's real proportions; CSS can still scale it.
> 2. In WordPress, recent versions add them automatically for images inserted through the editor; hard-coded theme images need them by hand.

The full getReport report and the [website speed test](https://getreport.app/tools/speed-test) include the same image findings next to everything else that slows a page, so you can see whether images are the main problem or one of several.

> **Check: Total image weight.** Images are usually the heaviest part of a page. Over 1.5 MB in total, or a single image over 500 KB, adds seconds on mobile and costs visitors real data.
>
> 1. Resize images to the size they are shown at (a 400 px wide photo does not need a 4000 px file).
> 2. Convert to WebP or AVIF and compress to about 80 % quality; CMS plugins and CDNs can do this automatically.

For a quick look without a tool, open your browser's developer tools, go to the Network panel, filter by Img, reload and sort by size. The fix pages on [image weight](https://getreport.app/learn/image-weight) and [image sizing](https://getreport.app/learn/image-sizing) explain each finding in plain language.

## Step 1: Pick the right pixel size

The biggest saving usually comes from resizing, because file size grows with the number of pixels. A 1600-pixel-wide photo shown 300 pixels wide carries about 28 times the pixels the slot can display (1600 × 1600 ÷ 300 ÷ 300, for a square image). The browser downloads all of them and then throws most away.

Export each image at the widest size it is shown at on your site, and at most twice that for high-density ("retina") screens. A full-width hero rarely needs more than about 2000 pixels; a content image in an 800-pixel column needs about 1600 at most; a thumbnail needs a few hundred.

The guide to [image sizes that do not hurt](https://getreport.app/guides/image-sizes-that-do-not-hurt) gives pixel and file-size targets for heroes, content images and thumbnails, and shows how to read the "Pixels" and "Displayed" columns of the checker. If you only fix one thing, fix the pixel size of the largest images first.

> **Check: Images are sized for how they are displayed.** Sending a 2000 px photo to a 400 px slot wastes most of the bytes. Responsive images let the browser pick the right size for each screen.
>
> 1. Add srcset and sizes to <img> so phones get small versions; most CMSs generate the sizes for you.
> 2. Resize the originals to the largest size you actually display.

## Step 2: Choose the right format

The format decides how efficiently the same pixels are stored. There are five you will meet:

| Format | Use it for | Avoid it for |
| --- | --- | --- |
| **JPEG** | Photos where WebP or AVIF is not an option; email; Open Graph images | Anything with transparency or sharp text |
| **PNG** | Screenshots and graphics that need exact pixels or transparency, when WebP is not an option | Photos (files get very large) |
| **WebP** | Almost everything raster: photos (lossy) and graphics (lossless), with transparency | Nothing in current browsers; some older desktop software cannot open it |
| **AVIF** | Photos where every kilobyte counts, such as heroes and product images | Very large batches if your tooling encodes slowly |
| **SVG** | Logos, icons, simple illustrations and diagrams | Photos |

Google's WebP documentation reports that lossy WebP images are 25–34 % smaller than comparable JPEGs at equivalent SSIM quality, and lossless WebP images 26 % smaller than PNGs. AVIF often compresses photos further again, most visibly at low and medium quality, but results vary by image: try both on a typical photo of your own. WebP and AVIF work in all current versions of Chrome, Edge, Firefox and Safari.

The guide to [modern image formats: WebP, AVIF and when JPEG is still fine](https://getreport.app/guides/modern-image-formats-webp-avif) covers the quality settings per format, the `<picture>` fallback and how CMSs and CDNs convert automatically.

> **Check: Images are served in modern formats (WebP or AVIF).** WebP and AVIF are 25–50 % smaller than JPEG and PNG at the same quality. Smaller images load faster and cost visitors less data.
>
> 1. Convert images to WebP or AVIF and serve them with <picture> or content negotiation.
> 2. WordPress: enable WebP/AVIF in your image plugin or CDN (Imagify, ShortPixel, Cloudflare Polish); Shopify does this automatically for its CDN.

### JPEG vs PNG

The oldest choice still causes the most waste: photos saved as PNG and logos saved as JPEG. JPEG is lossy and suits photos and smooth gradients; PNG is lossless and suits flat graphics with sharp edges, text or transparency. A photo stored as PNG is usually several times the size of the same photo as a JPEG, with no visible gain.

On a website, the same split still decides the kind of compression, but the containers have moved on: photos as WebP or AVIF, graphics as lossless WebP, logos as SVG. JPEG and PNG stay the right choice for the Open Graph image, email and downloads. The comparison of [JPEG vs PNG for photos, graphics and transparency](https://getreport.app/guides/jpeg-vs-png) explains how each format works, PNG-8 versus PNG-24, and how to convert between them.

### What WebP and AVIF are

WebP is an image format Google released in 2010 that handles photos, graphics, transparency and animation in one format. Every current browser, Windows, macOS and the main image editors open it. The explainer on [what a WebP file is and how to open or convert one](https://getreport.app/guides/what-is-webp) covers why images download as `.webp`, WebP vs JPG and PNG, and browser support.

AVIF is a newer, royalty-free format that stores images with the AV1 video codec in the HEIF container. It compresses photos further than JPEG, often further than WebP, and adds HDR, but encodes slowly and some older software still cannot open it. The guide to [what an AVIF file is](https://getreport.app/guides/what-is-avif) explains how to open and convert AVIF files, how it differs from HEIC, and browser support by version. For choosing between the two formats on your own site, use the modern formats guide above.

## Step 3: Compress without visible loss

Compression decides how much detail each format keeps. There are two kinds:

- **Lossy** compression throws away detail the eye is unlikely to notice. It is what makes photos small. JPEG, lossy WebP and AVIF work this way.
- **Lossless** compression stores every pixel exactly and only packs the data more tightly. It suits screenshots, diagrams and graphics with text. PNG and lossless WebP work this way.

For photos, a lossy quality around 75–80 for WebP and JPEG, and a lower number for AVIF (whose scale is not the same), usually looks identical to the original at the size the image is shown. Judge the result at the displayed size; if you see smearing or blocks, raise the quality by five and try again. Also strip metadata: camera EXIF data adds bytes and can include the GPS location where a photo was taken.

The step-by-step guide on [how to reduce image file size without losing visible quality](https://getreport.app/guides/how-to-reduce-image-file-size) puts resizing, compression, format and metadata in order, with a quality table per format and the exact steps in the Windows Photos app, Paint, Mac Preview, ImageMagick and cwebp. Use it for a single image or a folder before upload.

Which kind to use is a per-image decision. Lossy wins for anything photographic, because a photo's fine noise has no pattern for lossless compression to pack, while a lossy encoder removes it unseen. Lossless wins for screenshots with small text, flat-colour graphics, pixel art and master files, where lossy compression adds halos around edges and every re-save loses a little more.

The explainer on [lossy vs lossless compression](https://getreport.app/guides/lossy-vs-lossless-compression) shows how each works (PNG's filters and DEFLATE, JPEG's chroma subsampling and quantisation), which formats use which mode, the in-between options such as palette-reduced PNG and near-lossless WebP, and the encoder commands for each.

> **Free tool:** [Image compressor: WebP and AVIF, no upload](https://getreport.app/tools/image-compressor): Free image compressor for up to 50 JPEG, PNG or WebP images. Convert to WebP, AVIF or a smaller JPEG. Your files stay on your computer; nothing is uploaded.

The image compressor converts up to 50 JPEG, PNG or WebP images at a time to WebP, AVIF or a smaller JPEG, scaled down to the longest side you choose. It runs in your browser with the WebAssembly builds of libwebp, libavif and MozJPEG, the codecs Google's Squoosh uses, so your files are never uploaded. When the new file would be larger than the original, it keeps the original.

## Step 4: Serve the right size to every screen

A single file cannot suit a 360-pixel phone and a 2560-pixel monitor. Responsive images solve that: you list several widths of the same image in `srcset`, describe how wide the image is displayed in `sizes`, and the browser picks the smallest file that will look sharp.

```html
<img
  src="https://getreport.app/img/sofa-800.webp"
  srcset="/img/sofa-400.webp 400w, /img/sofa-800.webp 800w, /img/sofa-1600.webp 1600w"
  sizes="(max-width: 700px) 100vw, 700px"
  width="1600" height="1067"
  alt="Grey three-seat sofa with oak legs">
```

Without `sizes`, the browser assumes the image fills the whole screen width and often picks a larger file than needed. Most CMSs generate the widths for you; WordPress, for example, adds `srcset` to images inserted through the editor. The guide to [srcset and sizes explained with real numbers](https://getreport.app/guides/responsive-images-srcset-and-sizes) works through a three-breakpoint example with the real pixel counts.

## Step 5: Load each image at the right moment

When an image loads matters as much as how much it weighs.

**Lazy-load what is below the fold.** `loading="lazy"` tells the browser to wait until an image is near the viewport. On a long page, the images far down no longer compete with the ones the visitor sees first. All current browsers support it natively, and WordPress has added it by default since version 5.5.

**Never lazy-load the main image.** The hero or product photo at the top should load as early as possible. Lazy loading it delays the Largest Contentful Paint. Add `fetchpriority="high"` to that one image instead, so the browser fetches it before less important files; WordPress 6.3 and later adds it automatically to the image it judges most likely to be the LCP element.

**Always set width and height.** The attributes let the browser reserve the right space before the file arrives, so nothing jumps. Set them to the image's real pixel size or its ratio, and let CSS scale it with `height: auto`.

**Cache images for a long time.** Images rarely change at the same URL. A long `Cache-Control` lifetime means returning visitors do not download them again.

The guide on [lazy loading done right](https://getreport.app/guides/lazy-loading-done-right) covers what to lazy-load, what never to, iframes and how WordPress and plugins handle it.

> **Check: Offscreen images are lazy-loaded.** Images far below the fold compete for bandwidth with the ones visitors see first. Lazy loading defers them until they scroll into view.
>
> 1. Add loading="lazy" to images below the fold — but never to the hero/LCP image.
> 2. WordPress adds it by default since 5.5; check your theme or slider has not removed it.

> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with <link rel="preload" as="image"> or add fetchpriority="high" on the <img>.
> 3. Cut what comes before it — render-blocking CSS/JS and slow server responses push LCP back.

## Step 6: Automate it so it stays fixed

Optimizing images by hand works once. The next upload from a phone undoes it. Put the work where uploads happen.

### Image optimization plugins for WordPress

WordPress already creates several sizes of every upload, scales originals down to 2560 pixels on their longest side (since version 5.3), accepts WebP uploads since 5.8 and AVIF uploads since 6.5 when the server supports them. A plugin adds compression and automatic conversion to WebP or AVIF. The plugins differ mainly in where the processing runs (your server or theirs), what they charge and whether they also serve the right size. The honest comparison of [image optimisation plugins](https://getreport.app/guides/image-optimisation-plugins-compared-honestly) explains the trade-offs and what no plugin fixes, such as a 4000-pixel background set in a page builder.

### Image CDNs and on-the-fly resizing

An image CDN keeps one high-quality master and produces each size and format on request, from parameters in the URL, then caches the result near the visitor. It suits sites with many images or many layouts, at the cost of a monthly bill and one more dependency. The guide to [image CDNs and on-the-fly resizing](https://getreport.app/guides/image-cdns-and-on-the-fly-resizing) compares that with generating sizes at build time.

### Hosted platforms

**Shopify** resizes images and serves modern formats from its own CDN; your job is uploading sensibly sized originals and using the theme's `image_url` filter with a width, so templates do not request the full-size file. **Wix and Squarespace** convert and resize automatically, but still benefit from uploads that are not straight from a camera. **Cloudflare** can compress and convert images with Polish on its Pro plan and above, and resize them on request with image transformations, which the Free plan includes up to 5,000 unique transformations a month (Cloudflare's Images documentation). Check what your plan includes before relying on it.

## Image SEO: alt text, file names and Google Images

The optimization above is about speed. For search, three more things help Google understand and show your images:

- **Alt text** that describes the image in context. It is what screen readers announce and what Google reads to understand the image. Decorative images get an empty `alt=""`.
- **Descriptive file names**, such as `grey-three-seat-sofa.webp` rather than `IMG_0423.jpg`. Google's image documentation describes them as a light signal.
- **Images in HTML `<img>` elements**, not only as CSS backgrounds, which Google does not index as images; an image sitemap helps Google find images it might otherwise miss.

The guide to [image alt text for SEO and accessibility](https://getreport.app/guides/image-alt-text-for-seo-and-accessibility) shows how to write alt text for decorative, informative and functional images, including logos, product photos and charts.

> **Check: Every image has an alt attribute.** Alt text is how Google Images and screen readers understand a picture. Missing alt text loses image traffic and fails accessibility.
>
> 1. Describe each meaningful image in a short alt attribute ("Blue running shoe, side view").
> 2. Give purely decorative images an empty alt="" so screen readers skip them.

## How to verify the result

1. Re-run the image size checker on the same page. The heavy-files and oversized findings should be gone or reduced to images you chose to keep.
2. Run the speed test on mobile and look at LCP and the image opportunities; the savings estimates should have shrunk.
3. Open the page on a real phone on mobile data. The main image should appear quickly, and nothing should jump as you scroll.
4. After four weeks, check the real-visitor LCP in the speed test or in Search Console's Core Web Vitals report, since field data covers the last 28 days.

## Common mistakes

- **Uploading straight from the camera or a stock site.** Several megabytes and 5000 pixels for an image shown 800 pixels wide. Resize before or on upload.
- **Lazy-loading the hero.** A slider or theme setting that lazy-loads every image makes LCP slower. Exclude the first image.
- **Converting to WebP but not resizing.** A 4000-pixel WebP is smaller than a 4000-pixel JPEG and still far too big.
- **Compressing the same file again and again.** Each lossy save loses more detail. Keep a high-quality original and export from it.
- **Using PNG for photos.** Lossless storage of a photo produces huge files. Use WebP, AVIF or JPEG.
- **Removing width and height to "make images responsive".** CSS can scale an image with the attributes in place; without them, the layout jumps.
- **Running two image plugins.** They fight over the same files and can double-convert. Pick one.

## Questions people ask

### What are the steps to optimize images for a website?

Resize, convert, compress, then load them correctly. Export each image at the width it is displayed (at most twice that for sharp screens), save photos as WebP or AVIF and logos as SVG, compress photos at around quality 75–80, and add width, height and lazy loading below the fold. Finish by letting your CMS or an image plugin do the same for every new upload.

### What is image optimization?

Image optimization is reducing how many bytes an image costs and how long it takes to appear, without a visible loss of quality. It combines four levers: the right pixel size, an efficient format such as WebP or AVIF, sensible compression, and loading each image at the right moment. The aim is faster pages, especially a faster Largest Contentful Paint on phones.

### Does image optimization affect SEO?

Yes, indirectly through speed and directly through image search. Heavy images slow Largest Contentful Paint, one of the Core Web Vitals Google uses in ranking, and lighter pages keep more visitors. For Google Images, descriptive alt text, sensible file names and images placed in HTML img elements help Google understand and show them. Optimize for speed first, then add alt text.

### Does optimizing images reduce their quality?

Not visibly, when done with sensible settings. Resizing removes pixels the screen could never show, and modern formats store the same picture more efficiently. Lossy compression does discard detail, but at around quality 75–80 for WebP or JPEG most photos look identical at their displayed size. Check detailed areas such as text or hair, and keep your original so you can export again.

### Which images should I optimize first?

Start with the largest image at the top of your most visited pages, because it is often the Largest Contentful Paint element. Then fix any single file over 300 KB and any image served at more than twice its displayed size. An image size checker sorts a page's images by file size, so the top three rows usually hold most of the saving.

### Should I resize images before uploading them or let the CMS do it?

Both, ideally. Resizing before upload keeps oversized originals off your server and out of every backup, and avoids a theme or page builder accidentally using the full file. Letting the CMS or an image plugin generate sizes and modern formats catches the uploads that slip through. If you can only do one, set up the automatic route, because it applies to every future image.

### Do I need an image optimization plugin on WordPress?

Usually yes, if you want automatic compression and WebP or AVIF for every upload. WordPress already creates several sizes, adds srcset and lazy loading, and caps originals at 2560 pixels, but it does not compress aggressively on its own. One plugin is enough; two fight over the same files. The Modern Image Formats plugin from the WordPress performance team is a free starting point.
