Image Compression for Faster Websites: Fix Core Web Vitals | Cliptics

Your site is slow. You already know that. What you might not know is that images are probably the single biggest reason why.

I pulled up PageSpeed Insights on a client site last week. LCP was 4.2 seconds. The culprit? A hero image weighing 3.8MB that nobody had bothered to compress. Ten minutes of work brought LCP down to 1.6 seconds. That one fix moved their Core Web Vitals from failing to passing. One image. Ten minutes.

If you build websites or care about SEO in 2026, image compression is not optional. Google has made that painfully clear. Let me walk you through what actually works, what the numbers look like, and how to stop leaving performance on the table.

Why Images Still Wreck Your Performance

Here is the uncomfortable truth. Images account for roughly 50% of total page weight on the average website. That number has barely changed in years despite better formats and smarter tools being available. Most teams just do not prioritize it.

Core Web Vitals care about three things: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Images directly impact LCP because your largest contentful element is almost always an image. They also impact CLS when you forget to set width and height attributes and the layout shifts as images load.

Google uses Core Web Vitals as a ranking signal. Failing means your pages get penalized in search. Passing means you are at least not shooting yourself in the foot. The threshold is clear: LCP needs to be under 2.5 seconds for the 75th percentile of your users.

The Format Question: JPEG vs WebP vs AVIF

Let me cut through the noise. Here is what you should actually use in 2026.

WebP is the safe default. Browser support is now at 97%+. It gives you 25 to 35% smaller files compared to JPEG at equivalent visual quality. If you are doing nothing else, converting your JPEGs to WebP is the single highest impact change you can make. Tools like the Cliptics WebP Compressor handle this in seconds without quality loss.

AVIF is the next step. It beats WebP by another 20 to 30% on file size. The catch is encoding speed. AVIF takes significantly longer to generate, which matters if you are processing images on the fly. Browser support is around 93%, so you still need fallbacks.

JPEG is not dead. For photographs where you need maximum compatibility and your audience includes older browsers or email clients, a well compressed JPEG at quality 75 to 80 is still perfectly fine. The Cliptics JPG Photo Compressor lets you dial in the exact quality level while previewing the output.

The smart play is using a <picture> element with AVIF as first choice, WebP as fallback, and JPEG as the safety net:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="description" width="800" height="600">
</picture>

Always include explicit width and height on your <img> tag. That alone prevents CLS issues.

Compression Settings That Actually Work

I have tested this across hundreds of sites. Here are the numbers that consistently deliver the best quality to size ratio.

For JPEG: quality 75 to 82. Below 75 you start seeing artifacts in gradients and skin tones. Above 82 the file size increase is not worth the barely perceptible quality gain.

For WebP: quality 75 to 80. WebP handles compression more gracefully than JPEG at the same quality number, so you can often go lower without visible degradation.

For AVIF: quality 60 to 70. AVIF is remarkably efficient. Quality 65 in AVIF looks comparable to quality 80 in JPEG while being half the file size.

For PNG (screenshots, graphics with text): convert to WebP lossless. You will typically see 25 to 40% file size reduction with zero quality loss. If transparency is not needed, lossy WebP or JPEG will be dramatically smaller.

The Cliptics image compression tool supports all these formats and lets you batch process entire folders. I use it regularly because the preview comparison makes it easy to find that sweet spot before committing.

Responsive Images Are Not Optional

Serving a 2400px wide image to a phone on a 4G connection is wasteful. The fix is the srcset attribute:

<img
  srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px"
  src="image-800.webp"
  alt="description"
  width="1200"
  height="800"
  loading="lazy"
>

Generate 3 to 4 size variants for each image. At minimum: mobile (400px), tablet (800px), and desktop (1200px). If you have retina users, add a 1600px or 2400px variant.

The loading="lazy" attribute is free performance. Use it on every image except the hero/LCP image. For your LCP image, you want eager loading and ideally a fetchpriority="high" attribute so the browser prioritizes it.

The Automation Layer

Manual compression does not scale. Here is what a production setup looks like in 2026.

Build time optimization: Use Sharp (Node.js) or libvips in your build pipeline. Both are fast and support WebP and AVIF output. Configure them to generate multiple sizes and formats automatically.

CDN level optimization: Cloudflare, Fastly, and AWS CloudFront all offer automatic image optimization now. The CDN detects the browser, serves the best format, and resizes on the fly. This is the lowest effort, highest impact approach for existing sites.

CMS plugins: WordPress has Imagify and ShortPixel. Next.js has built in image optimization. Gatsby has gatsby-plugin-image. If your framework or CMS has a built in solution, use it before rolling your own.

CI/CD checks: Add image size checks to your pipeline. Flag any image over 200KB before it hits production. Tools like Lighthouse CI can automate Core Web Vitals monitoring on every deploy.

Measuring the Impact

You need numbers, not feelings. Here is how to measure what your compression work actually accomplished.

Run PageSpeed Insights before and after. Screenshot the results. Track LCP specifically because that is where image compression has the most direct impact.

Use Chrome DevTools Network tab filtered to images. Sort by size. Anything over 200KB on a standard page deserves a second look. Anything over 500KB is almost certainly a problem.

Set up real user monitoring with the Web Vitals JavaScript library. Lab data from Lighthouse is useful but field data from actual users is what Google uses for ranking decisions.

The target: 75th percentile LCP under 2.5 seconds, total image payload under 1MB for a typical page, and no single image over 200KB without a very good reason.

What I Keep Coming Back To

Image compression is boring. Nobody gets excited about shaving 40KB off a product photo. But it compounds. Every image you optimize makes your site faster. Every millisecond you save improves user experience. Every Core Web Vitals threshold you pass removes a penalty from your SEO.

The tools are there. The formats are mature. The techniques are well understood. The only thing missing is actually doing the work. Start with your top 10 pages by traffic. Run them through PageSpeed Insights. Identify the worst offending images. Compress them. Measure the difference.

Ten minutes of work. Measurable SEO improvement. That is the kind of ROI that is hard to argue with.