A gallery reader is mostly engineering. The reading experience is decided by how images are sized, loaded, and sequenced, and those decisions are invisible when done well and infuriating when done badly.
Preloading is the whole game
Reading feels continuous when the next image is already there. It feels broken when every page turn is followed by a blank rectangle and a spinner.
The fix is to load ahead — typically two or three images beyond the current one, adjusted for connection speed. That's enough to stay ahead of a reader without wasting data on a gallery they'll abandon after five pages.
Preloading in both directions matters too. People go back, and a reader that only loads forward makes a return trip as slow as the first pass.
How far to load ahead is a judgement rather than a constant. Too little and the reader stalls on a fast connection; too much and a phone on mobile data downloads a whole gallery to show five pages. Adjusting the window to measured speed is the standard answer and it is not complicated.
Image sizing and the data problem
Serving one large file per page is the common shortcut and the main cause of slow galleries. A phone doesn't need a 3000-pixel-wide image; it needs one sized for its screen, with the large version available if someone zooms.
| Approach | Result |
|---|---|
| One large file per page | Slow, expensive on mobile data |
| Screen-sized with zoom fallback | Fast, quality preserved when needed |
| Aggressive compression only | Fast but line art degrades badly |
| Modern formats with fallback | Best balance in practice |
Line art suffers more from aggressive compression than photographs do, for the same reasons streamed animation shows edge artefacts — covered in our piece on how animation compresses. Sizing beats compressing here.
Page-based versus continuous
Two reading modes, suiting different material. Page-based advances one image at a time and suits work laid out as discrete pages. Continuous scroll flows without breaks and suits work built as a column.
Forcing one mode on both kinds of material is a common mistake. Vertical-scroll work read page-by-page loses its pacing entirely, since the gaps between panels are the timing device — the point in our piece on the vertical format.
Good readers detect the material's shape or let the reader choose, and remember the choice.
Double-page spreads complicate this further. Work drawn for print sometimes needs two images shown side by side to read correctly, and a reader that splits them destroys the composition. Detecting wide images and pairing them is a small feature that a certain kind of material depends on completely.
The features readers actually miss
Ask people what they want from a gallery reader and the answers are consistent and modest.
- Position memory. Return to where you stopped, every time.
- A page counter. Knowing how much is left changes how you read.
- Fit modes. Fit width, fit height, and original size, remembered.
- Fast jump. A way to get to page forty without forty taps.
Position memory tops the list every time and is missing surprisingly often. It costs almost nothing to implement and it's the difference between a reader people return to and one they tolerate.
What the reader can't fix
Interface quality doesn't change what's in a gallery. Metadata still has to be present, artists still have to be credited, and the floor still applies: characters are fictional and unmistakably adult, with no ambiguity about age, no real-person sexual depiction, and no coercion presented as romance.
A polished reader on top of a scraped catalogue is still a scraped catalogue — the distinction drawn in our piece on aggregators and archives. Our standards are in the control room, and connected creation stays on models.
What makes a long gallery comfortable
Load ahead, size images for the screen, offer both reading modes, and remember where someone stopped. Four things, all unglamorous, all decided in engineering rather than design.
Readers rarely praise a good one — they simply keep using it. The bad ones get described as slow, and slow is almost always a preloading and sizing problem rather than a bandwidth one.