How to Find and Fix the Images Slowing Down Your Website (Image Audit)

To find the images slowing down your site, list every image on a page with its file size and the size it is shown at, then sort by bytes and by position. The heavy files near the top of the page are usually the ones to fix first. That list is an image audit, and for one page it takes about an hour once you know the steps.

This guide gives you a repeatable image audit website owners and developers can run with free tools: the Chrome DevTools Network panel, Lighthouse, PageSpeed Insights and a short console snippet. You will learn how to find the Largest Contentful Paint (LCP) image, record findings in a spreadsheet, choose a fix order and check the result. An audit changes nothing on your site. It shows where bytes are wasted so you can decide what to change.

Before you begin

You will need:

Google Chrome or another Chromium browser, so you can open DevTools (F12, or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac).
The addresses of the pages to audit. Start with the home page, your most visited page and one page of each template, such as a product page, an article and a category page.
A spreadsheet application.
Access to wherever images are uploaded or generated: a CMS media library, a build step, an image CDN or a server folder.

Two terms to know first:

LCP (Largest Contentful Paint): the time until the largest image or block of text in the visible area is drawn. A good score is 2.5 seconds or less at the 75th percentile of visits. On many pages the LCP element is an image.
Intrinsic size: the pixel width and height stored inside the image file. The displayed size is the size the page draws it at. A big gap between the two wastes bytes.

Audit on a normal connection first, then repeat with network throttling and a phone-sized viewport in DevTools.

Step-by-step instructions

Step 1: List the images in the Network panel

Open DevTools, choose the Network tab, tick Disable cache, then reload the page. Click the Img filter to show only images, then click the Size column header to sort largest first.

The Size column shows the bytes transferred and, below that, the size of the resource after decompression. The Waterfall column shows when each request started and how long it took. Scroll to the bottom of the page and watch for new rows: images that only appear as you scroll are lazy loaded, and they belong in your list.

What success looks like: you can name the five largest images on the page and their sizes in kilobytes.

Step 2: List every image with a console snippet

The Network panel shows requests but not how large each image is drawn. This snippet reads document.images, the list of every <img> element, and prints the address in use, the intrinsic width, the displayed width and the size from the browser's resource timing entries. It only reads the page and writes to the console. It sends no requests and changes nothing.

(() => {
  const timing = new Map(
    performance.getEntriesByType('resource').map(e => [e.name, e])
  );
  const rows = [...document.images].map(img => {
    const entry = timing.get(img.currentSrc);
    const shown = Math.round(img.getBoundingClientRect().width);
    return {
      src: img.currentSrc.split('/').slice(-2).join('/'),
      naturalWidth: img.naturalWidth,
      displayedWidth: shown,
      pixelRatio: shown ? +(img.naturalWidth / (shown * devicePixelRatio)).toFixed(2) : null,
      kb: entry && entry.encodedBodySize ? Math.round(entry.encodedBodySize / 1024) : null,
      loading: img.loading,
      hasAlt: img.hasAttribute('alt') && img.alt.trim() !== ''
    };
  });
  rows.sort((a, b) => (b.kb ?? -1) - (a.kb ?? -1));
  console.table(rows);
})();

How to read the output:

currentSrc is the file the browser actually chose, which matters when a page uses srcset. The snippet shortens the address for readability.
pixelRatio divides the intrinsic width by the displayed width multiplied by the screen's device pixel ratio. Near 1 means the file suits this screen. A value of 2 or more means the file is at least twice as wide as the screen can show.
kb comes from encodedBodySize, the body size before decoding. It can be empty or zero for images from another domain that does not send a Timing-Allow-Origin header, and for some cached responses. Use the Network panel for those rows.
Lazy images you have not scrolled to show a natural width of 0. Scroll down and run it again.

Chrome warns you before it lets you paste code into the console. Only paste code you have read and understand. You can save the snippet under Sources, then Snippets, to reuse it.

What success looks like: a table with one row per image, sorted by size, ready to copy into a spreadsheet.

