Why Your Website Images Are Slowing Down Your Page

The quick diagnosis

Website images slow pages when the browser has to download, decode, and paint more image data than the layout actually needs. Sometimes the fix is compression. Sometimes it is resizing. Sometimes the image is fine, but the browser discovers it too late because it is lazy-loaded, hidden in CSS, or injected by JavaScript.

Start with the symptom:

The useful question is not "How do I compress all images?" It is "Which image is blocking the page, how big is the delivered file, and how large is it on screen?"

How images actually slow a page

Images affect speed in four different ways.

First, they add network bytes. A 2 MB hero image on a fast office connection may feel acceptable. On a congested mobile connection, it can dominate the page load.

Second, they compete with other resources. If the browser is downloading a large hero image, several product thumbnails, fonts, and scripts at the same time, the important image may not finish early enough.

Third, they can delay Largest Contentful Paint. LCP measures when the largest visible content element is rendered. On many landing pages, product pages, and blog posts, that element is an image. web.dev's LCP guidance breaks LCP into subparts such as resource load delay, resource load duration, and element render delay. A slow image can affect more than one part.

Fourth, images can cause layout shift. If the browser does not know the image dimensions before download, content below the image may jump when the image finally appears.

That is why image optimization is not one setting. It is a pipeline: dimensions, format, compression, HTML markup, loading priority, and verification.

Step 1: find the image that is actually slow

Before resizing a whole media library, inspect the page.

In Chrome DevTools:

1. Open the page.
2. Open the Network panel.
3. Reload with cache disabled.
4. Filter by Img.
5. Sort by transferred size and duration.
6. Click the largest files and compare request URL, format, dimensions, and cache status.

Then inspect the visible image element and run:

const img = $0;
const box = img.getBoundingClientRect();
({
  renderedWidth: Math.round(box.width),
  renderedHeight: Math.round(box.height),
  naturalWidth: img.naturalWidth,
  naturalHeight: img.naturalHeight,
  dpr: window.devicePixelRatio,
  currentSrc: img.currentSrc || img.src
});

If naturalWidth is far larger than the rendered width times DPR, visitors are downloading extra pixels. If currentSrc points to a generated CDN URL you did not expect, the page may be serving the wrong variant. If the slowest image is above the fold, treat it differently from a gallery image near the bottom of the page.

Chrome's image delivery insight and Lighthouse's properly size images audit both look for wasted image bytes. They are useful because they connect file size to displayed size, not just file size by itself.

Step 2: resize before you compress

The biggest waste is often dimensions, not quality.

web.dev's image performance guide gives the basic rule: an image displayed in a 500 x 500 CSS pixel container is optimally 500 x 500 on a 1x display, about 1000 x 1000 on a 2x display, and larger on higher DPR screens. In practice, many sites aim for 2x on important images and avoid shipping giant originals to every device.

Use this formula:

source width = largest rendered CSS width x target DPR

Practical starting sizes:

Avoid uploading a 6000 px camera original if the page displays the image at 900 px. Also avoid resizing a detailed hero down to exactly 900 px if it needs to look sharp on 2x screens. The right answer sits between those extremes.

Step 3: choose the format by image content

Wrong format is the next common problem.

Use these defaults:

MDN's image format guidance describes JPEG as a strong lossy choice for still photos, PNG as better for precise reproduction and transparency, and WebP as a modern format with better compression plus transparency support. The article should not turn that into "use WebP for everything." If a destination rejects WebP, use JPG or PNG. If a logo exists as SVG, do not rasterize it into a large PNG.

Step 4: compress with the page context in mind

Compression quality should follow the image's job.

Good starting points:

The quality number is not a shared scale. WebP 80 and JPG 80 are not the same thing. A 90 KB image with smeared product labels is worse than a 150 KB image that users can trust.

Look for:

• banding in skies and gradients;
• waxy faces or fabric;
• halos around product edges;
• fuzzy screenshot text;
• blocky dark shadows;
• color shifts in brand images.

Chrome's image delivery insight recommends improving image download time with tactics such as compression, modern formats, and appropriate sizing. The order matters: resize first, then choose format, then tune quality.

Step 5: treat the LCP image as a special case

The hero image is not just another image. If it is the Largest Contentful Paint element, it should be:

• close to the final rendered dimensions;
• in a modern format with an appropriate fallback;
• visible to the browser early in the HTML;
• not lazy-loaded;
• given width and height;
• considered for fetchpriority="high" if it is likely to be the LCP image.

web.dev's LCP guidance is blunt about this: do not lazy-load the LCP image, because it creates unnecessary resource load delay. It also notes that fetchpriority="high" can help when an image is likely to be the LCP element, but using high priority on too many images makes the hint less useful.

