How to Identify and Fix Oversized Images That Slow Down Your Website

Oversized images slow a website when they transfer more bytes than necessary or deliver far more pixels than the rendered slot and device need. Find candidates with Lighthouse, compare each image’s intrinsic dimensions with its rendered size and device pixel ratio, then serve appropriately sized responsive variants and compress them while checking visual quality. Do not lazy-load the image likely to be your Largest Contentful Paint (LCP) element.

1. Find image candidates with Lighthouse

Run Chrome Lighthouse on the affected page, or enter its URL in PageSpeed Insights. Inspect the image opportunities, especially Properly size images and Efficiently encode images. The first identifies images whose delivered dimensions may exceed what the page needs; the second identifies encoding opportunities. Use the reports to find candidates, not as instructions to blindly change every flagged image.

Lighthouse’s sizing audit accounts for device pixel ratio (DPR) and flags images when its estimated rendered-size savings reach at least 4 KiB. Its encoding audit compares JPEG and BMP images against an encoding at quality 85 and reports potential savings of at least 4 KiB. These are audit heuristics, and behavior can vary by Lighthouse version. Quality 85 is not a universal production setting.

Make the audit repeatable

Choose a representative page and run Lighthouse with a consistent device profile.
Record the flagged image URLs, estimated savings, and the page’s likely LCP element.
Open each image and note its intrinsic pixel dimensions, file size, format, and transparency needs.
Inspect the page at relevant viewport widths. Record the image’s rendered CSS dimensions and consider the DPR of the devices you support.
Fix the delivery or encoding issue, then rerun the audit and inspect the actual selected image in browser developer tools.

2. Decide whether an image is oversized

Compare the source pixels with the image’s rendered CSS size and the screen’s DPR. A 500 by 500 CSS-pixel slot can use a 500 by 500 source at DPR 1 or a 1000 by 1000 source at DPR 2. A 1000-pixel-wide file displayed at 500 CSS pixels is therefore not automatically wasteful: it may be appropriate for a DPR 2 screen. Conversely, a very large source may waste bytes if the layout never displays it near that size.

There is no single correct source width for a responsive page. A card may be narrow on a phone and much wider on desktop, and users have different screen densities. Choose a practical set of variants based on the actual layout and audience rather than resizing every image to one desktop width.

What to compare	What it tells you
Intrinsic width and height	The pixels available in the downloaded file.
Rendered CSS width and height	The slot the page gives the image at the current viewport.
DPR	How many source pixels may be useful for each CSS pixel on the device.
Transferred bytes and format	Whether encoding or format conversion may reduce download cost.
Visual quality and transparency	Whether compression or format changes preserve the image’s requirements.

3. Serve responsive image variants

Generate a reasonable set of sizes and let the browser select a candidate using srcset width descriptors and sizes. Set the sizes value to reflect the image’s actual layout; otherwise the browser may choose a source that is too large or too small.

<img
  src="/images/article-800.jpg"
  srcset="/images/article-480.jpg 480w,
          /images/article-800.jpg 800w,
          /images/article-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, (max-width: 1000px) 80vw, 800px"
  width="1200"
  height="800"
  alt="A developer reviewing a website on a laptop"
>

The width and height attributes communicate the image’s aspect ratio so the browser can reserve space while it loads. Use dimensions that match the source aspect ratio. The browser chooses from the candidates according to the available slot and DPR; inspect the selected resource at representative viewport sizes to confirm your markup describes the layout correctly.

Use <picture> when you need art direction, such as a different crop on a narrow screen, or when offering alternate formats with a fallback:

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-640.avif 640w, /images/hero-1280.avif 1280w"
    sizes="(max-width: 700px) 100vw, 1200px"
  >
  <source
    type="image/webp"
    srcset="/images/hero-640.webp 640w, /images/hero-1280.webp 1280w"
    sizes="(max-width: 700px) 100vw, 1200px"
  >
  <img
    src="/images/hero-1280.jpg"
    srcset="/images/hero-640.jpg 640w, /images/hero-1280.jpg 1280w"
    sizes="(max-width: 700px) 100vw, 1200px"
    width="1280"
    height="720"
    alt="A team planning a website redesign"
  >
</picture>

Modern CMS features can generate and publish responsive image variants for you. An image CDN can also transform and serve variants, sometimes with automatic format selection. Compare implementation and operational complexity with the actual bytes delivered and visual result; a CDN is an option, not a requirement.

4. Compress and choose formats deliberately

Compression and format conversion can lower transferred bytes, but always compare the output file size and inspect the image at its actual display size. A conversion can make an already optimized asset larger.

JPEG: common for photographs without transparency; tune compression to the image and inspect artifacts.
WebP: supports lossy and lossless compression and transparency, including transparency with lossy encoding. It often compresses better than JPEG, PNG, or GIF, but measure your own images.
AVIF: can offer good compression; check support for your audience and verify output quality and delivery behavior.
PNG: useful where lossless detail or transparency matters; it may be unnecessarily large for photographs.

Tools such as Squoosh and ImageOptim provide graphical workflows for comparing encodings. ImageMagick can be used in command-line image processing workflows. Choose settings per asset class and visual inspection, rather than treating a single quality number as correct for every image.

5. Keep the LCP image discoverable and prioritized

