Start with the simplest asset: no image at all

Before adding an image, ask whether one is actually needed. Images typically cost far more bytes than HTML, CSS, or JavaScript. If you can achieve the intended effect without an image resource, you have already found the best optimization.

When an image does earn its place, check whether a non-image technology can do the job more efficiently:

  • CSS effects such as shadows, gradients, and animations are resolution-independent. They stay sharp at any zoom level and often use a fraction of an image file's bytes.
  • Web fonts give you custom typefaces while keeping text selectable, searchable, and resizable.

Never encode meaningful text inside an image. Text rendered as pixels is not selectable, searchable, zoomable, or accessible, and it looks poor on high-DPI displays. Web fonts need their own performance tuning, but they solve all of those problems and are always the better choice for displaying text.

Vector vs. raster: a fundamental split

If you do need an image, the next decision is whether it should be vector or raster. Vector formats (like SVG) describe an image with lines, points, and polygons. Raster formats (PNG, JPEG, WebP, AVIF) store a color value for every pixel in a rectangular grid.

Vectors are a natural fit for logos, icons, and text—anything composed of relatively simple geometric shapes. They render sharply at any resolution and scale cleanly across display sizes. But vector formats fall apart on complex scenes such as photos: describing every shape in SVG markup becomes prohibitively expensive, and the result still may not look photorealistic. For that kind of content, use a raster format.

Raster images have the opposite tradeoff. They encode data per pixel, so scaling one up produces jagged, blurry edges. To serve users well across devices, you may need to produce multiple resolutions of the same raster asset.

What high-resolution screens really cost

CSS pixels and device pixels are not the same thing. One CSS pixel may map to one device pixel on one screen and to several on another. More device pixels per CSS pixel means finer on-screen detail—that is the appeal of high-DPI (HiDPI) displays.

HiDPI screens look great, but they impose a clear cost. A display with double the horizontal and vertical resolution has four times as many pixels, so raster assets need four times the pixel data to look sharp. In practice:

  • Use vector images whenever possible. They are resolution-independent and always render crisply.
  • If a raster image is unavoidable, serve responsive images so each device gets an appropriately sized file.

Comparing raster formats by feature

Raster formats differ in more than compression. Each one supports a distinct set of features such as animation and alpha (transparency) channels, so the right format depends on both the visual result you need and the functional requirements of the asset.

PNG and JPEG are the two universally supported raster formats. Modern browsers also support WebP and AVIF, which generally compress better and offer more features. Prefer WebP or AVIF where possible, with a JPEG or PNG fallback for older clients.

For the legacy formats specifically, match the format to the use case:

  1. Do you need animation? Use a <video> element. GIF is capped at 256 colors and produces much larger files than video. APNG supports more colors than GIF but still comes in significantly larger than a visually equivalent video file. Replace animated GIFs with video.
  2. Do you need to preserve fine detail at the highest quality? Use PNG or lossless WebP. PNG applies no lossy compression beyond the color palette choice, so it preserves quality but at a high byte cost—use it sparingly. Lossless WebP often beats PNG on size. If the asset is mostly geometric shapes, convert it to SVG. If it contains text, use a web font instead.
  3. Is it a photo, screenshot, or similar? Use JPEG, lossy WebP, or AVIF. JPEG combines lossy and lossless optimization; test several quality levels to find the sweet spot. Lossy WebP and lossy AVIF are strong JPEG alternatives for web images, but remember that lossy encoding discards information, so some colors may differ from the JPEG equivalent.

If you control the client—for example, rendering in a WebView inside your own application—you can standardize on WebP exclusively. Facebook and many other companies use WebP for all in-app images, and the byte savings justify it.

Images and Largest Contentful Paint

Images are often LCP candidates, meaning the largest visible element on the page is an image. When that is the case, the image's byte size directly affects its load time, and efficient encoding becomes crucial to keeping LCP fast. Prioritizing good format and compression choices for images is therefore a key step in making the page's perceptual performance as fast as possible.