The 'we'll optimise later' trap
Performance is almost never addressed at the start of a project. It's usually addressed the week before launch, when someone runs a Lighthouse audit and sees a score in the 30s. By that point, the architectural decisions that caused the problem are already baked in — and fixing them means rework, not optimisation.
Speed is a design decision
Font choice affects performance. Image treatment affects performance. Animation approach affects performance. The number of typefaces, the size of hero images, the use of video backgrounds — these are design decisions with measurable performance consequences. Treating them as purely aesthetic isolates the designer from the outcomes their work creates.
Core Web Vitals as design constraints
LCP, CLS, INP — these aren't DevOps metrics, they're user experience metrics. LCP measures how quickly the user sees the main content. CLS measures how much things move around as the page loads. INP measures how responsive the page is to interaction. All of these are directly shaped by design decisions. The teams that hit the performance targets are the ones that included them in the design brief.
The practical shift
You don't need to make designers into engineers. You need to make performance visible in the design process. That means performance budgets set at the start of a project, Lighthouse scores checked in design review (not just dev review), and a shared understanding that 'it looks good' and 'it loads fast' are not separate conversations.