Lazy loading can defer images that start below the initial viewport, but do not add loading="lazy" to the image likely to be the page’s LCP element. The browser should discover that important image early from the initial HTML. For one or two likely LCP images, fetchpriority="high" may help; verify the resource priority in DevTools and check performance results.

<!-- Likely LCP image: keep it eager and discoverable in the initial HTML. -->
<img
  src="/images/hero-1200.webp"
  srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
  sizes="100vw"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="A dashboard displayed on a laptop"
>

<!-- Below-the-fold image: defer loading until it approaches the viewport. -->
<img
  src="/images/team-800.webp"
  width="800"
  height="533"
  loading="lazy"
  alt="A team working together"
>

Use high priority sparingly. Applying it to many images can undermine the browser’s ability to prioritize the resources that matter most.

6. Verify bytes, quality, and user experience

Rerun Lighthouse on the same page and profile. Check whether the image opportunities changed and whether the intended candidate is still flagged.
In DevTools, inspect the network request to see which responsive source was selected and how many bytes transferred.
Compare the image at its real display size and on high-density screens. Look for blur, banding, compression artifacts, lost detail, or incorrect crops.
Check that image dimensions reserve the right layout space and that the LCP image is not lazy-loaded.
Where field performance data is available, review it as well as lab results. An audit alone does not establish how users experience the page.

Evaluate changes across the dimensions that matter: bytes at the target slot and DPR, visual fidelity, transparency, browser support, implementation effort, and loading priority. Keep the variants that improve delivery without introducing quality or reliability problems.

Common problems and fixes

Symptom	Likely cause	Fix
Lighthouse still flags an image after resizing it	The page may still serve the original, or the source may remain larger than needed for the tested slot and DPR.	Inspect the requested URL and selected candidate in DevTools. Update the markup or image pipeline, then rerun the audit.
The browser downloads the largest `srcset` candidate on mobile	`sizes` may describe a larger slot than the image actually occupies, or the layout differs from the assumed breakpoints.	Measure the real slot at that viewport and update `sizes`. Check the selected resource again.
An image looks blurry on a high-density display	The largest available candidate may not provide enough pixels for the slot and DPR, or the chosen compression may be too aggressive.	Provide a suitable higher-resolution candidate and inspect the output quality at the actual display size.
A format conversion increased file size	The source may already be optimized, or the new format and settings may not suit that image.	Compare bytes and appearance for the original and converted files. Keep the smaller acceptable output.
The hero image appears late or LCP worsens	The likely LCP image may be lazy-loaded, discovered late, or competing with too many high-priority resources.	Make the image discoverable in the initial HTML, remove lazy loading from it, and use high fetch priority only for one or two likely LCP images where it helps.
The image jumps as it loads	The browser was not given dimensions or an aspect ratio to reserve its space.	Set accurate `width` and `height` attributes or reserve the matching aspect ratio in CSS.
A responsive crop cuts off important content	The same source crop is being used for layouts that need different compositions.	Use art-directed sources with `<picture>` and test the crop at each relevant breakpoint.
The Lighthouse score changes between runs	Audit results can vary with environment, page state, and tool version; small scores are not a substitute for checking the delivered resource.	Compare the same page and profile, inspect requests and image quality, and use field data where available.

Performance, reliability, and cost considerations

Responsive variants can reduce bytes without making every image visibly smaller, but they add generation and markup decisions. Automated image CDNs can simplify transformation and format selection while adding a service dependency and configuration to operate. Compression can save transfer cost at the expense of visible quality if settings are too aggressive. Measure the delivered variant, not just the size of the original source file.

For reliability, keep a valid fallback source when serving alternate formats, ensure generated variants exist at the URLs your markup references, and check the page after changing the image pipeline. Preserve meaningful alt text and dimensions through build or CMS transformations. Defer only noncritical offscreen images; keep the likely LCP resource early in the document.

Or skip the browser setup

To inspect how a page renders before and after an image change, ScreenshotNeo can capture its current appearance with one request. It is a website screenshot API and MCP server from ScreenshotNeo; its screenshots help you review visual changes, while Lighthouse and DevTools remain the tools for measuring image bytes and audit opportunities.

See the ScreenshotNeo API documentation for request options. This complete cURL example saves a WebP screenshot of a page:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners, newsletter popups, and chat widgets are removed before capture; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed; response headers say which page verdict occurred and whether it was billed.
An MCP server lets AI agents, including Claude and Cursor, take screenshots with ScreenshotNeo tools.
1,000 screenshots a month are free with no card. Paid plans start at $5 for 3,000 screenshots.

FAQ

Does “oversized” mean the source is wider than the CSS slot?

No. Account for DPR: a source may need about twice the CSS dimensions for a DPR 2 display. Judge it in the context of the actual layout and devices.

Should I convert every image to WebP or AVIF?

No. Compare output size, appearance, transparency needs, and browser support for your audience. Retain a suitable fallback where needed.

Should I set quality to 85?

Not as a blanket rule. Lighthouse uses 85 as part of an audit comparison, not as a universal recommendation for production images.

Can ScreenshotNeo tell me which image is oversized?

No. ScreenshotNeo captures page appearances; use Lighthouse, DevTools, and performance data to inspect image delivery and bytes.