Performance for Designers
Performance isn't just an engineering concern. Design decisions directly impact how fast pages load and feel. This guide helps designers understand and improve performance.
Last updated: July 2025
Why performance matters for UX
Slow experiences frustrate users:
- 53% of mobile users abandon sites that take over 3 seconds to load
- Every 100ms of latency can reduce conversion by 7%
- Slow sites feel less trustworthy and professional
Performance is especially critical for users on slower connections or older devices—often the users who most need your service.
For detailed guidance on measuring and improving web performance, see web.dev's performance documentation.
Core Web Vitals explained
Google's Core Web Vitals measure real-world user experience:
Largest Contentful Paint (LCP)
What it measures: How long until the largest visible content loads (usually hero image or main heading).
Target: Under 2.5 seconds.
Designer impact: Hero image size, font loading strategy, above-the-fold content complexity.
First Input Delay (FID) / Interaction to Next Paint (INP)
What it measures: How long until the page responds to user interaction.
Target: Under 100ms (FID) / under 200ms (INP).
Designer impact: Animation complexity, number of interactive elements loading initially, JavaScript-dependent interactions.
Cumulative Layout Shift (CLS)
What it measures: How much content moves around as the page loads.
Target: Under 0.1.
Designer impact: Image dimensions, font loading, dynamic content, ads and embeds.
Every time content jumps while loading—an image appearing and pushing text down, a font switching after loading, a banner inserting itself—that's layout shift. It's disorienting and often causes misclicks.
Design decisions that affect performance
Images
Images are typically the heaviest elements on a page.
Size appropriately: A 4000px image displayed at 400px wastes bandwidth. Provide images at the sizes they'll actually be displayed.
Choose the right format:
- JPEG: photographs
- PNG: graphics with transparency
- SVG: icons, logos, simple graphics
- WebP/AVIF: modern formats with better compression
Consider necessity: Does this decorative image add enough value to justify its weight? Sometimes the answer is no.
Specify dimensions: Always include width and height attributes so browsers can reserve space before the image loads, preventing layout shift.
Fonts
Custom fonts look nice but come with costs.
Limit font weights/styles: Each weight and style is a separate file. Do you really need thin, regular, medium, semibold, bold, and black?
Consider system fonts: System font stacks (-apple-system, BlinkMacSystemFont, Segoe UI, Roboto...) load instantly and look good on each platform.
Use font-display: font-display: swap shows text immediately with a fallback font, then swaps when the custom font loads. Prevents invisible text.
Animation and motion
Smooth animation requires thoughtful implementation.
Animate transform and opacity: These properties can be GPU-accelerated. Animating width, height, margin, and padding forces layout recalculation—slower and janky.
Avoid animating many elements: Each animated element has a cost. Animating 100 particles may look cool but performs poorly on mobile.
Respect motion preferences: Some users have vestibular disorders or simply prefer reduced motion. Honor the prefers-reduced-motion media query.
Layout complexity
More elements mean more work for browsers.
Simplify where possible: Deep nesting, excessive elements, and complex CSS selectors all slow rendering.
Consider progressive disclosure: Show what's needed now; load more on interaction. A collapsed FAQ loads faster than all answers expanded.
Be thoughtful with shadows and effects: Complex shadows, multiple gradients, and heavy filters require processing. Use them intentionally.
Designing for perceived performance
Actual load time matters, but perceived speed matters too. Users experience time subjectively.
Show something fast
Even if the full page takes time, showing key content quickly improves perceived performance:
- Render above-the-fold content first
- Use skeleton screens to indicate content is coming
- Display important text before all images load
Provide feedback
When things take time, let users know:
- Loading indicators for operations over 1 second
- Progress bars for longer operations
- Subtle animation to show the system is working
Avoid jarring changes
Smooth transitions feel faster than abrupt ones:
- Fade in images rather than popping them in
- Animate content shifts when unavoidable
- Maintain visual stability as elements load
Working with developers on performance
During design
- Ask about performance constraints before designing
- Discuss image budgets (how many KB for key images?)
- Review font choices for loading implications
- Consider animation complexity trade-offs
During handoff
- Provide properly sized images (or specify which sizes to generate)
- Document which fonts/weights are essential vs. nice-to-have
- Note animation timing and easing (so developers can implement efficiently)
- Specify loading priorities (what must appear first?)
During review
- Test on real devices, not just fast development machines
- Check with throttled connections
- Verify lazy loading is working
- Look for layout shift issues
Performance checklist for designers
Images
- Images sized appropriately for their display size
- Modern formats (WebP/AVIF) where supported
- Width and height specified
- Decorative images justified or removed
Fonts
- Minimum necessary weights and styles
- System font alternatives considered
- Font loading strategy discussed with development
Animation
- Animations use transform/opacity where possible
- prefers-reduced-motion alternative provided
- Animation serves a purpose (not just decoration)
Layout
- Above-the-fold content loads quickly
- Layout doesn't shift as content loads
- Progressive disclosure for heavy content
- Skeleton states designed for loading
Content
- Essential content prioritized
- Third-party embeds evaluated for necessity
- Video/audio optimized and appropriate
Common performance pitfalls
Hero video backgrounds
Auto-playing hero videos are heavy and often don't add value proportional to their cost. Consider:
- Is this video essential to communication?
- Would a static image work almost as well?
- Can it load after core content?
Carousels with many items
Carousels that load 10 high-res images upfront waste bandwidth. Most users see only the first 1-2 slides. Lazy load subsequent slides.
Infinite scroll without limits
Loading content forever as users scroll can exhaust device memory. Implement windowing or pagination beyond a certain point.
Large hero images
A 3MB hero image dominates load time. Optimize aggressively—users often don't notice quality differences between 80% and 100% quality compression.
Use Chrome DevTools Lighthouse for quick audits. PageSpeed Insights provides field data. Test on real mobile devices when possible—your MacBook Pro isn't representative of most users' experience.
It depends on your audience and content, but under 1MB is a reasonable target for most pages. Image-heavy content (portfolios, e-commerce) might be higher; text-focused content can be much lower.
No—meaningful animation improves UX. The key is intentional, efficient animation. Animate what matters, keep it smooth, and provide reduced-motion alternatives.
Consistent components mean reusable, optimized code. When every card is different, each needs custom implementation. When cards follow a system, they share efficient code.
Third-party embeds often hurt performance significantly. Load them on interaction (click to load map), use facades (show a static image until clicked), or evaluate if they're truly necessary.