Cheap for one visitor, expensive for a thousand

Cost does not scale the way intuition suggests, and the surprise usually arrives at the worst moment.

Test a page alone and it feels instant. The machine had nothing else to do, every resource was available the moment it was asked for, and there was no queue. Now imagine a thousand people asking within the same second. Each is asking for the same modest amount of work, but they are now competing for the same limited things: the capacity to run the work, the connections to stored information, the memory to hold it all. Modest work multiplied enough becomes a wall, and it does not degrade gently. Response times creep, then jump.

The usual culprit is not one slow step but a small inefficiency repeated. A page that fetches stored information once is fine. A page that fetches it once for every item in a list of fifty is fine when tested with three items and disastrous with five hundred visitors and fifty items each. Nothing is broken. The arithmetic simply changed. This is why load is a design consideration and not a problem to be solved later with a bigger machine.

The practical response is to know your busy path. Every site has a handful of pages that carry the bulk of the traffic, and they are rarely the ones that took the longest to build. Make those cheap, use saved copies where staleness is tolerable, and accept that a rarely visited administrative screen may be allowed to take its time. Effort spent on the busy path is worth several times the same effort spent anywhere else.