Example:

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img
    src="/images/hero.jpg"
    width="1600"
    height="900"
    fetchpriority="high"
    alt="Product dashboard showing weekly sales trends">
</picture>

If the hero is a CSS background image, the browser may discover it later than an HTML image. Consider moving critical hero imagery into HTML or preloading the exact resource if your design requires CSS backgrounds.

Step 6: lazy-load the right images

Lazy loading is good when it removes unnecessary initial work. It is bad when it delays visible content.

Use loading="lazy" for:

• images below the initial viewport;
• long blog article images after the intro;
• gallery items far down the page;
• product recommendations below the main product section;
• footer logos and badges.

Avoid loading="lazy" for:

• hero images;
• the likely LCP image;
• images visible in the first viewport;
• first carousel slides;
• logos or badges that define the page above the fold.

web.dev's lazy-loading guidance recommends eager loading images visible in the first viewport and using lazy loading for images outside it. It also stresses that dimensions still matter, because lazy-loaded images without width and height can contribute to layout shifts.

<!-- Above the fold -->
<img src="/images/hero.webp" width="1600" height="900" alt="Hero product view">

<!-- Below the fold -->
<img src="/images/gallery-04.webp" loading="lazy" width="800" height="533" alt="Detail view">

Step 7: reserve space to prevent layout shift

Missing dimensions may not make the network slower, but they make the page feel worse. When the browser does not know how much space an image needs, it may lay out text first and then push it down when the image loads.

Add width and height attributes that match the image aspect ratio:

<img src="/images/article.webp" width="1200" height="800" alt="Workflow screenshot">

If the image is responsive, CSS can still scale it. The attributes give the browser an aspect ratio before the image downloads. That is the part that helps prevent visual jumping.

Step 8: do not trust the media library preview

The file you upload may not be the file visitors download. CMS platforms, e-commerce systems, and CDNs often create their own image variants.

Common surprises:

• the media library shows the original 2400 px file, but the page requests a 6000 px source;
• the template uses the full-size original instead of a generated thumbnail;
• mobile receives the desktop hero crop;
• the CDN converts to WebP but keeps oversized dimensions;
• the theme uses a CSS background image that bypasses the normal responsive image component;
• cache shows an older, heavier file after you replace the asset.

Inspect the live currentSrc, not the upload screen. If the URL contains parameters like w=, width=, q=, format=, or a size name such as large, check whether those values match the rendered slot.

A PhotoTools workflow before uploading

Use this repeatable workflow for image-heavy pages:

1. Find display sizes. Check the real page layout or template, not just the CMS editor.
2. Resize first. Use Resize to create a 2x source for important images and smaller copies for cards and thumbnails.
3. Choose the right format. Use WebP or AVIF for web photos when your stack supports it. Keep JPG or PNG where compatibility matters.
4. Compress second. Use Compress and start around 80-85 for normal web photos. Raise quality for faces, labels, dark images, and heroes.
5. Batch carefully. Apply the same settings to similar images, but spot-check hard cases.
6. Upload and inspect the live page. Confirm currentSrc, rendered dimensions, transfer size, LCP element, and layout stability.

PhotoTools' resize/compress path runs in the browser. The image is decoded, drawn to a canvas, and exported as a new JPG, WebP, AVIF, or PNG file with the selected settings. That makes it useful for preparing delivery copies before the originals reach a CMS, CDN, or form upload.

Quick checklist

Before publishing an image-heavy page, check:

• The LCP image is not lazy-loaded.
• The LCP image starts loading early enough.
• Above-the-fold images have width and height.
• Below-the-fold images use loading="lazy".
• Large photos are resized to the largest real display size, often around 2x.
• srcset and sizes match the actual layout.
• WebP or AVIF is used where the site supports it.
• JPG/PNG fallbacks exist where compatibility matters.
• Screenshots with text are not over-compressed as JPG.
• The live CDN/CMS URL serves the variant you expected.
• The page is checked in PageSpeed Insights or DevTools after upload.

Bottom line

Website images slow pages when image delivery is treated as an upload task instead of a rendering task. The browser does not care that your source file looked good in a folder. It cares how many bytes it has to fetch, when it discovers the image, how large the image is on screen, and whether the layout can reserve space.

Fix the pipeline in order: measure the live image, resize to the rendered slot, choose the right format, compress with visual checks, load the hero early, lazy-load offscreen images, set dimensions, and verify the delivered URL. That is much more reliable than blindly compressing every image and hoping the page feels faster.