Gallery sites live and die on image quality. Every page is image-heavy by design. The hero images, card thumbnails, collection grids, and featured study visuals are the content, not decoration around the content. That makes image delivery the single highest-impact performance consideration for any visual gallery. This guide covers the practical decisions behind image format selection, compression tuning, responsive sizing, lazy loading, and delivery optimization, drawn from running a gallery site where every page has at least one large visual and most have several. We address format trade-offs, JPG quality tuning, dimension strategies, layout shift prevention, and how to think about image performance holistically rather than obsessing over individual file sizes.

Google Developers’ image optimization documentation provides additional technical detail on format internals and compression algorithms for readers who want to go deeper on encoding specifics.

Format Selection

For gallery sites with photographic or rendered visual content, the practical format choices are:

JPG remains the default for photographic and complex visual content. It compresses well, renders consistently across all browsers, and has mature tooling for quality/size trade-offs. For a gallery site, JPG at quality 75-85 strikes the best balance between visual fidelity and file size for hero and card images.

WebP offers 25-35% smaller files than equivalent-quality JPG (according to Google’s compression studies). Browser support is now universal in modern browsers. The trade-off is that WebP encoding at high quality can produce artifacts around sharp edges and text that JPG handles more gracefully.

AVIF pushes compression further (roughly 50% smaller than JPG at equivalent quality, based on Netflix’s 2020 AVIF comparison study), but encoding is slow, browser support is still catching up in older versions, and quality tuning is less predictable than JPG.

SVG is the right choice for illustrations, icons, and any content that is fundamentally vector-based. It scales perfectly, can be styled with CSS, and compresses extremely well with gzip/brotli.

For a gallery site, the pragmatic approach is to use JPG as the base format with optional WebP or AVIF variants served through <picture> elements or server-side content negotiation. Do not convert everything to WebP blindly. Evaluate each image category on its merits.

JPG Quality Tuning

JPG quality is not linear. The visual difference between quality 95 and quality 85 is minimal, but the file size difference is significant (often 40-60% reduction). The visual difference between quality 85 and quality 75 is still small for most photographic content. Below quality 65, artifacts become noticeable in gradients, skin tones, and fine details.

For gallery hero images (1600px wide), quality 80 is a strong default. For card thumbnails (600px wide), quality 75 works well because the smaller rendered size hides compression artifacts. For full-screen detail views, quality 85 preserves enough detail for close inspection.

Always evaluate quality settings at the intended render size, not zoomed in. Artifacts that are visible at 400% zoom are invisible at 1x rendering.

Responsive Sizing Strategy

A gallery site typically needs three to four image sizes per visual:

  • Thumbnail (400-600px wide) for card grids and collection strips
  • Standard (1200px wide) for in-content display and guide illustrations
  • Hero (1600px wide) for above-the-fold hero sections
  • Full (2400px wide, optional) for detail views on high-density displays

Use the srcset attribute to let the browser choose the appropriate size:

<img
  src="/img/guides/example-1200.jpg"
  srcset="/img/guides/example-600.jpg 600w,
          /img/guides/example-1200.jpg 1200w,
          /img/guides/example-1600.jpg 1600w"
  sizes="(max-width: 768px) 100vw, 1200px"
  alt="Example visual study"
  width="1200"
  height="750"
  loading="lazy"
>

The sizes attribute tells the browser how wide the image will be rendered, which combined with srcset widths, allows it to pick the smallest sufficient file.

Preventing Layout Shift

Images without declared dimensions cause layout shift when they load, pushing content around and degrading Cumulative Layout Shift scores. The fix is simple: always include width and height attributes that reflect the image’s aspect ratio.

<img src="..." width="1200" height="750" alt="...">

Combined with CSS max-width: 100%; height: auto;, this gives the browser the aspect ratio information it needs to reserve space before the image loads. The actual rendered dimensions are controlled by CSS, but the ratio prevents the layout jump.

For gallery grids where images have different aspect ratios, use aspect-ratio in CSS to enforce consistent card proportions:

.card-image {
  aspect-ratio: 16 / 10;
  overflow: hidden;
}
.card-image img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

Lazy Loading

Native lazy loading (loading="lazy") is the simplest and most effective approach. It defers image loading until the image is near the viewport, reducing initial page weight.

The one exception: do not lazy-load above-the-fold images. Hero images and any visual content visible without scrolling should use loading="eager" (or omit the attribute entirely, since eager is the default). Lazy-loading visible content delays the Largest Contentful Paint metric and makes the page feel slower.

Self-Hosted vs. CDN

For a gallery site, self-hosting images with a CDN layer (like Cloudflare’s built-in caching) is the simplest architecture. The images live in your repository or deploy pipeline, and the CDN handles edge caching and delivery.

External image CDN services (Cloudinary, Imgix, etc.) offer on-the-fly resizing and format conversion, but add a dependency, a cost layer, and potential availability risk. For sites with a finite, curated image set, self-hosting with pre-generated sizes is more predictable and reliable.

Set long cache headers for image assets. Images in a gallery rarely change once published. A Cache-Control: public, max-age=31536000, immutable header with fingerprinted filenames lets browsers cache images for a year.