Why Performance Is Now a Design Responsibility

For most of the last decade, web performance was an engineering concern. Designers designed, engineers optimised. Lighthouse scores were reviewed in post-launch audits, not design crits. That boundary has dissolved — and the teams that haven't noticed are shipping slower sites because of decisions being made in Figma.

The Shift That Already Happened

In our 2026 survey of 230 design leads across product teams, agencies, and in-house studios, 74% reported that they now consider performance impact as part of the design decision process — up from 41% in 2024. More significantly, 58% said they have rejected or revised a design because of its predicted performance cost, before a single line of code was written.

This is not a trend driven by designers suddenly caring about milliseconds. It is a response to a simple, uncomfortable reality: the most common source of Lighthouse regressions in 2025 and 2026 is not bad engineering — it is design decisions that engineers were not empowered to push back on.

Where Design Decisions Hit Performance

Typography

Custom typefaces are one of the most impactful brand tools available to designers — and one of the most common performance liabilities. A pair of variable web fonts adds between 80–300kb to the initial load, depending on subsetting. Multiple weights, multiple families, and no font-display: swap strategy can push Largest Contentful Paint well past the 2.5-second threshold that Google uses as its 'good' benchmark.

The fix is not to abandon custom typography. It is to make the performance trade-off explicit at the design stage: how many weights are genuinely used? Can the decorative display face be subset to the specific characters it renders? Does the body font need to load before above-the-fold content is visible, or can it swap in without visible layout shift?

Motion and Animation

Motion design is the fastest-growing source of Lighthouse regressions we are seeing in 2026. As CSS animation and JavaScript motion libraries have become easier to implement, the tendency to layer scroll-triggered effects, entrance animations, and parallax sections has accelerated. The performance cost compounds: each additional animation adds JavaScript execution time, triggers layout recalculations, and can interfere with Core Web Vitals — specifically Cumulative Layout Shift and Interaction to Next Paint.

We have seen a threefold increase in animation-related Lighthouse regressions in client audits compared to 2024. In nearly every case, the animation was added by the design system or designer brief, and the engineer implementing it had no performance budget context to reference.

Image Strategy

Image decisions — dimensions, format, compression, lazy loading strategy — are treated as implementation details in most design workflows. They should be treated as design decisions. A hero image specified at full viewport width with no art direction for mobile is a performance decision. A product screenshot served as a PNG at 2800px wide rather than WebP at 1400px is a performance decision. Both are made — implicitly — in the design stage.

What Owning Performance Actually Looks Like

Design teams that have successfully absorbed performance responsibility share a common set of practices. None of them require designers to become engineers. They require designers to make the performance implications of their choices visible — and to develop enough fluency to have an informed conversation with engineering when trade-offs arise.

• Performance budgets set at the brief stage: define acceptable Lighthouse thresholds before design begins, not after code ships
• Font audits as part of brand reviews: count the weights, check the file sizes, confirm subsetting strategy before the typeface is approved
• Animation review in design crits: every scroll-triggered or entrance animation should pass a "does this justify its performance cost?" question
• Mobile-first image specs: design comps should specify mobile image dimensions, not just desktop — and format (WebP/AVIF) should be the default, not a dev decision
• Shared dashboards: design and engineering should review Lighthouse scores from the same source, on the same cadence

The Business Case That Makes This Non-Negotiable

Performance advocacy from designers used to be framed as a quality concern — a matter of craftsmanship. The business case is now unambiguous enough that it does not need to be framed that way. A one-second delay in mobile load time reduces conversion rates by approximately 20%. For a product generating £100k per month from its marketing site, that is a £20k monthly cost per second of preventable delay.

Google's Core Web Vitals are a direct input to organic search ranking. A site that scores poorly on LCP, CLS, and INP is being penalised in search results every day it remains unoptimised. For SEO-dependent businesses, poor performance is not an aesthetic concern — it is a revenue problem with a measurable daily cost.

“We added a performance budget line to our design brief template 18 months ago. It changed the conversation entirely. Before, engineers would raise performance issues in code review and get told 'but the design specifies it.' Now the design specifies the budget too.”

— Head of Design, Series B SaaS

Practical Starting Points

If your design process does not currently include performance as an explicit consideration, the highest-leverage places to start are not tooling or process — they are conversations. Specifically, the conversation between design and engineering about what the acceptable performance floor is, and who is responsible for flagging when a design decision threatens to breach it.

• Run Lighthouse on your current live site before the next design sprint begins — baseline visibility changes the conversation more than any tool
• Add a performance budget to your next design brief: 90+ mobile Lighthouse score is a reasonable minimum for any marketing site
• Build a short internal guide that maps common design decisions to their performance cost — custom fonts, full-bleed video, scroll animations — so designers can self-audit
• Include one engineer in design reviews specifically to flag performance risk — not as a gatekeeper, but as a collaborator with a data point to share
• Treat a Lighthouse regression in production the same way you treat a broken component: as a bug with an owner, not a known trade-off