How Do Design Choices Affect Website Energy Use?

Design choices affect a website's energy use because design decides two things that determine energy almost entirely: how much data a page sends, and how much work it asks the visitor's device to do. Long before a developer writes production code, a designer's decisions about imagery, video, fonts, animation, scrolling behaviour and the number of third-party features have effectively set the page's energy budget. Heavy media and busy interfaces transfer more bytes and demand more processing, which consumes more energy in data centres, across networks and on devices. This guide walks through each major design lever — from images and autoplay video to infinite scroll, trackers and the much-misunderstood question of dark mode — and explains what to do instead, with page weight as the throughline that ties it all together.

It is the designer-focused companion to how to reduce page weight for a faster, greener website, which covers the engineering tactics in detail.

Why design decides most of the energy

There is a tendency to think of a website's energy use as a technical concern, settled by engineers tuning servers and shaving milliseconds. In reality, most of a page's energy footprint is decided at the design stage, because design determines the raw material that everything downstream has to handle.

Two factors govern energy use, and design controls both. The first is data transferred — the bytes that move across the network when the page loads. Every image, video, font and script a designer specifies becomes data that has to travel from a data centre, through networks, to a device, all of which costs energy. The second is device work — the processing the visitor's phone or laptop must do to render the page. Complex layouts, continuous animation and heavy scripting all make the device's processor work harder, draining battery and consuming energy.

A developer can optimise the implementation, but they cannot easily undo a design that calls for a full-screen autoplay video, a dozen high-resolution images above the fold and six font weights. Those decisions set the ceiling. This is empowering rather than discouraging: it means designers hold the largest lever for a greener web, and that lever is exercised in everyday choices, not exotic techniques.

The benchmark: how heavy the typical page is

To see why media decisions dominate, it helps to know the shape of the average page. According to the HTTP Archive, whose Web Almanac crawls millions of real pages, the 2025 median mobile page weighs around 2,360 KB — roughly 2.3 megabytes. Crucially, that weight is not spread evenly: images and JavaScript are the two heaviest categories by a wide margin, together accounting for the majority of a typical page's bytes.

That single fact should anchor a designer's priorities. If images and scripts are where the weight is, then decisions about imagery and about how many interactive features and third-party tools a page carries are where the energy is. Fonts, animation and the rest matter, but they are secondary to getting media and feature-bloat under control. The median is not a target to design up to, either — plenty of excellent pages come in well under a megabyte. It simply tells you where the broad web sits and confirms that the typical page is heavier than it needs to be.

Imagery: the biggest single lever

On most pages, images are the largest contributor to weight, and therefore the single most important design decision for energy. The questions a designer asks shape the outcome: How many images does this layout truly need? How large do they need to be? Could a smaller, well-chosen image carry the same meaning as a sprawling hero?

The good news is that image weight is highly controllable without sacrificing quality. Compress images so they carry no unnecessary data, size them to their actual display dimensions rather than shipping a huge file into a small slot, use modern formats like WebP and AVIF that are far smaller than older JPEG and PNG at equivalent quality, and lazy-load images below the fold so they download only when the user scrolls to them. The complete method is in how to optimize images for the web. A designer who keeps image discipline tight has already controlled the majority of the page's energy use.

Video and autoplay: the heaviest media of all

If images are the biggest everyday lever, video is the heaviest single thing a page can carry. A few seconds of video can outweigh an entire page of text and images combined. And the worst pattern is autoplay — video that starts on its own, often muted, frequently as decoration. Autoplay forces every visitor to download and render that video whether or not they want it, multiplying its energy cost across all your traffic for little user benefit.

The design guidance is direct. Avoid autoplay. Do not use video as pure background decoration. When video genuinely serves the content, let users choose to play it, and stream it adaptively so devices receive a quality appropriate to their screen and connection rather than one enormous file. A short, deliberate, click-to-play video is a world apart from an autoplaying background loop, both in energy and in user respect.

Fonts: small decisions, repeatable savings

Custom fonts feel lightweight but add up. Each font weight is a separate download, so a design that specifies six weights of a typeface ships six files, each adding to page weight and potentially blocking text from rendering until it loads. Designers control this directly: limit the number of weights to what the design genuinely needs (two or three is usually plenty), prefer the efficient woff2 format, subset fonts to the characters actually used, and ask whether a custom typeface is even required where a well-chosen system font would serve. None of these savings is huge alone, but they are easy, repeatable and cost nothing in quality.

Animation and motion: continuous device work

Motion adds energy cost in two ways. Large animated assets — heavy GIFs, complex Lottie files, video-as-animation — add to page weight. And animation that runs continuously forces the device into continuous rendering work, keeping its processor busy and draining battery for as long as the animation plays. A page full of scroll-triggered effects, parallax and looping motion can keep a device working hard the entire time it is open.