Step 3: Find the LCP image

Open the Performance panel, record a page reload and look for the LCP marker in the timings. Selecting it shows the element involved. Lighthouse and PageSpeed Insights also name the Largest Contentful Paint element in their diagnostics. For a quick check in Chromium browsers, this snippet prints the current LCP candidate.

new PerformanceObserver(list => {
  const last = list.getEntries().at(-1);
  console.log('LCP', Math.round(last.startTime), 'ms', last.element, last.url || '(text)');
}).observe({ type: 'largest-contentful-paint', buffered: true });

If the element is an image, url shows its address. Write it down, and check desktop and phone sizes separately because the LCP element can differ. If it is text, images are probably not your main LCP problem. See Fix Largest Contentful Paint (LCP) on Mobile.

What success looks like: you know which image, if any, is the LCP element on each screen size.

Step 4: Run Lighthouse and PageSpeed Insights

Lighthouse is built into Chrome DevTools (the Lighthouse tab) and powers PageSpeed Insights at pagespeed.web.dev, which also shows field data from real Chrome users when enough visits exist. Audit names change between Lighthouse versions, and newer versions may group several under one image-delivery insight, but look for findings on these topics:

Properly sized images: files with more pixels than the displayed size needs.
Efficiently encoded images: files that could be smaller with better compression.
Modern formats: JPEG or PNG files that could be WebP or AVIF.
Offscreen images: images below the first screen that load too early.
LCP image: whether the LCP image is found and loaded early.
Explicit width and height: images without reserved space, which can shift content.

Treat estimated savings as pointers, not promises, because they come from a simulated lab test. Lab and real-user numbers often differ; see Field Data vs Lab Data: Why Lighthouse and Real Users Disagree.

What success looks like: each flagged file is matched to a row in your list.

Step 5: Read a waterfall

A waterfall draws every request as a bar along a time axis. The Network panel has one, and tools in the WebPageTest style draw a similar chart from a test on a remote machine at a chosen connection speed. Look for these patterns:

A late-starting LCP image. The bar begins long after the HTML arrives, perhaps because the image is set by JavaScript or CSS, or is marked lazy.
Many images starting together. Dozens of simultaneous requests compete, so the important one finishes later.

What success looks like: a short note per page such as "hero image discovered late" or "ten gallery images load before the fold".

Step 6: Record findings in a spreadsheet

Use one row per image. Useful columns are: page, image address, position (above the fold, below the fold or hidden), kilobytes, intrinsic size, displayed size, format, LCP image yes or no, problems, planned fix and status. List a sitewide image such as a header logo once, because fixing it helps every page.

What success looks like: a sheet you can sort and filter, ready to hand to whoever will do the work.

Step 7: Prioritise by bytes and by position

Bytes tell you how much there is to save. Position tells you how soon a visitor feels it.

Priority	Bytes	Position	Action
1	Large	Above the fold, or the LCP image	Fix first.
2	Large	Below the fold	Resize, compress and lazy load.
3	Small	Above the fold	Check dimensions and loading attributes.
4	Small	Below the fold	Fix in routine upkeep.

What counts as large is your decision. Agree a starting threshold for your site and lower it as you improve.

What success looks like: your sheet is sorted with the ten most valuable fixes at the top.

Step 8: Fix in a sensible order

Earlier steps often make later ones unnecessary.

Remove images you do not need. It is the cheapest fix.
Resize to the displayed size. Scale files to about the largest size they are shown at, allowing for high-density screens.
Offer several widths. Use srcset and sizes so small screens get small files. See Responsive Images with srcset and sizes: Serve the Right Size.
Choose a better format. WebP and AVIF are often smaller than JPEG or PNG at similar quality. Check current browser support at caniuse.com and keep a fallback where needed. See Use WebP and AVIF Images to Improve Website Speed.
Compress. Lower the quality setting until you notice a difference, then step back a little.
Treat the LCP image carefully. Keep it in the page HTML so the browser finds it early, do not lazy load it, and consider fetchpriority="high".
Lazy load images below the fold. Add loading="lazy" there, not to the first image. See Lazy Loading Images for SEO: Defer Images Without Hiding Them.
Reserve space. Add width and height so the layout does not jump. See Reduce Cumulative Layout Shift (CLS) Step by Step.
Fix names and alt text. See Image SEO: Alt Text, File Names and Formats That Help Search.

