How to cut 40% off page load time by auditing images and choosing the right next-gen formats

Why images are the low-hanging fruit for faster pages

Images are often the single biggest contributor to page weight. On many sites I audit, a handful of hero images and unoptimized thumbnails make up 40–60% of total bytes. That means you can get dramatic speed wins by focusing on images before tackling JavaScript or server infrastructure.

In my own projects I’ve repeatedly seen a 30–50% reduction in page load time simply by auditing what images are used, re-encoding them with modern formats, and serving appropriately sized files. The process is straightforward, repeatable, and—importantly—measurable. Below I’ll walk through how I approach an image audit and the practical steps to adopt next‑gen formats like WebP and AVIF without breaking browsers or workflows.

Start with measurement: find the image offenders

Don’t guess. Run an audit to identify the worst offenders.

• Use Lighthouse (in Chrome DevTools) to get a quick overview of network weight and which image files are largest.
• Open the Network tab and sort by size to see which images consume the most bytes, then filter to “Img”.
• Use WebPageTest for a timeline of asset loading and filmstrip views—this helps identify render-blocking or late-loading images.
• Grab a HAR file and analyze it if you need to script audits across many pages.

Record the biggest images and note where they appear: hero banners, background images, gallery items, or icons. These will be your priorities.

Audit checklist: what to look for

• Oversized images: Files that are larger in pixel dimensions than they’re served. Example: a 4000px-wide JPG used as a 1200px hero.
• Wrong format: PNGs used for photos, or uncompressed TIFF/BMPs leaking into the build.
• High quality settings: JPEGs saved at 100–95% quality when 75–85% would be visually similar but much smaller.
• Unnecessary transparency: PNGs with alpha where a JPEG or WebP would suffice.
• Duplicated images: Same asset embedded at multiple sizes or paths.
• No responsive sources: Single-size images without srcset/picture to serve smaller images to mobile.
• No lazy-loading: Loading below-the-fold images eagerly.

Choosing next-gen formats: WebP vs AVIF (and JPEG/PNG fallbacks)

Next-gen formats change the game because they deliver the same visual quality at much smaller sizes. Here’s a practical comparison I use when deciding which to adopt:

I usually recommend a progressive rollout:

• Generate WebP for most images because it has broad support and fast encoding.
• Use AVIF for key high-res photography where you want the biggest savings and can afford longer encoding time.
• Keep JPEG/PNG as fallbacks for older browsers if you need universal compatibility.

Implementation patterns that work

How you serve next-gen images matters as much as which format you choose.

• Picture element with type-based sources

  Example pattern:

  <picture>
    <source srcset="hero.avif" type="image/avif">
    <source srcset="hero.webp" type="image/webp">
    <img src="hero.jpg" alt="..." loading="lazy" decoding="async">
  </picture>

• Srcset & sizes for responsive images

  Provide multiple widths so the browser picks the smallest adequate image. Example: srcset="img-400.webp 400w, img-800.webp 800w, img-1200.webp 1200w" and sizes="(max-width: 600px) 100vw, 1200px".

• Lazy-loading and native hints

  Use loading="lazy" and fetchpriority for critical images (fetchpriority="high" for hero images in critical viewport). Avoid lazy-loading above-the-fold content.

• Content Delivery & image CDNs

  Use an image CDN (Cloudinary, Imgix, Fastly Image Optimizer, BunnyCDN, or the built-in features of Netlify/Vercel) to auto-convert formats on the fly, resize per device, and cache aggressively.

• Automated build optimizations

  In your build pipeline use tools like Sharp, Squoosh CLI, image_optim, or imagemin to generate WebP/AVIF variants and optimized JPEGs. If you use Next.js, Gatsby, or Eleventy, enable their image plugins to handle srcset generation.

Encoding settings and visual testing

Quality is subjective. I recommend encoding samples at different quality settings and inspecting them visually and with metrics (PSNR/SSIM if you want to be thorough).

• For JPEG: try quality 75–85 as a starting point.
• For WebP: quality 70–80 usually balances size and fidelity.
• For AVIF: quality 40–60 often yields dramatic savings with acceptable artifacts.

I use Squoosh.app for quick, visual comparisons and scripts with sharp or avifenc for batch processing. Don’t rely solely on file size—open images at 100% and 200% to check for banding or detail loss in critical areas like faces and product shots.

Automating everything: CI and developer tooling

Manual optimization is fine for small sites, but you want automation as projects grow.

• Integrate an image processing step in your CI that takes source assets and outputs optimized formats + metadata (widths/heights) to commit to the build or to upload to a CDN.
• Use npm packages like sharp, @squoosh/lib, or imagemin in build scripts.
• Consider serverless functions or an image CDN that converts on-the-fly so you can keep originals while delivering optimized variants dynamically.

Measuring the win

After changes, measure before and after:

• Re-run Lighthouse and WebPageTest to track total bytes, Largest Contentful Paint (LCP), and Speed Index.
• Check Core Web Vitals in real traffic (Chrome UX Report or your analytics provider) for real-world impact.
• Track conversion metrics and bounce rate where applicable—smaller images often improve engagement on slower connections.

In projects where I applied these steps, LCP often dropped by 30–60% and overall page weight dropped by 40% or more. That translates to faster perceived load times and better mobile experiences—especially on cellular networks.

Common pitfalls and how to avoid them

• Serving modern formats without fallbacks: Use picture or server-side content negotiation so older browsers still get images they can display.
• Encoding everything at once without testing: Start with the largest, highest-impact images first and verify visual quality.
• Neglecting caching headers: Optimized images should be cached aggressively—set long cache lifetimes and use cache-busting on deploy.
• Forgetting responsive art direction: Sometimes cropping a different focal area for mobile is better than simply scaling—use source selection wisely.

Optimizing images is one of the highest-leverage performance improvements you can make. With a simple audit, some modern formats, and automated tooling, you can shave off large chunks of page load time and deliver a noticeably faster experience to users.