The photographer and the 4 MB hero image

A wedding photographer was disappointed that her new site loaded slowly. It looked wonderful on her office computer, and the pictures were exactly what she wanted potential couples to see. On her phone, away from home wifi, it sat on a blank page for what felt like ages and then trickled in from the top.

She did what most people would do and assumed the hosting was to blame. She upgraded the plan, then upgraded it again, and each time the support team told her the server was healthy. Nothing improved. When she finally ran a speed test, the waterfall chart showed a single image on the homepage weighing just over four megabytes, followed by fifteen more at two megabytes each.

What she saw and what she tried

The symptoms were mixed, which made it harder to pin down. On her desktop, with a fast fibre connection, the homepage appeared in a couple of seconds and she thought the complaints were exaggerated. On a mobile connection in a village with patchy signal, the page could take well over a minute. A couple who had enquired by email mentioned the site was "a bit heavy". Bounce rates in her analytics told the same story: a lot of visitors left before the first image appeared.

Her first step was to ask the host. The support agent checked the load on the server, saw that CPU and memory were hardly used, and confirmed that response times for the HTML were fast. That answer is correct and unhelpful at the same time, because the first byte arriving quickly says nothing about what happens afterwards.

So she moved up a plan. The cost went up, the page load did not change. She moved up again, this time to a virtual private server, on the theory that a dedicated slice of a machine would be quicker. It was not. The extra CPU had nothing to do, because the bottleneck was a long way from the server's processor.

The waterfall that explained it

The turning point was a free speed test that produced a waterfall: a chart with one horizontal bar per file the browser downloaded, in the order it asked for them. The HTML bar was short. The CSS and JavaScript bars were short. Then came a column of long bars, one for each photograph.

The top of the page held a hero image, the wide photograph behind the headline, at just over 4 MB. Below that were fifteen gallery thumbnails, each about 2 MB. Adding it up, the page weighed roughly 38 MB. Those thumbnails were not thumbnails in any real sense: they were the full camera files, shrunk on screen by the browser's layout engine to a card about 400 pixels wide.

That is what "the upload process does not complain" means. A photo from a modern camera might be 6000 pixels wide. A phone screen is perhaps 400 to 800 CSS pixels wide, and a large desktop monitor 1920. When a 6000-pixel file is displayed in a 400-pixel slot, the browser downloads every byte, decodes all of it, and throws away most of the detail. The visitor pays for pixels they can never see.

Why bigger hosting did nothing

Hosting capacity governs how quickly the server can produce a response. It does not change how much data has to cross the network afterwards. A page carrying 38 MB needs 38 MB to travel from the data centre to the visitor, and on a slow mobile link, say 5 megabits per second, that alone is about a minute even if every other part of the system is perfect. (38 MB is about 304 megabits, so around 60 seconds at that speed.)

The server was, if anything, extremely good at the job: it was sending those large files at full speed. Upgrading the plan was like buying a faster delivery van to move a load that was too heavy for the road it had to use.

It is worth understanding how the work divides:

• Server time, for generating the page and returning the first byte. Hers was already fast.
• Transfer time, which depends on total bytes and the visitor's connection. This was the problem.
• Browser time, for decoding images and laying out the page. Large images make this worse on older phones.

The page weight calculator on this site does the transfer arithmetic for various connection speeds, and the numbers tend to be sobering.

The fix, step by step

The repair was dull work but not hard, and she did most of it herself over a long afternoon with an image tool and a hosting support agent on chat.

1. Decide the largest size each image is ever shown. The hero spans the page width, so 1920 pixels wide is plenty for most screens. The gallery cards were around 400 pixels wide on desktop, so 800 pixels covers a high-density phone screen.
2. Export new copies at those sizes from her editing software, keeping the originals safely in her own archive. She did not overwrite anything she could not recover.
3. Convert to a modern format. Browsers have supported WebP for years, and AVIF is widely supported too. At comparable visible quality, these files are often a half or a third the size of the equivalent JPEG, though the saving varies by picture.
4. Add width and height attributes to each image, so the browser can reserve space and the page does not jump around while loading.
5. Turn on lazy loading for everything below the first screen, so the browser asks for gallery pictures only as the visitor scrolls towards them.

The hero image dropped from just over 4 MB to roughly 300 KB. The gallery pictures dropped from 2 MB to about 120 KB each. The page came out at under 3 MB, and on the same mobile connection it became usable in a few seconds. She then dropped back to the cheap plan she had started with, which she should never have left.

How the layers of an image add up

A quick table helps show where the savings come from. These are example numbers for a single wide-format photograph, not measurements of any particular camera or tool.

Most of the saving comes from resizing. The format change adds a useful second layer on top, but converting a 6000-pixel image to WebP and leaving it enormous would have missed the point.

Gallery plugins and the next upload

Resizing by hand is fine once. It does not survive the next wedding. The longer-term answer was a gallery plugin that creates properly sized versions of every upload automatically. Content systems such as WordPress already generate several sizes of each image when it is added to the media library, but only if the theme or gallery asks for the right size. Many page builders and older themes insert the original file at full size, which defeats the whole mechanism.

When choosing a plugin or theme setting, look for these properties: it generates a few widths per image, it serves them using srcset so phones receive the smaller ones, it lazy loads below-the-fold pictures, and it does not rely on a script that loads everything first and shrinks it afterwards. A plugin that makes thumbnails by CSS alone is not making thumbnails.

The risk remains highest for photographers, designers and anyone who works with large originals, since their files are enormous and the upload form is perfectly happy to take them.

Look at your own configuration

Open your homepage in a browser, press F12, choose the Network tab, tick "Disable cache" and reload. Sort by size. If a single file is bigger than about 500 KB, ask why. Along the bottom, the browser reports the total transferred; for a typical small business homepage, a few megabytes at most is a reasonable target.

From a terminal, you can see the size of a particular image without downloading it all:

curl -sI https://www.example.com/images/hero.jpg | grep -i content-length

Then throttle the connection in the browser's developer tools to a slow mobile profile and watch what happens. If you want arithmetic rather than a stopwatch, the page weight calculator turns kilobytes into seconds.