The Performance Decisions Designers Actually Make
The Lighthouse report comes back and the score is 43. Everyone is looking at the developer. Nobody is looking at the carousel.
There is a pattern I keep seeing on design teams. Performance gets treated as an implementation problem, something the developers handle after design is signed off. Then the product hits staging and the animations are janky, the hero image takes three seconds to appear, and the carousel that looked great in the prototype is triggering layout shifts on every scroll. By that point, the design decisions are locked in. The conversation about tradeoffs happens too late to be useful.
This happens because most designers do not have a clear model of how their Figma decisions translate to browser cost. Not because they do not care about performance. Most do. Because nobody ever showed them the connection.
What the browser is actually doing with your design
When a user loads your product, the browser is doing a lot before anything appears on screen. It is downloading HTML, parsing it, building a document tree, downloading CSS, calculating which styles apply to which elements, and only then figuring out where everything goes on the page and painting it. Any resource that blocks that sequence delays the point at which the user can see anything meaningful. A large image in the hero, a full-width video background, a heavy web font: all of them stall that process.
The metric that matters most for that first impression is Largest Contentful Paint. It measures when the biggest visible element on screen has loaded. That is typically your hero image, a large heading, or a feature illustration. A good LCP is under 2.5 seconds. Most design decisions that hurt performance hit this number first.
Designers do not need to know how to fix LCP. But they do need to know which design patterns make it worse.
The patterns that cost the most
Image carousels are the clearest example. A five-slide carousel with a full-width hero image on each slide means the browser is loading five large images at page start, even though the user sees one. The performance cost is not the carousel interaction. It is the asset weight of all those images being fetched upfront. Lazy loading helps, but it rarely gets implemented correctly when the design has already been approved and built.
Parallax scrolling is similar. The effect requires constant layout recalculation as the user scrolls, which is expensive on mobile devices with slower processors. It looks smooth on a MacBook Pro with a dedicated GPU. On a mid-range Android phone, it drops frames.
Animation is the subtler one. CSS animations on properties like transform and opacity are GPU-accelerated and cheap. Animations that change width, height, top, left, or box-shadow trigger what the browser calls a layout reflow. It has to recalculate the position of potentially every element on the page. When those animations run continuously, or trigger on scroll, they can make a product feel broken even when the code is technically correct. This is worth understanding before specifying complex reveal animations or hover states across dozens of elements.
Heavy illustration and full-resolution photography carry the same problem as carousels: asset weight. A beautifully detailed SVG illustration with hundreds of paths can be more expensive to render than a rasterized PNG at the same visual quality. A hero photograph saved at print resolution but displayed at a smaller size is still downloading at print resolution. The browser scales it down after loading the whole thing.
The decisions that are actually yours to make
Here is where this gets practical. Designers have more control over performance than they usually take credit for.
Choosing a single strong hero image instead of a carousel is not just an editorial decision. It is a performance decision that might improve your LCP by two seconds. Choosing a system font stack over a custom web font eliminates a render-blocking download entirely. Choosing to specify animations on transform properties instead of layout properties gives the browser something cheap to compute. Choosing to build an illustration in fewer paths, or to export it at the right dimensions rather than relying on CSS scaling, reduces the rendering work on the user's device.
None of these require you to write any code. They require knowing the tradeoff exists.
The practical starting point is Lighthouse. Run it on any product you are working on, or on a competitor's, and look at the Opportunities section. Most of the issues it surfaces trace back to design decisions: oversized images, render-blocking fonts, excessive main-thread work from JavaScript triggered by interaction patterns that were designed and signed off without any performance conversation. The report tells you the cost in real load time. That number is useful in design reviews.
Web Vitals is worth bookmarking too. It is a more user-focused framing of the same metrics. LCP for loading, Interaction to Next Paint for responsiveness, Cumulative Layout Shift for visual stability. That last one is almost always a design problem. Elements jumping around as the page loads is what happens when images and fonts do not have reserved space in the layout, which gets decided at the design stage.
Having the conversation before it is too late
The staging retrospective is the wrong time to talk about this. By then the design is done, the build is done, and any significant change costs weeks of rework. The right time is during design review, or earlier when patterns are being chosen.
The most useful question designers can ask developers during design review is not "can we build this?" It is "what will this cost on a slow connection?" That question changes the conversation. It shifts performance from an implementation concern to a shared product concern, which is what it actually is.
Most developers will tell you the answer honestly if you ask. They will not volunteer it unprompted, because they assume the design is already approved and raising it will seem obstructive. That is a dynamic designers can break by asking first.
I have found that when designers ask about performance cost during review, something shifts. Developers start flagging things earlier. The conversation stops happening after the fact and starts happening when the decisions are still open. That is the only point at which it is useful.
Performance problems in shipped products rarely come from bad code. They usually come from design decisions that nobody evaluated for browser cost before the design was locked in. The Figma file does not show you load times. Staging does. The earlier you understand that gap, the less often you end up staring at a Lighthouse score of 43 wondering where it went wrong.
