Design reviews scrutinize color, spacing, and type with real rigor and almost never ask the question that determines whether any of it will be experienced the way it was designed: how many kilobytes does this hero section cost, and how long until the page is actually interactive on a real connection, not the reviewer's office wifi.
The industry's attempt to make this measurable — Core Web Vitals, largest contentful paint, time to interactive — exists precisely because performance is a user experience property, not a separate engineering concern that gets addressed after design is 'done.' A beautiful layout that takes six seconds to become usable isn't a beautiful layout with a technical flaw. It's a slow site that also happens to look nice once it finally loads.
The failure mode is rarely one dramatic mistake. It's usually an accumulation of individually reasonable choices — a font loaded from three separate weights, a hero animation library pulled in for one effect, an image exported at twice the resolution it's displayed at — each fine in isolation, collectively the reason the page feels sluggish by the time it ships.
The fix that actually works is procedural, not just aspirational: set a real budget — total page weight, JavaScript execution time, largest contentful paint on a throttled connection — before design starts, and treat it the way a print designer treats a fixed page size. Not a target to hit if there's time left over. A constraint the design has to work within from the first draft.
Once performance is a constraint instead of a hope, it stops competing with design for priority, because it's no longer a separate axis being traded off against it. It's just one more thing the design has to be good within, the same as any other limit that's been there from the start.