Guides
performanceimagescore-web-vitals

How to Compress Images for the Web Without Killing Your Core Web Vitals

Images account for 37-44% of page weight and are the #1 cause of slow Largest Contentful Paint scores. Learn which formats to use, the right quality settings, and a practical compression workflow that keeps your site fast.

A
Avidity Studio Team
February 2, 2026
8 min read

How to Compress Images for the Web Without Killing Your Core Web Vitals

You've built your landing page, polished the copy, and you're ready to launch. Then you run Lighthouse. Your performance score is 52, the hero image takes 4 seconds to load, and Google flags your Largest Contentful Paint as "Poor." The culprit? A single uncompressed 3MB JPEG.
This happens more often than you'd think, and it's almost always preventable. Images are the single biggest lever you have for improving web performance. In this guide, we'll cover the formats that matter in 2026, the quality settings that actually work, and a practical workflow you can use today.
What we'll cover:
  • Why images are your biggest performance bottleneck
  • JPEG vs PNG vs WebP — when to use each
  • The right compression quality settings
  • A practical step-by-step workflow
  • Quick wins checklist

Why Images Are Your Biggest Performance Problem

The numbers are clear. According to the 2025 Web Almanac by HTTP Archive, the median web page weighs 2.86 MB on desktop and 2.56 MB on mobile. Images account for roughly 1,059 KB of that — about 37% of total page weight, making them the single heaviest resource type.
And here's why that matters for SEO: images are the LCP element on over 50% of websites. LCP (Largest Contentful Paint) measures how long it takes for the biggest visible element to load, and Google uses it as a direct ranking signal. The threshold is 2.5 seconds — anything slower and you're penalized.
The business impact is real:
CompanyLCP ImprovementResult
Vodafone31% faster8% increase in sales
Renault1 second faster14% reduction in bounce rate
The Economic Times80% faster (to 2.5s)43% reduction in bounce rate
If your LCP is slow, start with images. It's usually the biggest quick win.

JPEG vs PNG vs WebP: When to Use Each

