Anybody publishing images or video on their own site eventually meets the same surprise. Keeping files somewhere costs almost nothing. Sending them to people costs real money, and the amount scales with success, so the bill arrives at precisely the moment a project is doing well and nobody has planned for it.
Understanding roughly where the money goes makes this manageable rather than alarming. Most of the fixes are technical, cheap, and available before there is any problem to solve, which is the sensible time to apply them.
Storage versus transfer
Storing a large archive is inexpensive on any modern service, and the price has fallen steadily for years. Transfer, meaning the data actually sent to readers, is priced separately and does not fall the same way. A gallery that nobody visits costs a few coins a month; the same gallery in front of a large audience costs a great deal more.
The practical consequence is that archive size is rarely the problem. Popularity is. A single image shared widely can move more data in a day than an entire back catalogue does in a normal month, which is why costs are spiky rather than smooth.
Video is a different order of magnitude
A still image is measured in hundreds of kilobytes and a minute of video in tens of megabytes, so hosting video yourself is roughly a hundred times more expensive per view. This is the practical reason so much video sits on platforms that absorb the cost in exchange for control, despite the drawbacks described in the piece on video platforms.
Where video must be self-hosted, encoding decisions matter enormously, since bitrate is a direct multiplier on the bill. The settings discussion in the piece on compression is therefore a cost conversation as much as a quality one.
Caching does most of the work
A content delivery network keeps copies of files near readers and serves them without touching your server. That reduces both cost and load, and it is the single most effective measure available. Many providers include a generous allowance, and for a small publisher that allowance frequently covers everything.
Correct cache headers are the free half of this. Files that do not change should be marked as cacheable for a long time, so a returning reader downloads nothing. A surprising number of small sites send every image again on every visit purely because nobody set a header.
Sizing images properly
Serving a four-thousand-pixel image into a space six hundred pixels wide wastes the difference on every single view. Generating a few sizes and letting the browser choose reduces transfer dramatically and improves loading for readers on slow connections, which is the reading-situation argument in the piece on one-thumb readers.
Modern image formats compound the saving substantially over older ones at the same visual quality. Keeping high-resolution masters privately and publishing appropriately sized versions is the practice recommended in the piece on archiving, and it happens to solve the cost problem as well.
Hotlinking and scrapers
Other sites embedding your images directly makes you pay for their traffic. Automated scrapers do the same at scale, and between them they can account for a large fraction of a bill without producing a single reader. Basic referrer rules and rate limiting remove most of this in an afternoon.
It is also a reason to watch traffic sources rather than only totals. A month where transfer doubled and visits did not is a sign that something is copying rather than that anything is going well, and it connects directly to the automated mirroring economy that scrapes new work as soon as it appears.
Planning for the day something works
Set spending limits and alerts before you need them, put a delivery network in front of everything, size images properly, set cache headers, and block hotlinking. All of it takes an afternoon and none of it needs revisiting, which makes it some of the best-value work available to a small publisher.
Our own approach to publishing and data is described in the data page.