When a site is slow, the conversation usually turns to hosting, caching plugins and frameworks. Those matter at the margins. But the majority of slow business websites we are asked to fix are slow for a much simpler reason: somebody uploaded a folder of photographs straight out of a camera, and nobody ever set a limit.
The arithmetic is unforgiving
A single modern camera file can be several megabytes. Put six of them on a homepage and the page weighs more than a short video, before a line of CSS has loaded. On a fast office connection this is invisible. On a phone on mobile data, which is how most South African visitors will see it, it is the difference between a page that appears and a page that is abandoned.
No amount of caching fixes this, because caching makes the second visit faster. The visit that matters is the first one.
Set a page weight budget before design starts
The most useful thing you can do for a website is decide, before anything is designed, how heavy a page is allowed to be. Once that number exists, every subsequent decision has something to be measured against. A full width background photograph on the homepage is a legitimate choice. It is just a choice that has to be paid for from a fixed budget, which means something else gets smaller.
Designers work better with a constraint than with an instruction to be efficient.
Serve the size that is actually displayed
A photograph shown in a card three hundred pixels wide does not need to be delivered at full sensor resolution. Modern platforms will generate the right sizes and hand the browser a choice, but only if the system is set up to do it and the templates declare how large the image will actually appear. That last part is where most implementations quietly fail, and the browser conservatively downloads the largest option.
Choose which image is important
One image on any page is worth loading immediately: the one visible before the visitor scrolls. Everything else can wait until it is needed. Marking that distinction correctly is a two line change and it moves the perceived load time more than most infrastructure work.
Fonts count too
Every custom typeface is a file that has to arrive before text can render in its final form. Two well chosen families, self hosted and subset to the characters you actually use, will cost a fraction of four families pulled from a third party service. This site runs on two.
The short version
Speed is not a technical afterthought applied at the end of a build. It is the sum of content decisions made throughout it: how many photographs, how large, how many typefaces, how much script. Make those decisions deliberately and the site is fast without heroics. Make them by default and no amount of optimisation afterwards will fully recover it.
