Image Compression vs. Resizing: Picking the Right Optimization for Web Performance

A designer once handed me a landing page where every photo was a 5 MB PNG dropped straight out of Lightroom. The site was "optimized" because they had run each image through a compressor that shaved off 8 percent. Largest Contentful Paint on a mid-tier Android phone over LTE was 11 seconds. The fix was not a better compressor. The fix was admitting that an 8000-pixel-wide PNG never had to ship at 8000 pixels in the first place.

Compression and Resizing Are Not the Same Operation

The two words get used interchangeably in casual conversation, but they reduce file size through completely different mechanisms.

• Compressionreduces the number of bytes per pixel without changing the pixel grid. A 1920×1080 photo stays 1920×1080. The encoder finds a more efficient representation of the same image.
• Resizingreduces the number of pixels themselves. A 4000×3000 original becomes a 1200×900 derivative. There is now literally less image to transmit, decode, and paint.

File size depends on both, multiplicatively. If a 4000×3000 PNG is 6 MB, resizing it to 1200×900 cuts the pixel count by roughly 11×. Compressing the result as a quality-80 WebP cuts the bytes per pixel by another order of magnitude. The combined output might be 60–80 KB. That is the difference between "optimization" as a checkbox and "optimization" as a real performance budget.

What Each Operation Actually Affects

It helps to think of three costs whenever an image is loaded: the bytes on the wire, the memory in the decoder, and the milliseconds the GPU spends rasterizing. Compression and resizing influence them differently.

The takeaway: compression is a one-dimensional knob (bytes ↔ visual fidelity). Resizing is multi-dimensional. It cuts transfer size, decoder memory, GPU work, and CPU time simultaneously, and it does so without any visible quality loss as long as the target dimension is at least as large as the displayed size on the user's screen.

Lossy vs Lossless Compression

Within compression, there is a second axis: whether you keep every pixel value exactly as it was, or whether you let the encoder throw away information that humans probably will not notice.

Lossless

Lossless compression rebuilds the exact original on decode. PNG and lossless WebP both fall in this category. Use lossless when the image has hard edges and flat color regions — UI screenshots, logos, line art, charts, anything with text inside it. Lossy encoders smear those edges; lossless preserves them. The cost is bigger files for photo-like content, where lossless cannot exploit the redundancy that lossy formats excel at.

Lossy

Lossy compression discards detail in ways the human visual system tolerates: subtle color gradations get quantized, high-frequency texture gets approximated. JPEG, lossy WebP, AVIF, and HEIC are all lossy. For natural photographs, lossy formats produce files five to ten times smaller than lossless at quality settings most people cannot distinguish from the original. Use them on anything continuous-tone.

Quality Numbers in Practice

The "quality" slider exposed by encoders is not a percentage of how good the image looks — it is an internal parameter to the rate-distortion model. Some practical ranges I have settled on after a lot of A/B testing:

• JPEG: q=78 to q=85 for hero photos. Below 70 you start seeing blocking artifacts on smooth gradients.
• WebP (lossy):q=75 reaches roughly the same perceived quality as JPEG q=85, in 25–35% fewer bytes.
• AVIF: q=50 looks comparable to JPEG q=85 in many tests, in half the file size. Encoding is slow, so cache aggressively.

Always do a side-by-side eyeball check at the actual display size before settling on a quality value for production. Numerical metrics like SSIM are useful guidance but they miss perceptual issues like color banding in skies.

When to Compress, When to Resize, When to Do Both

Resize First, Always

The single biggest win in image performance is shipping the right pixel count. A 4000-pixel photo displayed in a 600-pixel-wide column is not just wasteful on the wire — it is also slower to decode and paint, and it costs more battery on the user's device. Pick a target dimension based on where the image will appear, then compress.

Compress Only When the Pixel Count Is Already Right

Photographs that are already at delivery size benefit from a high-quality lossy encode and not much else. A WebP or AVIF at quality 75 is going to crush a comparable JPEG and any amount of further resizing would hurt clarity.

Both, for Hero Photos

Anything heavy — full-bleed banners, gallery images, e-commerce product photos — needs both. Resize down to the largest size you actually display (multiplied by DPR), then compress. Then generate additional smaller variants so phones do not download the desktop hero asset.

