What Happens Before an Image Actually Renders

Images dominate web traffic, but the technical details of how they are stored, compressed, and delivered often stay hidden behind the final visual. Getting a handle on a few core concepts—compression, color encoding, and loading behavior—makes it easier to understand why format choice matters so much for site performance and user experience.

Compression Strategies: Lossy vs. Lossless

Compression is what keeps image files from becoming too heavy to transmit quickly over networks. The trade-off always comes down to file size versus visual fidelity.

  • Lossy compression removes data that is considered less important to the human eye. It yields much smaller file sizes, but over-compression can introduce visible artifacts and blurring.
  • Lossless compression packs data more efficiently without discarding any information, so a decompressed image is pixel-identical to the original. It keeps quality intact but generally produces larger files. Formats like PNG and certain WebP variants rely on this method.

Resolution, Pixel Density, and Bit Depth

Resolution refers to the total pixel count in an image’s width and height, while pixel density is measured as pixels per inch (PPI). High-density screens (such as Retina displays) require larger resolution images to remain sharp, which increases file size.

Bit depth dictates how much color information each pixel stores. An 8-bit image can hold 256 colors per channel, while a 16-bit image jumps to 65,536. The result is richer visuals at the cost of a larger file footprint, forcing a trade-off between color precision and load times.

Why Encoding Uses Color Subsampling

RGB might be the most familiar color model, but compression pipelines often rely on the YCbCr color space instead. The Y channel holds luminance (brightness), while Cb and Cr store chrominance (blue and red color differences). Since the human eye is significantly more sensitive to brightness than to color, encoding can reduce detail in the chrominance channels without any noticeable impact.

That selective reduction is called chroma subsampling, and its notation signals how much color data is kept relative to luma:

  • 4:4:4: No subsampling—every pixel retains full luminance and chrominance data. Highest fidelity, biggest file.
  • 4:2:2: Luma is kept for four pixels, but chroma is averaged across two, halving color resolution horizontally.
  • 4:1:1: Only one in every four pixels carries chrominance data, shrinking the file further but weakening color accuracy.
  • 4:4:0: Color resolution drops vertically rather than horizontally—chroma is shared across rows, preserving horizontal color while cutting vertical color detail.

Cutting chroma information trims file sizes dramatically, but over-simplifying makes colors look flat or blurred.

Progressive vs. Baseline Delivery

How an image reveals itself also affects perceived performance. Baseline loading draws the image top-down, forcing users to wait for the full download if they want to see the bottom without scrolling prematurely. Progressive loading instead displays a rough version of the whole image at once, sharpening as more data arrives—which feels faster even if the file isn’t fully decoded yet.

For older formats such as JPEG, the loading mode is fixed during encoding and cannot be changed without re-encoding. Newer formats such as WebP and AVIF are more flexible, letting the decoder decide between baseline or progressive display. That flexibility matters on real-world sites, where network speed, browser type, and context can vary widely.

Transparency and Hidden Data

An alpha channel records each pixel’s transparency level, letting images blend into varied backgrounds seamlessly. PNG and WebP both support alpha channels, making them favorites for logos and graphical overlays.

Beyond visible pixels, images often carry metadata such as Exif data—camera settings, timestamps, and even geolocation tags. While this information can aid organization or enhance UI design, it also inflates file sizes. Worse, it creates privacy risks: a photo shared online might quietly broadcast a user’s location. Utilities such as the piexifjs library let developers read, edit, or strip Exif data when needed.

Format-by-Format Analysis

JPEG

JPEG has been the default for photographs for decades, favoring partial data loss and the YCbCr color space to compress heavy images efficiently.

  • Compression: Lossy, tuned to discard visual information humans aren’t likely to notice.
  • Features: Supports both baseline and progressive loading but lacks any transparency support—JPEGs sit on a solid background.
  • Best used for: Photographs and other images where minor fidelity loss is acceptable, especially when bandwidth matters.

JPEG XL is positioned as its modern successor, offering both lossless and lossy coding, higher dynamic range, and faster decode speeds with backward compatibility. But browser adoption remains a limiting factor, and it is not yet a safe choice for general web deployment.

PNG

