Large images are often the heaviest thing on a page. Here is what actually makes them lighter — measured on a real photograph — and the part of a slow page that compression cannot fix.
Quick answer:
Resize each image to about twice the width it is shown at, compress it, and save it as WebP or AVIF. On the photograph we measured, that took an 810 KB file down to 140 KB–172 KB, and a responsive set let a phone download just 47 KB.
Do images slow a page down?
Often more than anything else on it. An image is the largest thing painted on 73.3% of mobile pages and 83.3% of desktop pages (HTTP Archive Web Almanac 2024), so its size and its timing decide Largest Contentful Paint.
Will optimizing images improve my Google ranking?
Nobody can promise that, and we will not. Google says Core Web Vitals are used by its ranking systems — and that good scores do not guarantee high rankings (Google Search Central). Optimized images improve loading and the experience of the people who visit.
What size should an image on a web page be?
About twice the width it is displayed at, so it stays sharp on high-density screens. A photo shown 800 px wide needs a 1600 px file, not the 4000 px one the camera made.
WebP or AVIF?
Both beat JPEG. On our test photo, at the same visual quality, WebP was 25.8% smaller than JPEG and AVIF 39.5% smaller. WebP opens in every current browser; AVIF needs Chrome 85+, Firefox 93+ or Safari 16+.
Is compressing enough to fix a slow LCP?
Often not. It shortens the download. web.dev found the median page with a poor LCP waits almost four times longer to START downloading its main image than to download it — so do not lazy-load that image, and let the browser find it early.
Every item below is a control on the image compressor. It all
runs in your browser; the images never leave your device.
✓ Reduce image file size — the Quality slider, which
shows what each setting really costs on your own image before you commit to it.
✓ Resize oversized images — Resize: a preset long edge
or an exact width and height. Nothing is ever enlarged.
✓ Convert JPG or PNG to WebP — the Output chips. The
panel under them measures which format comes out smallest for your image.
✓ Convert to AVIF — the same chips. Its encoder is 3.4 MB, so it is
only downloaded if you pick it.
✓ Preserve transparency — PNG and WebP keep it. A transparent image is
only flattened if you choose JPG yourself.
✓ Generate responsive image sizes — Responsive sizes
makes 480 to 2000 px copies in one ZIP, with the srcset code for each image,
including its real width and height.
✓ Do a whole folder at once — on desktop, drop a folder or choose one;
the download keeps the same folders.
One photograph, measured step by step
A real 2,725 × 2,225 photograph (810 KB), taken through each
step. Download time is the file alone at 1.6 Mbps, the connection Lighthouse uses for
its mobile test.
Step
Pixels
File
Download
Smaller
The photo as it came off the camera
2,725 × 2,225
810 KB
4.05 s
—
Compressed only (JPEG, quality 75, same size)
2,725 × 2,225
578 KB
2.89 s
28.6%
Resized to 1600 px wide, then compressed (JPEG)
1,600 × 1,306
232 KB
1.16 s
71.4%
Same, saved as WebP at the same visual quality
1,600 × 1,306
172 KB
0.86 s
78.8%
Same, saved as AVIF at the same visual quality
1,600 × 1,306
140 KB
0.7 s
82.7%
The 800 px WebP a phone picks from a responsive set
800 × 653
47 KB
0.23 s
94.2%
Resizing did most of the work. Taking the photo down to the size a page
actually shows removed 578 KB on its own;
changing the format then took off another 60 KB
to 91 KB. Compressing the full-size photo
without resizing saved only 28.6%.
Quality numbers do not travel between formats. At the same setting of
"75", AVIF came out larger than WebP (228 KB against 122 KB). That is not
AVIF losing; 75 simply means something different to each encoder. The WebP and AVIF rows above
are compared at the same visual error as the JPEG — the smallest file each needs to
look as close to the original — which is the only fair way to compare them.
One photograph, encoded with libjpeg-turbo,
libwebp and libavif — the libraries browsers and this tool are built on. Your images will land
somewhere else; a flat graphic or screenshot behaves very differently from a photo. The shape —
size first, then format — is what carries over.
What compression cannot fix
Largest Contentful Paint has four parts: the wait for the page itself, the delay before the
image starts downloading, the download, and the time to draw it. Compression shortens exactly
one of them — the download. web.dev
found that the median page with a poor LCP spends almost four times as long waiting to
start downloading its main image as it does downloading it. So check these too:
Never lazy-load the main image.loading="lazy" makes the
browser wait for layout before asking for it. Use it for images further down the page.
Let the browser find it early. Put it in the HTML as an
<img>, not as a CSS background, and consider
fetchpriority="high" on it.
Always give width and height. Without them the browser cannot reserve
the space, and the page jumps when the image arrives — that is Cumulative Layout Shift.
Serve the size the screen needs.srcset and
sizes let a phone take the small file and a large screen the big one.
The Responsive sizes button writes this for every image you compress,
with the real width and height filled in.
Reading a PageSpeed Insights report
Since Lighthouse 13 (October 2025), the separate image audits are grouped into
insights. The names changed; the advice underneath did not. Here is what each one
is pointing at, and what answers it.
Improve image delivery. This one absorbed the older "Properly size
images", "Serve images in modern formats" and "Efficiently encode images". It lists each
heavy image with an estimated saving in kilobytes. Answer it with a resize, WebP or AVIF,
and a sensible quality setting — the first three items in the list above.
LCP request discovery. This one absorbed "Preload Largest Contentful
Paint image" and "Largest Contentful Paint image was lazily loaded". It checks that the main
image is in the HTML, is not lazy-loaded and carries fetchpriority="high". No
file tool can fix this. It is a change to your markup.
Layout shift culprits. Among other causes, this names images with no
width and height. The srcset snippet this tool writes carries both,
measured from the file itself.
Two cautions. The kilobyte savings are estimates, made against a generic re-encode of
each image, so your own result can land either side of them. And a lab run on a simulated
phone is one visit under fixed conditions; the field data at the top of the report, where a
site has enough traffic, is what real visitors experienced.
Which format for which kind of image
Photographs: WebP, or AVIF where the extra saving is worth its slower
encode. JPEG is the fallback that opens absolutely everywhere.
Screenshots, charts and flat artwork: PNG or lossless WebP. Sharp text
and flat colour are what JPEG handles worst — it blurs edges and adds ringing around
lettering.
Logos and icons: SVG where you have the original vector, since it
stays crisp at any size and is often a few kilobytes. This tool does not compress SVG;
the vectorizer can trace a raster logo into one.
Anything with transparency: PNG or WebP. JPEG has no alpha channel,
so a transparent area gets filled with a solid colour.
Animations: a short muted video usually beats an animated GIF by a
wide margin. This tool keeps only the first frame of an animated GIF or WebP.
Not sure which wins for a particular picture? Drop it into the compressor. The panel
under the Output chips encodes it each way and shows which really came out smallest.
A "good" LCP is 2.5 seconds or less, measured at the 75th percentile of real visits —
web.dev: Optimize LCP.
Great content still comes first. Faster images make a page better to use; they do not
make up for a page that does not answer the question.
A short checklist
Find the page's main image: PageSpeed Insights names it as the
Largest Contentful Paint element.
Resize it to about twice the width it is shown at.
Compress it, and try WebP and AVIF — the compressor shows which is smaller.
Export responsive sizes and paste in the srcset code.
Keep width and height; never lazy-load the main image.
Lazy-load the images further down the page.
Frequently Asked Questions
Not on its own, and no tool can promise that. Google says Core Web Vitals are used by its ranking systems, and also that good Core Web Vitals scores do not guarantee high rankings. What optimized images reliably do is make pages load faster and feel better to use.
The time until the largest image or block of text in the first screen is drawn. Google counts 2.5 seconds or less as good, measured at the 75th percentile of real visits. On most pages the largest thing is an image.
About twice the width they are displayed at, then compressed. On the photograph we measured, resizing to the size a page shows cut the file by 71.4% before the format was even changed.
AVIF was smaller on our test photo: 39.5% under JPEG against 25.8% for WebP, at the same visual quality. WebP opens in every current browser; AVIF needs Chrome 85+, Firefox 93+ or Safari 16+. The compressor measures both on your own image.
No. Lazy-load the ones further down the page, never the main image at the top: loading="lazy" makes the browser wait for layout before it even asks for it, which delays Largest Contentful Paint.
Because an image is being sent bigger than the space it is shown in. Resize it to about twice its displayed width, or serve responsive sizes with srcset so each screen gets the file it needs.
No. Resizing, compression, format conversion and the responsive sizes all happen in your browser. The images never leave your device.
Yes, on desktop: drop a folder onto the compressor or choose one. Every image in it, subfolders included, is added, and the download keeps the same folders.