Photo Gallery

Why It Matters

Image weight is the whole story. A 5 MB photograph resized to 1600 pixels wide and saved as WebP usually comes out in the low hundreds of kilobytes, so a forty-image gallery falls from something near 200 MB to well under 20 — the difference between a page that works on a train and one that stalls. Nobody reports a slow gallery; they simply close it. There is a cost on the other side too: if full-resolution originals sit directly behind the thumbnails on a public page, anyone can take them, and your bandwidth pays for every attempt.

How It Works

Generate two sizes of every picture: a thumbnail of a few hundred pixels for the grid, and a display version around 1600 to 2000 pixels wide for the larger view. Serve the grid with lazy loading, the loading="lazy" attribute on each img element, so the browser fetches what is near the viewport instead of all forty at once. Use responsive images as well — a srcset listing two or three widths with a sizes hint — and a phone pulls the small file while a desktop pulls the large one. Give every image alt text describing what is actually in it, both for screen readers and because that text is what a search engine has to work with. Then let caching do the rest: photographs never change once published, so they are the ideal thing to serve with a long Cache-Control lifetime.

Real-World Example

Common Mistakes

• ✕Uploading straight from the camera — the browser will happily scale a 6000-pixel image down to 400 pixels on screen, but only after downloading every byte of it
• ✕Using one file for both the thumbnail and the full view — the grid then costs as much to load as opening every photograph at once
• ✕Leaving alt text empty throughout — a screen reader announces forty unlabelled graphics, and a search engine has nothing to index

Related Terms