An above-the-fold image set up for speed:

<img
  src="/img/hero-1200.webp"
  srcset="/img/hero-600.webp 600w, /img/hero-1200.webp 1200w, /img/hero-1800.webp 1800w"
  sizes="100vw"
  width="1200" height="600"
  alt="Team reviewing a launch checklist"
  fetchpriority="high">

What success looks like: the top rows of your sheet are marked done on staging or in the CMS.

Step 9: Recheck

Run the same tools with the same settings and compare the Network totals, snippet output and Lighthouse report with your first run. Update the status column.

Lab tests respond immediately. Field data is typically based on about the last 28 days of real visits, so it improves gradually.

What success looks like: large above-the-fold files are smaller, the LCP image loads earlier in the waterfall and no new problems appeared.

Using Crawvix Image Doctor for a site-wide image audit

The steps above work one page at a time. Crawvix's Image Doctor is the no-setup way to do the same across many pages. It lists up to 2,000 images written into the HTML of the pages of a full scan of a verified website, checks up to 200 of them for status, type and file size, and reports missing or generic alt text, broken images, large files, missing width and height, a lazily loaded first image, older formats and generic file names. Each finding comes with evidence and what to do, and a CSV export gives you a ready-made spreadsheet. It only reads your website and never changes it.

Final verification checklist

You audited the home page and one page per template.
Every image has a row with kilobytes, intrinsic size, displayed size and position.
The LCP image is identified, is not lazy loaded and is present in the page HTML.
Images far larger than their displayed size are resized or offered in several widths.
Large photographs use an efficient format with a fallback where needed.
Below-the-fold images use loading="lazy".
Every <img> has width and height.
Meaningful images have useful alt text, and decorative ones have an empty alt="".
You ran Lighthouse again and recorded the change.

Common mistakes to avoid

Auditing only the home page. Product, article and category templates often carry the heaviest images.
Optimising the wrong image. Identify the LCP element before spending time elsewhere.
Lazy loading everything. The first visible image should load immediately.
Resizing with CSS only. Shrinking a 4000 pixel file to 600 pixels in CSS still downloads all of it.
Never rechecking. New uploads bring new heavy files, so make the audit routine.

Frequently asked questions

How do I find which images are slowing down my website?

Open the Network panel in Chrome DevTools, filter to Img, reload and sort by Size. The largest files, and any image that is the LCP element, are the usual suspects. A Lighthouse report also names files it considers oversized or in an older format.

How do I list all images on a web page?

Run a short script that reads document.images, or use the Network panel's Img filter. The snippet in this guide prints each image's currentSrc, intrinsic width, displayed width and size from performance entries. Scroll first so lazy images load.

What is a good image size for a web page?

There is no single figure. A good file has no more pixels than the largest size it is shown at, adjusted for high-density screens, and is compressed as far as quality allows. Compare each image with the space it fills rather than a fixed byte count.

Should I lazy load the LCP image?

No. Lazy loading can delay the request until the browser decides the image is near the viewport, which can push back LCP. Load the main image at the top of the page normally and consider fetchpriority="high".

Why does my Lighthouse result differ from what real visitors experience?

A Lighthouse run uses one simulated device and connection, while field data covers many real devices and connections. Use the lab run to find image problems and field data to see whether real visits improve.

How often should I run an image audit?

After every redesign, theme change or large content import, and on a regular schedule such as once a quarter.

Official references

Next step: Run Image Doctor on your verified website or see how Crawvix checks a website. This guide gives technical information and no guarantee of rankings, traffic or index inclusion.