Why Is My Client Gallery So Slow to Load?

Before you can fix anything, pin down the symptom. These are four different problems with four different causes, and clients describe all of them with the same sentence.

• The page itself takes a long time to appear. Blank screen, spinner, nothing to look at. That is usually the page furniture, not the photos.
• The page appears but the thumbnails fill in slowly. Grey boxes that resolve one by one over many seconds. That is almost always image weight.
• Scrolling stutters or the phone gets hot. The browser is decoding more image data than the device can comfortably handle at once.
• Clicking one photo to view it large takes a long time. A single large file, or a file being fetched from far away.

Ask the client which of those it was, and on what device. One clarifying question often ends the investigation before it starts.

This is the single most common cause, and it is worth more of your attention than everything else on this page combined.

A thumbnail in a proofing grid occupies a few hundred pixels on screen. A camera original is many times larger in every dimension, and file size grows roughly with area, so an image with four times the width and height carries something like sixteen times the data. When a gallery displays originals scaled down with CSS instead of serving purpose-made smaller copies, the browser still downloads every byte of the original, then throws most of the detail away to draw a small square. The client waits for a print file in order to look at a thumbnail.

Multiply that by a screen full of thumbnails and the arithmetic gets ugly fast. One screenful of originals can cost the client many times the transfer that the view actually needed. On a laptop on office fibre you may never notice. On a phone on mobile data it is the whole problem.

A properly built gallery generates several sizes of every photo and hands the browser the one that fits the slot: a small file for the grid, a larger one when the client opens a photo full screen, and the original only when they deliberately download it. Modern galleries also serve those files in a compressed format that browsers can decode efficiently.

How to check this yourself, without any technical knowledge: open the gallery, right-click a thumbnail and save it to your desktop, then look at the file size and the pixel dimensions. If a thumbnail saves as a multi-megabyte file with camera-sized dimensions, you have found your answer. Nothing else you do will matter until that is fixed.

If the gallery is on your own website, this is usually a theme or plugin setting, or a photographer uploading exports straight out of the camera folder. If it is a hosted platform, the platform is meant to be handling this for you, and if it is not, that is a real reason to move.

The second cause is quantity. Even correctly sized proofs add up. A gallery with two thousand images in one continuous grid asks a phone to keep track of two thousand image slots, and depending on how the page is built, to fetch a great many of them before the client has scrolled anywhere near them.

Two techniques keep this under control. Lazy loading means the browser only requests an image as it comes close to the viewport, so a client who looks at the first twenty photos downloads twenty photos. Pagination or sectioning means the gallery is broken into pages or chapters so no single page is responsible for everything.

You have a lever here that has nothing to do with technology: send fewer photos. A proofing gallery with a hard cull is faster, and it also gets picked faster, because clients stall in front of a wall of near-duplicates. If you are sending everything you shot and letting the client sort it out, the loading time is the smaller of your two problems.

When a shoot genuinely is enormous, split it. One gallery per day, per location or per setup loads better than one gallery holding all of it, and it reads better too.

Every image request is a round trip between the client's device and wherever the file lives. If all your files sit on a single server in one city, a client on the other side of the world pays that distance on every single request, and a grid makes many requests.

Distributed delivery solves this by keeping copies of the files close to the people asking for them, so the request is answered from a nearby location instead of the original one. Most established gallery platforms do this. Self-hosted galleries on a basic shared hosting plan frequently do not, and that is why a gallery that feels fine to you in your own city feels sluggish to a client three time zones away.

This cause has a signature: the gallery is consistently slower for some clients than others, in a way that correlates with where they are rather than with what device they use. If your local clients never complain and your overseas ones always do, look here.

Sometimes the photos are fine and the page around them is the problem. This is most common on galleries built into a photographer's own website, where the gallery inherits the whole theme.

• Autoplay video headers. A cover video starts downloading before the client sees a single photo, and competes with the photos for bandwidth.
• Large custom font files. Several weights of a display face, loaded before text renders, delay the whole page for the sake of typography nobody is there to admire.
• Tracking and marketing scripts. Analytics, chat widgets, pixels, cookie banners, popup builders. Each is a separate download that runs code before the page settles.
• Bloated themes and page builders. A theme designed to do everything ships the code for everything, on every page.

