Performance·June 2024·9 min read

Eco-Friendly Web Development: Best Practices for Sustainable Coding

The frontend's carbon cost is bytes transferred and pixels rendered: oversized images, blocking fonts, and unsplit JavaScript bundles. None of it requires a separate sustainability initiative. It requires the same performance discipline Core Web Vitals already measures, pointed at a different unit of concern.

This is the page-weight half of a two-part problem

None of the fixes below need a rewrite or a new framework. Most are configuration changes, an attribute, a build-step flag, a CSS property, applied to a page that already exists.

Sustainable web engineering splits cleanly into infrastructure and frontend. The infrastructure half, compute region selection, autoscaling, cloud carbon dashboards, is covered in Sustainable eCommerce Tech: How IT Consulting Can Drive Green Retail. This is the other half: what happens in the browser, on the device a visitor is actually holding.

The frontend's energy cost is dominated by three things: how many bytes a page transfers, how much of that transfer blocks rendering, and how much JavaScript the device has to parse and execute before the page becomes usable. All three are measurable today, without any new tooling.

Images: still the single biggest lever

An unoptimized hero image, uploaded straight from a camera or phone at full resolution, remains the most common source of unnecessary transfer weight on a typical page. Serving responsive, correctly sized images and using the srcset attribute so a device only downloads the resolution it actually needs is documented directly in web.dev's images guidance (web.dev — Learn Images).

Modern formats compound the savings

AVIF, built on the open AV1 video codec, produces smaller files than JPEG or WebP at comparable visual quality, and browser support has been in place since 2020 in Chromium-based browsers, with Firefox and Safari following in 2021 and 2022 (web.dev — Image formats: AVIF). Serving AVIF with a JPEG or WebP fallback through the picture element captures the size reduction without breaking older clients, per web.dev's own compression guidance (web.dev — Using AVIF to compress images on your site).

Every byte saved here is a byte the network doesn't move and the device doesn't decode. That's a direct reduction in both load time and energy draw, not a proxy metric standing in for one.

Native lazy loading cuts transfer for anything below the fold

The browser-native loading="lazy" attribute defers requesting an image or iframe until it's near the viewport, which means a long product listing or article page never transfers the bytes for images a visitor never scrolls to see, a behavior documented directly in the HTML specification and web.dev's own guidance on it (web.dev — Browser-level image lazy-loading for the web). It costs a single HTML attribute to add and requires no JavaScript library.

The one place to leave it off deliberately: the page's largest above-the-fold image, usually the same element driving Largest Contentful Paint, should load eagerly, since lazy-loading it would delay the exact render Core Web Vitals measures.

Autoplay video is the new oversized hero image

A muted autoplay background video is a heavier version of the same mistake an oversized hero image makes: it transfers far more data than a static image or a short optimized clip, and it keeps transferring and decoding for as long as it loops, whether or not anyone is still looking at it. The video element's own specification supports a poster attribute specifically so a static frame can render immediately while the video loads, or instead of it entirely on constrained connections (MDN — The Video Embed element).

Where a video isn't essential to the page's actual content, replacing it with a static image or a short, compressed, user-triggered clip removes a meaningfully larger and more persistent energy cost than any single image ever would.

Fonts: the render-blocking cost nobody budgets for

Web fonts delay text rendering by default, which can push back First Contentful Paint and, depending on the font-loading strategy, Largest Contentful Paint too, according to web.dev's own font performance guidance (web.dev — Best practices for fonts). Setting font-display to swap in the @font-face declaration tells the browser to render fallback text immediately rather than blocking on the font download, a behavior defined directly in the CSS specification (MDN — font-display).

Subsetting a font to only the character set a page actually uses, and self-hosting it behind the same CDN and caching headers as the rest of the site, cuts both transfer size and the number of separate network round trips, per web.dev's font-loading optimization guidance (web.dev — Optimize WebFont loading and rendering).

A font-display value of swap doesn't make a font file smaller. It stops the font from blocking the page's first paint while it downloads, which is a rendering-strategy fix, not a compression fix, and both are needed.

JavaScript weight: parse and execution cost, not just download

Every kilobyte of JavaScript costs more than its transfer size suggests, because the device still has to parse, compile, and execute it before the page responds to input. Code splitting, shipping only the JavaScript a specific route or interaction needs instead of one monolithic bundle, is the documented fix, implemented through dynamic import() and supported natively by every major bundler (web.dev — Reduce JavaScript payloads with code splitting).

