Key Takeaways
- WebP is the baseline format for 2026 — it achieves 25–35% smaller file sizes vs JPEG at equivalent quality and is supported by all modern browsers; serve WebP for all non-transparent images, PNG only for images requiring lossless transparency
- AVIF achieves 50% smaller files than JPEG at equivalent quality but encoding is slow (not suitable for real-time image processing) — best for pre-encoded static images; use
<picture>with AVIF + WebP + JPEG fallback for maximum compression with broad browser support - The LCP image must not be lazy-loaded — add
loading="eager"andfetchpriority="high"to the above-the-fold hero image; lazy-loading the LCP candidate delays the most important visual element, directly worsening LCP score widthandheightattributes on all<img>elements prevent Cumulative Layout Shift — the browser reserves space for the image before it loads; without these attributes the page reflows when the image arrives, causing CLS- Responsive images (
srcset+sizes) serve the appropriately-sized image for the user's viewport — a 1200px-wide image served to a 375px mobile screen wastes 70%+ of the download;srcseteliminates this waste with no quality trade-off
Choosing the Right Image Format
The format you choose determines the ceiling for how much you can compress an image. Modern formats achieve dramatically better compression than JPEG at equivalent perceived quality — but browser support and encoding trade-offs still matter.
| Format | Use case | Compression | Browser support |
|---|---|---|---|
| JPEG | Photos, gradients | Lossy | Universal |
| PNG | Screenshots, transparency | Lossless | Universal |
| WebP | Photos + illustrations | Lossy + lossless | 97%+ |
| AVIF | Maximum compression | Lossy + lossless | 92%+ |
| SVG | Icons, logos, illustrations | Vector | Universal |
Decision tree for format selection:
- Icon or logo → SVG (scales without quality loss, tiny file size)
- Photo or complex image → WebP (lossy, quality 75–85 for photos)
- Image with transparency → WebP (lossless) or PNG fallback
- Maximum compression for static image → AVIF with WebP fallback via
<picture> - Legacy browser support required → JPEG with WebP
<picture>source
For most sites in 2026, WebP covers the vast majority of images with no additional complexity. AVIF is worth adding as a <source> in <picture> elements where static pre-encoding is feasible — the 50% file size reduction over JPEG directly translates to faster LCP on image-heavy pages.
Lossless vs Lossy Compression
Lossless compression reduces file size without discarding any image data. The decompressed image is bit-for-bit identical to the original. Use for: screenshots, UI mockups, images with text, images requiring repeated editing. PNG and WebP both support lossless mode.
Lossy compression discards imperceptible image data to achieve significantly smaller files. Use for: photos, illustrations, hero images. Quality setting 75–85 in WebP or JPEG is imperceptible to most users but achieves 40–60% size reduction versus quality 100.
Rule of thumb: never save the original as lossy — always keep a lossless master and export the web version as lossy. Re-saving a JPEG from a JPEG compounds quality loss with each generation, introducing visible compression artefacts that cannot be reversed.
Responsive Images with srcset
Serving a single full-size image to every device is the most common image performance mistake. A 3000px hero image served to a 390px phone delivers the same visual result as a 400px image but at 50× the file size.
The srcset and sizes attributes solve this by letting the browser select the correct image variant before the CSS is even parsed:
<img
src="hero-800.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 600px) 100vw, (max-width: 900px) 50vw, 800px"
alt="Hero image description"
width="800"
height="450"
loading="eager"
fetchpriority="high"
>srcset lists the available image files with their intrinsic widths (the w descriptor). sizes tells the browser which CSS size the image will occupy at each viewport width. Together they allow the browser to compute: "at this viewport width, the image displays at X pixels, so I need the smallest srcset candidate that covers X pixels at the current device pixel ratio."
Without srcset: every device downloads the full-size image. With srcset: mobile gets the 400w variant, tablet the 800w, desktop the 1200w. No JavaScript, no build complexity — just HTML attributes.
LCP Image Optimisation
The LCP (Largest Contentful Paint) image is the single most important image on any page. Google's Core Web Vitals use LCP as a direct ranking signal — and the LCP element is almost always an image on image-heavy pages.
To identify your LCP image: PageSpeed Insights → Diagnostics → "Largest Contentful Paint element" shows which element Chrome measured as LCP during the test.
LCP image optimisation checklist:
loading="eager"— never lazy-load the LCP image; it must start downloading immediatelyfetchpriority="high"— tells the browser this is the most important resource to fetch<link rel="preload" as="image" href="lcp-image.webp">in<head>— preloads before HTML parsing completes, shaving hundreds of milliseconds off LCP- Served from same origin or a CDN with low TTFB — third-party image hosts add DNS lookup time and connection overhead to every image load
- Compressed to WebP or AVIF — every kilobyte counts for LCP; file size directly determines download time
- Correct
widthandheightset — avoids layout shift as it loads, keeping CLS at zero
loading="lazy" to a hero image because "lazy loading improves performance." It does — for below-fold images. For the LCP candidate it actively worsens LCP by deferring the most important resource. The Page Speed Inspector flags this check explicitly.
Lazy Loading Below-Fold Images
Once the LCP image is handled, every other image below the fold should use native lazy loading:
<img src="thumbnail.webp" alt="Product thumbnail" width="300" height="200" loading="lazy">Browser support: all modern browsers. Fallback behaviour: older browsers simply load the image normally — no JavaScript required, no polyfill needed.
loading="lazy" defers loading until the image is approximately one viewport away from being scrolled into view. For a page with 20 product thumbnails, this reduces initial page weight by 80%+ — the user only downloads images they actually scroll to.
Do NOT use loading="lazy" on:
- The LCP candidate image (see above)
- Any image in the first viewport on mobile — these are visible immediately and should load eagerly
- Images used as CSS
background-image— the attribute only applies to<img>elements; CSS background images require Intersection Observer if you need deferred loading
Build Process Integration
Manual compression doesn't scale for sites with hundreds of images. Automating image optimisation in the build pipeline removes the human error factor and ensures every image is consistently compressed.
Sharp (Node.js): High-performance image processing library — resize, convert to WebP/AVIF, compress, and generate srcset variants in a single build step. The de facto choice for Node-based build systems. Supports batch processing, aspect ratio preservation, and progressive encoding.
Squoosh CLI: Google's open-source image optimizer — WebP/AVIF/JPEG compression with quality control from the command line. Good for ad-hoc compression and verifying quality settings before committing to a build pipeline.
CDN image transformation: Cloudflare Images, Imgix, and Cloudinary serve the correct format and size via URL parameters — no build step changes required. The CDN detects the browser's Accept header and serves WebP or AVIF automatically. This approach shifts compression to the CDN edge and removes the local build dependency entirely.
CMS integration: WordPress (Imagify, ShortPixel), Shopify (built-in WebP conversion), and Webflow (built-in) all offer automatic WebP conversion and compression on upload. For CMS-managed sites, these plugins are the lowest-effort path to consistent image optimisation.
Check Your Page's LCP Image and Load Performance
Free, no signup. The Page Speed Inspector measures TTFB, download time, compression, and HTML checks including images missing width/height attributes and lazy-load issues — the same signals that drive Core Web Vitals scores in Google Search Console.
Inspect Your Page Speed Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.