The tell for this cause is a long blank or half-drawn period before any photo starts loading. If the first thumbnail appears quickly and the rest trickle in, this is not your problem.

Photographers forget this one constantly, because they test on a good laptop, on their own studio connection, with the images already cached from the upload.

Your client might be on a phone on mobile data with one bar. They might be on a corporate network that inspects every file passing through it, which adds delay to large downloads and sometimes blocks them. They might be on a hotel or airport connection shared with two hundred people. They might be on a six-year-old laptop where the browser struggles to decode many images at once, whatever the network is doing. The parents of the bride are frequently the slowest connection in the group, and they are the ones who tell everybody.

You cannot fix your client's network. You can stop sending files heavy enough for it to matter, which brings you back to cause one.

Do these in order and stop when you find the answer. The point is to isolate one variable at a time instead of guessing.

1. Reproduce it on a phone on mobile data. Turn WiFi off on your phone and open the gallery link. This alone reproduces most complaints. If it is fast here, the problem is on the client's side, not yours.
2. Save one thumbnail and check its size. Right-click, save, look at the file size and dimensions. Camera-sized thumbnails end the investigation.
3. Compare one image against the whole grid. Open a single photo full screen from a direct link. If one photo is quick but the grid crawls, you have a quantity or lazy-loading problem. If one photo is also slow, you have a file-size or distance problem.
4. Watch what appears first. A long blank page before any photo points at page furniture. Photos appearing quickly and then filling in slowly points at image weight.
5. Try a different network. Home WiFi, then mobile data, then a different building if you can. Consistent slowness everywhere is the gallery. Slowness on one network only is that network.
6. Ask one other person somewhere else to open it. Ideally far away. This separates distance from everything else, and takes one message to arrange.

Six steps, one variable each. By the end you will know whether to change your export settings, cull harder, fix your website theme, or move platform.

Stated plainly and without a benchmark. When you upload photos, they are compressed in your own browser into proof JPEGs sized for viewing before anything is sent. The gallery grid is therefore not serving camera originals, which is the cause described at the top of this page. Your originals stay on your drives, where they belong.

Fair use matters here for a reason that is about speed, not billing. A gallery holds up to 1,000 photos. If you go over, you are told to split the shoot into another gallery, and galleries are unlimited, so splitting costs you nothing. A very large single gallery is itself a cause of slowness, so the ceiling and the advice point the same way.

Full-resolution files are a separate handoff rather than something the grid loads. You upload a full-resolution ZIP per gallery when the client is ready for finals. The gallery page stays a viewing page.

We host JPEGs. We do not warehouse RAW files or master video, which is part of why the price is flat and why the gallery is not being asked to display things it should never display.

We publish no speed benchmark, and you should not trust one from any vendor, including us. A number measured on someone's office connection with a ten-photo test gallery tells you nothing about your wedding gallery on your client's phone. Load your own photos, in your own quantity, and open the link on the kind of connection your clients actually use. That test takes ten minutes and it is worth more than every marketing claim on the subject, ours included.

Be honest with yourself about the diagnosis, because some of these causes travel with you.

• The gallery is a page on your own website. If a bloated theme, an autoplay video header and a stack of tracking scripts are the cause, that is your site, not your gallery tool. Fix the theme. A new gallery platform embedded in the same page inherits the same problem.
• Your hosting is the constraint. A cheap shared host in one location will be slow for distant visitors no matter what software sits on top of it.
• You send two thousand photos per job. Every platform will be slower with two thousand images on one page than with three hundred. Cull, or split into several galleries, and do it before you judge any platform.
• One client on a bad connection. If everyone else is fine, you are about to migrate your whole business to solve one hotel WiFi connection.

Moving is the right answer when the platform is genuinely handing full-size files to a thumbnail grid, or serving everything from one distant place, and you cannot change either. Everything else on this list is yours to fix where you are.