How to Resize Images for Web Performance

Serve images at the size they will be displayed at, not at their source resolution. A 6000-pixel-wide photograph displayed at 800 pixels wastes 98% of its pixel data. Every unnecessary byte extends page load time, worsens Core Web Vitals, and costs mobile users bandwidth.

A modern responsive image workflow generates the same photo at multiple widths and lets the browser choose. Four widths cover almost every layout: 400w for small mobile, 800w for large mobile and small tablet, 1200w for tablet and small desktop, and 1600w for large desktop and 2x-density mobile.

The browser picks based on the actual rendered size and the device's pixel density. On a Retina phone showing an image at 375 CSS pixels, the browser downloads the 800w variant (375 * 2 = 750 device pixels). This is invisible to the developer once srcset is set up correctly.

The HTML pattern is short. Below, the browser picks the closest match to the rendered size:

• srcset lists the same image at multiple widths, each with its w descriptor.
• sizes describes the rendered width at each viewport - the browser uses this to choose.
• src is the fallback for browsers that ignore srcset (extremely rare in 2026).

Largest Contentful Paint (LCP) - Google's flagship page-speed metric - is dominated by the largest above-the-fold image on most pages. Cutting that image's file size in half typically cuts LCP by 30-60% on mobile networks.

A hero image served at 400 KB WebP with srcset will almost always beat a 3 MB PNG served without srcset, even after browser cache warming. Server-side compression alone cannot make up for serving desktop-size images to phones.

Add loading="lazy" to every image below the fold. Browsers defer loading these until the user scrolls near them. This costs zero engineering effort and reliably improves LCP by removing bandwidth competition with the hero image.

Never lazy-load the LCP image itself - lazy loading it delays the metric Google measures. The first hero, product photo, or above-the-fold image should use loading="eager" (the default).

The three lever together compound. Resizing halves file size 4x; converting to WebP halves it again; srcset ensures small screens get small files. A typical hero image path is: source PNG 4 MB → resized to 1600 px wide → converted to WebP quality 80 → served via srcset. End result: ~120 KB on desktop, ~40 KB on mobile.