It's an incentives problem. We could solve it if we checked performance like we do unit tests, and held developers accountable to a literal performance budget

It's an incentives problem. We could solve it if we checked performance like we do unit tests, and held developers accountable to a literal performance budget set by the business. > Few teams I’ve encountered have actionable metrics associated with the real experiences of their users. Imagine getting latency numbers on load times, bundle sizes, TTI, and so forth on every commit. PRs that blow the performance budget would be immediately flagged. You could plan for performance like any other business cost. Even nontechnical business leaders can understand reports like "3s load time", and set tech team goals based on a relationship between load times and lost sales. "Load time must be under 2s, even on old Android + Edge" is something everyone can understand. The article is right: what's most pleasant for the developer isn't necessarily what's best for the business. If metrics like load times are only being seen by developers, the developers have a moral hazard: either they 1. make choices that benefit themselves, at a cost to the business 2. make their own lives voluntarily worse, without recognition The article is right again that sometimes, better DX is in fact worth worse performance for the user. As with anything, it depends on the business. But businesses won't accurately and fairly decide on their preferred tradeoff if only engineers are in charge of it. We need better performance infrastructure!