Why image optimisation matters more than anything else
I have audited dozens of slow websites, and the cause is images more often than anything else — slow JavaScript, render-blocking CSS, or poor server response times. Images typically account for 50–70% of a page's total download weight. An unoptimised homepage that should weigh 350KB often weighs 6–10MB because someone uploaded raw phone photos and called it done.
The difference in user experience is enormous. A 6MB page might load in 8–12 seconds on a mobile connection. The same page with properly optimised images loads in under a second. Google uses page speed as a ranking signal, and users abandon pages that take more than 3 seconds to load — so this directly affects both SEO and bounce rate.
Step 1: Choose the right format before compressing
Different image formats are optimised for different types of content. Using the wrong format can cost you 5× the file size compared to using the right one.
Photographs and complex images: Use WebP as your primary format with JPEG as a fallback. WebP produces files 25–35% smaller than JPEG at equivalent visual quality. AVIF is even better (40–60% smaller) but has less browser support as of 2026, so always include a fallback.
Logos, icons, and illustrations with flat colours: Use SVG if the image is vector-based. An SVG logo is typically 3–20KB and scales to any size perfectly. A PNG equivalent might be 50–200KB.
Screenshots and images with text: Use PNG or WebP. JPEG compression introduces artefacts around text that make it unreadable at small sizes.
Animated images: Use WebP animation or video (MP4) instead of GIF. An animated GIF can be 10–50× larger than an equivalent MP4. Videos also play smoother and support audio.
iPhone HEIC photos for web: Convert to JPG or WebP first. HEIC is not widely supported in browsers and will either fail to display or use a browser's fallback renderer. My HEIC converter handles this locally without any upload.
Step 2: Resize to actual display dimensions
This is the single most impactful optimisation and the one most often ignored. If your website displays an image at 800px wide, there is absolutely no reason to serve a 4000px image. The browser downloads the full 4000px version and then scales it down — wasting bandwidth and slowing load time for zero visual benefit.
A 4000×3000px photo from a modern smartphone is typically 8–12MB. Resized to 800×600px, the same quality JPEG is 80–150KB. That is a 50–100× size reduction from resizing alone, before any compression is applied. Always resize to the maximum display size of the image (accounting for 2× retina displays — if the image displays at 800px, resize to 1600px for retina).
Step 3: Compress at the right quality level
Compression quality levels are not linear in their impact on file size. For JPEG, moving from 100% quality to 85% quality often halves the file size with no visible difference to the human eye. Moving from 85% to 70% cuts size by another 30–40%, and there starts to be visible artefacting on detailed areas like hair and grass. Below 70%, artefacts become obvious.
My general rule: start at 82% quality for photographs, check at full resolution, and only go lower if the file is still too large. For WebP, slightly lower quality settings (75–80%) can produce excellent results because WebP's compression algorithm is simply better than JPEG's at the same numerical quality level.
Step 4: Use responsive images in HTML
Serving the same image to a 320px mobile screen and a 1920px desktop monitor is wasteful. The picture element in HTML lets you specify different image sources for different screen sizes and formats:
<picture>
<source srcset="photo-800.webp 800w, photo-1600.webp 1600w" type="image/webp">
<img src="photo-800.jpg" srcset="photo-800.jpg 800w, photo-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 800px" alt="...">
</picture>The browser picks the appropriate size and format automatically. Mobile users download the small version; retina desktop users get the large one; browsers without WebP support fall back to JPEG. This is the gold standard for image delivery.
Step 5: Add lazy loading
Images below the visible viewport (below the fold) do not need to load immediately — the user has not scrolled to them yet. The loading="lazy" attribute tells the browser to defer loading until the user is about to scroll the image into view:
<img src="article-photo.jpg" loading="lazy" alt="...">This is supported in all modern browsers, requires no JavaScript, and can dramatically reduce initial page load time for long pages with many images. The only image that should not be lazy loaded is the hero image at the top of the page — that one should load as fast as possible, so leave it without the attribute.
Step 6: Consider a CDN with automatic optimisation
If you host images on a CDN that supports on-the-fly image transformation (Cloudflare Images, Imgix, Cloudinary), you can often skip manual optimisation entirely. These services automatically convert to WebP, resize to the requested dimensions, and compress intelligently — all on the CDN edge, close to the user. The cost is usually worth it for high-traffic sites.
Quick results in practice
A typical before/after for a homepage: raw iPhone photos uploaded directly → 14MB page weight, 8-second load. After format conversion, resizing, and compression → 420KB page weight, 0.6-second load. That is a 33× improvement in file size and a 13× improvement in load time from applying these techniques for a couple of hours.