Digital imagery accounts for the vast majority of total network payload bytes transferred across modern web pages. If an engineering team serves unoptimized assets to end-users, page speed plunges, causing bounce rates to rise and search engine optimization (SEO) performance to drop. Google's Core Web Vitals metrics, particularly Largest Contentful Paint (LCP), place a premium on asset load speeds. Achieving optimal scores requires modern image optimization and deployment strategies.

The Limits of Legacy Formats

Traditional image file formats carry significant legacy overhead. Portable Network Graphics (PNG) files use robust lossless data compression, making them ideal for high-contrast technical graphics or layouts requiring alpha-channel transparency, but they result in excessively large file sizes for photographic elements. Joint Photographic Experts Group (JPEG) files offer more manageable compression ratios for photos, but they suffer from blocky artifacting when compressed tightly and lack native support for alpha transparency layers.

These constraints forced developers into awkward trade-offs. PNG for graphics with transparency, JPEG for photos, GIF for short animations, BMP for legacy compatibility. The accumulation of format-specific code paths and the persistent overhead of JPEG artifacts on tight budgets drove the search for a unified replacement.

The WebP Solution

WebP, developed by Google, solves these limitations by offering superior lossy and lossless compression mechanics for web imagery. WebP lossy files leverage advanced predictive coding algorithms, using data blocks from adjacent pixels to accurately forecast value changes across image structures. This engineering approach yields file sizes up to 30% smaller than equivalent JPEGs at identical visual qualities. Transitioning asset pipelines to WebP via localized responsive compressors allows web developers to dramatically compress layout files while maintaining clean visual presentation.

WebP also supports lossless compression, transparency (alpha channel), and animation in a single format. A site that previously shipped JPEG for photos, PNG for icons, and GIF for animations can now ship WebP for all three, simplifying the asset pipeline and reducing the total bytes transferred.

The State of WebP in 2026

Browser support for WebP is now universal. Every shipping browser — Chrome, Edge, Firefox, Safari (since 14), and all mobile browsers — can decode WebP. The remaining reason to ship JPEG or PNG fallbacks is for users on locked-down corporate networks running browsers older than Safari 14, a population that has shrunk to near-zero. The default for new web projects should be WebP, with the legacy formats generated only when a specific user segment requires them.

WebP's encoding speed has historically been its weakness. Encoding WebP at high quality is roughly 5–10x slower than encoding JPEG, which makes runtime conversion expensive. The right place to do WebP encoding is at build time, not at request time. Build pipelines like sharp, libvips, or cwebp generate WebP variants once at deploy time, and the CDN serves them indefinitely.

AVIF: The Next Step

AVIF (AV1 Image File Format) is the next-generation format based on the AV1 video codec. AVIF delivers another 20% reduction over WebP at equivalent visual quality, supports 10-bit and 12-bit color depth for HDR content, and includes wide-gamut color support. Browser support landed in Chrome 85 (2020), Firefox 93 (2021), and Safari 16 (2022). By 2026, AVIF works everywhere WebP does, with rare edge cases in embedded WebViews.

The cost is encoding speed. AVIF encoding is roughly 10x slower than WebP encoding, which means build-time generation is essential. For most websites, the slower build is worth it: the smaller payload improves user experience measurably.

JPEG XL: The Promised But Delayed Successor

JPEG XL was designed as the formal successor to JPEG, with superior compression and backward compatibility (a JPEG XL file can losslessly contain a JPEG). Chrome support was added in 2022; Safari support exists but is not enabled by default; Firefox support was removed in 2024. The current state of JPEG XL is unclear, and most projects are skipping it in favor of AVIF.

Choosing the Right Format by Use Case

A practical format selection matrix for typical web workloads:

  • Product photography on e-commerce: AVIF first, WebP fallback. The smaller payload improves conversion rates measurably on slow mobile networks.
  • Editorial photography for blogs: WebP first, JPEG fallback. AVIF encoding time is rarely worth it for editorial content where the article text dominates the payload.
  • Icons and small UI graphics: WebP or PNG. For very small icons (under 100 bytes), the difference between formats is negligible.
  • Logos with transparency: WebP or PNG. SVG is usually a better choice for logos because it scales to any size without quality loss.
  • Animated content: WebP for short loops, MP4 for longer sequences. AV1 MP4 is the modern best-in-class.
  • Screenshots and UI captures: WebP lossless. The crisp edges of UI elements compress poorly in lossy formats.

