AVIF’s headline advantage is file size: at equivalent visual quality it typically produces smaller files than WebP or JPEG, which is why it gets recommended as a default “next-gen format” choice. But file size and decode time are not the same variable, and AVIF’s compression efficiency comes partly from a more computationally complex codec (it’s based on AV1 intra-frame coding), which means decoding an AVIF file can take meaningfully more CPU work than decoding a comparably-sized WebP or JPEG file. For an LCP-critical image, that decode step happens on the client, on the main thread or a compositor thread, before the image can be painted, so a smaller file that takes longer to decode can produce a worse LCP time than a larger file that decodes faster, especially on lower-end mobile CPUs where decode throughput is the bottleneck rather than network transfer time.
Mechanism: why a smaller file can paint slower
Core Web Vitals, and LCP specifically, measure wall-clock time to render, not bytes transferred. The full path for an image to count toward LCP is: request sent, bytes received, image decoded from its compressed format into raw pixel data, and that pixel data composited/painted to the screen. On a fast network with a slow CPU (a very common real-world combination for mid-range and budget Android devices, which make up a large share of global mobile traffic), the transfer step can be nearly instant while the decode step is not. If an encoding profile prioritizes maximum compression, it can produce output that is smaller in bytes but structured in a way that requires more decode-side computation to reconstruct, and on a slow CPU that computation cost can outweigh the time saved on the network.
This is a direct consequence of how AVIF’s encoder exposes a speed/effort tradeoff. AVIF encoders (based on AV1 encoding tools, most commonly libaom or rav1e in practice) expose parameters, often called “speed” or “effort,” that trade encode-side computation for compression efficiency: a slower, higher-effort encode pass can extract more redundancy and produce a smaller file, but the resulting bitstream isn’t necessarily any cheaper to decode as a result of that extra encode effort, since encode effort and decode complexity are governed by different parts of the codec design. In other words, tuning the encoder for “smallest possible file” optimizes the metric most visible in a file-size comparison, while leaving decode-side cost unmanaged, and decode cost is what actually gates LCP on the client.
It’s also worth being precise about what’s documented versus what’s project-reported: the general characteristic that AVIF can carry a heavier decode cost than JPEG or WebP, particularly on constrained hardware, is a widely discussed tradeoff in codec and browser engineering circles and is consistent with AVIF’s basis in a more sophisticated coding format than the DCT-based approaches JPEG and WebP use. There isn’t a single universal published number for “AVIF decode time versus WebP decode time” that applies across all images and devices, because it depends heavily on image content, resolution, encoder settings, and the specific hardware and browser decode path (hardware-accelerated decode where available versus software decode, which some browsers use for AVIF depending on platform support). Anyone citing a specific fixed percentage difference is asserting more precision than the underlying reality supports; the honest claim is the direction and existence of the tradeoff, not a fixed magnitude.
Practical implication: calibrate and test, don’t assume format alone solves it
The practical error this produces is treating “convert to AVIF” as a checkbox that’s finished once file size drops in a before/after comparison. Web.dev’s own image-format guidance frames AVIF and WebP as “next-gen formats” that reduce file size, but file size reduction is a proxy for the actual Core Web Vitals goal, not the goal itself, and proxies break down exactly in cases like this one.
What calibration actually looks like:
Test decode performance on real low-end hardware, not just file size in a compression tool. A file-size comparison between AVIF and WebP output tells you about network transfer cost only. To know the LCP effect, measure actual paint timing on representative low-end devices, or at minimum in a CPU-throttled Chrome DevTools session (the Performance panel’s CPU throttling, combined with network throttling to isolate decode cost from transfer cost), for the specific images that are LCP candidates. If the site has real user monitoring, segmenting LCP by device class after an AVIF rollout is the most direct field confirmation, since it captures the actual distribution of CPUs in the visitor base rather than a single test device.
Treat the LCP element differently from decorative or below-the-fold images. The decode-time risk matters most for whichever image is the actual LCP candidate on a given template, since that’s the one gating the metric Google measures. For non-LCP images, a slightly slower decode has much less consequence because it doesn’t block the metric the same way. This argues for evaluating format choice per template/image-role rather than applying one blanket “AVIF for everything” rule sitewide.
Reconsider encoder effort settings, not just format. If using AVIF for LCP-critical images, testing a faster/lower-effort encoder setting that trades some additional file size for a less complex, faster-to-decode bitstream can be worth it specifically for those images, even though it would look like a “worse” choice in a pure file-size comparison. This is the calibration the question points at: the encoding profile needs to be chosen with decode speed as an explicit input, not just final byte count.
Keep format negotiation in place and don’t treat AVIF as a strict replacement. Serving AVIF only to browsers that support it, with WebP or JPEG fallback (via the <picture> element’s multiple <source> types, letting the browser pick the first supported format it encounters), remains correct practice. The backfire scenario in this question isn’t about AVIF support detection going wrong, browsers that don’t support AVIF simply won’t select it. The risk is that even among browsers that do support and correctly decode AVIF, decode cost on weak hardware can erase or reverse the expected LCP benefit, which a format-support fallback doesn’t protect against, since the fallback logic only handles compatibility, not performance-per-device.
The general principle: format selection for Core Web Vitals should be validated against rendering time on the actual device distribution being served, not against file size alone, because file size is only one of the two variables (transfer time and decode time) that determine when an image actually paints.
A worked example of the tradeoff going the wrong way
Suppose a mid-range e-commerce site converts its hero product image from WebP to AVIF using a high-effort encoder setting, and the file drops from 85KB to 52KB, a result the team treats as an unambiguous win in a before/after comparison tool. On a CPU-throttled trace simulating a common budget Android device, the WebP version transfers in roughly 180ms and decodes in about 40ms, landing LCP around 220ms after the request starts. The AVIF version transfers faster, around 110ms given the smaller payload, but the heavier decode step takes close to 300ms on the same throttled CPU, pushing LCP to roughly 410ms, nearly double the WebP result, despite being the smaller file. The byte-size comparison said AVIF won; the paint-timing comparison said it lost, because the encoder’s high-effort setting optimized for compression ratio while leaving decode cost on constrained hardware unmanaged. Switching that specific hero image to a faster, lower-effort AVIF encode, or leaving it as WebP, would close the gap the file-size number never revealed.
