Common image handling mistakes that slow down your website

Images are often among the heaviest and most common resources on a page, so oversized files, late discovery, and layout shifts can all make a site feel slower. The fix is not to convert every file or lazy-load every image: choose an appropriate source for its rendered size and content, reserve its layout space, and make the important above-the-fold image available early. web.dev’s image performance guidance covers these tradeoffs.

1. Sending an image that is much larger than its rendered slot

A 2,000-pixel-wide source displayed in a 400-pixel content column can waste transfer bytes. But do not size an image to the CSS width alone: a high-density display may need a larger source to look crisp. Provide several candidates and let the browser select based on the layout and device pixel ratio (DPR).

For width-descriptor srcset, pair the candidates with an accurate sizes value. The browser uses that description of the rendered slot, along with its knowledge of the display, to choose a candidate.

<img
  src="/images/article-800.jpg"
  srcset="/images/article-400.jpg 400w,
          /images/article-800.jpg 800w,
          /images/article-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="1200"
  height="800"
  alt="A developer reviewing a web page"
>

Here, the image uses the full viewport width up to 600 CSS pixels, then an 800-pixel slot. Replace those assumptions with your actual layout. If the slot is narrower at a breakpoint, describe that width rather than declaring 100vw everywhere. An overstated slot can make the browser download a larger file than necessary; an understated one can produce a soft image.

The width and height attributes describe the source aspect ratio and give the browser dimensions to reserve. Responsive CSS can still scale the image:

img {
  max-width: 100%;
  height: auto;
}

For art direction—where the crop or composition should change at a breakpoint—use <picture> with media conditions and a fallback <img>:

<picture>
  <source media="(max-width: 600px)" srcset="/images/article-mobile.jpg">
  <img src="/images/article-wide.jpg" width="1200" height="800" alt="A developer reviewing a web page">
</picture>

Use art direction when a different crop helps the small-screen composition. Use width candidates when the same composition can simply be rendered at different resolutions. See web.dev’s responsive images guide.

2. Treating format conversion as a guaranteed optimization

WebP and AVIF may produce smaller files than older formats, but the result depends on the image, resolution, quality setting, and browser support. A format name alone does not guarantee fewer bytes or acceptable visual quality. Compare representative assets at a visually acceptable quality, and account for transparency, animation, and the browsers your audience uses. web.dev’s image guidance and its format discussion explain the tradeoffs.

For a modern-format option with a fallback, a <picture> element can offer alternatives:

<picture>
  <source srcset="/images/diagram.avif" type="image/avif">
  <source srcset="/images/diagram.webp" type="image/webp">
  <img src="/images/diagram.png" width="1200" height="800" alt="A system diagram">
</picture>

Keep the fallback appropriate for the content: a photograph, line drawing, image with transparency, and animation can have different quality and compatibility needs. Check the actual encoded bytes and inspect visual artifacts at the delivered size. Do not assume every PNG should become JPEG or that every image benefits from the same quality setting.

3. Leaving out intrinsic dimensions

When an image has no known dimensions, the browser may not reserve its space before the file arrives. Content below it can shift as the image loads. Include its intrinsic width and height; the browser can use their ratio to reserve space while responsive CSS controls the displayed size. The attributes do not force the image to remain at those pixel dimensions. The web.dev responsive images guide says, “If you know an image’s dimensions, always include width and height attributes.”

For a dynamically generated image whose dimensions are not known until runtime, set an aspect-ratio or an appropriate reserved container size when possible. Ensure the chosen ratio matches the image, or the browser may reserve the wrong shape and still move content when the image appears.

4. Lazy-loading every image, including the hero

Native lazy loading can defer images that are below the fold, avoiding downloads for content a visitor may never reach. The hero or other image likely to be the Largest Contentful Paint (LCP) element is different: marking it lazy can delay its request and slow the main content’s appearance. Leave that image eager or at the default loading behavior, and lazy-load suitable images farther down the page.

<!-- Important above-the-fold image: do not lazy-load it -->
<img src="/images/hero.jpg" width="1600" height="900" alt="Product dashboard on a laptop">

<!-- Lower-page image: may be deferred until needed -->
<img src="/images/details.jpg" width="1200" height="800" loading="lazy" alt="Close-up of a product detail">

Check framework defaults or shared components: a rule that adds loading="lazy" to every image can accidentally affect the hero. web.dev’s LCP guidance explains why the important image should be discoverable early.

5. Hiding or delaying discovery of the LCP image

An image whose URL is in the initial HTML is generally easier for the browser to discover early than one inserted later by JavaScript or referenced only as a CSS background. If the important visual is a CSS background and cannot reasonably be represented as an HTML image, a preload may help. High fetch priority is another option for a genuinely important image, but applying priority hints indiscriminately can compete with other critical resources.

Start by checking the page’s request waterfall and the image’s resource priority. Confirm when the request starts and whether the image is the LCP element before adding preload or fetchpriority="high". For example:

<img src="/images/hero.jpg" width="1600" height="900"
     fetchpriority="high" alt="Product dashboard on a laptop">

Use this only when the image is truly important to initial rendering. The LCP article discusses discovery and resource priority.

6. Providing responsive candidates with an inaccurate sizes value

srcset candidates with w descriptors tell the browser the intrinsic width of each file. The sizes attribute describes the expected CSS slot width under media conditions. If sizes claims an image fills the viewport when it actually sits in a narrow column, the browser may choose an unnecessarily large candidate. If it claims a smaller slot than the real one, the selected source may look soft.

Measure or derive the actual column widths from the layout’s breakpoints. Then inspect selected candidates at representative viewport widths and DPRs. For example, if the content column is full width on mobile and capped at 720 CSS pixels on larger screens:

<img
  src="/images/story-720.jpg"
  srcset="/images/story-360.jpg 360w,
          /images/story-720.jpg 720w,
          /images/story-1080.jpg 1080w,
          /images/story-1440.jpg 1440w"
  sizes="(max-width: 760px) 100vw, 720px"
  width="1440"
  height="960"
  alt="A person reading an article"
>

Open the page at several viewport sizes and inspect the image’s current source in browser developer tools. Make sure the selected resource fits both the rendered slot and the display density. Responsive image selection depends on the layout and DPR together, as described in web.dev’s guide.

7. A practical diagnostic workflow

1. Find the expensive images. Inspect the browser’s network panel and sort image requests by transferred bytes. Note dimensions, format, and whether the asset is requested more than once.
2. Identify the loading role. Determine which image is above the fold and whether it is the LCP element. Separate that image from below-the-fold content before changing loading behavior.
3. Compare source and rendered sizes. Check the intrinsic dimensions, rendered CSS box, DPR, selected srcset candidate, and the sizes description.
4. Check layout stability. Confirm that images have dimensions or reserved aspect-ratio space and that the space matches the eventual image.
5. Compare formats and quality. For representative content types, compare bytes and visual quality. Preserve required transparency or animation and provide suitable fallbacks.
6. Change one thing at a time. Recheck the request waterfall, selected candidate, visual appearance, and layout after each change.
7. Check both lab and field signals. A lab run helps reproduce a page under controlled conditions; field data shows how real visitors experience it. Revisit after changes to layout, templates, or the image pipeline.

Image size, candidate choice, discovery, and priority interact. Use actual page evidence rather than applying blanket rules. The reviewed guidance recommends checking resource priority and using lab and field tools; it does not establish a guaranteed speed gain for a particular conversion.

8. Troubleshooting common image performance problems

Symptom	Likely cause	What to check or change
A hero appears late despite being small on screen	It is lazy-loaded, discovered late through JavaScript or CSS, or competing at low priority	Remove lazy loading from the hero; put its URL in initial HTML where practical; inspect the waterfall and priority. Consider preload or high priority only after confirming the bottleneck.
Large image downloads in a narrow column	sizes overstates the slot, candidates are sparse, or the layout uses a larger candidate than needed	Describe the real slot at each breakpoint, add suitable width candidates, and inspect the selected source at relevant viewport sizes and DPRs.
Image looks blurry on a high-density screen	The candidate set or sizes understates the rendered slot or lacks a sufficiently large source	Verify the rendered width and DPR, then provide a larger candidate and correct sizes.
Text jumps when images load	Intrinsic dimensions are missing, or the reserved aspect ratio is wrong	Add accurate width and height attributes or reserve a matching aspect ratio.
Modern format is not smaller	The content or quality setting does not suit that format, or the comparison used different dimensions or visual quality	Compare equivalent dimensions and acceptable appearance across representative assets; keep an appropriate fallback.
Transparent edges or animation break after conversion	The replacement format or conversion pipeline does not preserve the asset’s transparency or animation behavior	Use a format and delivery path that supports the required behavior, then inspect the result in target browsers.
Changes help one viewport but hurt another	Breakpoints or sizes do not match the responsive layout	Test mobile, intermediate, and desktop widths, including relevant DPRs, and describe actual rendered slot widths.

9. Performance, reliability, and cost considerations

Responsive variants and modern formats can reduce bytes when the delivered candidate is a good match, but they introduce production and maintenance choices: which sizes to generate, how to name and cache them, how to preserve fallbacks, and how to update derivatives when originals change. Image CDN or transformation services can automate resizing and format delivery for image-heavy sites; evaluate them against your pipeline needs and operational cost rather than assuming they are necessary for every site.

For reliability, keep an appropriate source fallback, ensure generated variants are available wherever the page is served, and avoid markup that references files your deployment does not publish. Validate quality and behavior for the content types you actually use. For performance, prioritize the LCP image’s discovery and correct candidate, then defer suitable lower-page images. For cost, compare the bytes saved and engineering or service costs of the pipeline; the cited guidance does not provide a universal savings figure.

10. Inspecting the rendered page and capture output

A browser screenshot can help you spot a missing image, a layout jump, or a hero that appears only after interaction. It shows the rendered result at a chosen viewport; use the browser network waterfall and performance tools to diagnose transfer size, candidate selection, priority, and LCP timing.

For local investigation, load the page at representative viewport widths, capture before and after changes, and compare the same content and viewport. If you automate checks, keep the capture environment and wait conditions consistent so a delayed image is not mistaken for a missing one.

11. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One request returns a PNG, JPEG, WebP, or PDF capture; its options include viewport presets, full-page capture with lazy images loaded, waits, and custom CSS or JavaScript. It can help you inspect the rendered result while you use browser performance tools for byte and priority diagnosis. See the ScreenshotNeo API documentation.

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

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

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}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Cookie and consent banners are accepted and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Sign up free and capture 1,000 screenshots a month with no card.

12. Frequently asked questions

Should I convert all images to AVIF or WebP?

No. Compare formats on representative content at equivalent dimensions and acceptable visual quality, and account for transparency, animation, and browser support.

Does adding width and height prevent responsive sizing?

No. They provide intrinsic dimensions and a ratio for space reservation; responsive CSS can scale the rendered image.

Can I lazy-load the hero if it is below the fold on some screens?

Base the decision on its role and placement for the page’s typical initial viewport. Check LCP and request timing across the layouts you support rather than applying a global image rule.

Is an image CDN required to fix slow images?

No. Correct source sizes, responsive candidates, and loading behavior can be implemented in your existing pipeline. A transformation service is an operational choice for teams that need automated variants and delivery.