Responsive Images: srcset and sizes

Browsers do not need a single image. They need the right image for the device asking. The srcset attribute lets you offer several pre-resized variants and lets the browser pick:

<img
  src="hero-1200.jpg"
  srcset="
    hero-400.jpg   400w,
    hero-800.jpg   800w,
    hero-1200.jpg 1200w,
    hero-1600.jpg 1600w,
    hero-2400.jpg 2400w
  "
  sizes="(max-width: 600px) 100vw,
         (max-width: 1024px) 80vw,
         1200px"
  alt="Mountain landscape at sunrise"
  loading="lazy"
  decoding="async"
/>

The two attributes work together. srcset lists the candidates with their intrinsic widths. sizes tells the browser how big the image will render at various breakpoints. The browser combines both with its current viewport width and pixel density to pick the smallest candidate that is still big enough.

picture for Format Negotiation

When you want to ship AVIF to browsers that support it and fall back to JPEG elsewhere, wrap the same image in a <picture> element with multiple <source> children:

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="100vw" />
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="100vw" />
  <img src="hero-1200.jpg" alt="Mountain landscape at sunrise" loading="lazy" decoding="async" />
</picture>

Browsers walk the source list top to bottom and pick the first format they understand. The bare <img> is the universal fallback and is also the element that carries alt and the layout attributes.

Device Pixel Ratio: 1x, 2x, 3x

High-density displays pack more physical pixels into the same CSS pixel area. A 300×200 box on a 2x phone covers 600×400 device pixels. If you ship a 300×200 image, it will be upscaled by the GPU and look soft. If you ship a 1200×800 image, it will be downsampled and look sharp but waste bandwidth.

The fix is to provide images at the dimensions the device will actually use. With srcset using width descriptors (the 800wexamples above), the browser handles density automatically — a 2x phone with a 400-CSS-pixel-wide layout will request the 800w variant. With density descriptors (1x, 2x) you spell it out:

<img
  src="logo.png"
  srcset="logo.png 1x, logo@2x.png 2x, logo@3x.png 3x"
  width="120"
  height="40"
  alt="Brand logo"
/>

Width descriptors are more flexible (they cover both fluid layouts and DPR), so they are the right default for photos. Density descriptors are convenient for fixed-size assets like icons and logos.

Picking the Right Format

SVG deserves a special call-out: for anything that is geometric (icons, charts, simple illustrations), it is by far the smallest and the only format that stays crisp on every DPR. Run SVG through an optimizer to strip editor metadata before shipping — raw Sketch or Figma exports often carry kilobytes of unused<defs> and namespace declarations.

Automated Pipelines and CDNs

Generating five sizes in three formats per image becomes painful by hand. Three patterns scale better.

Build-Time Generation

Static-site generators (Next.js next/image, Astro <Image />, Nuxt Image, Eleventy Image) read your source files at build time and emit pre-resized, pre-encoded variants alongside the right srcset markup. You write <Image src="hero.jpg" /> once and get a full responsive set for free.

On-Demand Image CDNs

Cloudflare Images, Cloudinary, imgix, and Imgproxy take the same idea further: you upload a single high-resolution master and request transformed variants by URL. The CDN caches each variant after the first request, so the cost is amortized.

https://cdn.example.com/cdn-cgi/image/width=800,format=auto,quality=75/hero.jpg
                                  ▲       ▲              ▲
                                  │       │              └── 클라이언트 협상 (AVIF/WebP/JPEG)
                                  │       └── 적응형 인코더 품질
                                  └── 디스플레이 크기에 맞는 픽셀 폭

Bake-Then-Serve

For sites with a small, mostly-static set of images, generating variants once with sharp, imagemagick, or vips and committing them to the repo is the simplest pipeline that exists. No CDN bill, no runtime path. The trade-off is that adding a new breakpoint means re-running the script.

How Image Choices Show Up in Web Vitals

Image performance is not a vibe; it is measurable. Three Core Web Vitals are particularly sensitive to image decisions.

• Largest Contentful Paint (LCP). The hero image is usually the LCP element on a content page. Cutting its byte size and decode time is the single highest leverage thing you can do for LCP.
• Cumulative Layout Shift (CLS). Always set explicit width and height attributes (or aspect-ratio CSS) so the browser reserves space before the image arrives. Otherwise content reflows when the image lands and CLS spikes.
• Total Blocking Time (TBT) / Interaction to Next Paint (INP). Decoding enormous images on the main thread blocks user interaction. Resize aggressively and add decoding="async".

