A project about efficient software should have an efficient website

GreenCode exists to cut the energy that software wastes, so its own website is built the same way. The site is a set of static pages served from Cloudflare's edge network, with no application server, no database behind a page view and no build step at request time. Every page is generated in advance and cached close to the visitor.

Until September 2026 the site ran on WordPress on a virtual server in London. A first view of the home page then transferred about 6,766 KB over 80 requests, and every request ran PHP and a database. The migration rebuilt the same content as static files and cut a first view of the home page to about 1,719 KB over 33 requests, with images recompressed and served as WebP, scripts reduced to what each page needs, unused styles purged and the theme font self-hosted.

How the footer figure is calculated

Every page carries a line in the footer that states how much data the page view transferred and an estimate of the carbon it produced. The estimate comes from CO2.js, an open-source library from the Green Web Foundation, using version 4 of the Sustainable Web Design model. The model converts bytes transferred into energy across four segments, data centre, network, the visitor's device and the embodied energy of the hardware involved, and then into carbon using an average grid intensity. Because the site is served from a provider that matches its electricity use with renewables, the data centre segment is calculated with the model's green-hosting factor.

The letter rating next to the figure places the page against the model's percentile bands for web pages in general: an A rating means the page produces less carbon than about 95% of pages tested. The measurement is made in the visitor's browser from the resources the page actually loaded, so it reflects caching, image sizes and the scripts that ran on that view.

The figure is an estimate, not a meter reading. It does not know which power station fed the visitor's device, and the model's per-gigabyte energy figures are sector averages. It is useful for the same reason the GreenCode pipeline is useful: measured consistently before and after a change, it shows whether a page got lighter.

What delivering the site has cost so far

The table below applies the same model to every month since the site launched, using the page views recorded by Google Analytics for the WordPress years and by Cloudflare Web Analytics from the move to Cloudflare Pages. Each month is costed with the page weight and hosting of its era, so the effect of the migration is visible in the figures.

Monthly view figures are not loaded yet. When the Google Analytics and Cloudflare exports are in place this table shows every month since the site launched with its estimated carbon.

The lifetime total will appear here once the monthly page views from Google Analytics (WordPress years) and Cloudflare Web Analytics (from the migration) are loaded into the site's statistics file.

How our films are made

The explainer films on this site, and the Shorts cut from them, are made by Explain a Paper, which produces energy-efficient video for technical concepts. They are built the way GreenCode builds software: with the smallest tool that does the job.

• Drawn in code, not generated. Every frame is a vector drawing produced by a program from the film's script, then rasterised on an ordinary processor and encoded with ffmpeg. No video-generation model is involved: there is no diffusion model painting frames on a bank of graphics cards, and the diagrams stay exact because they are drawn, not guessed.
• One small model, run locally. The only model in the pipeline is the voice: Kokoro-82M, an open-weight text-to-speech model of 82 million parameters, running on a local machine rather than as a cloud service.
• Frugal use of language models. A language model helps draft each script from the reviewed copy of the page it sits on, and translates the captions into the channel's languages. Each draft is checked by people against the source; nothing in a film says more than the page does.
• Made once, reused. The Shorts and TikToks are cut from the finished films rather than rendered again, and a film is re-rendered only when its page changes.
• Delivered only when wanted. A page shows the film's poster; the film itself, around ten megabytes for a two-to-three-minute explainer, is fetched only when a visitor presses play, from storage in Western Europe or from YouTube.

What we do to keep it low

• Static delivery. Pages are files on an edge network; nothing is computed per request except the newsletter and contact forms, which run as small functions only when submitted.
• Lean pages. Native lazy loading for images, one self-hosted font, scripts loaded only on the pages that use them, stylesheets purged of unused rules, and the third-party analytics and advertising tags held back until a visitor consents.
• Optimised media. Every image is recompressed and served as WebP where that is smaller; the films are loaded only when played.
• Measured on every page. The footer figure keeps the site honest: a change that makes a page heavier shows up immediately.

The methods are the same ones GreenCode applies to software systems at a much larger scale: measure, optimise, verify and keep measuring. The benefits pages describe what that means for a codebase, and the climate case sets out why it matters.