Lossy compression

Compression mechanism and codecs

Lossy image codecs follow a broadly similar pipeline. Pixels are first converted to a colour space that separates luminance from chrominance (e.g., Y’CbCr), because human vision is more sensitive to brightness detail than colour. Many codecs apply chroma subsampling (often 4:2:0), storing fewer chroma samples than luma to save bits with limited perceptual cost. Blocks or tiles of the image are then transformed from the spatial domain to a frequency domain using discrete cosine transforms (DCT) or wavelets, concentrating energy into fewer coefficients that can be quantised efficiently.

Quantisation is where information is irreversibly removed. Coefficients are divided by quantiser values and rounded, coarsening fine detail and noise that are harder to see. Perceptual models may weight frequencies and directions to keep visually important structure while sacrificing less noticeable content. Finally, the quantised symbols are entropy‑coded losslessly (e.g., Huffman, arithmetic, or ANS coding) to remove statistical redundancy. The decoder inverts only the lossless parts, reconstructing an approximation governed by the chosen quantisation and coding tools.

Common web codecs include JPEG (8×8 DCT, mature, ubiquitous), WebP (block‑transform with in‑loop filtering, lossy and lossless modes), AVIF (intra frames of AV1 with advanced transforms, tools, and alpha), and JPEG XL (various transforms, perceptual quantisation, near‑lossless and lossless support). Typical photographic pages achieve 10:1–20:1 compression with JPEG at mid settings; WebP and AVIF can often deliver a further 20–50% reduction at similar subjective quality, depending on content and encoder tuning. Results vary widely with texture complexity, edges, and the presence of artificial graphics.

How lossy compression improves page speed and Core Web Vitals

Images typically account for the largest share of page weight, often 40–70% on content‑rich sites. Reducing image bytes shortens transfer time over mobile and congested networks, allowing earlier rendering of above‑the‑fold content. This directly benefits Largest Contentful Paint (LCP) when the hero image is the LCP element. Smaller payloads also reduce bandwidth contention for other critical resources, making the page feel more responsive across a broader set of devices and connection qualities.

Beyond transfer time, decode and rasterisation costs matter. Modern codecs vary in CPU requirements: AVIF and JPEG XL tend to achieve lower bitrates but can demand more decode time than JPEG or WebP on some clients. The net effect on user‑perceived speed depends on device capability, image dimensions, and concurrency with main‑thread tasks. Thoughtful choices—such as using highly compressed next‑gen formats for large photos while keeping UI assets simpler—can strike a balance between byte savings and processing overhead.

Field data often shows meaningful improvements from switching from JPEG to WebP or AVIF for large imagery, with 20–60% median byte reductions at comparable visual quality. This can translate into tenths of a second improvement for LCP on mobile. Gains compound with other techniques—responsive images, preloading the hero asset, efficient caching, and HTTP/2 or HTTP/3 delivery—to improve Core Web Vitals outcomes and reduce data costs for users.

• LCP: fewer bytes and prioritised delivery of the hero image lower the time to render the largest element.
• INP: less main‑thread pressure from decoding large images can reduce interaction latency on low‑end devices.
• CLS: not directly affected by compression, but predictable intrinsic dimensions and responsive sizing prevent layout shifts.

Lossy compression removes or coarsely quantizes information to reduce bitrate, which introduces characteristic distortions. The trade-off is governed by rate–distortion optimization: lower bitrates (or lower “quality” settings) increase distortion, and the type and visibility of artifacts depend on the codec, encoder tuning, chroma subsampling, bit depth, display, and image content.

Rate–distortion optimisation balances bits spent against perceived quality. Encoders adjust quantiser levels, transform tools, and in‑loop filters to maximise quality per bit. The same nominal “quality 75” means different things across codecs and even across encoders of the same format. Content matters: detailed foliage, hair, and fine textures are harder to compress than smooth backgrounds, often needing more bits to avoid objectionable degradation.

