BlogImage Compression

How to Compress Website Images for Better Page Speed

Learn how to resize, compress, and serve responsive website images without avoidable quality loss, then verify the impact on LCP and page speed.

June 21, 2026

Updated: June 21, 2026

To compress website images for better page speed, follow this sequence: measure your current LCP baseline, choose the right format for each image type, resize each image to its largest rendered dimension, compress with your encoder's quality controls, serve responsive variants with srcset, and re-test. When the LCP element is an image and image transfer time is a meaningful bottleneck, reducing file size can shorten the time that image takes to load and improve your LCP score. The steps below show exactly how to do each one.

Key Takeaways

Measure before you compress. Run PageSpeed Insights or Lighthouse first so you have a baseline to compare against.
Format selection has the biggest single impact. Switching from JPEG or PNG to a modern format often yields substantial savings before you adjust quality.
Resize to display size. A source image much wider than its rendered container wastes bandwidth that compression alone cannot recover.
Serve responsive variants. Use srcset so phones and desktops each download an appropriately sized file.
Never lazy-load the hero image. The LCP element must load eagerly; lazy-loading it directly delays the metric you are trying to improve.
Verify with metrics, not just file size. LCP, not kilobytes, is the goal.

How Image Size Affects Page Speed and LCP

Images are frequently among the heaviest resources on a page. According to the HTTP Archive Web Almanac, images consistently account for the largest share of page weight across the web.

Largest Contentful Paint (LCP) measures the time from when the page begins loading until the largest visible content element — often a hero image — finishes rendering. Google's page experience documentation confirms that Core Web Vitals are among the signals Google's ranking systems use, though content relevance remains the primary factor. An LCP score of 2.5 seconds or faster (measured at the 75th percentile of real page loads) is considered good by the Core Web Vitals standard.

Reducing image file size can shorten network transfer time for the LCP image, which may improve LCP — but only when image loading is actually the bottleneck. LCP is also affected by server response time (TTFB), when the browser discovers the resource, and render-blocking delays.

Measure Before You Compress

Before touching a single image, establish a baseline:

Open PageSpeed Insights and enter the URL of your slowest page.
Note the current LCP value and identify which element it measures.
Check the Network tab in browser DevTools to find the file size, format, and dimensions of the LCP image.
Record these numbers — you will compare them after optimizing.

Lab data vs. real user data: Lighthouse (and the lab section of PageSpeed Insights) gives you immediate, repeatable results useful for before/after comparison. The CrUX field data in PageSpeed Insights reflects real user measurements aggregated over roughly 28 days at the 75th percentile; it will not update immediately after you deploy a change. Use lab data for iteration, and field data to confirm sustained improvement.

Choose the Format and Compression Mode

Format selection typically has the largest impact on file size. The right choice depends on image content, not just personal preference.

Format Decision Table

Image type	Recommended format	Compression mode	Why
Photographs, hero images	AVIF (WebP fallback)	Lossy	Modern formats often produce smaller files than JPEG at comparable visual quality
General web graphics	WebP	Lossy or lossless	Widely supported in current browsers; good balance of quality and size
Logos, icons, line art	SVG	Vector (lossless)	Scales without quality loss; often very small
Screenshots of text, diagrams	PNG or lossless WebP	Lossless	Preserves sharp edges and text readability
Transparent raster images	WebP, AVIF, or PNG	Lossy or lossless	WebP and AVIF both support alpha; PNG for maximum compatibility
Legacy fallback	JPEG	Lossy	Universally supported; use only when modern formats are not viable

Practical serving strategy: Use a <picture> element to offer AVIF first, then WebP, then JPEG. The browser picks the first format it supports:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Descriptive alt text" width="800" height="450" />
</picture>

Check Can I Use — AVIF and Can I Use — WebP for current browser compatibility data before deciding which formats to generate for your specific audience.

Lossy vs. Lossless

Lossy: Discards data the eye is unlikely to notice. Use for photographs and most web images. This is where meaningful file size reductions come from.
Lossless: Preserves every pixel. Use only for images where exact reproduction matters: screenshots of text, interface diagrams, or images you will edit again.

Quality settings: Each encoder (libjxl, libwebp, ffmpeg for AVIF, etc.) uses its own quality scale, so a "quality 80" in one tool is not the same as "quality 80" in another. Start from your tool's medium-to-high quality preset, reduce incrementally, and compare the result at full display size. The goal is the lowest setting where you cannot see a meaningful difference — not a fixed number.

Resize Images and Generate Responsive Variants

No encoding format fixes the problem of serving a source image that is far larger than its rendered size. If your layout renders an image at 800 px wide and your source is 4000 px wide, the source is five times wider — and if the aspect ratio is the same, it contains roughly 25 times as many pixels as the display actually uses.

How to size correctly:

Inspect the rendered width of the image at each breakpoint (browser DevTools → Elements → Computed).
Generate size candidates that cover your breakpoints. For high-density screens, you may want a 2× candidate for a given layout width, but confirm this against your actual srcset descriptors and layout rather than applying it universally.
Compress each candidate at the target quality for that size.
Do not re-export a source image at a larger dimension just to fill a bigger display slot if the original source is smaller — this increases file size without improving visible quality.

Note for CMS and CDN users: If your platform (WordPress with a modern image plugin, Cloudflare Images, Cloudinary, Imgix, etc.) already generates responsive variants automatically, do not repeat this step manually. Redundant processing can produce inconsistent outputs and wastes time.

