Photography Hosting: What Image-Heavy Sites Actually Need

A photography website is not a website with pictures on it. It is an image-delivery system with some HTML wrapped around it, and almost every decision that matters is about how those images get from storage to a visitor’s screen.

Search for photography hosting and you get portfolio builders selling templates and galleries. Templates are the easy part. The hard part is that a single unoptimised photograph can weigh more than an entire well-built website, and a gallery of forty of them is a page that takes ten seconds to load on the phone your prospective client is holding. Here is what to actually evaluate.

The arithmetic that governs everything
The three transformations that do all the work
Where the bandwidth bill comes from
Static is almost always the right shape
A checklist before you commit
How this fits the rest of the stack
FAQ

The arithmetic that governs everything

Start with real numbers, because they make every subsequent decision obvious. A JPEG straight out of a modern camera at full resolution is commonly 5 to 15 megabytes. A gallery page with twenty of them, served as-is, is somewhere between 100MB and 300MB.

On a good mobile connection that page takes tens of seconds. On a bad one it never finishes, because the visitor left. And you paid for every byte that was transferred before they did.

The same twenty images, resized to sensible display widths and encoded as AVIF or WebP, land somewhere around 2 to 5 megabytes for the whole page. That is not a marginal improvement. It is two orders of magnitude, and it is the difference between a portfolio that feels professional and one that feels broken.

Everything else in this post is a way of achieving that reduction reliably, without you having to remember to do it manually for every upload.

The three transformations that do all the work

In order of impact, and none of them require a photographer to change how they shoot.

Resize to display size. A 6000px-wide original displayed in a 1200px container downloaded five times more data than the screen could use. Generate a handful of widths — something like 400, 800, 1200, 2000 — and serve them via srcset so the browser picks.
Encode as a modern format. AVIF is typically half the size of a comparable JPEG; WebP is somewhere in between. Serve those with a JPEG fallback through a <picture> element and browsers take the best one they support.
Lazy-load what is below the fold — and only what is below the fold. Add loading="lazy" to gallery images. Do not add it to the hero image, which is almost always the largest-contentful-paint element and which you want fetched immediately.

Do all three and a typical gallery page drops by 90% or more. Do only the third and you have delayed the problem rather than fixed it.

The other thing that costs nothing: put explicit width and height attributes on every image. Without them the browser does not know how much space to reserve, and the page shifts as each photograph arrives — which is both visually unpleasant and a measurable ranking signal.

Where the bandwidth bill comes from

Photography sites are the clearest case of hosting costs being driven by transfer rather than compute. The site itself is trivial to serve. The photographs are not.

The pattern that catches people out is a spike. A portfolio does modest traffic for months, then a shoot gets shared somewhere with an audience, and a month’s worth of transfer happens in six hours. If your host meters bandwidth, that is the month you find out at what rate.

Three questions worth answering before you need the answers:

How much bandwidth is included, and what is the per-gigabyte rate after that?
Is there a hard cap that takes the site offline, or overage billing that does not? Both exist, and they fail very differently.
Are images served from an edge cache, or from the origin every time? A cached image transferred once and served a thousand times is a fundamentally different cost than the same image fetched from origin a thousand times.

A generous included allowance is worth more than a slightly cheaper base plan, because the base plan is predictable and the transfer is not.

Static is almost always the right shape

A photography portfolio is content that changes when the photographer changes it, which is to say rarely and deliberately. There is nothing per-visitor about it. That makes it a static site in the precise technical sense, and static sites are the cheapest and fastest thing to serve.

The build step is where the image work happens. Point a static generator at your originals, let it produce the resized variants and modern-format encodes at build time, and deploy the output. Every visitor then gets pre-optimised files from a cache. Nothing is transformed per-request, so nothing costs compute.

The parts that genuinely need a server — a contact form, client galleries behind a password, print ordering — are small and can sit alongside as a service without turning the whole portfolio into a dynamic application.

The alternative shape, a database-backed site rendering gallery pages per request, is a lot of machinery for content that does not change. It costs more, it is slower, and it needs maintaining.

A checklist before you commit

Whatever you end up choosing, these are the things to verify rather than assume.

Custom domain and certificate, handled automatically. A portfolio on a subdomain of someone else’s brand is a portfolio you do not own.
Bandwidth allowance and the overage rate, in writing, before the first busy month.
Whether the build can generate image variants, or whether you will be resizing by hand forever.
Export. Can you get your originals and your site out? If a portfolio builder holds your full-resolution files, moving means re-uploading your entire archive.
Actual measured performance. Run a page-speed test against a real gallery page on a throttled mobile connection, not against the homepage.

The last one is the one people skip, and it is the only one that tells you the truth. A portfolio that scores well on the homepage and badly on the gallery is a portfolio that scores badly, because the gallery is what clients came to see.

How this fits the rest of the stack

For an image-heavy site the number that moves is bandwidth, not compute, and it moves suddenly rather than gradually. The RunxBuild hosting calculator lets you model the transfer alongside the build and any service you need for forms or client access, so the busy month is priced in advance. RunxBuild static sites build from a repository — which is where the resize-and-encode step belongs — and include 120GB of bandwidth before metering at $0.10/GB, with the custom domain and certificate handled as part of the deploy.

Useful related references:

FAQ

What is the best hosting for a photography website?

For a portfolio, static hosting with a build step that generates resized and modern-format image variants, plus a generous bandwidth allowance. The site itself is cheap to serve; the photographs are what costs money, so bandwidth terms matter more than the base plan price.

How do I make my photography website load faster?

Three things, in order of impact: resize images to the widths you actually display and serve them via srcset, encode as AVIF or WebP with a JPEG fallback, and lazy-load everything below the fold while explicitly not lazy-loading the hero image. Together these typically cut a gallery page by more than 90%.

How much bandwidth does a photography site use?

Far more than a text site, and unpredictably. A gallery of unoptimised full-resolution images can be 100MB or more per page view. Optimised properly the same gallery is a few megabytes. The optimisation is what makes the bandwidth question manageable rather than the hosting plan.

Should I use a portfolio builder or host it myself?

Builders remove all setup and give you templates, at the cost of your files living inside their system and your site living partly under their brand. Self-hosting a static build costs more setup and gives you a domain you own, originals you can move, and control over the image pipeline. If the archive matters long-term, own it.

Do I need a CDN for a photography website?

Effectively yes, and static hosting usually includes edge caching by default. Serving images from a cache near the visitor rather than from a single origin is the difference between a fast gallery worldwide and a fast gallery only near your server.