Image file size and format decide how fast the heaviest part of your page loads. Photos and banners are the largest files on most pages and frequently the Largest Contentful Paint (LCP) element, so shrinking them, picking a modern format and loading them in the right order is the fastest way to pass Core Web Vitals on an image-heavy site.
What does image file size work cover?
Five separate jobs, each with its own fix:
- Format: the file type (JPEG, PNG, WebP, AVIF, SVG).
- Compression: how much quality you trade for bytes.
- Dimensions: the pixel size of the file against the size it shows on screen.
- Loading order: which images load first and which wait.
- Reserved space: telling the browser the image size so the page does not jump.
Why does it matter for SEO?
Google reads real-user data for three Core Web Vitals at the 75th percentile: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, CLS of 0.1 or less. Images hit two of them directly. A heavy hero image delays LCP, and an image without dimensions pushes text down when it arrives, which raises CLS. Google’s image documentation also lists WebP and AVIF among the formats Search supports, so modern formats cost you nothing in image search. More on speed in page speed.
Which image format should you use?
The web.dev guide on image formats gives these rules:
| Format | Use it for | Notes |
|---|---|---|
| AVIF | Photos, lossy | Generally compresses better than WebP. Works in all modern browsers. |
| WebP | Photos and graphics | Generally compresses better than PNG and JPEG. Supports transparency and animation. |
| JPEG | Photos, fallback | Works everywhere. Test several quality levels. |
| PNG | Lossless graphics that need transparency | Much larger files than the others. Use sparingly. |
| SVG | Logos and icons | Vector, stays sharp at any size. Poor for photos. |
web.dev advises WebP or AVIF where possible with a JPEG or PNG fallback, and <video> instead of animated GIF. It also says to avoid putting text inside images, so use web fonts and real HTML text.
How do you reduce image size, step by step?
- Find the heavy images. Run PageSpeed Insights on your top five pages and read “Properly size images” and “Serve images in next-gen formats”. Note the LCP element it names.
- Resize to the display size. A photo shown 800 pixels wide does not need a 4,000 pixel file. Export at the largest size it appears, times 2 for high-density screens.
- Convert to WebP or AVIF. Use Squoosh for single images, or
sharpand ImageMagick for a folder. Compare the result by eye at several quality levels and keep the lowest one that still looks clean. - Offer several sizes with
srcset. Let phones download small files:
<img src="/img/hero-800.jpg"
srcset="/img/hero-400.webp 400w, /img/hero-800.webp 800w, /img/hero-1600.webp 1600w"
sizes="(min-width: 900px) 800px, 100vw"
width="800" height="533" alt="Bakery counter with fresh sourdough loaves">Google says to always give a fallback src, because some browsers and crawlers do not understand srcset or <picture>.
5. Set width and height on every image. The browser then reserves the space before the file arrives. web.dev notes that without them, lazy-loaded images count toward layout shift, since the dimensions default to 0 by 0.
6. Lazy-load only below the fold. Add loading="lazy" to images outside the first screen. web.dev’s LCP guide says: never lazy-load your LCP image.
7. Prioritise the LCP image. Put fetchpriority="high" on the one image that is your LCP element. web.dev warns that setting high priority on more than one or two images makes it meaningless. Make sure the image URL sits in the HTML as a normal src or srcset, not injected by JavaScript or hidden in data-src (see JavaScript SEO).
8. Automate it. Use your CMS’s image pipeline or an image CDN so new uploads convert and resize themselves. Hand-compressing every upload does not last past month two.
How do you measure the result?
- PageSpeed Insights and the Chrome UX Report: compare the LCP value in the field data before and after, over 28 days.
- Search Console, Core Web Vitals report: URLs should move from Poor or Needs improvement to Good.
- WebPageTest waterfall: the LCP image should start downloading early and its
Content-Lengthshould drop. - Lighthouse: the image audits (“Properly size images”, “Efficiently encode images” and “Image elements have explicit width and height”) should pass.
web.dev’s LCP breakdown suggests the browser should find the LCP image almost immediately: resource load delay under about 10% of total LCP time. Treat that as a guide, not an exact target.
What mistakes should you avoid?
- Lazy-loading the hero image. It always adds delay to LCP.
- Using CSS background images for content images. Google does not index CSS images, and the browser finds them late.
- Missing dimensions. Every unsized image is a layout shift waiting to happen.
- Inline Base64 images. Google allows them, but warns they can greatly increase page size.
- Wrong file extension. Google recommends that the extension matches the actual file type.
- Compressing until it looks bad. A blurry product photo costs sales faster than a slow one costs rankings. Check the result by eye.
- Forgetting descriptions. Faster images still need good alt text.
Where can you learn more?
The web.dev “Learn Images” course goes deeper on every point above. For a full walk through of speed and on-page work for a new site, the free digital marketing module of the Fe/male Switch startup school is a good start. Next steps: list your important images in an image sitemap and run the landing page analyzer on your top page.