The Impact on Core Web Vitals

The LCP element on a typical page is an image — a hero photograph, a product shot, a featured illustration. Reducing the size of that image directly improves LCP. Google's published case studies show that moving from JPEG to WebP at the same quality improves LCP by 200–500 ms on mid-range mobile devices, enough to move a page from "needs improvement" to "good."

The Interaction to Next Paint (INP) metric is also affected. While INP measures JavaScript responsiveness, image decoding happens on the main thread for large images and competes with JavaScript execution. Faster image decoding (AVIF hardware acceleration is now common on flagship phones) frees the main thread for interactive scripts.

Responsive Images and the srcset Pattern

Modern image deployment is not just about format; it is also about resolution. A 4K monitor should not receive the same 800-pixel-wide image as a smartphone. The HTML srcset attribute and the <picture> element let the browser choose the right asset:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="600">
</picture>

The browser picks the first source it supports, falling back through the chain. Combined with responsive size variants, the same <picture> element can serve a 200 KB AVIF to a smartphone and a 1.5 MB AVIF to a 4K display, both at appropriate visual quality.

Lazy Loading and Priority Hints

Images below the fold do not need to load with the initial page; they can be deferred until the user scrolls toward them. The native loading="lazy" attribute triggers this behavior without JavaScript:

<img src="below-fold.jpg" alt="..." loading="lazy" decoding="async">

For images above the fold (especially the LCP element), priority hints help the browser load them first:

<img src="hero.jpg" alt="..." fetchpriority="high">

Combined with modern formats, lazy loading, and responsive sizes, a typical image-heavy page can deliver a 60–80% reduction in image bytes without any visible quality loss.

Common Image Optimization Mistakes

  • Serving unoptimized originals from a CMS. A 6 MB hero photograph uploaded by an editor reaches users at full size. Build-time optimization should be automatic.
  • Using PNG for everything. PNG is lossless and produces sharp results for UI graphics, but it produces massive files for photos. A 5 MB photo is fine as a 200 KB JPEG or 150 KB WebP.
  • Skipping the width and height attributes. Without explicit dimensions, the browser cannot reserve layout space and must wait for the image to load before rendering. This causes layout shift, which hurts CLS.
  • Embedding large images as Base64 data URIs. A 200 KB image as a data URI becomes 270 KB of text inside HTML, blocks the parser, and prevents separate caching. Reserve data URIs for icons under 5 KB.

Build-Time vs. Runtime Compression

For most web applications, build-time image optimization is correct. The build pipeline ingests originals from the CMS, produces optimized WebP and AVIF variants at multiple resolutions, and stores the output in the static asset directory. The runtime cost is zero — the CDN serves pre-built files.

Runtime compression is appropriate only for user-uploaded content. A social network with millions of user photos cannot pre-build every variant; it compresses uploads at ingestion and stores the optimized versions. Our image compressor uses server-side runtime compression for exactly this case, with files auto-deleted after five minutes to preserve privacy.

The Bottom Line

Modern image formats deliver measurable performance gains. AVIF for high-impact imagery, WebP as the universal default, and JPEG/PNG only for legacy compatibility. Combined with responsive sizes, lazy loading, and proper dimension attributes, the typical web page can deliver image payloads 60–80% smaller than the unoptimized original — directly improving Core Web Vitals, search ranking, and user experience.

Further Reading

  • WebP specification — Google Developers documentation on the format, encoder, and decoder behavior.
  • AVIF specification — the Alliance for Open Media's documentation on AV1 Image File Format.
  • Web Vitals — Google's official guidance on Core Web Vitals and the LCP metric.

Frequently Asked Questions

Should I always use AVIF? AVIF is the highest-compression choice but encoding is slow. For high-impact imagery on slow networks, the bandwidth saving is worth it. For low-impact images or fast build pipelines, WebP is sufficient.

What about animated GIFs? Replace with WebP or MP4. A 500 KB animated GIF typically becomes 100 KB as an MP4 and 150 KB as an animated WebP, with better quality at the smaller size.

Is there a single best format for everything? No. Different content types benefit from different formats. The goal is to use the best format for each asset, with fallback chains for browser compatibility.