- Those who don't care about performance, as long as it loads within a few seconds on their own beefed up system on the LAN. This article is for them, and we can only hope they will listen.
- Those who care about performance, and work for people who care. They are already doing great work (or are about to), producing those rare low-friction, high-speed, content-is-king sites which we all love.
- Those who care about performance, but work for people who don't. Since the developer doesn't get to decide what to work on, they can either get cracking on feature #357, work on performance on the sly at the risk of losing their job, or quit. Not much of a choice, really, unless you have some other-worldly lax schedule and minimal oversight. And don't forget, if you are allowed to work on performance the burden is on you to prove how much faster things are with your changes (which can be really hard to show conclusively) and that your N days is worth more than Bob working N days on that sexy ticket #357.
Substitute "security", "UX", or anything else you want for "performance", it works the same way.