Sustainable UX: Designing Low-Impact, High-Performance Interfaces
Every page load, every API call, every animation consumes energy somewhere in the chain — from the user's device through network infrastructure to data centres. Sustainable UX is about making deliberate design choices that reduce this energy consumption without sacrificing user experience. The good news: sustainability and performance are usually the same goal. Lighter pages load faster and use less energy.
Last updated: 30 March 2026
Where digital energy goes
Understanding the energy chain helps you target high-impact areas:
Data centres (~15%). Servers processing requests, running databases, and serving files. Larger payloads mean more processing. More requests mean more server cycles.
Network transfer (~14%). Moving data from server to device. Heavier pages consume more network energy, especially on mobile networks which are less efficient than Wi-Fi.
End-user devices (~71%). The biggest share. Screen brightness, CPU processing for JavaScript, GPU rendering for animations — all draw power from the user's battery. This means client-side complexity is the largest lever.
Designing for page weight
Page weight is the simplest sustainability metric and directly correlates with performance. The performance for designers guide covers Core Web Vitals — sustainable design amplifies those same practices:
Images (typically 50–70% of page weight)
- Use modern formats: WebP or AVIF instead of PNG/JPEG (30–50% smaller).
- Serve responsive sizes — a 400px-wide container doesn't need a 2000px image.
- Lazy-load below-fold images so they only load if the user scrolls to them.
- Question whether each image earns its weight. A decorative gradient that adds 200KB but no information should go.
JavaScript (typically 10–25% of page weight)
- Every kilobyte of JavaScript costs more than a kilobyte of image — it must be downloaded, parsed, compiled, and executed. Images are just rendered.
- Audit third-party scripts. Analytics, chat widgets, and social embeds often add 200–500KB each.
- Use code splitting to load only what's needed for the current page.
- Consider whether client-side rendering is necessary. Static or server-rendered HTML is dramatically lighter.
Fonts (typically 5–10% of page weight)
- Subset fonts to the characters you actually use.
- Limit to 2 font families and 3–4 weights. Each weight is a separate file.
- Use
font-display: swapto avoid layout shift.
Set a page-weight budget of 500KB (compressed) for content pages. This forces prioritisation and delivers both sustainability and performance benefits. Most pages can achieve this without visible sacrifice.
Reducing unnecessary requests
Each HTTP request consumes energy at every point in the chain. Reduce them:
- Combine and cache. Serve CSS and JS as bundled, versioned files with long cache headers. Returning visitors make zero requests for cached resources.
- Eliminate analytics you don't act on. If nobody looks at the heatmap data, remove the heatmap script. Every data collector costs energy on every page load.
- Prefetch intelligently. Prefetching resources the user is likely to need next is good. Prefetching everything "just in case" wastes energy.
Dark mode and OLED screens
On OLED screens, dark pixels are literally off — they consume no energy. Dark mode on OLED devices can reduce screen energy by 30–50%. On LCD screens, the difference is negligible because the backlight stays on regardless of pixel colour.
Design implications:
- Offer a dark mode option (or respect
prefers-color-scheme). - In dark mode, use true blacks (
#000000) sparingly and dark greys for most backgrounds (pure black on OLED creates a "smearing" effect during scrolling). - Ensure accessibility contrast ratios are met in both light and dark modes — dark mode doesn't automatically pass contrast checks.
Motion and animation sustainability
Animations consume GPU and CPU energy. Every transform, opacity transition, and scroll-triggered effect has an energy cost.
Design rules:
- Use motion purposefully. Transition animations that help users track layout changes are worth the energy. Background particle effects are not.
- Respect
prefers-reduced-motion. Users who enable this setting often do so for medical reasons, but it also saves device energy. - Avoid looping animations. A loading spinner is fine. An infinitely animated gradient background is pure waste.
- Prefer CSS transitions over JavaScript animation libraries. CSS transitions are GPU-accelerated and dramatically more efficient.
Content strategy for sustainability
Less content doesn't mean less useful. Often it means more useful:
- Concise writing. Shorter pages mean less rendering, less scrolling, less data transfer. Clear, concise writing from our UX basics guide is also sustainable writing.
- Progressive disclosure. Show summaries with "read more" options. Users who don't need the detail save the energy of rendering it. This pattern is covered in the onboarding patterns guide.
- Evergreen content. Content that stays relevant for years gets cached by browsers and CDNs for longer, reducing repeated transfers.
Measuring your digital footprint
Several metrics help track sustainability:
- Page weight (transferred bytes per page). Target under 500KB.
- HTTP requests per page. Target under 30 for content pages.
- JavaScript execution time. Measure with Lighthouse. Target under 2 seconds.
- CO2 per page view. Tools like Website Carbon Calculator estimate this. A median web page produces about 0.8g of CO2 per view.
Track these alongside your standard UX metrics — performance and sustainability metrics reinforce each other.
Common mistakes
Treating sustainability as a marketing add-on. Adding a "green" badge while your page loads 3MB of JavaScript is greenwashing. Sustainability is in the implementation, not the branding.
Optimising images but ignoring JavaScript. JS is the most expensive resource per byte. A 500KB image is cheaper than 500KB of JavaScript.
Removing features users need. Sustainability doesn't mean a stripped-down experience. It means eliminating waste — unused code, unnecessary requests, decorative bloat — not useful functionality.
Ignoring the back end. A fast-loading page that triggers 50 database queries on every load is not sustainable. Work with engineers to optimise server-side efficiency too.
Not measuring. Without a weight budget and regular audits, page weight inevitably grows. Measure every release.