Image optimisation guide

Why it matters

Images are usually the largest single source of page weight. On a typical marketing site they outweigh every script, stylesheet, and font combined. Optimising images is the cheapest and most predictable way to improve LCP, reduce bandwidth, and speed up mobile pages. The full chain is: right format, right size, right compression, and fast delivery.

Choose a format

• JPEG: photographs and anything with gradients. Compress well, no transparency.
• PNG: graphics with transparency and sharp edges. Heavy at large sizes.
• WebP: the modern default. Good compression for photos and graphics, supports transparency, and every current browser supports it.
• AVIF: often slightly smaller than WebP for the same quality, with a wider but still growing support story. Use it when your stack and server can serve it with WebP fallback.
• SVG: logos, icons, simple diagrams. Vector, infinitely scalable, tiny. Never use it for photos.

Rule of thumb: if it is a photo, use a modern format such as WebP or AVIF; if it is a graphic, use a modern format if it helps, otherwise keep PNG; if it is an icon or logo, use SVG.

Compress

Compress at export time, not in the browser. Tools such as cwebp, oxipng, pngquant/optipng, jpegtran, svgo, and sharp produce files a fraction of the original. Target a quality that is visually indistinguishable, usually around quality 75 to 85 for JPEG and WebP photos. A 2.4 MB photo becomes roughly 200 to 400 KB in WebP without visible loss.

Set concrete thresholds and guard them in the build: if an original is over about 1 MB, warn or convert automatically, because a hero image over about 500 KB is almost always a mistake.

Deliver fast

• Resize to the largest render size you actually use. Serving a 4000px-wide photo into a 1200px container wastes everything downstream.
• Use srcset with sizes so mobile devices download the small file, not the hero.
• Add width and height or CSS aspect-ratio so the browser reserves space and CLS stays low.
• Lazy-load below-the-fold images with loading="lazy", but keep the hero eager so LCP is not delayed. Decode hero images with fetchpriority="high".
• Cache images long-term with far-future cache headers and a content hash in the URL so caches never serve a stale version after a change.
• Serve from a CDN or the same static CDN as the site, so image requests are not a round trip to a slow app server.

Verify

After re-exporting, compare the new page weight and LCP in Lighthouse or PageSpeed Insights against the baseline from the same tool. A good check: total page weight should drop, and the hero image should be the image doing the least wasted work. Re-run after every asset change because these gains evaporate the moment a designer uploads a raw export into the CMS.