An image is large enough to be slowing the page down

Why it matters

`one of your images` is over a megabyte. A well-optimised full-width image costs roughly 150-250 KB in a modern format, so this is several times what the job needs, and every visitor downloads it before the page finishes drawing. This is the usual reason a page has a poor Largest Contentful Paint: the biggest element on screen is an image, and the browser cannot paint it until the whole file has arrived. On a phone on mobile data — which is most visitors — a megabyte is seconds, not milliseconds, and it is charged to their data plan. Three fixes, in order of how much they return. Convert it to AVIF or WebP, which typically cuts 60-80% with no visible difference. Serve it at the size it is actually displayed rather than at export resolution — a 4000px-wide original shown in a 800px column wastes most of those bytes. Then add a `srcset` so phones fetch a smaller file than desktops do.

How ShipReady detects it

Images heavy enough to be the reason a page is slow. SITE-scoped so a hero repeated across every crawled page is weighed once, and so the scan's whole image budget is a single fixed number rather than a number multiplied by the crawl size.

Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.0.0.

How to fix it

This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.

An image on your site is over a megabyte. Every visitor downloads it before the page finishes drawing, and it is almost certainly the reason your Largest Contentful Paint is slow.

CONVERT THE FORMAT FIRST — it is the biggest win for the least work. AVIF typically cuts 60-80% off a PNG or JPEG with no visible difference; WebP is a little larger and supported everywhere. One command:

    npx @squoosh/cli --avif auto hero.png
    # or: cwebp -q 80 hero.png -o hero.webp

RESIZE TO WHAT IS ACTUALLY DISPLAYED. A 4000px-wide export shown in an 800px column wastes most of its bytes. Export at the largest size the layout uses, at 2x for high-DPI screens — so roughly 1600px for that column, not 4000.

THEN SERVE RESPONSIVELY so a phone does not fetch the desktop file:

    <img src="hero-800.avif"
         srcset="hero-800.avif 800w, hero-1600.avif 1600w"
         sizes="(max-width: 768px) 100vw, 800px"
         width="800" height="450" alt="...">

IF YOU ARE ON A FRAMEWORK, use its image component instead of doing this by hand — `next/image`, `nuxt/image` or an Astro `<Image>` will convert, resize and generate the srcset at build time. That also stops the next image somebody adds from repeating this.

KEEP `width` AND `height` ON THE TAG whatever you do, so the browser reserves the space before the file arrives and the page does not jump as it loads.

ONE THING NOT TO DO: leaving the file large and adding `loading="lazy"` does not fix this if the image is above the fold. Lazy-loading the main image delays it further, because the browser deliberately waits before fetching a lazy image.

Frequently asked questions

What does "An image is large enough to be slowing the page down" mean?

`one of your images` is over a megabyte. A well-optimised full-width image costs roughly 150-250 KB in a modern format, so this is several times what the job needs, and every visitor downloads it before the page finishes drawing. This is the usual reason a page has a poor Largest Contentful Paint: the biggest element

How serious is it?

ShipReady rates this medium. Fix soon. Meaningfully weakens a defence or degrades how the site works.

How do I fix it?

Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.

Can I check my own site?

Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

• A JavaScript bundle is large enough to make the page feel slowmedium
• Real visitors wait too long to see your main contentmedium
• The page is served without compressionmedium
• The page is slow to respond when people tap or clickmedium
• The page moves under people while it loadsmedium
• Build assets are served without cachinglow