Used purposefully, motion is fine and often valuable for usability. The sustainable approach is to keep it intentional and efficient: animate to communicate, not to decorate; prefer lightweight CSS transitions over heavy animated media where possible; and avoid endless, ambient motion that costs energy without serving the user. Respecting reduced-motion preferences is both an accessibility and an energy win.

Infinite scroll: loading what nobody asked for

Infinite scroll is a design pattern with a hidden energy cost. As the user scrolls, the page silently fetches and renders more and more content — more images, more markup, more scripts — much of which the user may never actually look at. The result is data transferred and energy consumed well beyond what the user's actual need required, and a page that grows heavier and heavier in the device's memory the longer it stays open.

For some experiences infinite scroll is genuinely the right choice, but as a default it tends to waste both energy and attention. Alternatives like pagination or an explicit load-more button put the user in control: content loads only when they ask for it, which transfers less data and uses less energy while often making the content easier to navigate and return to. The design question is whether the endless feed truly serves the user or merely maximises time-on-page at an energy cost.

Ad and tracker bloat: weight users never wanted

Many of the heaviest, most energy-hungry elements on a page are not the content at all — they are the ads, analytics tags, trackers, chat widgets and social embeds layered on top. Each third-party script adds bytes to download and code to execute, and each can pull in further requests the designer never explicitly chose. They frequently add weight and device work out of all proportion to the value they deliver, and they are a leading cause of pages quietly getting heavier over time.

While engineering owns much of the implementation, design and product decisions determine how many of these features exist in the first place. Every tracker, widget and embed is a choice. Questioning whether each one earns its energy cost — and removing or deferring those that do not — is one of the highest-impact things a team can do, often second only to images.

Dark mode: a real but limited effect

No design-and-energy discussion is complete without addressing dark mode, because it is widely misunderstood. The honest summary: dark mode saves energy, but only a little, and only in specific conditions.

The saving is real on OLED and AMOLED screens, where each pixel emits its own light, so dark pixels genuinely draw less power than bright ones. On these displays — common on many phones and some premium laptops — a dark interface can modestly reduce screen energy use. But on the LCD screens still found on most laptops and many monitors, the backlight is always on regardless of what is displayed, so dark mode saves essentially nothing. And critically, dark mode does nothing to reduce the data a page sends — it changes colours, not bytes.

So treat dark mode as a welcome preference and accessibility option, not a sustainability strategy. The energy it might save on some screens is a rounding error next to the savings available from cutting page weight. A designer serious about energy use should offer dark mode if users want it, then spend their real effort on images, video and feature bloat.

Design choice → energy impact → better practice

Design choice	How it affects energy	Better practice
Large / numerous images	Largest weight driver; most data transferred	Fewer, compressed, correctly sized images in WebP/AVIF; lazy-load
Autoplay / background video	Heaviest media; forced on every visitor	No autoplay; click-to-play; adaptive streaming
Many font weights	Each weight is a separate download	Limit weights; woff2; subset; consider system fonts
Heavy / continuous animation	Adds weight and ongoing device work	Purposeful, lightweight motion; respect reduced-motion
Infinite scroll	Loads content the user may never see	Pagination or load-more; user controls loading
Ad / tracker bloat	Extra bytes and execution per third party	Question every tag; remove or defer non-essential ones
Dark mode	Saves a little on OLED only; no data savings	Offer as a preference, not as an energy strategy

The throughline: it all comes back to page weight

Step back and a single pattern connects every lever above: they all influence page weight and device work, and those two things drive energy use. That is why this subject is ultimately encouraging for designers. You do not need a separate, complicated sustainability practice. You need to design lean pages that respect the user's data and device — and the same choices that achieve that make the page faster, which improves Core Web Vitals and the page-experience signals that feed SEO.

In other words, designing for low energy use is designing for good performance, which is also designing for a better user experience. The goals converge. A designer who keeps images tight, avoids autoplay video, limits fonts, uses motion purposefully, prefers controlled loading over infinite scroll, and questions every tracker is simultaneously building a greener, faster, more pleasant site. For the broader principles behind this, see what makes a website sustainable by design; for how to confirm the gains, see how to measure your website's carbon emissions.

A quick checklist

• Treat design as the stage where most of the page's energy is decided.
• Control images first: fewer, compressed, correctly sized, modern formats, lazy-loaded.
• Avoid autoplay and decorative video; make video click-to-play and adaptive.
• Limit font weights; keep animation purposeful and lightweight.
• Prefer pagination or load-more over infinite scroll.
• Question every ad, tracker and embed.
• Offer dark mode as a preference, but invest real effort in page weight.

Go deeper

• The engineering side of the same work: how to reduce page weight for a faster, greener website.
• The principles behind these choices: what makes a website sustainable by design.
• The biggest single lever, in depth: how to optimize images for the web.
• Confirm your gains: how to measure your website's carbon emissions.
• The performance twin: Core Web Vitals explained.

Want your design choices measured as page weight, performance and efficiency? Analyse any URL with StackOptic — one report, free, no sign-up.