Not every image should be the same format. Here's a quick decision guide:
FormatBest ForCompressionBrowser SupportTypical Size
JPEGPhotos, gradientsLossy100%Baseline
PNGLossless screenshots, text, diagramsLossless100%2-5x larger than JPEG
WebPBoth photos and graphicsLossy + Lossless96.5%~30% smaller than JPEG
The short version:
  • Use WebP as your default. It's 30% smaller than JPEG at equivalent visual quality and supported by every major browser (Chrome, Firefox, Safari, Edge).
  • Use PNG when you need lossless reproduction — screenshots with text, technical diagrams, or pixel-art. (WebP also supports transparency, so PNG's real advantage is lossless fidelity.)
  • Use JPEG as a fallback for environments where WebP isn't supported (increasingly rare).

What About AVIF?

AVIF achieves roughly 50% smaller files than JPEG — impressive. But browser support is at 85.2%, and encoding is significantly slower. It's worth using if your build pipeline supports it (Next.js, Cloudflare Images, etc.), but WebP remains the safer default for most projects.
A concrete example: a 2000×2000 product photo at comparable visual quality:
  • JPEG (Q80): ~540 KB
  • WebP (Q85): ~350 KB
  • AVIF (CQ28): ~210 KB

The Right Quality Settings

This is where most developers either over-compress (blurry images) or barely compress at all (huge files). The sweet spot is simpler than you think.

The 80% Rule

Quality 80% is the sweet spot for most images. Here's why:
  • Above 90%: Diminishing returns. The file size increases dramatically, but the visual difference is nearly invisible. A JPEG at Q95 can be 3-4x larger than Q80 with no perceptible improvement.
  • 70-85%: The golden range. File sizes drop significantly while quality remains excellent for web display.
  • Below 60%: Visible artifacts appear — banding in gradients, halos around text, blocky compression noise.
For most web images (hero banners, product photos, blog images), start at 80% and adjust from there. Always check the result visually — some images with fine detail may need 85%, while simple graphics can go as low as 70%.

A Practical Compression Workflow

Here's the workflow we use for every project:

Step 1: Choose the Right Format

Photo or complex gradient?  → WebP (or JPEG fallback)
Needs transparency?         → WebP (or PNG fallback)
Simple graphic or icon?     → SVG if possible, otherwise WebP
Screenshot with text?       → PNG (text stays sharp)

Step 2: Resize to Display Dimensions

Don't just compress — resize first. Serving a 4000×3000px image in an 800px container wastes bandwidth no matter how aggressively you compress it. Resize images to the largest size they'll actually be displayed at, then compress.
Common target widths:
  • Hero images: 1200-1600px
  • Blog content images: 800px
  • Thumbnails: 400px

Step 3: Compress at 80% Quality

Use our Image Compressor — it runs entirely in your browser (your images never leave your device), supports JPEG, PNG, and WebP, and lets you adjust quality with a slider. Drag in multiple files and download them all as a ZIP.

Step 4: Implement Lazy Loading

Add
loading="lazy"
to every image below the fold. Don't lazy load your hero image — it's likely your LCP element and needs to load immediately.
<!-- Hero image: load immediately -->
<img src="hero.webp" alt="..." width="1200" height="600">

<!-- Below-the-fold: lazy load -->
<img src="feature.webp" alt="..." loading="lazy" width="800" height="400">

Step 5: Set Width and Height to Prevent Layout Shift

This prevents Cumulative Layout Shift (CLS) — another Core Web Vital. Without explicit dimensions, the browser doesn't know how much space to reserve, causing content to jump as images load. You'll notice the code examples above already include
width
and
height
— make this a habit for every
<img>
tag.

Quick Wins Checklist

If you do nothing else, do these:
  • Convert images to WebP — 30% smaller than JPEG with no visible quality loss
  • Compress at 80% quality — the sweet spot for size vs. quality
  • Resize before uploading — serve images at display size, not original size
  • Add
    loading="lazy"
    to below-the-fold images
  • Set
    width
    and
    height
    on every
    <img>
    tag to prevent layout shift
  • Preload your hero image
    <link rel="preload" as="image" href="hero.webp">
    helps LCP
  • Use
    srcset
    for responsive images
    — serve smaller files to mobile devices
  • Audit regularly — page weight creeps up over time as content is added

Frequently Asked Questions

Does WebP work on all browsers?

Effectively, yes. WebP has 96.5% global browser support — every current version of Chrome, Firefox, Safari, and Edge handles it natively. The remaining ~3.5% is outdated browsers that are rarely encountered in practice. For maximum safety, use a
<picture>
element with a JPEG/PNG fallback.

Should I use AVIF instead of WebP?

AVIF produces smaller files (~50% smaller than JPEG vs. WebP's ~30%), but browser support is at 85.2% and encoding is slower. If your build pipeline supports it (Next.js
next/image
, Cloudflare Images, or Vercel's image optimization), serve AVIF with a WebP fallback. Otherwise, WebP alone gets you most of the benefit with zero compatibility risk.

Do I need to compress SVGs?

SVGs are already lightweight, but they can contain unnecessary metadata from design tools. Run them through SVGO to strip editor cruft — it typically reduces file size by 20-40% without changing the visual output.

How often should I audit my page weight?

Every time you add new content. It's easy to upload a 2MB hero image to a blog post without thinking about it. Run Lighthouse or PageSpeed Insights after publishing to catch regressions before they affect your rankings.

Key Takeaways

  • Images are the #1 bottleneck — they account for 37% of page weight and are the LCP element on over half of all websites
  • WebP should be your default format — 30% smaller than JPEG with 96.5% browser support
  • 80% quality is the sweet spot — significant size reduction with no visible quality loss
  • Resize before compressing — don't serve 4000px images in 800px containers
  • Lazy load below the fold, preload above it — treat your hero image as the LCP-critical asset it is

Try It Yourself

The Image Compressor is free to use. No signup required, no limits. Your images are processed entirely in your browser — nothing gets uploaded to a server. Drag in your files, adjust the quality slider, and download the compressed versions individually or as a ZIP.
If you're launching a new project, pair image optimization with smart domain name selection and consistent social handles to set your brand up for success from day one.

Questions or feedback? Reach out — we'd love to hear how you're optimizing your site's performance.