I think we often don't realize how much performance is part of the user requirements (i.e., "the thing it was meant to do") because users don't specify that as a requirement. And when they do we get all engineer-y about it and start asking about TTFBs, throughput rates, TPS's and nobody gets anything sensible out of the conversation. But users don't mention it because they don't know how slow complex systems could be or how complex a mere CMS could be that for them this is one of those
requirements that don't even need to be said.
Anecdata time...
There was once a scrappy start-up who, like all scrappy start-ups, was taking on the heavyweight incumbent gorilla of the industry. They started poaching the small customers from the gorilla, just enough for the gorilla to notice. These customers often cited how "fast and lightweight" the start-up's platform was compared to the gorilla.
The claim wasn't really supported by Grafana. The numbers weren't bad; in fact they were very average. For some metrics, the gorilla was actually still the gold standard the scrappy start-up targeted. The engineers suspected "fast and lightweight" had more to do with the user experience (they had smoothly-animated loading screens) than actual server performance. Still, it's not a complaint so they took that as a win.
After a couple of years of steady growth poaching from the gorilla, they started getting bug reports of slow performance. The customers have been seeing more and more of the smooth loading screen animations and less of the data they actually need to work on. And this time, the claims were supported by Grafana! There was no way to massage the statistics to even claim the reports are outliers or to pass the blame on to the unreliable ISPs.
The problem, it turns out, was that they were sending emails as notifications for a bunch of user actions and at that point there were about 2-3 such user actions per minute. While they could async some of those, there were a bunch whose succeeding states assumed that the notifications have been sent.
After three weeks of profiling and going through the whole performance optimization playbook, the fix boiled down to a one-liner in SQLAlchemy that offloaded loading notification mailing lists to Postgres cursors rather than loading whole lists into memory in one go.
Moral of the story: no one is asking you to build a racecar but that doesn't mean performance is not table stakes. A good senior engineer knows just where the balance is to still deliver business value. That is the salary you are paying for.