Every page view uses electricity: in the data centre that serves it, the networks that carry it, and the phone or laptop that renders it. The encouraging part is that almost everything that reduces a website's footprint also makes it faster, cheaper to run and more pleasant to use. Sustainable web design is mostly good engineering with a clearer reason behind it.

Where a website's energy actually goes

It helps to think in three places:

Data centres, which store, compute and serve your pages.
Networks, which move every byte from server to visitor.
End-user devices, which download, parse, execute and paint everything you send.

Popular carbon estimators, including the Website Carbon Calculator and the Green Web Foundation's open-source CO2.js library, use the Sustainable Web Design model, which estimates emissions mainly from data transferred. That makes page weight a useful, measurable proxy. But treat any grams-of-CO2-per-page figure as an estimate, not a measurement. Bytes-based models also struggle to capture the energy a device spends running heavy JavaScript or animation, which is why this guide treats CPU and GPU work as a separate lever.

If you want a structured framework, the W3C's draft Web Sustainability Guidelines (WSG) cover design, development, hosting and business strategy in one place.

Ship fewer bytes

Images

Images are usually the biggest and easiest win.

Serve images at the size they are displayed. next/image generates responsive variants, but only picks the right one if you set the sizes prop accurately.
Use modern formats. AVIF and WebP are typically much smaller than JPEG at similar visual quality. AVIF often compresses further but costs more CPU to encode, so enable both and let the browser choose.
Lazy-load everything below the fold. Visitors who never scroll that far never download it.
Never use PNG for photographs, and run SVGs through an optimiser to strip editor metadata.

Video

An autoplaying background video can outweigh the rest of the page several times over. Use one only when it genuinely earns its place. When you do, keep it short and muted, give it a lightweight poster image, set preload to none or metadata, and offer a still image to visitors who prefer reduced motion. For longer content, adaptive streaming sends each viewer only the quality their connection and screen need.

Fonts

Each weight and style is a separate file. Prefer one variable font over several static weights, subset to the character sets you actually use, ship WOFF2, and self-host. In Next.js, next/font handles self-hosting and subsetting for you. For body text, a well-chosen system font stack costs nothing at all.

JavaScript

JavaScript is the most expensive byte on the web, because after it is downloaded it still has to be parsed and executed on the visitor's device.

In the Next.js App Router, keep components as Server Components unless they truly need interactivity. Server Components send HTML, not component code.
Run a bundle analyzer and question every large dependency. Many date, utility and animation libraries can be replaced by built-in browser APIs such as Intl or by CSS.
Audit third-party scripts: tag managers, chat widgets, heatmaps and social embeds. Remove what nobody reads, and load the rest only after consent or interaction.

Cache aggressively, render once

Rendering the same page for every visitor wastes server energy.

Prerender wherever you can. A static page is rendered once at build time or on revalidation, then served from a CDN close to the visitor.
Use long-lived caching for fingerprinted assets. Next.js already serves its hashed build files with immutable cache headers, so returning visitors download nothing new.
Revalidate on change, not on a timer. Tag cached data and invalidate it when the CMS publishes, instead of re-rendering every minute just in case.
Replace polling with events. A webhook that fires once beats a client that asks every few seconds whether anything has changed.

Device energy: the part bytes don't show

A page can be light to download and still drain batteries if it keeps the CPU or GPU busy. Many people browse on older or mid-range phones, where wasted work turns into heat, lag and shorter battery life.

Animate with CSS transform and opacity, which the browser can usually hand to the compositor, instead of animating layout properties from JavaScript.
Stop infinite animations, carousels and timers when they are off-screen or the tab is hidden.
Avoid scroll handlers that run on every pixel of movement; use IntersectionObserver for scroll-triggered effects.
Offer a dark theme. On OLED screens, dark pixels draw less power, though the saving is small on LCD screens and depends on how much of the page is actually dark.

I should be honest about my own site here. It runs real-time WebGL: a GPU fluid simulation, a deep-space starfield with a procedural nebula, and hero smoke. Effects like these are not "green" by default, so I treat them as a cost to justify and contain:

They are lazy-loaded, so the content arrives and works before any 3D code downloads.
The nebula is rendered at a fraction of screen resolution and upscaled, which cut its GPU cost several-fold with no visible difference.
An adaptive quality governor lowers simulation quality when a device genuinely struggles, and switches effects off one at a time on weak hardware.
Visitors who ask their operating system for reduced motion get the calm backdrop only, without the pointer-driven fluid or the smoke.
WebGL contexts and GPU resources are released when canvases unmount.

That is the general rule I apply to clients too: rich visuals are a deliberate choice, scoped to where they add meaning, with a lighter path for every device that needs one.

Infrastructure choices

Choose a green host. The Green Web Foundation keeps a public directory of hosting providers that run on, or offset with, renewable energy.
Think about region. Electricity grids differ a lot in carbon intensity. When latency allows, run servers and databases in a region with a cleaner grid.
Right-size and scale to zero. Idle servers still draw power. Serverless or autoscaling setups that shrink when traffic drops avoid paying, financially and environmentally, for capacity nobody uses.
Clean up. Delete unused environments, stale preview deployments, orphaned storage buckets and logs kept far longer than anyone needs them.
Use AI features deliberately. Calling a large model on every page view is expensive. Cache results, generate content once rather than per request, and use a smaller model where it is good enough.

Design decisions are sustainability decisions

The lightest page is the one nobody had to load. Clear navigation, honest headings and content that answers the question on the first visit all reduce wasted page views. Structured data helps too: on my own site, JSON-LD and an llms.txt file describe my services plainly, so search engines and AI assistants can point people straight to the relevant page.

Other choices that matter: a "load more" button gives people control that infinite auto-loading does not, a single strong hero image beats a ten-slide carousel nobody watches, and retiring outdated pages keeps both your site and your hosting lean.

Measure, budget and enforce

What gets measured gets kept. Track page weight, request count, JavaScript size and Core Web Vitals for your key templates, and use a carbon estimator for rough before-and-after comparisons. Then turn your targets into a budget that fails the build when it is exceeded, so regressions are caught in a pull request instead of in production.

[
  { "name": "Client JavaScript", "path": ".next/static/chunks/**/*.js", "limit": "250 kB" },
  { "name": "Global CSS", "path": ".next/static/css/*.css", "limit": "40 kB" }
]

A .size-limit.json file like this, checked in CI with the size-limit tool, is a simple start. The exact numbers matter less than having numbers at all.

Key takeaways

Data centres, networks and devices all use energy; page weight is a useful proxy, but not the whole picture.
Images, video, fonts and JavaScript are the main levers, and JavaScript costs the most per byte.
Prerender, cache for a long time and revalidate on change instead of on a timer.
Device energy matters: stop off-screen work, animate on the compositor and contain heavy visuals.
Green hosting, right-sizing and cleanup reduce the footprint behind the scenes.
Set a performance budget and enforce it in CI.

Most of this overlaps with performance work. If your site is heavy or slow, my Core Web Vitals fixes are usually the fastest way to cut both load time and waste, and they are the defaults I build with in my web development work.

Planning a project? Book a free discovery call — I'll tell you honestly what it needs.

Sustainable Web Design — Why Lighter, Faster Websites Use Less Energy