Characteristic artefacts vary by codec and setting. Blockiness and mosquito noise are common in block‑based systems when quantisation is high, while ringing can appear near sharp edges due to truncated high‑frequency coefficients. Heavy chroma subsampling may cause colour bleed around text and thin lines. At very low bitrates, banding appears in gradients, and high‑frequency textures can smear. Display size, pixel density, viewing distance, and ambient light all affect whether users notice these issues.

Objective metrics such as PSNR and SSIM provide a coarse signal of distortion, while MS‑SSIM and VMAF correlate better with human judgements in many cases. However, perceptual quality remains context dependent. Teams often target “visually lossless” thresholds where artefacts are not apparent at typical viewing conditions, reserving more aggressive settings for thumbnails or background imagery where defects are less likely to be scrutinised.

Relationship to search performance

Lossy compression itself is not a direct ranking factor, but its effects on page experience feed into search performance. Smaller image payloads can improve Core Web Vitals—particularly LCP—contributing to better page experience signals in Google’s systems. Faster rendering lowers bounce risk and can improve engagement metrics that indirectly correlate with search visibility and conversion outcomes.

For image search, visual clarity and relevance remain critical. Over‑compressed images may show artefacts that reduce click‑through rates or harm perceived quality on product detail pages. Maintaining appropriate resolution, accurate alt text, structured data, and descriptive filenames remains essential; lossy compression should be tuned so that important details (e.g., textures of apparel, legibility of labels) are preserved for both users and automated systems that generate previews and thumbnails.

Crawl efficiency can also benefit when media is smaller and cacheable, reducing server load during discovery and refresh. However, repeated transcoding between lossy formats across pipelines may degrade quality over time (generation loss). To avoid unintended quality dips in search previews or social embeds, keep a high‑quality master and standardise publish‑time settings per placement and device class.

Use cases, limits, and alternatives

Lossy compression is well suited to photographs, textures, camera‑captured artwork, and complex scenes where human vision tolerates small detail loss. It is frequently applied to hero banners, editorial images, social previews, and user‑generated photos to reach practical delivery sizes. For very large hero assets, next‑gen codecs can achieve substantial savings while retaining visual fidelity when tuned thoughtfully per image and display density.

Limits appear with sharp graphics such as logos, UI icons, screenshots, and text overlays. Chroma subsampling and quantisation can blur edges, introduce colour fringing, and cause banding. In these cases, vector formats (SVG) or lossless raster formats (PNG, lossless WebP/AVIF, or JPEG XL lossless) are preferable. Archival or editing workflows should avoid cumulative loss; store or edit in a lossless master and export lossy variants only for distribution targets.

Near‑lossless modes—available in codecs like WebP and JPEG XL—offer fine‑grained control to approach visually lossless results at reduced bitrates. Alternatives also include increasing bit depth to mitigate banding when gradients are unavoidable, or disabling chroma subsampling (4:4:4) for assets that mix photos with small text. The right choice depends on content, brand requirements, and the relative weight of bytes, quality, and decode cost in your performance budget.

• Good fits: photos, backgrounds, product shots without tiny text, lifestyle imagery, textures.
• Avoid or limit: logos, UI sprites, text‑heavy images, line art; prefer SVG or lossless.
• Alternatives: PNG, SVG, lossless WebP/AVIF, JPEG XL lossless; or hybrid approaches (photo lossy + overlayed vector text).

Implementation notes

Choose formats per context. JPEG remains dependable for broad compatibility; WebP is well supported and usually smaller; AVIF often delivers the best compression at higher encode/decode cost on some clients; JPEG XL offers strong efficiency where supported. Serve the smallest acceptable format via responsive images and content negotiation, with safe fallbacks for legacy browsers. Prioritise the LCP image with preload and ensure it is sized appropriately for the viewport to avoid wasting bytes.