This overlaps directly with Interaction to Next Paint, one of the three Core Web Vitals metrics: less JavaScript executing at startup means the main thread frees up sooner to respond to a real click or tap.

The frontend build pipeline is where these decisions get enforced

None of the levers above stay fixed once a site ships. A team that optimizes images and fonts at launch, then adds a marketing embed, a chat widget, and an unoptimized banner image over the following year, ends up back where the sustainable-ecommerce companion piece describes: a site that quietly regressed one reasonable-looking addition at a time.

Enforcing a page-weight budget in continuous integration, failing a build when a page's transferred bytes or Lighthouse score crosses a set threshold, catches this drift before it ships rather than after an audit finds it months later.

The dark mode myth, checked against the actual research

Dark mode gets pitched constantly as an energy-saving design choice, and the honest answer is: it depends entirely on device type and screen brightness, not a flat percentage that applies everywhere. A Purdue University study measured OLED smartphone power draw across six popular apps and found that at 30 to 50% brightness, typical for most usage, dark mode saved only 3 to 9% of power on average (Purdue University Research — Dark mode may not save your phone's battery life as much as you think).

The same study found the picture changes sharply at maximum brightness, where the savings rose to 39 to 47%. And critically, none of this applies to non-OLED displays at all: on an LCD screen, which produces white and black pixels using roughly the same backlight power, dark mode has essentially no energy benefit.

Dark mode is a real, measured energy saver on OLED displays at high brightness. It is not a universal energy feature, and shipping it as a design preference is a legitimate UX decision, just not a sustainability strategy on its own.

Comparing the frontend levers by effort and payoff

Lever	Engineering effort	What it actually reduces	Also shows up in
Responsive images + modern formats	Medium — pipeline setup, then ongoing discipline	Network transfer, device decode work	LCP, bounce rate
font-display: swap + subsetting	Low — a CSS property and a build step	Render-blocking time, transfer size	FCP, LCP
JavaScript code splitting	Medium to high — architectural change	Parse and execution time on every visit	INP
Dark mode as a toggle	Low to medium — design system work	OLED power draw at high brightness only	User preference satisfaction, not universal energy savings

A rollout order that ships the highest-confidence wins first

Audit current image weight and format on the highest-traffic pages before touching anything else; this is almost always the biggest single win.
Set font-display: swap on every @font-face declaration and subset fonts to the character set actually used.
Identify the largest JavaScript bundles by route and split anything not needed for the initial render.
Ship dark mode as a genuine user preference feature, not as a marketed sustainability claim, since its energy impact is device- and brightness-dependent.
Re-measure against Core Web Vitals after each change, since the same metrics validate both the performance and the energy story.

Standards worth tracking, without over-claiming what they require

The W3C's Web Sustainability Guidelines reached first Public Draft Note status and structure sustainability guidance the way WCAG structures accessibility, as a checklist, not an enforceable standard yet (W3C — Web Sustainability Guidelines).
The Green Software Foundation's Software Carbon Intensity specification defines a rate metric, carbon per unit of work, rather than a total figure, which is the format that lets a team compare a page redesign against the version it replaced (Green Software Foundation — Software Carbon Intensity specification).

FAQ

Is image optimization really the biggest single frontend lever?

In most audits, yes. Oversized, unoptimized images are the most common single cause of excess page weight, and the fix, responsive sizing plus a modern format, is well documented and low-risk.

Does font-display: swap reduce the size of a font file?

No. It changes when the browser renders text relative to the font download, preventing render-blocking, but the file transfer size is unaffected. Subsetting and self-hosting are the levers that actually shrink the file.

Should every site ship dark mode as a sustainability feature?

Ship it as a user preference. Marketing it as an energy-saving feature overstates the research, which shows meaningful savings only on OLED displays at high brightness, not universally.

Does code splitting help every kind of website?

It helps most sites with more than a trivial amount of JavaScript, especially anything with route-based navigation or optional interactive features that don't need to load on first paint.

How is this different from the infrastructure side of sustainable web engineering?

This covers what happens in the browser: bytes transferred, render-blocking, JavaScript execution. The infrastructure side, compute region, autoscaling, cloud carbon dashboards, is a separate set of decisions covered in the companion post on sustainable ecommerce infrastructure.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.