FileSlim logo - compress images and PDFs online free
FileSlim
Last Updated:

Image Compression for Web Performance

Images drive 60–80% of page weight on most sites — and most of your LCP score. Here's how to compress them for fast Core Web Vitals without thinking about it on every project.

3 image rules for good LCP:

  1. Keep the LCP image under 100 KB, with fetchpriority="high" and no lazy loading.
  2. Serve AVIF → WebP → JPEG via <picture>.
  3. Compress at build time so a bad asset can never ship.

Juraj Cukan

Founder, CEO & Lead Developer

Student, Comenius University - Faculty of Mathematics, Physics and Computer Science
Full-Stack Developer
Compression Algorithm Specialist
50M+ Files Processed

Juraj is a Computer Science student at Comenius University in Bratislava, Slovakia, and the sole creator of FileSlim. Frustrated with inefficient and expensive compression tools, he built FileSlim from the ground up as a free, privacy-first alternative. Working entirely alone, Juraj developed every aspect of the platform—from the compression algorithms to the user interface—ensuring complete browser-based processing that never uploads files to servers. His work has helped users worldwide compress over 50 million files while maintaining complete privacy and achieving 60-90% file size reductions.

Core Web Vitals in 60 Seconds

LCP

Largest Contentful Paint — when the biggest above-the-fold element finishes loading. Goal: ≤2.5 s. Images are the usual culprit.

INP

Interaction to Next Paint — replaced FID in 2024. Goal: ≤200 ms. Heavy image decode work can push INP into the red.

CLS

Cumulative Layout Shift. Goal: ≤0.1. Always set width/height (or aspect-ratio) on <img> so the browser reserves space.

Format Decision Matrix

Use casePrimaryFallbackNotes
Photo (hero, content)AVIFWebP → JPEGAVIF wins 20–30% vs WebP on photos
Graphic / screenshotWebPPNGWebP lossless beats PNG by 20–40%
Logo / iconSVGWebPVectors scale and gzip well
AnimatedAVIF / WebPMP4 videoSkip animated GIF — 5–10× larger
OG share imageJPEGMany crawlers still don't decode WebP/AVIF

Reference Markup

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" />
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" />
  <img
    src="hero-1600.jpg"
    srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
    sizes="(min-width: 800px) 1600px, 100vw"
    width="1600" height="900"
    fetchpriority="high"
    alt="..."
  />
</picture>

For below-the-fold images, drop fetchpriority and add loading="lazy" and decoding="async".

File-Size Budgets by Image Role

Hero / LCP element

Target ≤100 KB. Use AVIF, served with fetchpriority="high".

Content images

Target ≤80 KB. Lazy-load anything below the fold.

Thumbnails / avatars

Target ≤20 KB. WebP at 70% quality is usually enough.

OG / social share

Target ≤300 KB. JPEG at 1200×630 — keep it under the 5 MB Twitter limit by a wide margin.

Build-Pipeline Integration

Compress at build time so an unoptimized asset can never ship to production. The @fileslim/compress SDK runs in Node-compatible Wasm runtimes and in CI:

// scripts/compress-assets.ts
import { compressImage } from '@fileslim/compress';
import { readFile, writeFile } from 'node:fs/promises';
import { AD_SLOTS } from '@/config/adsense';

const buf = await readFile('src/assets/hero.jpg');
const out = await compressImage(new Blob([buf]), {
  preset: 'web',
  format: 'avif',
  targetBytes: 100_000,
});
await writeFile('dist/hero.avif', new Uint8Array(await out.blob.arrayBuffer()));

Wire this into a pre-commit hook or your CI build step and budget violations fail the build.

Need a hosted equivalent? See the PDF compression API guide for tradeoffs between client-side SDKs and REST APIs.

Common Mistakes That Tank LCP

  • Lazy-loading the hero image (breaks LCP — drop loading="lazy" for the LCP element).
  • Serving a 4000 px image into a 800 px slot (use srcset).
  • Shipping PNG photos (PNG is for graphics; photos belong in JPEG/WebP/AVIF).
  • Forgetting width/height attributes (causes CLS).
  • Trusting a CDN to fix uncompressed source assets — pay the cost at build time, not on every request.

Frequently Asked Questions

How much do images affect Core Web Vitals?

Images are the single biggest contributor to LCP (Largest Contentful Paint) on most pages — typically 60–80% of the LCP element is an image. They also drive page weight, which affects INP indirectly through main-thread parsing work. Compressing the hero image alone often shifts LCP by 500–1500 ms.

What's the best image format for web performance in 2026?

AVIF for photos when you control the encode (30–50% smaller than JPEG at equivalent quality). WebP as the fallback (supported everywhere modern, 25–35% smaller than JPEG). JPEG as the universal fallback. Use <picture> with srcset to serve the best format each browser can decode.

What file size targets should I aim for?

Hero/LCP image: ≤100 KB. Above-the-fold content images: ≤80 KB. Thumbnails and avatars: ≤20 KB. Open Graph share images: ≤300 KB. These targets keep most pages under the 1.5 MB total page-weight budget recommended for good LCP on 4G.

Should I use lazy loading?

Yes for below-the-fold images (loading="lazy"). No for the LCP element — lazy loading the hero image actively hurts LCP because the browser delays the request. Mark the LCP image with fetchpriority="high" instead.

Does AVIF really beat WebP?

For photos, yes — typically 20–30% smaller at the same SSIM score. For graphics with sharp edges (logos, screenshots), WebP often matches or beats AVIF and decodes faster. Test both per asset class; don't blindly convert everything to AVIF.

What about JPEG XL?

JPEG XL offers excellent compression and progressive decoding but browser support remains limited (Safari yes, Chrome no as of 2026). Ship it as a progressive enhancement via <picture>, but keep AVIF/WebP as your primary modern format.

Can I automate compression in my build pipeline?

Yes. Tools like @fileslim/compress (JS), sharp (Node), squoosh-cli, or imagemin can compress on build. Run them in CI so your bundle never ships an uncompressed asset. For dynamic uploads, run compression in the browser before upload to save bandwidth.

Does a CDN make compression unnecessary?

No. A CDN with image optimization (Cloudflare Polish, Fastly IO, Cloudinary) helps but doesn't replace shipping well-optimized source assets. CDN-side optimization adds latency on first request and costs money at scale. Pre-compress at build time, let the CDN handle just format negotiation.

Compress an image for the web now

Drop an image into FileSlim and get a web-ready AVIF/WebP/JPEG in seconds.

Get more FileSlim in Google

Tell Google you want to see FileSlim guides and tools more often. Takes one click and you stay on this page.

Make us a preferred source