There’s a persistent myth in web design: that performance is something developers handle after the design is done. The designer creates the vision, hands it off, and then engineers figure out how to make it load fast.

This division of labor produces mediocre results. By the time performance becomes a concern, key decisions have already been made—decisions that determine whether a fast, accessible site is even possible. The layout has been set. The imagery has been chosen. The animations have been specified. At that point, optimization is damage control.

Performance isn’t a technical afterthought. It’s a design decision, and the most impactful performance decisions are made in the design phase, not the development phase.

Why performance is a design problem

Consider what determines a website’s load time and runtime performance.

Images are typically the heaviest elements. The design decides how many images, at what sizes, in what formats, and whether they’re decorative or essential.

Layout complexity affects rendering speed. Nested elements, absolute positioning, complex grid structures—these are design choices that have performance implications.

Animations can block the main thread, cause repaints, and drain battery. The decision to animate, what to animate, and how to animate comes from design.

Typography affects both load time (font file sizes) and rendering (layout shifts as fonts load). The choice to use one typeface versus four, web fonts versus system fonts, variable fonts versus multiple weights—these are design decisions.

Third-party embeds—videos, maps, social feeds, chat widgets—come with significant performance costs. The decision to include them is often made in design, not development.

In other words, the major performance factors are determined before a developer writes a line of code. A design that specifies a video header, full-screen animations, four custom typefaces, high-resolution background images, and embedded social feeds has already chosen slow. No amount of optimization can fix decisions made at the design level.

The false choice

The assumption behind “we’ll optimize later” is that there’s a trade-off between beauty and speed. Make it beautiful first, then figure out how to make it fast.

But this is a false dichotomy. Constraints often produce better design, not worse. When you design with performance in mind from the start, you make different choices—and those choices often result in cleaner, more focused, more impactful work.

A single striking image beats a carousel. Clear typography beats decorative flourishes. Purposeful motion beats gratuitous animation. Fast interactions beat slow spectacles.

Performance constraints push designers toward essentialism. What really matters? What actually serves the user? What earns its weight? These are good questions to ask, regardless of performance.

Designing for core web vitals

Google’s core web vitals have made performance measurable and consequential. Three metrics—largest contentful paint, cumulative layout shift, and interaction to next paint—now affect search rankings and can be tracked precisely.

Rather than seeing these as technical hurdles, designers can treat them as creative constraints.

Largest contentful paint (LCP) Measures how quickly the main content appears. This pushes toward designs where the important content is actually the largest element, not hidden below decorative headers or delayed behind animations. It rewards designs that get to the point.

Cumulative layout shift (CLS) Measures visual stability—whether elements jump around as the page loads. This pushes toward reserved space for images and embeds, toward consistent typography that doesn’t shift when web fonts load, toward layouts that are stable from first paint. It rewards designs that respect the viewer’s attention.

Interaction to next paint (INP) Measures responsiveness—how quickly the page reacts to user input. This pushes toward simpler interactions, toward offloading heavy work, toward designs that don’t block the main thread with excessive animation or computation. It rewards designs that feel snappy.

Each of these metrics, taken as a design constraint rather than a technical requirement, points toward better user experience. They’re not arbitrary hurdles—they’re proxies for what users actually feel.

Practical design choices for performance

Here are concrete decisions designers can make to build performance into their work.

Lead with content, not decoration. If the most important thing on the page is the headline and first paragraph, make sure that’s what loads and renders first. Background images, sidebars, and decorative elements can load later.

Choose imagery intentionally. Every image adds weight. Ask whether each image genuinely adds value or just fills space. When images are necessary, specify appropriate sizes—don’t force developers to guess. Consider art direction: does this image need to be full-width on mobile, or can a cropped, smaller version work?

Limit animation scope. Motion can enhance experience, but broad animations that affect many elements create performance problems. Constrain motion to specific, purposeful moments. Use CSS transforms and opacity, which can be hardware-accelerated, rather than properties that trigger layout recalculations.

Consolidate typography. Each font file costs loading time. Each font variation increases that cost. A design that uses one typeface in two weights loads faster than one that uses three typefaces in multiple weights. Variable fonts can offer flexibility with a single file, but even they have weight.

Design system font fallbacks. Font loading causes layout shift unless fallbacks are carefully matched. Design with an understanding of what the page will look like before web fonts load, and make that state acceptable rather than broken.

Reserve space for dynamic content. Ads, images, embeds—anything that loads after initial render needs reserved space to avoid layout shifts. Build aspect ratios and placeholder dimensions into the design.

Question every third-party embed. Video players, maps, social widgets, chat tools—each comes with significant javascript and network overhead. Ask whether the functionality is worth the cost. Consider alternatives: static map images with links, facade patterns that load embeds on interaction, native video elements for simpler use cases.

The designer-developer conversation

None of this works if design happens in isolation. Performance-aware design requires ongoing conversation between designers and developers.

Designers should ask: what are the performance implications of this choice? Is there a lighter-weight way to achieve this effect? What constraints should I be working within?

Developers should share: here’s where we’re struggling with performance. Here’s what’s heavy. Here’s what could work differently.

The best outcomes happen when performance is a shared concern from the first conversation, not a problem to solve after the design is “done.”

Speed as a feature

Fast sites feel better. They feel more professional, more trustworthy, more competent. Users don’t consciously think “this site’s LCP is under 2.5 seconds”—they just feel that it works.

Slowness, conversely, creates friction, frustration, and abandonment. It signals that the site wasn’t built with care, that the organization behind it doesn’t respect the user’s time.

Performance is not just a technical metric. It’s part of the user experience, part of the brand impression, part of the emotional response to your work. It deserves design attention, not just engineering effort.

The sites that load instantly, respond immediately, and run smoothly didn’t get that way through post-hoc optimization. They got that way because performance was a design priority from the start—a constraint that shaped decisions rather than an afterthought that required fixing.