BlogImage Compression

Image Compression Checklist: Optimize Images for Faster Pages

Use this image compression checklist to resize, choose WebP or AVIF, compress, serve responsive images, and verify page performance.

Updated: June 22, 2026

A complete image compression workflow runs in three phases. Before you upload, resize the image to its largest display size, choose the right format for the content type, strip unnecessary metadata, and apply lossy or lossless compression. In your page template, set width and height on every <img>, serve responsive variants with srcset and sizes, keep the LCP hero image out of lazy loading, and add fetchpriority="high" only to confirmed LCP candidates. After publishing, verify with Lighthouse image diagnostics, PageSpeed Insights, and Chrome DevTools. There is no single format, quality value, or file-size target that fits every image — the right answer depends on the content, the encoder, and what a side-by-side visual check tells you.

Key Takeaways

  • Resize before you compress. Serving a 4 000 px-wide photo into a 640 px column wastes more bytes than any other mistake on this list.
  • Test AVIF and WebP for photos; SVG for icons. Both formats are supported by current major browsers. Test both and keep the smaller result at acceptable quality.
  • The LCP image is special. Do not add loading="lazy" to it. Consider fetchpriority="high" only after confirming it is the LCP candidate.
  • Always set width and height. It is the fastest fix for Cumulative Layout Shift and requires no tooling.
  • Verify, do not guess. Lighthouse image diagnostics and PageSpeed Insights field data show what is actually being delivered and where it hurts.

How Image Weight Affects Page Performance

Images are not a minor asset. According to the 2024 HTTP Archive Web Almanac (Media chapter, Judis & Portis), images are the Largest Contentful Paint element on approximately 68% of mobile pages. When images are slow, LCP is slow — and Core Web Vitals are used by Google's ranking systems as part of page experience signals, though strong scores do not guarantee higher rankings on their own.

Page weight also drives bandwidth costs and abandonment risk. A high-density display contains four times as many pixels as a 1× screen of the same CSS dimensions, which can substantially increase transfer size if you serve the same single file to every device. Compression and responsive delivery are the most direct levers for reducing that transfer cost.

Which Image Format Should You Choose?

When to Choose AVIF, WebP, JPEG, PNG, or SVG

Content typeRecommended formatWhyWatch out for
Photographs, complex imageryAVIF (test against WebP)Often achieves smaller files at equal visual quality for photographs; supported by current major browsersEncoding can be slow; results vary by image content and encoder
Most photos, general useWebP (lossy or lossless)According to Google's WebP documentation, lossy WebP is typically 25–34% smaller than a comparable JPEG at equivalent quality, and lossless WebP is about 26% smaller than PNGTest against AVIF; results vary per image
Logos, icons, UI art, simple chartsSVGResolution-independent, very small for simple shapes, crisp on any screenComplex SVGs can be large; sanitize before serving untrusted SVGs
Screenshots with text or flat colorPNG or lossless WebPKeeps sharp edges and text without compression artifactsToo large for photographs; do not use for people or nature photos
Short animationsVideo (MP4/WebM)Typically far smaller than GIF at similar quality per web.dev guidanceProvide a poster image; ensure controls or autoplay attributes match accessibility needs

Add a fallback format (JPEG or PNG) only if your audience data, embedded WebView targets, or platform requirements justify the added complexity. For most sites targeting current browsers, AVIF with a WebP fallback is sufficient.

Before Upload: Prepare and Compress the Source Image

Work through these items on every image before it reaches your CMS.

  • Export at display size, not capture size. Resize to the largest CSS size the image will render at, multiplied by the maximum device-pixel ratio you support (usually 2×). The 2024 HTTP Archive Web Almanac reports that a substantial share of pages send images larger than the viewport's maximum displayable pixel count — pure wasted transfer.
  • Choose the format deliberately. Use the table above. Test AVIF and WebP for photographs and keep the smaller result. Use SVG for logos and icons. Use PNG only when lossless detail is required.
  • Strip metadata you do not need. EXIF camera data, GPS coordinates (which also carry a privacy risk), and embedded thumbnails can add kilobytes that never reach the viewer. Keep color profiles (ICC/CICP) so colors render correctly across displays.
  • Compress to a sensible quality. Quality scales differ by encoder, so 70–80 on a 0–100 tool is a rough starting point, not a universal rule. Always do a side-by-side visual check at the intended display size. For lossless assets — line art, screenshots with text — use lossless mode. Stop compressing when further reduction causes visible quality loss; going lower does not always produce a smaller file after encoding overhead.
  • Never upscale. Enlarging a small source to fill a larger slot adds bytes and introduces blur. Capture or request a higher-resolution source instead.
  • Work from the original. Re-compressing an already lossy file compounds artifacts and can even increase file size. Always start from an uncompressed or minimally compressed source.

As a pre-upload check, you can test an exported image with LessMB and compare the result with the original at its intended display size before finalizing your upload.

In Your Page Template: Deliver the Right Image

Compression at the file level only pays off if you deliver the image correctly.

  • Set width and height on every <img>. The browser needs these values to reserve the layout box before the image loads. Make sure the values reflect the correct aspect ratio.

    <img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="533"
  alt="A mountain trail winding through pine forest in early morning light"
  loading="lazy">

    For decorative images that convey no content, use an empty alt: alt="".

  • Serve responsive variants with srcset and sizes. Generate a few widths (for example 400, 800, 1 200, and 1 600 px) and let the browser pick the best candidate for the viewport and device pixel ratio.

  • Keep the LCP image out of lazy loading. Do not add loading="lazy" to the hero or any image above the fold. The default loading behavior is already eager; making it explicit with loading="eager" does no harm.

  • Add fetchpriority="high" only to confirmed LCP candidates. Use it on the single most important above-the-fold image after confirming it is the LCP element in Lighthouse or PageSpeed Insights. Applying it to multiple images defeats the purpose.

  • Consider <link rel="preload" as="image"> only when testing shows a benefit. Preloading is useful when the LCP image is discovered late in the HTML (for example, injected by JavaScript), but it competes for bandwidth and should be validated with real measurements before deploying.

  • Use descriptive, specific alt text. Write what the image shows in the context of the page. Do not keyword-stuff. Decorative images should use alt="" so screen readers skip them.

  • Serve over a CDN with appropriate cache headers. Long Cache-Control lifetimes reduce repeat-visitor transfer costs. Brotli and gzip compress SVG and text assets effectively but do not re-compress raster images.

