Develop With Faith
May 5, 2026

The Gallery Problem: 200 Photos Killing Your Page Speed

After a baptism Sunday, a missions trip, or a youth retreat, someone on staff uploads 200 photos straight from a DSLR to the website. The intent is good — the church wants to celebrate the moment. The result is a page that takes 18 seconds to load on a phone, drains battery, and gets abandoned before anyone sees the second image.

This is one of the most common performance issues we audit. It is also one of the easiest to fix once you understand what is actually happening behind the scenes.

Why Galleries Are Worse Than You Think

A single uncompressed photo from a modern camera is 6 to 12 MB. Twenty of them is more than a hundred megabytes. Even with a fast connection, that takes meaningful time to download. On a phone connecting through cellular, it can be the difference between a visitor staying and a visitor leaving.

The browser also has to decode every image into memory before painting it. On a mid-range Android device, decoding 200 large JPEGs can lock the page up for several seconds even after the bytes finish arriving. The page is technically loaded — but unusable.

The good news is that most of this is solvable with a few disciplined steps. None of them require a redesign.

Modern Formats: AVIF and WebP

JPEG is 30 years old. The web has better tools now. AVIF and WebP are modern image formats that produce dramatically smaller files at the same visual quality.

A typical example: a 3 MB JPEG of a worship service compresses to roughly 400 KB as a WebP at 80 percent quality, and around 250 KB as AVIF. The visual difference is imperceptible. The bandwidth difference is enormous.

The good news is that browser support is now universal. Safari, Chrome, Firefox, and Edge all handle WebP, and AVIF is supported in everything released in the last three years. The HTML picture element lets you serve AVIF to browsers that support it, fall back to WebP, and finally fall back to JPEG for anything ancient.

<picture>
  <source srcset="baptism-2026.avif" type="image/avif" />
  <source srcset="baptism-2026.webp" type="image/webp" />
  <img src="baptism-2026.jpg" alt="Baptism service, May 2026" />
</picture>

Most modern CMS platforms and image CDNs handle this automatically. Cloudinary, Imgix, and Cloudflare Images will generate the right format based on the requesting browser. If you are on WordPress, plugins like ShortPixel or Imagify do the same.

Responsive Sizing: Stop Sending Desktop Images to Phones

The other half of the gallery problem is sending a 3000-pixel-wide image to a phone that only has 400 pixels of horizontal space to display it. The browser scales it down, but it had to download the full thing first.

The srcset attribute on an image tag tells the browser what sizes are available so it can pick the right one. A gallery thumbnail might offer versions at 300, 600, and 900 pixels wide. The browser grabs whichever fits the device.

<img
  src="retreat-thumb-600.webp"
  srcset="retreat-thumb-300.webp 300w,
          retreat-thumb-600.webp 600w,
          retreat-thumb-900.webp 900w"
  sizes="(max-width: 768px) 50vw, 300px"
  alt="Youth retreat, summer 2026"
/>

For a gallery of 200 photos, this single change can cut total bandwidth by 70 percent on mobile. The pictures still look sharp because the browser is picking exactly the size it needs.

Lazy Loading: Only Load What Is Visible

A visitor on your gallery page is looking at maybe six photos at a time. The other 194 should not download until they scroll toward them. This is called lazy loading, and it is now a single HTML attribute.

<img src="..." loading="lazy" alt="..." />

That is it. Every modern browser honors it. There is no JavaScript required for the common case. The browser holds the image request until the photo is about to enter the viewport, then loads it on demand.

For the first few images that are visible on page load, leave lazy loading off so they render immediately. Lazy load everything below the fold. The difference on a gallery page is often a fivefold reduction in initial bandwidth.

Lightboxes and the Tradeoffs Worth Naming

When a visitor clicks a thumbnail, you usually want to show a larger version in a lightbox. There are three honest options here.

A lightweight library like PhotoSwipe is well-built, accessible, and around 30 KB. A heavier full-featured option like Fancybox brings more polish at the cost of more JavaScript. A native HTML approach using the dialog element and a few lines of CSS is the lightest of all and works on every modern browser.

We tend to recommend PhotoSwipe for ministries that want a polished feel without page weight. It supports touch gestures, keyboard navigation, and screen readers without configuration. The native dialog approach is excellent for simpler galleries where the lightbox just needs to show a larger image and close cleanly.

A Practical Workflow for Ministry Teams

The image optimization process does not need to be technical. A repeatable workflow looks like this.

  • Before uploading, resize photos to a maximum of 2000 pixels on the longest side. A free tool like ImageOptim or Squoosh handles this in seconds.
  • Convert to WebP at 75 to 80 percent quality. The same tools do this.
  • Let your CMS handle responsive sizes — most modern platforms generate them automatically on upload.
  • Make sure loading="lazy" is in your gallery template.
  • Test the gallery page on a real phone after publishing.

Taking care of the images people see is one small way of honoring both their attention and the moment you are documenting. A gallery that loads gracefully says the people in those photos mattered enough to take the extra step.

If your gallery pages are dragging down your site and you would like help tuning them, reach out through our contact page.

← Back to all posts