From F to A: the Choices Behind a More Sustainable Website

Our vision for the site

We gave ourselves a brief with two halves that were equally important.

First, the site had to show what we do. We're a creative technology studio, so our website is also our shop window - it needs to feel crafted, expressive and ambitious, not a stripped-back compromise.

Second, it had to be built within constraints we set for ourselves. Every page should ask as little as possible of the people visiting it: less to download, less code to run, less energy used on their device, across the network and in the data centres serving it.

Our old website scored an F on Website Carbon. The new one, aerstudios.co.uk, averages an A. This article is about the choices behind that change, and why they matter.

Where it started

The thinking behind the build began before the project did.

When Wayne, one of our software engineers, came back from the Web Developer Conference in Bristol in 2025, he wanted to try something. He set himself a challenge to see how much he could build using only what the browser already provides, before turning to JavaScript. He wrote about it in A Journey Towards a More Sustainable Front End, and the result was his side project he called FreeFrom.

That kind of exploration doesn't always have any obvious return at the start, but in this case the payoff came quickly. When we started to build the new website, Wayne already had the ideas, the experiments and the confidence to apply them across an entire site.

Sustainability isn't a badge

It's tempting to think of a "sustainable website" as something you add at the end, like a green-hosting badge, a plugin or a carbon offset. Some of those help - but just as with accessibility, it's wishful thinking. Most of a website's footprint is decided much earlier, in the many small decisions that were made while it's being designed and built.

Take the menu that opens when you tap the icon on a phone. On a lot of websites, that simple action relies on a chunk of code that has to download and start up before the menu works, just so the page can remember whether the menu is open or closed.

The browser can already do that - it knows when a checkbox is ticked, so our menu uses that. There's nothing extra to download, and nothing waiting to start up before you can tap it.

While that example is small, it shows the approach the team took everywhere. Three principles, all drawn from FreeFrom, guided the build:

• Use the platform first. Modern browsers can do far more on their own than they could a few years ago. Start from what they already offer.

• Build less. Get the same result, or a better one, while doing less work.

• Treat every byte as having a cost. Everything we ask a visitor to download has to earn its place.

It started with how the pages are made. The team built the site with Astro, which lets us prepare each page ahead of time instead of assembling it in the visitor's browser on every visit. By the time a page reaches you it's already complete, with less work left for your device to do.

Showcase and constraint: the homepage

The two halves of our brief met head-on on the homepage.

We wanted the homepage to show what a creative technology studio can do. That meant motion: layers moving and shifting as you scroll, each timed to tell part of our story. It's exactly the kind of thing that proves a studio's craft, and exactly the kind of thing that usually adds weight to a website.

There was a quick way to build it. Ready-made animation libraries exist for exactly this, and one of them would have got us close in an afternoon. It would also have meant more code for every visitor to download and run, just to move things around the screen.

The team proposed the slower route: building the motion with the browser's own animation capabilities. That meant a lot of patient fine-tuning to get every movement, delay and speed right. It took longer than the shortcut would have, and we were happy to back that decision.

We didn't want to tone down the design to stay light, and we didn't want to give up on lightness to hit the design quickly. The point of the brief was to do both. For me, this was the clearest test of whether we meant what we'd written down, because a principle only really counts if you keep to it when it's inconvenient.

Built for this site, not for every site

Off-the-shelf themes, page builders and DIY website tools have to work for thousands of different websites. So they usually include every interactive feature they might need, as generic code, whether or not a given page uses it. They're built to work anywhere, not built for you.

The team built our own component library instead: a set of reusable building blocks designed for this site. Before building any interactive piece, they asked what it actually needed to do and what the browser could already handle:

• The testimonials carousel on our About us page moves between quotes with no carousel library behind it.

• The Sectors section uses the browser's built-in expand-and-collapse elements, so keyboard support comes included rather than being rebuilt by hand.

• Our icons all come from shared files that are downloaded once and reused everywhere.

Because these building blocks are reused across the whole site, each light choice gets repeated too. A component that avoids unnecessary code avoids it on every page it appears on. As we add new content and features, the site doesn't get slower each time.

This doesn't stop at launch

A lot of websites are at their best on launch day and slowly get heavier after that. To stop that happening, every proposed change to our site is now automatically checked against the same carbon standard it launched with, before it goes live.

If you're a developer and want to know how that works, and what the trickiest parts of this build actually cost, Wayne will cover it in a technical follow-up article he’s working on titled: What "from F to A" actually took.

Living up to the mission

It's easy to picture a "sustainable website" as a compromise: plainer, less ambitious, less fun. Our new site showed us the opposite. It's expressive where we wanted it to be, it's fast, and it asks your device to do far less than our old one did.

There was much more to this than simply choosing a hosting provider that nodded to their green credentials. It came from a team that kept asking the same questions throughout the delivery process: what does the browser already give us, what does this experience really need, and what are we asking someone to download?

Our mission is to have a positive impact on people and planet. Our own website is where we have the most control over that, so it's where we had to start. It's also the standard we'll bring to every project we take on next.