Serve Images Without Delaying LCP

How an image is loaded matters as much as its file size.

Non-LCP images (below the fold)

<img
  src="content-image-800.webp"
  srcset="content-image-400.webp 400w, content-image-800.webp 800w, content-image-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800"
  height="450"
  alt="Descriptive alt text"
  loading="lazy"
/>

LCP image (above the fold, hero)

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800"
  height="450"
  alt="Descriptive alt text"
  loading="eager"
  fetchpriority="high"
/>

Critical attributes:

width and height on every <img>: reserves space in the layout and prevents Cumulative Layout Shift (CLS). The CLS threshold for a "good" score is 0.1 or less at the 75th percentile.
loading="lazy" only for images below the fold. Never apply it to the LCP image — it directly delays the element LCP measures.
fetchpriority="high": signals to the browser that this resource is important. Consider adding a <link rel="preload"> for the LCP image only if it is discovered late (for example, in a CSS background or injected by JavaScript). Images in the initial HTML <img> tag are typically discovered early without a preload.

Compress With LessMB and Verify the Result

Once you have generated the correctly sized and formatted files, compress them before uploading. If you want a no-sign-up, browser-based workflow, LessMB compresses supported image files locally on your device — nothing is uploaded to a server and no account is required.

Illustrative before/after example (values will vary by image content, encoder, and settings):

	Before	After
Format	JPEG	WebP
Dimensions	2400 × 1600 px	800 × 533 px
File size	1.2 MB	98 KB
LCP (Lighthouse lab)	4.1 s	2.1 s
Visible quality difference	—	None at display size

Label this as illustrative: your results will differ. Always verify with your own images and measure LCP before drawing conclusions.

Verification Checklist

Check	How to verify	What to look for
File size reduced	Compare bytes before and after	Meaningfully smaller than the original; exact reduction depends on the source
No unacceptable quality loss	View at actual display size (100% zoom)	Indistinguishable to the eye at normal viewing distance
LCP improved	Lighthouse before/after (lab data)	LCP moves toward or below 2.5 s
Correct format served	DevTools → Network → Response Headers	`Content-Type: image/avif` or `image/webp` as expected
No layout shift introduced	Lighthouse CLS audit	CLS score 0.1 or lower
Field data improving	PageSpeed Insights CrUX (28-day lag)	LCP at the 75th percentile trending downward over subsequent weeks

Lab vs. field data reminder: Lighthouse lab scores update immediately and are ideal for iteration. CrUX field data in PageSpeed Insights aggregates real user sessions over roughly 28 days — do not expect it to reflect your optimization the same day you deploy.

Common Mistakes to Avoid

Resize first, then perform the final encode. Resizing after compressing discards your compression work.
One format for everything. Photos suit AVIF or WebP; logos suit SVG; transparency in raster images can use WebP, AVIF, or PNG depending on your compatibility requirements.
Lazy-loading the hero image. This directly delays the element LCP measures.
Omitting width and height. Without these attributes, the browser cannot reserve layout space, which causes content to shift as the image loads.
Evaluating quality on a small preview. Compression artifacts and softness are most visible at actual display size; always check there.
Re-optimizing images your CMS or CDN already handles. Check your platform's output before running additional tools.

Website Image Optimization Checklist

Use this before publishing any page with images:

FAQ

What is the best image format for page speed?

For photographic content, AVIF often produces smaller files than JPEG or WebP at comparable visual quality, though results vary by encoder and image content. WebP is widely supported in current browsers and is a practical choice for most sites. Use SVG for logos and icons, and PNG or lossless WebP when you need full transparency in raster images with specific compatibility requirements.

Does compressing images improve SEO?

Indirectly. Smaller images can reduce the time it takes for the LCP element to load, which may improve your LCP score — one of the Core Web Vitals signals Google's ranking systems consider alongside content relevance. The effect depends on whether the LCP element is an image and whether image transfer time is actually the bottleneck. See Google's page experience documentation for how these signals interact.

Will image compression make images look blurry?

Not if you compress carefully. Blurriness usually results from excessive compression, upscaling a lower-resolution image, or serving an image at a much smaller dimension than the source. Use your tool's medium-to-high quality preset as a starting point and compare the result at actual display size before publishing.

How large should website images be?

Images should be sized close to their largest rendered dimension, accounting for high-density displays where relevant. Generate multiple size candidates using srcset so each device downloads only what it needs. There is no single universal pixel limit — it depends on your layout, breakpoints, and device mix.

Should I lazy-load the hero image?

No. The hero image is often the LCP element. Applying loading="lazy" to it delays rendering and worsens LCP. Only lazy-load images that appear below the fold.

Should I use AVIF or WebP?

Use AVIF if your audience's browsers support it and your toolchain can generate it reliably. Fall back to WebP for broader compatibility. The practical approach is to serve AVIF with a WebP fallback inside a <picture> element, so each browser receives the best format it supports. Check caniuse.com/avif for current support data.

How can I test whether compression improved LCP?

Run a Lighthouse audit or use PageSpeed Insights before and after the change. Lighthouse gives you immediate lab data useful for before/after comparison. PageSpeed Insights also shows CrUX field data (real user measurements over roughly 28 days at the 75th percentile), which won't reflect your change immediately but is the most meaningful long-term signal.