Performance
AVIF
AVIF is a modern image format that is usually smaller than JPEG at the same visual quality. Browsers that cannot decode it need a fallback, so it ships inside a picture element or behind content negotiation.
How it is measured
Compare bytes on the wire for the same image at matched quality, using a perceptual metric such as SSIM or a side-by-side at the real display size. Then check the effect on Largest Contentful Paint, because a smaller hero only helps if it is the LCP element.
Decode cost is the part people skip. AVIF can take noticeably longer than WebP to decode on a low-end phone, so test in a throttled lab run and in field data, not only on a laptop.
Worked example
A recipe blog serves a 1600 px hero as a 214 KB JPEG. Re-encoded as AVIF at similar quality it is 71 KB. On a throttled 4G profile the image request drops from about 1,150 ms to about 410 ms, and LCP moves from 3,240 ms to 2,610 ms.
On an older Android handset the same AVIF adds roughly 60 ms of decode time on the main thread. LCP still improves, just less than the byte count promised.
How it differs
AVIF is a format. WebP is an older format with wider decoder support and faster decode. AVIF usually wins on size for photos and loses on encode time. A responsive image is about serving the right dimensions, which matters whichever format you pick.
Common errors
Converting every image and ignoring dimensions, so a 4000 px original is still sent to a 400 px slot. Encoding at a quality so low that gradients band. Dropping the JPEG fallback and breaking older Safari and some email clients. Judging only by file size without checking decode time. Lazy loading the AVIF hero and delaying LCP.
In practice
Start with the LCP image and the two biggest photos on your busiest template. Produce AVIF and WebP with a JPEG fallback, set width and height, and compare LCP before and after in both Lighthouse and field data. If your host has an image CDN, let it negotiate the format by Accept header.