How we build cleaner websites

Sustainable websites are not created by adding a green badge at the end of a project. They come from many small decisions made through the design, development and maintenance of a site.

Green hosting is a useful starting point, but it does not tell the whole story. A website still relies on data centres, networks and visitors' devices to load and use it. The amount of data moved, the work the browser needs to do and how often content is loaded all make a difference.

For us, building a cleaner website means following that whole journey. We first decide what the site genuinely needs, then structure it carefully, build it efficiently and measure the result. It is a practical process, not an extra feature added at the end.

Green hosting is only one part of a larger plan
Choosing a host that uses renewable energy is a good starting point. It can reduce the emissions connected with running the servers that deliver the website, and it gives the project a better foundation.

The host can change how the servers are powered. Changing the host alone does not reduce the size or complexity of the website being sent from them. A page with oversized images, unnecessary scripts or several tracking services will still make the server send all of that data, while the visitor's network and device still have to receive and process it.

Green hosting gives the site a better foundation, but the next step is to reduce what the site needs in the first place.

The decisions start before development
That work starts before we write code. We decide what each page needs to do, what a visitor should be able to find or complete, and what does not need to be there. Avoiding unnecessary work is one of the simplest ways to reduce a site's impact.

A clear structure usually means fewer templates, fewer repeated journeys and less content competing for attention. Reusing a small set of well-designed components also lets us solve common problems once, including mobile layouts and accessibility, instead of adding a new exception every time.

From there, we build pages around reusable content blocks and keep their behaviour predictable. Useful page content is delivered first, while extra browser behaviour is added only where it improves the experience. This makes the site easier to understand, quicker to load and simpler to maintain.

The same rule applies to third-party services. Analytics, video players, maps, chat tools and advertising scripts can all add network requests and browser work. They should be included when they provide clear value, not simply because they are available. Once the purpose and structure are clear, we can look at how much data the site sends.

Sending the right amount of data
Images are often the largest part of a page, so we prepare them at several sizes and let the browser choose the most suitable one for the visitor's screen. A phone should not need to download an image prepared for a large desktop display. We also use efficient modern formats and compress the files carefully so they remain sharp without carrying unnecessary weight.

Fonts need similar care. Each font file has to be downloaded, so a large family with many weights and styles can quickly add up on every page load. We keep the set focused and load only what the design requires.

The code behind the page matters as well. We keep browser scripts focused, avoid large libraries when a small piece of code will do the job, and do not make every page download behaviour that it never uses. Images and other heavier content can wait to load until they are close to the visitor's viewable area of the screen as they scroll, while files that rarely change can be cached and reused on later visits.

A lighter website should not feel reduced. Visitors usually notice the opposite: pages appear sooner, controls respond more quickly and the experience works better on slower connections and older devices. We then measure the result to check that these choices have made a real difference.

Measuring the result
Once the site is running, we can measure whether those decisions have made a difference. We can check how much data a page transfers, how many requests it makes and how much work it asks a browser to do. We can also test it under a slower mobile connection instead of judging it only on a fast office computer. Though so obvious, this is something that often gets overlooked.

Carbon tools use figures such as data transfer, energy use and the carbon intensity of electricity to estimate the emissions produced by a page view. Green hosting can then be included as another factor. This gives us a figure in grams of carbon dioxide equivalent, or CO₂e, for each visit.

Like calculating the impact of air miles, this is an estimate rather than a perfect reading. The result changes with the visitor's device, location, connection and behaviour. It is still useful because the same method lets us compare pages, identify the heavier parts of a site and measure whether our changes have improved them.

The aim is not simply to reach the smallest possible number. A website still needs to communicate and support a business. The useful measure is whether we can remove waste while keeping the content, accessibility and functionality that people need. A dated baseline gives us something practical to compare later.

ROW K Entertainment: a recent example
We applied this process to the Row K home page on 30 July 2026 with a throttled mobile Lighthouse test. The initial page load transferred approximately 751 KiB and returned a performance score of 93 out of 100. You can also view the current PageSpeed result and current Website Carbon result.

Using the transferred data and a recognised website carbon model, we estimated the page at approximately 0.07 g CO₂e for one visit. At 10,000 home-page views per month, the same estimate would be about 7.9 kg CO₂e over a year. The Green Web Foundation also identified the domain as using verified green hosting at the time of the check.

These figures are a snapshot rather than a permanent certificate. Content, third-party services and hosting can all change. What matters is that we have a dated baseline we can check against in the future. If the page becomes heavier, we can see it. If an improvement reduces the transfer or browser work, we can quantify that too. That attention has to continue after launch, because the site will keep changing.

Built to last
What happens after launch is part of a clean build too. A site that is difficult to update often gathers duplicate pages, inconsistent components and short-term fixes. Over time this can make it heavier and more expensive to maintain.

We keep the content model clear, reuse established patterns and make sure new material can be added without rebuilding the page each time. We also avoid tying ordinary content to one-off technical work when a simpler editing option will do.

This gives the website a longer useful life. It can change with the organisation without being replaced simply because its structure has become difficult to work with. That is better for the client and avoids repeating the cost and impact of an unnecessary rebuild.

There is no single switch that makes a website sustainable. It is a chain of choices made before, during and after development. Green hosting matters, but so do the structure, content, code, measurement and the way the site is maintained. Treating them as part of the same project lets us build websites that do what they need to do and use less in the process.

Method note
The Row K measurement was taken on 30 July 2026 using Lighthouse with mobile throttling. Transfer size was 769,375 bytes and the Lighthouse performance score was 93. The CO₂e estimate used Website Carbon's calculation method, which is based on data transfer and the Sustainable Web Design Model. Hosting status was checked through the Green Web Foundation's Greencheck service. These tools provide estimates and comparison points rather than an exact measurement of every visitor's electricity use.

Read the Website Carbon methodology · Read the Sustainable Web Design Model · Read about the Greencheck API