PNG was built to replace GIF format and leans on lossless compression, making it harder to mis-use.

  • Compression: Fully lossless, guaranteeing decompression restores the original pixels.
  • Features: Alpha channel handling means supports flexible transparency options, plus variable bit depths support more color depth if needed.
  • Best used for: Foreground graphics like logos, icons, and UI elements where crisp lines, text, or transparent layers are key. Use for photos hurts your files’ size quickly due to the lossless approach.

WebP

Google introduced WebP to bundle accessibility and speed into one format. Its encode efficiency usually beats both JPEG lossy compression at equal quality levels, and PNG-tier lossless when using transparent needs.

  • Compression: Supports both lossy and lossless pipelines, shrinks files significantly compared to predecessors.
  • Features: Gains full alpha channel transparency and even simple animation, unlike most older formats.
  • Best used for: Both photos and graphics web-wide, though browser compatibility scrutiny remains necessary before relying entirely on it.

AVIF

AVIF borrows codec strength from AV1 and targets a modern balance of higher compressed output without a steep fall in visuals.

  • Compression: Supports lossy and lossless modes, generally yielding even smaller results than WebP at matching quality.
  • Features: Keeps alpha transparency like WebP and demonstrates consistent real-world size savings, but encoding and decoding take a measurable 20% hit in speed, although caching mitigates the effect after the first visit.
  • Best used for: Situations where quality per byte truly matters—but keep an eye on the still-incomplete browser support landscape.

Selecting the right format ultimately means balancing correct color representation, download weight, rendering behavior, and how those details ripple into experience quality for different devices and connections.

The next/image component

Next.js ships with a built-in next/image component that handles image optimization automatically, serving the appropriate size and format for each device. By default, the component optimizes images to WebP when the images.formats property is omitted from next.config.js. You can extend this to support modern formats while retaining graceful fallbacks for older browsers.

next.config.js

module.exports = { 
   images: {   
      formats: ['image/avif', 'image/webp'],  
   },
}

With this configuration, the component serves AVIF to browsers that support it, falls back to WebP for those that don't, and preserves the original format if neither is supported.

Fine-tuning with quality and sizes

Beyond the required props, the component accepts optional quality and sizes props to control compression and responsive behavior.

The quality prop determines the degree of lossy compression. A lower value discards more data, reducing file size at the expense of potential visual clarity. A higher value retains more of the original data, producing a sharper image but with a larger file size. Adjusting this prop lets you strike a balance between image fidelity and payload weight.

// Good quality. A balance between image clarity and file size, suitable for most web use cases.  
<Image quality={75} />
// Maximum quality. Ensures the best clarity but results in the largest file size.
<Image quality={100} />
// Very low quality. The image will be compressed significantly, resulting in a smaller file size but noticeably reduced clarity.
<Image quality={33} />

The sizes prop signals to the browser how wide the image will render at different viewport widths. That information guides the browser in choosing the best entry from the generated srcset — high pixel density displays receive higher-resolution images for sharper rendering, while standard-density screens get a baseline resolution that conserves bandwidth.

// Takes full viewport width on screens up to 768 pixels wide, otherwise half viewport. Useful for mobile devices in portrait mode.
<Image sizes="(max-width: 768px) 100vw, 50vw" />
// Half viewport with on devices up to 768 pixels wide. For devices between 769 and 1200 pixels wide, it will take up a third of the viewport width. Useful for images in multi-column layouts
<Image sizes="(max-width: 768px) 50vw, (max-width: 1200px) 33vw, 20vw"  />
// Regardless of the device's width, the image will always render at 500 pixels wide.
<Image sizes="500px" />

When you omit sizes, Next.js treats the image as having a fixed dimension and optimizes pixel density accordingly. Including sizes declares that the image is responsive and will scale with the viewport, allowing Next.js to generate and serve responsive candidates more effectively.

A concluding note on image delivery

Image format selection is a meaningful factor in user experience. Along with format choice, careful consideration of pixel density, bit depth, and chroma subsampling ensures images remain visually sharp without bloating page weight. And because metadata can carry privacy risks, removing or managing it during optimization keeps images both efficient and safe to serve.