Tune quality by content class rather than a single global setting. Portraits, foliage, and fine patterns may need higher bitrates than flat backgrounds or bokeh. For UI‑adjacent assets or images with small text, consider 4:4:4 chroma or a lossless format. Avoid recompressing previously lossy images during transformations; retain a lossless or high‑quality master and generate final variants in one step to prevent generation loss. Validate outcomes with perceptual metrics and quick human review on both standard and high‑density displays.

• Resize before compressing; do not ship pixels users never see. Match DPR breakpoints where practical.
• Use per‑asset budgets (e.g., hero ≤150–250 KB on mobile, context dependent) and test on real networks.
• Preserve necessary ICC profiles and orientation metadata; strip non‑essential EXIF to save bytes.
• For transparency, prefer formats with native alpha (WebP, AVIF). Beware halos if mixing lossy colour with binary masks.
• Monitor decode time and memory on low‑end devices; large AVIFs may benefit from tiling or alternative fallbacks.

Comparisons

Lossy vs lossless

Lossy compression achieves larger size reductions by discarding information, while lossless preserves every bit and typically yields smaller savings for photographs. For crisp graphics and text, lossless maintains sharp edges and avoids colour fringing. Many modern ecosystems mix both: lossy for photos and lossless for UI or where legal/brand fidelity is non‑negotiable. Some codecs provide near‑lossless modes to span the middle ground.

JPEG vs WebP vs AVIF (images)

JPEG offers broadest compatibility and fastest decoding but larger files at equivalent quality. WebP often improves on JPEG by 20–30% for photographs and supports lossy alpha. AVIF typically compresses a further 20–40% beyond WebP at similar visual quality, with better handling of textures and gradients, but may decode more slowly on some hardware. Encoder choice and settings can shift these deltas; always validate with target content and devices.

Chroma subsampling 4:4:4 vs 4:2:0

4:2:0 reduces chroma resolution by half in both directions, saving bits with minimal impact on natural photos. However, it can blur coloured edges and small text. Using 4:4:4 preserves full colour detail at a bitrate cost and is preferable for screenshots, UI overlays, or product images with fine labels. Some workflows selectively enable 4:4:4 for specific assets while keeping 4:2:0 for general photography.

FAQs

What quality setting should I use for web images?

There is no universal number. A JPEG “quality 75” does not match a WebP or AVIF “75.” Start from a visually lossless target for your audience and device mix, then reduce until artefacts become just noticeable in typical viewing. Many teams land around JPEG 70–85, WebP 60–80, and AVIF cq levels tuned per encoder, but content variability means you should validate with representative images and track LCP and error rates in production.

Will lossy compression hurt my SEO?

Not directly. Properly tuned lossy compression generally improves page speed and Core Web Vitals, which can aid search performance. Problems arise when compression is too aggressive, harming user experience, product detail legibility, or click‑through from image results. Keep descriptive alt text, structured data, and sitemaps intact, and ensure images are clear at the sizes search platforms display.

Is AVIF always better than WebP or JPEG?

No. AVIF often yields smaller files at similar quality, particularly for large photographs and gradients, but it can decode more slowly on some devices and may not be supported in every environment. Small images and UI elements may show little benefit. Use content negotiation and responsive images to serve the best supported format per client, and retain WebP or JPEG fallbacks where necessary.

How do I avoid banding and colour fringing?

For gradients, favour codecs and settings that preserve smooth tones: slightly higher bitrates, dithering where available, and higher bit depth if supported. To prevent colour fringing around text or fine edges, disable chroma subsampling (4:4:4) or use a lossless format for those assets. Reviewing on high‑density displays at 100% zoom helps catch issues before publishing.

Does recompressing an image multiple times degrade it?

Yes. Each lossy encode introduces additional rounding and can amplify artefacts, a phenomenon known as generation loss. Keep a high‑quality or lossless master and generate final delivery variants in a single encode step per format and size. Avoid workflow loops that decode and re‑encode lossy assets during resizing or watermarking.