How to optimise images for websites

On a typical content page, images are the largest thing being downloaded — usually by a wide margin. They are also what the Largest Contentful Paint measurement tends to land on, so the biggest image above the fold effectively is your loading time as far as Core Web Vitals is concerned.

The good news is that image optimisation is one of the few performance jobs with no architectural risk. Nothing needs rewriting; the files just get smaller.

The most common waste by far is a 4000px camera file displayed in a 700px column. Nothing downstream can recover from that.

• Find the widest CSS width the image is actually displayed at.
• Export at roughly twice that, so it stays sharp on high-density screens.
• If you can serve multiple sizes with srcset, do — phones should not download the desktop file.

The resizer handles a folder in one pass with the ratio locked; the reasoning behind the two-times rule is in image resolution explained.

Format is a per-image decision, not a site-wide setting.

• Photographs — WebP, with JPG as the fallback if you support very old clients. JPG to WebP.
• Logos, icons, UI screenshots — lossless WebP or PNG. Never JPG: hard edges are exactly what lossy compression handles worst. PNG to WebP.
• Simple shapes and icons — SVG, if you have the vector. It scales perfectly and is usually tiny.

The full comparison, and whether AVIF is worth adding.

After resizing and choosing a format, compression is the last squeeze — not the first move. Something in the 75–85 band suits most delivery work; thumbnails tolerate less.

Compress the exported copy, not the master, and do it once. Every extra lossy save compounds the damage, which is why generation loss happens. The JPG and PNG compressors show the before and after size per file, so you can see which images are actually carrying the weight.

Half of what makes images feel fast is not the file at all.

• Always set width and height (or an equivalent aspect-ratio style). Without them the browser cannot reserve space, and the page jumps as each image arrives — the main cause of layout shift.
• loading="lazy" on images below the fold, and never on the one at the top: lazy-loading your hero delays the exact thing being measured.
• fetchpriority="high" on the hero, so it is not queued behind less important requests.
• Serve with a long cache lifetime and a versioned filename, so repeat visits pay nothing.

• Alt text that describes the image for someone who cannot see it. Write the sentence you would say aloud. Decorative images take an empty alt="" so screen readers skip them — that is correct, not lazy.
• Descriptive filenames. slate-roof-detail.jpg tells a crawler something; IMG_4821.jpg does not. Rename before export.
• Surrounding text. Image search leans heavily on the caption, heading and copy nearest the image. An image dropped into an unrelated block of text is hard to interpret.
• One canonical location. The same image at four URLs splits any signal it might have earned.

Do not keyword-stuff alt text

Alt text is an accessibility feature first. A description that reads as a keyword list serves nobody, and is trivially recognisable as such.

1. Resize to about twice the displayed CSS width.
2. Choose the format from the content, not from habit.
3. Compress once, in the 75–85 band, and check the worst image.
4. Set width and height on every <img>.
5. Lazy-load below the fold; prioritise the hero.
6. Write real alt text and a descriptive filename.
7. Cache aggressively with versioned URLs.

Steps one to three run in a browser with no upload from the tools index; the rest belong in whatever builds your pages.