Why Your Website Images Are Slowing You Down (And How to Fix It)

Images are the single largest contributor to page weight on most websites. According to HTTP Archive data, the median web page transfers about 1MB of images. For e-commerce sites, that number is often 2–4MB. And the majority of that weight is avoidable.

This guide is for developers and technically-minded site owners who want to understand not just what to do, but why it works. We'll cover the full picture: file formats, dimensions, lazy loading, CDN delivery, and the Core Web Vitals metrics that actually matter for rankings.

Why image performance matters more in 2026

Google's Core Web Vitals have been a ranking factor since 2021. The metric most directly tied to images is Largest Contentful Paint (LCP) — the time it takes for the main content of a page to become visible.

LCP benchmark:

• ✅ Good: under 2.5 seconds
• ⚠️ Needs improvement: 2.5–4 seconds
• ❌ Poor: over 4 seconds

If your above-the-fold content includes a large image (hero photo, product image, banner), that image is your LCP element. Optimising it is directly optimising your search ranking.

Beyond ranking, there's the user experience reality: 53% of mobile users abandon a page that takes longer than 3 seconds to load. On slower mobile connections common across Pakistan, India, and much of Southeast Asia, this gap is even more pronounced.

The four levers of image optimisation

1. Right format

This is the fastest win. Switching from JPEG to WebP on an e-commerce product grid typically reduces image weight by 25–35% with no visible quality difference.

Decision table:

Use the <picture> element to serve modern formats with fallbacks:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="630">
</picture>

2. Right dimensions

Serving a 3000×2000px image in a slot that displays at 600×400px wastes roughly 5x the bandwidth. The browser downloads all 3000 pixels and then scales it down in the render step.

The rule: serve images at 1x–2x their display size. For a 600px wide container, a 1200px wide image covers Retina displays. A 3000px image serves no purpose.

Use srcset to serve different sizes to different screens:

<img
  src="product-600.webp"
  srcset="product-600.webp 600w, product-1200.webp 1200w, product-1800.webp 1800w"
  sizes="(max-width: 768px) 100vw, 600px"
  alt="Product photo"
  width="600"
  height="600"
>

This tells the browser: on small screens, expect a 100% viewport-wide image; on larger screens, expect a 600px slot. The browser picks the best source from the srcset.

3. Right compression level

Compression is a trade-off between file size and visual quality. For most web images, quality levels of 75–85% in JPEG/WebP are indistinguishable from 100% at normal viewing distances.

Signs you're over-compressing:

• Visible blockiness (JPEG artifacts) especially around edges and text
• Colours that look slightly "off" compared to the source
• Fine detail that looks smeared

Signs you're under-compressing:

• Files over 500KB for a typical photo in a web slot
• Files over 200KB for a thumbnail
• JPEG files from a camera or design tool that haven't been optimised at all

A quick benchmark: a 1200×630 OG image (the preview image for social sharing) should be well under 200KB as a WebP. If yours is 800KB, that's a problem.

4. Right loading strategy

Not every image on a page needs to load immediately. Images below the fold — content the user hasn't scrolled to yet — can be deferred.

Lazy loading: Add loading="lazy" to any <img> tag that's below the fold. Modern browsers handle this natively with no JavaScript needed.

<!-- Load immediately (above fold) -->
<img src="hero.webp" alt="Hero" loading="eager">

<!-- Defer loading (below fold) -->
<img src="product.webp" alt="Product" loading="lazy" width="600" height="600">

Critical: don't lazy-load your LCP image. The hero image, above-the-fold product photo, or any image that's visible on first paint should load immediately (loading="eager" or simply no loading attribute). Lazy-loading it will hurt your LCP score.

Preloading the LCP image: For critical above-fold images, add a preload hint in your <head>:

<link rel="preload" as="image" href="hero.webp" type="image/webp">

This tells the browser to start fetching the image before it finishes parsing the HTML.

Next.js image optimisation (for developers)

Since SnapResizer is built with Next.js, this is worth covering specifically. Next.js has a built-in <Image> component that handles several of the above automatically:

import Image from 'next/image'

<Image
  src="/product.jpg"
  alt="Product"
  width={600}
  height={600}
  priority  // Use for above-fold/LCP images
/>

What Next.js Image does for you automatically:

• Converts to WebP for supported browsers
• Generates responsive srcset
• Prevents layout shift (requires width/height)
• Lazy loads below-fold images by default
• Serves from a built-in image optimisation API

What you still need to handle:

• Starting from good source images (correct dimensions, not massively oversized)
• Not importing raw camera photos directly into your project
• Setting priority correctly on your LCP image

If you're not using Next.js, Astro's <Image> component and Nuxt's <NuxtImg> offer similar automatic optimisation.

The e-commerce image problem

Product images are where most sites lose the most weight. A typical product listing page might have 24 product cards, each with a 2000×2000px JPEG straight from a product photographer. That's a disaster.

The right workflow for product images:

1. Start from the original high-res file (keep it archived)
2. Resize to your maximum display size × 2 for Retina (typically 800×800 or 1200×1200)
3. Convert to WebP
4. Store the optimised version in your CDN
5. Let your image component handle the responsive srcset

For sites running Shopify, the CDN handles WebP conversion automatically. For custom builds, Cloudinary and Imgix are worth the cost for high-traffic product catalogues — they generate optimised variants on-demand.

Measuring what you've actually fixed

Before and after any optimisation work, measure with real tools:

Google PageSpeed Insights — Tests your actual URL, gives Core Web Vitals scores, and tells you specifically which images are the problem. Use this first.

WebPageTest — More detailed waterfall chart showing exactly which assets load when and how they affect render.

Chrome DevTools Network tab — Filter by Img to see every image request, its size, and how long it took. Sort by Size descending to find the biggest offenders.

Google Search Console — Core Web Vitals report shows how real users on real devices experience your pages. This is what Google uses for rankings, not lab tests.

A practical checklist

Run through this for any site you're responsible for:

• Run PageSpeed Insights. Note the LCP score and which element is the LCP.
• Check if the LCP image is served as WebP or AVIF
• Check if the LCP image has a <link rel="preload"> hint in the head
• Check that the LCP image is NOT lazy-loaded
• Check all images for width and height attributes (prevents layout shift)
• Find the 5 largest images in the Network tab — are they oversized for their display slot?
• Verify below-fold images have loading="lazy"
• Check if your CDN or framework is serving WebP automatically

Fixing the top 3 issues from this list will typically move a poor LCP score to passing.

The bottom line

Image optimisation is not glamorous work. It's resizing, converting, and configuring — not building features. But it's one of the highest ROI improvements you can make to a live site, both for user experience and for search rankings.

The tools exist to make it nearly automatic if you set them up correctly. The gap between a 4-second page and a 1.5-second page is usually images served at the wrong size and format.