Image Delivery by Page Position

Image positionloadingfetchprioritysrcset/sizesNotes
Hero / LCP candidateeager (default)high (if confirmed LCP)YesNever lazy-load; validate in Lighthouse before adding preload
Above the fold, not LCPeager (default)OmitYesDo not lazy-load above-the-fold images
Below the fold (body, gallery)lazyOmitYesNative lazy loading is supported by current major browsers per MDN
Thumbnails in listslazyOmitRecommendedKeep dimensions small; CLS risk if width/height omitted

After Publishing: Verify the Result

Compression you cannot measure is just guesswork. Run these checks after every significant image update.

  • Lighthouse image diagnostics. Run a Lighthouse audit and review the image delivery and sizing diagnostics. These list images that are too large or poorly encoded, with estimated byte savings.
  • PageSpeed Insights. Shows lab performance metrics and, where there is enough traffic, field data from the Chrome UX Report (CrUX). Both LCP and CLS are visible per URL.
  • Chrome DevTools Network panel. Filter by Img, sort by transfer size, and confirm you are not shipping multi-megabyte files. Check the type column to verify AVIF or WebP is actually being served, not a fallback JPEG.
  • Search Console Core Web Vitals report. Monitors LCP and CLS at scale across URL groups. A regression after publishing a content batch often traces back to one oversized image.
  • Re-audit after major template or plugin updates. A CMS or framework update can silently revert lazy loading or strip width and height attributes.

Pass/Fail Verification Checklist

CheckPassFail
Natural image dimensions ≤ 2× largest CSS render size✓Image is wider or taller than needed
width and height set and match aspect ratio✓Missing or mismatched
LCP image has no loading="lazy"✓loading="lazy" present on hero
Format delivered is AVIF or WebP (verify in Network panel)✓JPEG or PNG delivered when modern format available
Visual quality acceptable at display size✓Visible artifacts or blur
LCP in PageSpeed Insights ≤ 2.5 s (good threshold)✓LCP > 4.0 s (poor)
CLS score < 0.1✓Layout shift visible or score ≥ 0.25

Compression before/after record example:

FileOriginalCompressedSavingVisual checkLCP change
hero.jpg → hero.avif1 200 KB180 KB85%Pass3.8 s → 1.9 s
sidebar.png → sidebar.webp340 KB62 KB82%Pass—

Common Image Compression Mistakes That Undo Your Work

  • Lazy-loading the hero image. This single mistake can add significant time to LCP because the browser deprioritizes what should be the most important asset.
  • Scaling a large image with CSS instead of resizing it. The browser downloads every pixel regardless of how it is displayed.
  • Re-compressing an already-compressed JPEG. Each lossy pass compounds artifacts. Work from the original.
  • Omitting width and height. The layout shifts when the image loads, and your CLS score reflects it.
  • Treating "smallest file" as the only goal. Below a threshold, compression removes perceptible detail. Compare side by side and keep the smallest file that still looks correct.
  • Optimizing images in isolation. A perfectly compressed hero still loads slowly behind render-blocking scripts or a slow server response time (TTFB).

FAQ

What is the best image format for a blog?

Test AVIF and WebP for photographs and serve whichever produces the smaller file at acceptable visual quality. Use SVG for logos and icons. Use PNG only for screenshots or graphics that require lossless detail. Add a JPEG or PNG fallback only if your audience data or platform requirements justify it — many modern sites targeting current browsers do not need one.

What quality level should I use when compressing images?

Quality scales differ between encoders, so there is no universal starting number. A common starting point for lossy photos is somewhere in the 70–80 range on tools that use a 0–100 scale, but always perform a side-by-side visual check at the intended display size and adjust until the result looks correct. Stop when further reduction causes visible quality loss.

Should I lazy-load every image on my page?

No. Never add loading="lazy" to the LCP or hero image, and skip it for anything above the fold. Reserve lazy loading for images that are below the fold and not visible on first paint.

Do responsive images still need width and height attributes?

Yes. Even with srcset and sizes, always include width and height so the browser reserves the correct layout space before the image loads, preventing shifts and protecting CLS. Ensure the values reflect the correct aspect ratio.

How large should a website image file be?

There is no single target, but keeping hero images under 200 KB and inline body images under 100 KB after compression is a practical starting point. Verify actual impact with Lighthouse and PageSpeed Insights field data, and stop compressing when further reduction causes visible quality loss.

Is AVIF always smaller than WebP?

Not always. AVIF often achieves smaller file sizes for photographs, but results vary by image content, encoder, and quality setting. Test both and keep whichever delivers smaller files at acceptable visual quality.

Should I compress images before uploading them to a CMS?

Yes. Compressing before upload gives you direct control over format, dimensions, and quality. CMS platforms may resize or re-encode automatically, which can undo optimizations or introduce extra lossy passes.

How can I tell which image is the LCP element?

Run a Lighthouse audit in Chrome DevTools or PageSpeed Insights. Both identify the LCP element and report its URL, size, and load time. The Performance panel in DevTools also marks the LCP event on the timeline.

Sources