WebP reduces file size by 25-35% compared to JPEG at equivalent quality. That compression alone does not pass LCP. A 4000×3000 pixel WebP hero image converted from the original camera file is still a 2MB file that takes seconds to download on 4G and requires massive memory allocation to decode. Format conversion without dimension resizing, quality calibration, and responsive delivery is one-third of the optimization required. Sites that convert to WebP and declare image optimization complete are addressing file format while ignoring file dimensions, quality overshoot, and device-appropriate delivery — the three factors that typically contribute more to LCP than format choice alone.
Why Format Conversion Alone Produces Insufficient File Size Reduction
WebP’s compression advantage over JPEG is meaningful but bounded. The format achieves 25-34% smaller files at equivalent perceptual quality through VP8 intra-frame encoding, which uses more efficient prediction and transform coding than JPEG’s DCT-based approach. But this percentage reduction applies to the file’s existing size — it does not address whether that existing size was appropriate in the first place.
A 1.5MB JPEG hero image becomes approximately 1MB in WebP. On a mobile 4G connection averaging 10Mbps throughput, the 1MB WebP still takes approximately 800ms just for the network transfer, consuming a significant portion of the 2.5-second LCP budget before decode and render time even begin. The 500KB savings from format conversion improved the situation but did not solve it.
The dominant file size factor is image dimensions, not format. A 4000px-wide image resized to 800px (appropriate for a mobile viewport) reduces file size by approximately 96% regardless of format, because pixel count scales with the square of the dimension ratio: (800/4000)^2 = 0.04, meaning the resized image contains only 4% of the original’s pixels. This dimension reduction saves more bytes than any format conversion. A 4000px JPEG at 1.5MB resized to 800px becomes approximately 60KB as a JPEG or 40KB as a WebP. The dimension change contributed 1.44MB of savings; the format change contributed 20KB. Treating format conversion as the primary optimization addresses the 20KB while ignoring the 1.44MB.
Chrome’s image delivery performance audit explicitly identifies “properly size images” as a higher-impact recommendation than format conversion, calculating the byte savings from serving images at rendered dimensions versus intrinsic dimensions (developer.chrome.com, 2025). Position confidence: Confirmed through Chrome Lighthouse audit documentation, which consistently ranks image sizing above format selection in its impact ordering.
The Responsive Sizing Gap That WebP Does Not Address
A single WebP file served to all devices means either desktop users receive an appropriately sized image while mobile users receive a massively oversized image, or mobile users receive an appropriately sized image while desktop users receive a blurry upscaled version. Neither scenario optimizes LCP across device tiers.
Responsive images using srcset and sizes attributes (or the <picture> element with <source> children) serve different image dimensions to different viewport widths. The browser selects the smallest derivative that covers the rendered dimensions at the device’s pixel ratio, downloading only the bytes necessary for the visual output.
Without responsive sizing, converting to WebP helps desktop users (who may have needed the full-size image anyway) marginally and helps mobile users minimally. The mobile user downloading a 1200px-wide WebP that renders at 375px wide is transferring 10x more pixels than needed. The WebP format saved 30% on those unnecessary pixels — a 30% reduction of waste rather than an elimination of waste.
The performance impact of the responsive sizing gap is substantial. Research and case studies consistently show that responsive image implementations reduce bandwidth usage and improve LCP by 40-60% on mobile devices (aibudwp.com, 2025). This improvement magnitude dwarfs the 25-34% file size reduction from WebP format conversion alone, confirming that responsive sizing is the higher-leverage optimization.
A critical implementation detail: using srcset with w descriptors requires the corresponding sizes attribute. Without sizes, the browser defaults to assuming the image occupies 100vw (100% of the viewport width), causing it to download the largest available derivative regardless of actual rendering size. This common omission negates the bandwidth savings that srcset was intended to provide, effectively producing the same over-downloading behavior as a single non-responsive image.
Quality Overshoot: Why Default WebP Quality Settings Waste Bytes
Most image conversion tools default to WebP quality 80, which produces excellent visual quality for all content types. This “excellent” quality is often unnecessary. Many images — particularly photographic content with natural texture that masks compression artifacts — are visually indistinguishable at quality 60-70 compared to quality 80. The default quality setting wastes 20-40% of bytes on imperceptible quality improvements that no human viewer can detect.
The quality overshoot problem is content-dependent:
- Photographs with natural texture (landscapes, portraits, food photography): quality 65-70 produces results that are perceptually identical to quality 80 for most viewers. The natural texture masks compression artifacts, allowing lower quality without visible degradation.
- Product images on white backgrounds: the product detail requires higher quality (75-80) to preserve edge sharpness, but the white background can be encoded at very low quality without visible artifacts. Uniform-color regions compress extremely efficiently at any quality level.
- Screenshots and text-heavy graphics: require higher quality (80-85) because compression artifacts around high-contrast text edges (ringing, blockiness) are visible at lower quality settings. These images are also excellent candidates for PNG rather than WebP lossy.
- Decorative backgrounds and ambient imagery: quality 50-60 is often sufficient because the image serves as visual atmosphere rather than conveying specific detail.
Perceptual quality calibration — adjusting quality per image based on SSIM or VMAF scores — produces files that are significantly smaller than default-quality WebP with no visible degradation. The calibration targets a perceptual quality threshold (e.g., SSIM 0.95) and encodes at the lowest quality that meets the threshold. For a photographic hero image, this might mean quality 65 instead of the default 80 — a difference of 30-40% in file size with zero perceptible quality loss.
This quality calibration compounds with format conversion and responsive sizing. An image that is correctly sized (375px for mobile), quality-calibrated (SSIM 0.95 target), and format-converted (WebP) might be 15KB. The same image at original dimensions (2000px), default quality (80), and WebP format might be 300KB. Format conversion alone accounted for a 30% improvement; the full optimization stack delivered a 95% improvement. The misconception that WebP conversion is sufficient optimization addresses 30% of a 95% opportunity.
The Decoding Consideration That Format Conversion Ignores
WebP decoding is faster than AVIF decoding on most devices but slower than JPEG baseline decoding on some low-end hardware. The VP8 codec underlying WebP lossy requires more computation per pixel than JPEG’s DCT-based decoding. On devices where the GPU has a fast dedicated JPEG decoder but relies on CPU-based VP8 software decoding (some budget Android devices from 2017-2019), converting a well-optimized progressive JPEG to WebP may actually increase decode time.
The decode time impact is typically small (10-30ms difference) and is masked by the download time savings from WebP’s smaller file size on most connections. But for LCP-critical hero images on pages where the 75th percentile includes devices with limited CPU performance, the format that minimizes total load-plus-decode time may be optimized JPEG rather than WebP on specific device tiers.
Format selection should be informed by field data on decode time across device tiers (measurable via the PerformanceElementTiming API’s renderTime - loadTime delta), not assumed based on file size alone. If field data shows that WebP decode time exceeds JPEG decode time on a significant portion of the user base, and the network is fast enough that the file size difference does not compensate, JPEG may be the better LCP choice for those users.
Position confidence: Observed based on format comparison studies and device-tier analysis. The decode speed difference between WebP and JPEG is format-inherent but its LCP impact is device-population-dependent and may be negligible for many sites.
The Complete Image Optimization Stack
Passing LCP through image optimization requires four layers, applied in order of impact:
Layer 1 — Responsive sizing (highest impact): serve images at the dimensions the layout actually renders at each viewport width. Use srcset with w descriptors and sizes to enable browser-native selection of the correct derivative. This layer alone typically reduces image transfer size by 60-80% for mobile users.
Layer 2 — Quality calibration (high impact): reduce quality to the minimum that maintains acceptable visual fidelity, using perceptual quality metrics (SSIM, VMAF) rather than fixed quality values. This layer typically reduces file size by 20-40% compared to default quality settings.
Layer 3 — Format selection (moderate impact): serve the most efficient format supported by the browser — AVIF, WebP, or JPEG — through server-side content negotiation via the Accept header. This layer typically reduces file size by 25-50% compared to JPEG at equivalent quality, depending on the format.
Layer 4 — Loading priority (LCP-critical): ensure the LCP image is eagerly loaded with fetchpriority="high" and, if it is a CSS background image, preloaded with <link rel="preload" as="image">. Never apply loading="lazy" to the LCP image. This layer does not reduce file size but ensures the optimized file is requested and prioritized as early as possible in the page load sequence.
WebP conversion addresses only Layer 3, and it is not the highest-impact layer. The misconception that WebP conversion constitutes complete image optimization skips the layers that typically deliver the largest byte savings (Layer 1) and the most consistent quality-per-byte improvement (Layer 2), while also ignoring the loading priority control (Layer 4) that determines whether any optimization actually translates to faster LCP.
When WebP-Only Conversion Actually Suffices
The narrow scenario where WebP conversion alone is sufficient: images that are already correctly sized for their rendering dimensions, already quality-calibrated to perceptual quality targets, and served to an audience predominantly on devices with hardware VP8 decoders. In this case, format conversion captures the remaining compression opportunity that the preceding optimizations left on the table.
This scenario applies to sites that already implement responsive images and quality optimization but have not yet adopted next-gen formats — a mature optimization state that most sites have not reached. HTTP Archive data shows that the median website serves images that are significantly larger than their rendered dimensions, uses default quality settings, and lacks responsive image markup. For the majority of sites, WebP conversion without the preceding optimization steps addresses the least impactful layer first while leaving the highest-impact layers unaddressed.
The correct optimization sequence starts with responsive sizing (the largest byte-savings opportunity), proceeds to quality calibration (the most consistent per-image improvement), then applies format conversion (the incremental compression gain), and finally ensures correct loading priority (the LCP timing control). Declaring image optimization complete after format conversion alone is equivalent to painting a house’s trim while leaving the walls bare — it addresses a visible detail while ignoring the dominant surface area.
Does converting PNG screenshots and graphics to WebP lossy produce acceptable results, or should PNG be retained for those image types?
PNG should be retained or WebP lossless used for screenshots containing text, UI elements, or sharp geometric edges. WebP lossy compression introduces ringing artifacts around high-contrast edges that are visually distracting in screenshots, even at quality 85+. WebP lossless compresses PNG-type content by 20-30% without any quality loss, making it the correct WebP variant for screenshots. Applying WebP lossy to all images regardless of content type is a common implementation error that degrades visual quality for non-photographic assets.
Can the picture element with multiple source formats replace srcset for responsive image delivery?
The picture element and srcset serve complementary purposes, not interchangeable ones. The picture element with source children handles format selection (serving AVIF to supporting browsers, WebP to others, JPEG as fallback). The srcset attribute with width descriptors handles resolution selection (serving appropriately sized derivatives per viewport). A complete implementation combines both: picture element sources for format negotiation, each containing srcset attributes for responsive sizing. Using picture for format selection alone without srcset for sizing addresses format but not the higher-impact dimension optimization.
Does lazy loading all images except the hero image guarantee passing LCP for the hero image?
No. Lazy loading non-hero images prevents them from competing for bandwidth during initial page load, which can help, but LCP depends on many factors beyond bandwidth competition. The hero image still requires correct fetchpriority=”high” designation, appropriate file size through responsive sizing and quality calibration, sufficient server response speed (TTFB), and absence of render-blocking resources that delay the image paint. Lazy loading secondary images is a supporting optimization, not a sufficient condition for LCP compliance.
Sources
- https://developer.chrome.com/docs/performance/insights/image-delivery
- https://aibudwp.com/image-optimization-in-2025-webp-avif-srcset-and-preload/
- https://www.frontendtools.tech/blog/modern-image-optimization-techniques-2025
- https://digitalthriveai.com/en-us/resources/guides/lcp-optimization-guide/
- https://developer.mozilla.org/en-US/blog/fix-image-lcp/
