Why image size controls page speed
Images typically contribute 50–70% of a page's download weight, so a single 4 MB phone photo can delay rendering longer than all your code combined. On average 4G that one photo needs over three seconds alone — past the point where many mobile visitors abandon the page. Google's Largest Contentful Paint should land under 2.5 seconds, and hero images usually decide it.
The cost is concrete: every extra second of load trims conversions by an estimated 7%. A product page with six 3 MB photos ships 18 MB; the same page with 150 KB versions ships under 1 MB and feels instant.
- Images are usually 50–70% of page weight — the biggest lever you have
- Largest Contentful Paint under 2.5 s is the target; heroes decide it
- Measure before and after with PageSpeed Insights, not guesswork
WebP and modern formats explained
WebP encodes photographic detail about 25–35% smaller than JPEG at equal visual quality, and replaces PNG graphics at a fraction of the size with transparency intact. A 1.2 MB JPEG hero routinely becomes a 750–850 KB WebP with no visible change. AVIF compresses further still but encodes slower and needs fallbacks on older browsers.
The practical setup is WebP first with JPEG fallback via the picture element. Archive originals as high-quality JPEG or PNG, export WebP at quality 75–82 for photos, and reserve PNG for pixel-perfect icons. Format choice alone typically removes a third of image weight.
- WebP at quality 75–82 for photos; PNG only for tiny crisp icons
- Serve WebP first with JPEG fallback via the picture element
- Archive originals; trial AVIF on the heaviest heroes only
Resizing: serve the right dimensions
A 4032-pixel phone photo displayed in an 800-pixel column wastes roughly 96% of its pixels — the browser downloads far more data than it renders. Check the rendered size in dev tools, then export at that width times two for retina sharpness at most. Blogs, cards, and thumbnails each deserve their own sized variant.
Responsive images automate the rest: the srcset attribute lists 480, 800, 1200, and 1600-pixel variants and lets the browser pick the smallest sufficient file. A phone fetches the 480-pixel version while a retina laptop fetches the 1600-pixel one — each visitor pays only for what their screen needs.
- Export at display width × 2 maximum — never upload the camera original
- Create 480 / 800 / 1200 / 1600-pixel variants served via srcset
- Thumbnails get their own tiny files; CSS scaling is not optimisation
Compression workflow that works every time
Follow the same order for every image. First resize to target dimensions, since compressing pixels you will discard wastes effort. Second convert photos to WebP at quality 78–82. Third compare side by side at full zoom — stop when you first notice artefacts, then step quality up slightly. Fourth strip EXIF metadata like GPS coordinates, which also protects privacy.
Fifth, verify the numbers: heroes between 100–300 KB, content images 50–150 KB, thumbnails under 50 KB. If a file misses its budget, resize rather than crushing quality — dimensions move weight faster than quality sliders.
Alt text, filenames, and lazy loading
Name files descriptively — handmade-ceramic-mug.webp beats IMG_4032.webp — because search engines read filenames for ranking signals. Write alt text under 125 characters describing content and function, so screen readers convey meaning and broken images degrade gracefully.
Mark below-the-fold images with loading="lazy" so phones skip them until scrolled to. Preload only the hero with explicit width and height to reserve layout space — missing dimensions cause layout shift. Eager-load one hero, lazy-load everything else.
- Descriptive filenames and sub-125-character alt text boost SEO and access
- loading="lazy" below the fold; eager preload only the hero
- Always set width and height to prevent layout shift
Image optimization mistakes to avoid
The most expensive mistake is uploading camera originals and letting CSS shrink them — a 4 MB file styled to 300 pixels still downloads all 4 MB. Next is converting everything to PNG: a 2 MB PNG photo that WebP renders at 250 KB is pure waste. Third, quality-100 exports preserve imperceptible detail at triple the weight; 78–82 looks identical on screens.
Then the invisible errors: lazy-loading the hero so the most important paint waits, missing dimensions causing content jumps, and forgetting social-share images. Audit quarterly by sorting uploads by size and fixing the top ten offenders.
- Never serve camera originals — resize before uploading, every time
- Photos belong in WebP or JPEG, not PNG
- Export photos at quality 78–82, not 100
Image optimization questions answered
How much quality does lossy compression lose? At WebP quality 80, effectively none visible: viewers cannot distinguish it from originals at normal viewing distances. It discards data human vision barely registers while keeping edges and colours intact — the only test that matters is reading the article normally.
Should I switch to AVIF now? Not as a sole format — keep WebP primary with JPEG fallback and trial AVIF on the heaviest heroes. How many variants per image? Four widths cover nearly all layouts, and always optimise at upload rather than relying on CDN transforms.
- WebP quality 78–82 is visually lossless for screens
- Keep WebP primary with JPEG fallback; trial AVIF on heavy heroes
- Four srcset widths cover phones through retina desktops