How we’re building more sustainable websites using the Web Sustainability Guidelines

What are the Web Sustainability Guidelines?

The WSG are a set of guidelines designed to help anyone apply sustainability principles to digital products and services. If you're familiar with the Web Content Accessibility Guidelines (WCAG), you'll find the structure very similar, which is intentional. The WSG were founded on work by the W3C's Web Accessibility Initiative, are evidence-backed, and align with existing reporting standards like the Global Reporting Initiative.

In total, there are four categories, 80 guidelines, and 224 success criteria. That's a lot(!), so it’s worth saying upfront that following every single one probably isn’t realistic. The goal is progress over perfection: start with some small changes and take it from there.

The four categories are:

• User experience: how users interact with the site, the content we choose to include, and accessibility (which overlaps quite a lot with sustainability)
• Web development: page weight, JavaScript, images, templates; the technical side of how a website is built and delivered
• Infrastructure: where the site is hosted and how it's delivered, including CDNs, caching, and data centres
• Business and product: longer-term decisions, like whether a feature is actually needed, and increasingly, the impact of AI usage

For this post, I'm focusing on a few guidelines from the first two categories, and what we're already doing (and could do more of) in our builds.

What we're already doing well

2.11 — Optimise media to reduce resource use

Images are by far the biggest contributor to page weight on the average website. In 2025, the median mobile homepage ships around 900 KB of images compared to around 600 KB of JavaScript and much less for everything else. This makes it one of the highest-impact areas to get right.

In the websites we build, we:

• Serve images in modern formats (like WebP) that reduce file size without losing quality
• Deliver images at the right size for the user’s device (so mobile users aren’t downloading large desktop images)
• Only load images when they’re needed on screen, rather than all at once
• Set image dimensions in advance to avoid layout shifts as the page loads

These defaults already align well with the guidelines.

2.13 — Use optimised and appropriate web typography

Fonts can add a surprising amount of page weight, especially when you're loading multiple weights and styles as separate files.

We reduce this by:

• using variable fonts in efficient formats like WOFF2
• limiting the range of font weights used

This avoids shipping unnecessary font files and keeps things lean, which speeds up page load times.

3.6 — Give third parties the same priority as first parties

Third-party content, like analytics, embeds and widgets is often some of the heaviest stuff on a page, and easy to overlook because we didn't build it. But it still runs on our sites, so it's still our responsibility.

A good example of how we handle this is video embeds. Rather than loading the full player immediately, we show a lightweight placeholder and only load the actual embed when the user interacts with it. This avoids loading a large chunk of JavaScript unnecessarily.

3.12 — Use sustainability-beneficial user preference media queries

Media queries like ‘prefers-reduced-motion’ and ‘prefers-color-scheme’ are often introduced for accessibility reasons, for users who are sensitive to motion, for example. But they also have sustainability benefits:

• reducing animation lowers processing
• dark mode can reduce energy use on certain devices

We use these preferences to adapt the experience based on user or device settings, a low-effort change with meaningful impact.

Other things already in place

There are a number of other WSG guidelines that are often addressed through good engineering practices and sensible defaults:

• Present documents with their file size and type before download (2.17)
• Compress CSS and JS by default (3.2)
• Use a component system to reduce code duplication (3.5)
• Add skip links and correct focus management (3.9)
• Use a full set of structured meta tags (3.11)
• Implement security defaults including CSP, HTTPS, and error monitoring (3.15)
• Use the latest stable versions of your core technologies (3.19)

Individually small, but together they add up.

Where we could do more

3.1 — Set goals based on performance and energy impact

You can't improve what you don't measure, but this is also about defining what "good" looks like in the first place. The WSG encourages setting targets: things like page weight budgets or performance thresholds. Different types of content have very different impacts, JavaScript and video are much heavier than plain HTML or CSS.

We already add sites to DebugBear as part of our launch checklist. Going further means picking something from the data and actively working to improve it, whether that's page weight, number of requests, or a Core Web Vital that's slipped.

3.16 — Use dependencies appropriately

Every dependency has a cost in bytes, processing, and ongoing maintenance. This applies across front-end and back-end code. Over time, projects can accumulate unused or outdated dependencies, which can lead to security vulnerabilities.

The question worth asking regularly is: do we actually need this, or could we solve it more simply? It's a small habit to build into the natural rhythm of a project, the same way we already think about keeping dependencies up to date.

Why Wagtail (and our Charity Blueprint) help

While everything in this post applies broadly, the tools we use make a big difference.

Wagtail and our Charity Blueprint in particular help embed many of these practices by default:

• built-in support for responsive and optimised images
• structured content that encourages reusable patterns
• sensible performance and accessibility defaults
• flexibility to control how content and features are delivered

This means many sustainability best practices are already part of the foundation, rather than something that needs to be retrofitted later.

Final thoughts

The WSG can feel overwhelming at first given the scope of it, but browsing through a category at a time, you'll find a lot of it maps to things that are already considered good practice. The sustainability framing just makes those reasons more explicit.

As we continue to build and evolve websites, the WSG provides a useful framework to keep returning to, helping us make more intentional decisions over time.