An estate agent's homepage opened with a full-screen slideshow of eight property photos. Each one was a camera original of about 12 MB, resized only by the browser.
The page weighed close to a hundred megabytes. On an office connection it loaded after a pause. On a phone it never finished. The agent kept hearing that the site was slow and kept upgrading hosting without effect.
After the photos were resized and compressed to under 300 KB each, the page was about two megabytes. He cancelled the upgrade. The business is invented, but the mistake is one of the most common on the web, and the usual response to it, paying for a bigger server, is the least useful one.
The homepage
The agency had four staff and perhaps forty properties on its books at any time, each of which was photographed by a freelancer on a decent camera. The photographer delivered the pictures as a folder of full-size JPEGs, because that is what a photographer should do. Somebody in the office uploaded eight of the best to the media library of the content management system and placed them in a slideshow block at the top of the homepage.
On the office computers it looked superb. The pictures filled the screen and faded into each other every five seconds. The agent was proud of it, and told prospective vendors that the site was how people first met the agency.
The trouble was that the browser was doing all the work of making those pictures fit. A camera original is typically around 6000 pixels wide. A laptop screen is 1400 to 2000. The CSS told the browser to display each image at the width of the window, and the browser obliged by downloading the full file and then shrinking it for display. All of the extra pixels travelled across the network and were thrown away on arrival.
Where the complaints came from
People started saying the website was slow, but never in a helpful way. A vendor said it "hung" on her phone. A colleague working from home said it took ages. A buyer mentioned that he had given up on it and gone to a portal. Nobody could say when it had started, because the pictures had accumulated gradually: first three, then five, then eight.
The agent did what most people do. He rang the host. Support looked at the account, saw nothing unusual, and offered a plan with more CPU and memory for a higher monthly fee. He took it. Nothing changed. Three months later, after a second round of complaints, he took the next plan up. Still nothing changed, and by then he was paying nearly three times the original price.
Why a faster server did nothing
A web server's job in this case is to hand over eight files. That takes almost no effort, and even the cheapest plan does it in milliseconds. The delay was in the stretch between the server and the visitor, and that stretch is set by the visitor's connection, not the host's hardware.
The arithmetic is short. Eight photos at 12 MB come to about 96 MB, which is about 770 megabits. Divide by the speed of the connection:
| Connection (example speed) | Before: about 96 MB | After: about 2 MB |
|---|---|---|
| Fast office line, 100 Mbit/s | about 8 seconds | under a quarter of a second |
| Typical home Wi-Fi, 20 Mbit/s | about 38 seconds | under a second |
| Mobile in a weak area, 2 Mbit/s | over 6 minutes | about 8 seconds |
These are best cases, ignoring connection setup, congestion and phones that give up when a tab sits in the background. In practice a page this size on a mobile connection stalls. That is what "never finished" meant.
How it was diagnosed
The breakthrough came from the freelance photographer, who happened to open the site on his phone and said, flatly, that the page was a hundred megabytes. He opened the browser's developer tools on a laptop to show the agent. In Chrome or Firefox: press F12, choose the Network tab, tick "Disable cache", reload, and read the line at the bottom of the panel that says how much was transferred.
It said 94.6 MB. Sorting by size put eight JPEGs at the top, all between 11 and 13 MB. The agent stared at the figure for a while, then asked why nobody at the host had said anything. The plain answer is that the host was not asked the right question. "Why is my site slow?" gets a server answer. "How big is my page?" gets a different one.
The same check works without a browser:
curl -sI https://example.com/wp-content/uploads/2025/03/house-01.jpg | grep -i content-length
content-length: 12582912A content-length of 12582912 is 12 MB. Multiply by the number of images and you have the problem. The page weight tool will do the same sum for a page you paste in.
The fix
None of it required new software. The freelancer re-exported the eight images at 1920 pixels wide, JPEG quality around 78, with the camera metadata stripped. Each came out between 180 and 290 KB. On a full-screen slideshow on a normal monitor they look the same as the originals. On a phone they look better, because the phone is not struggling.
magick house-01.jpg -resize 1920x -quality 78 -strip house-01-1920.jpg
ls -lh house-01-1920.jpg
-rw-r--r-- 1 user user 246K house-01-1920.jpgThen he did three smaller things that made the page behave properly on a phone as well.
- Offered a smaller version of each image for small screens, using
srcset, so that a phone fetches about 800 pixels, not 1920. - Loaded only the first slide at once and deferred the rest with
loading="lazy", so a visitor who leaves after the first picture never downloads the others. - Gave each image explicit width and height, so that the page does not jump about while loading.
<img src="house-01-1920.jpg"
srcset="house-01-800.jpg 800w, house-01-1920.jpg 1920w"
sizes="100vw" width="1920" height="1080"
alt="Front of a three-bedroom terraced house" loading="lazy">The aftermath
The homepage dropped from about 95 MB to about 2 MB. On a phone it painted in under two seconds. The agent cancelled the expensive plan at the next billing date and went back to the original, which is where the site has stayed. He also wrote a one-page note for the office, kept next to the shared drive: resize before uploading, aim for 300 KB or less, never upload from the camera folder.
The enquiries from the website, which he had not tracked before, were counted after the change. He would not put a figure on the improvement, and it would be wrong to guess, but he did notice that calls beginning with "I was looking at your site on my phone" became more common.
A habit like that needs a backstop, because offices change staff. A cheap one is to cap the upload size in the content management system, so that a 12 MB file is refused with a message rather than accepted. Another is an image optimisation plugin that resizes and recompresses on upload. Neither replaces looking at the page, but both stop the same mistake being repeated by the next person with a memory card.
Commands worth running
Open your busiest page with developer tools on, in the Network tab, with the cache disabled. Look at the transferred total, and sort by size. Anything over about 500 KB for a single image deserves a second look; anything over 2 MB is almost certainly a camera original. Many content management systems also resize on upload, but only if the original is not placed at full size, so check what is actually being sent.
find wp-content/uploads -type f -size +1M -print | head -20The troubleshooting guide has a short routine for slow pages, and the uptime maths tool is useful if you are weighing a plan upgrade by its promised availability.
Things people ask
How big should a hero image be?
Wide enough for the largest screen you care about, usually 1600 to 2400 pixels, and as small in bytes as you can get away with. Under 300 KB is a fair target.
Are newer formats worth using?
WebP and AVIF are well supported now and are often a good deal smaller than JPEG at the same appearance. A plain compressed JPEG is still a big improvement on an original.
Will my host's caching or a CDN solve this?
A CDN helps with distance, not size. Some can resize images on the fly, but the cleaner fix is a properly sized file in the first place.
Looking back
Before paying for a faster server, find out how much the page weighs. If the answer is tens of megabytes, no hosting plan will fix it, and the repair costs an afternoon with an image tool. Resize before upload, check the transferred total after every redesign, and treat any single image above a megabyte as a bug.