Skip to content

Guide

Compressing images for page speed: what LCP actually needs

A hero image is very often the single biggest lever on a page's Largest Contentful Paint score.

By Published

Core Web Vitals scores a page on Largest Contentful Paint — the time until the biggest visible element (almost always a hero image, banner, or above-the-fold photo on content sites) finishes rendering. Google’s threshold for “good” is 2.5 seconds at the 75th percentile of real visits. On image-heavy pages, that single image’s file size is frequently the largest lever available — a 4MB uncompressed photo can single-handedly push LCP past the threshold on a mid-tier mobile connection, while a properly compressed version of the same photo loads in a fraction of a second.

Why file size dominates LCP on image-heavy pages

Download time scales directly with bytes transferred and available bandwidth. On a 4G connection realistically averaging a few megabits per second, a 3-4MB unoptimized photo can take a full second or more just to download, before the browser even decodes and paints it — and that’s before accounting for server response time, DNS lookup, and any render-blocking resources ahead of it in the loading sequence. Compress that same photo to a properly sized WebP file under 200KB and the download portion of LCP effectively disappears from the budget.

Realistic size targets

Image roleReasonable target size
Full-width hero / banner100-250KB
In-article photo50-150KB
Thumbnail / card image10-40KB
Icon / logo (use SVG where possible)Under 10KB

These targets assume the image has also been resized to match its actual display dimensions — serving a 4000px-wide source file into a 1200px-wide hero slot wastes bandwidth on pixels the browser immediately discards, regardless of how well the file is compressed. Combine resizing to the display size with format and quality compression for the biggest improvement.

Format choice matters as much as the quality slider

For photographic content, WebP typically beats JPEG by 25-35% at matched visual quality, and every major browser has supported it since 2020 — there’s little reason to default to JPEG on a modern site. For graphics with large flat color areas, sharp edges, or text (screenshots, diagrams, logos), compare WebP against PNG rather than assuming WebP wins automatically; see PNG vs JPG vs WebP for how to decide. Whichever format you land on, the combination of correct pixel dimensions plus a sensible quality setting (75-85 for WebP/JPEG) is what actually moves the LCP number — not the format alone.

Frequently asked questions

What's a good LCP score?
Google's threshold for 'good' is 2.5 seconds or faster at the 75th percentile of real user visits. Between 2.5 and 4 seconds is 'needs improvement'; above 4 seconds is 'poor'. On most content-heavy pages, the LCP element is a large image, so the compression and format of that one image often decides which bucket the page lands in.
Does image compression alone fix a slow LCP?
Usually most of the way, but not entirely. File size drives download time, which is typically the largest chunk of LCP on image-heavy pages, but render-blocking CSS/JS, server response time, and whether the image is prioritized for early loading also contribute. Compressing the LCP image is the highest-leverage single fix on most sites, not the only one.
Should I use WebP for every image to help page speed?
For photos, yes in almost all cases — WebP typically produces 25-35% smaller files than JPEG at equivalent visual quality, and all major browsers have supported it since 2020. For screenshots or graphics with large flat color areas and text, compare WebP against PNG, since PNG's lossless compression can occasionally win on that content.

Sources & references

Authoritative references cited by this piece. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

Related

More guides on this topic

Published September 25, 2026