Use loading="lazy" for below-the-fold images and fetchpriority="high" for the LCP candidate. The two together give you the best chance of fast first paint without crowding network bandwidth on assets the user may never scroll to.

Common Mistakes

Compressing without resizing

The most expensive image on most sites is a single 4000-pixel hero shipped as a JPEG with quality 90. Lowering the quality to 80 saves a few hundred kilobytes. Resizing it to 1600 pixels and quality 80 saves megabytes. Always resize first.

Shipping animated GIFs in 2026

A 5-second animation in GIF format is often 10–20 times the size of the same content as an <video autoplay muted loop playsinline> with H.264 or AV1. The format predates the modern web and was never designed for video. Convert.

Forgetting width and height attributes

Without explicit dimensions the browser cannot reserve layout space, and content jumps when the image finally lands. This is one of the most common causes of CLS regressions. Even responsive images need the intrinsic width and height set so the browser can compute the aspect ratio.

Re-encoding lossy as lossy

Each lossy encode introduces new artifacts. If you take a JPEG, recompress it to a JPEG, recompress that to a WebP, then back to a JPEG, you have multiplied the artifacts at every step. Keep a high-quality master (PNG, lossless WebP, or original camera RAW) and produce every delivery format from that single source.

Try It with BeautiCode Tools

The fastest way to internalize the trade-offs is to push real images through real tools and watch the file size move. All of these run entirely in your browser, so the original never leaves your device.

• Image Resizer — reduce a 4000-pixel original to 1200 or 800 pixels and compare the file size delta. This is almost always the biggest single win.
• Image Compressor — tune quality on the resized output. Try q=85, q=78, and q=70 on the same photo and decide where the visual cliff is for your content.
• Image Format Converter — transcode the same source to JPEG, WebP, and AVIF and compare the resulting sizes side by side. Useful before deciding which formats to put in your <picture> fallback chain.
• SVG Optimizer — for icons and illustrations exported from design tools, strip editor metadata and unused attributes. A typical Figma export shrinks 60–80%.

Frequently Asked Questions

Should I just use AVIF for everything?

AVIF is excellent for photographs and the best lossy compressor available right now, but it has weaknesses. Encoding is computationally expensive, decoding is heavier than JPEG, and a few older browsers (notably Edge before Chromium and some embedded browsers) still do not support it. Ship AVIF as the first choice with WebP and JPEG fallbacks via <picture>. For UI screenshots and logos, AVIF is a poor fit — use lossless formats instead.

How many srcset variants do I need?

Three to five widths covers nearly everything. A common spread is 400w, 800w, 1200w, 1600w, 2400w. The browser interpolates smartly, so adding more widths past five buys diminishing returns and inflates your build artifacts. Match the breakpoints to your actual layout: if your widest column is 1200 CSS pixels, the 2400w variant is for 2x retina at that column; you do not need 3200w.

Can I compress losslessly without losing quality?

Yes — PNG and lossless WebP both preserve every pixel exactly. The savings come from better entropy coding, not from discarding information. Tools like oxipng, zopflipng, and cwebp -lossless often shrink PNGs by 20–40% without changing a pixel. For UI screenshots that contain text or logos, lossless is the right default; the file is still much smaller than the original even if it is larger than a comparable lossy.

What about progressive JPEG?

Progressive JPEG encodes the image as a series of refinement passes, so the user sees a coarse version of the whole image quickly and detail fills in. It produces marginally smaller files than baseline JPEG and feels faster perceptually on slow connections. Modern HTTP/2 multiplexing has reduced the benefit somewhat, but it is still a free win on photo-heavy pages. Most encoders have a flag to enable it.

How do I know what dimensions to resize to?

Open your site in a browser, narrow the viewport, and use DevTools to read the rendered width of the image element at each breakpoint. Multiply by your highest target DPR (usually 2; rarely 3 for premium phones), then add about 10% headroom. The result is the largest pixel width that variant ever needs to be. Anything bigger than that is wasted bandwidth on every device that loads it.