Sustainable Web Development: Green Solutions

Sustainable web development in March 2023 sits between two poles. On one side, a growing need to honestly address the energy use and CO2 footprint of digital products — as an engineering question, as a client requirement, as an auditability topic. On the other side, a wave of "green" logos, certificates and promises whose substance is often thin. In this post I write about what we concretely do at Moselwal, what we measure — and what we deliberately leave out to avoid the greenwashing trap.

Where energy use in the web actually sits

The CO2 footprint of a website roughly splits across three areas. The data centre in which the application runs is the obvious item. The transmission infrastructure — networks, CDN edges, ISP servers — is the second, often underestimated one. The third, and largest in aggregate, is the end-user device: the laptop, smartphone or tablet that renders the page and consumes power during use. Anyone talking only about the data centre is talking about the smaller problem.

Practically: a 5-megabyte website hosted on a solar-powered data centre has a worse total footprint than a 500-kilobyte website on conventional hosting. The mobile device bears the main load, downloading, parsing, executing and rendering five megabytes. Reduction on the delivery side is therefore the single biggest lever.

Hosting: region, energy mix and hardware efficiency

On the hosting side, three variables count. The region of a data centre decides the energy mix — an application in Frankfurt runs today with a significantly higher share of renewable energy than the same application in a region still leaning heavily on coal and gas. That is an argument for the Frankfurt region (eu-central-1) that goes beyond the GDPR perspective.

The provider's energy mix is the second variable. AWS has committed to 100 percent renewable energy by 2025; Hetzner declares its German data centres similarly; Google Cloud and Microsoft Azure run comparable roadmaps. Anyone choosing a provider without such a commitment should know that.

Hardware efficiency is the third. For most of our workloads we use ARM64 processors — at AWS the Graviton instances, at Hetzner the Ampere-based instances. In our load tests, the ARM64 architecture delivers roughly 20 percent more performance per watt than comparable x86_64 instances. On workloads that run continuously, that is a measurable item.

As a base image we use lean distributions: Alpine Linux or Distroless for application containers. A smaller image starts faster, needs less memory and therefore less power — the effects are small, but they add up over many container starts per day.

Frontend: size and effort cost on the end device

Frontend optimisation is the stage where sustainability is most visible. The measures are less spectacular than their effect would suggest.

Image optimisation. WebP instead of JPEG/PNG wherever the browser support picture allows — and in March 2023 that covers 95+ percent of the global browser population. AVIF is newer and delivers even smaller files but does not yet have stable support everywhere. We use WebP as default and AVIF as an optional second path. Responsive images with srcset are not a nice-to-have but a duty: no one on a smartphone needs a 2,000-pixel hero image.

JavaScript diet. Every unnecessary JS library costs bandwidth, parse time, and battery life on the end device. We check on every project whether a framework is really needed or whether HTML with selective JS is enough. For TYPO3 and Symfony setups, this usually means: server-side rendering is the default, JavaScript is used only where it delivers real interaction value.

Fonts. Web fonts are an often-overlooked item. A single typeface in four weights can take between 100 and 400 kilobytes. We subset our web fonts (only the glyphs needed) and load them deferred with font-display: swap. System fonts are the most sustainable choice when brand identity allows it.

Caching and compression. Brotli delivers responses about 20 percent smaller than gzip for text. HTTP/2 or HTTP/3 prevents many round trips. A correctly configured Cache-Control strategy reduces repeated downloads over weeks and months.

Backend: cache, DB efficiency and workload shaping

On the server side, three levers stand out — none of them new, all three often half-heartedly implemented in practice.

A fully warmed page cache replaces the bulk of server work for most websites. We set up reverse-proxy caching with Varnish or the cache configuration in CloudFront so that dynamic requests only occur where they are truly needed. For TYPO3 setups that means a carefully maintained cache rule with a defined Vary header.

Database efficiency is the invisible factor: a poorly indexed table that runs a full-table scan on every request measurably costs power on a loaded system. We check slow-query logs systematically and optimise the ten most frequent queries of every platform.

Workload shaping is the third lever: cron jobs, image generation, reports run at night and on Spot instances when that is possible without user wait time. A background job that does not generate load between 9 and 17 relieves the daytime peak and indirectly the whole data centre.

Devices and lifecycle

The biggest item in a digital team's CO2 ledger is often not the servers but the end devices. Producing a laptop typically accounts for more CO2 over its lifecycle than its entire electricity use over five years. The most sustainable hardware is therefore the one you keep.

We buy devices planned for at least five years of use. Apple Silicon MacBooks and comparable modern ARM laptops are a clear step forward here — they are more energy efficient than the x86_64 generation, quieter, cooler, and therefore last longer without significant performance loss. On a defect, we check repair before replacement; when a device is replaced, the old one goes refurbished onward, not into e-waste.

To this come cable quality, power-saving settings at the workplace, avoiding permanent stand-by loads — small items that add up.

What we measure and what we do not

Greenwashing often arises when a measure is sold as "green" without anyone measuring whether it does anything. What we concretely measure:

• Page weight per page (total transfer size, broken down by HTML, CSS, JS, images, fonts), monthly.
• CO2 estimate via the Website Carbon Calculator or comparable tools, per main page once a quarter.
• Lighthouse performance score (as a proxy for efficiency), automatically on every pull request.
• Server CPU utilisation as a curve across the day — indicator for workload-shaping effects.

What we do not measure because the numbers are unreliable: individual kWh values per page view, "carbon neutrality" through purchased certificates, marketing numbers from vendor logos.

What we deliberately do not do

Three practices that are widespread in the "green web" we do not run.

No carbon certificates as a substitute for engineering. If the website is five megabytes, it is five megabytes — even if the hosting provider sports a "CO2 neutral" logo. Certificates can compensate for unavoidable residual emissions, but they do not replace the optimisation work.

No "eco mode" toggle for users. A switch that makes the page "more resource-efficient" is usually theatre. If the resource-efficient layout works, it should be the default layout.

No green logos without substance. We pass on seals and certificates that have no measurable work behind them. What we do, we document soberly — what we cannot measure, we do not claim.

Conclusion

Sustainable web development is at its core an engineering discipline: smaller pages, more efficient hardware, longer lifecycles, honest measurement. The interesting levers rarely sit at the hosting provider but at the frontend, in image optimisation, and in the lifespan of one's own devices. Anyone who reckons honestly builds better websites — and notices along the way that sustainable practice and fast websites are the same goal, not two different ones.