How to build a CO2-friendly website

A CO2-friendly website reduces unnecessary data transfer and computation. It sends less data, does less unnecessary work, loads faster, and is easier to maintain. That makes it better for users and for the infrastructure behind the site.

The practical path is not to chase a perfect sustainability badge. It is to reduce waste in the parts of the site people actually use: images, scripts, hosting, caching, content structure, backend work, and now AI-powered features.

Why website efficiency matters

Websites use energy through servers, networks, and user devices. The more data a page transfers and the more work it makes the browser do, the more resource-intensive the experience becomes.

Efficiency has practical business value too. Efficient pages load faster on mobile, behave more predictably, and are easier to keep stable. That connects directly to performance and Core Web Vitals. The current W3C Web Sustainability Guidelines treat performance, infrastructure, content, and AI as related parts of digital sustainability.

Best practices for a CO2-friendly website

1. Choose efficient hosting

Hosting matters, but do not treat it as a magic fix. Prefer providers with transparent infrastructure, sensible data-centre locations, good caching options, current PHP/runtime support, and clear operational controls.

Delivery path matters. Choose infrastructure near the audience when practical, and use a CDN or edge cache to reduce latency and repeated origin work. These measures help, but the page itself still needs to be efficient.

2. Reduce page weight

The fastest and cleanest request is the one you do not need to make. Keep templates simple, remove unused CSS and JavaScript, and avoid heavy libraries for small interactions.

• Remove unused scripts and plugins
• Keep CSS focused on what the page needs
• Avoid autoplay video and oversized background media
• Use system features before adding heavy JavaScript

3. Optimise images and media

Images are often the biggest avoidable weight on a small business website. Use appropriate dimensions, compression, lazy loading for offscreen images, and modern formats where the platform supports them.

On product pages, portfolios, service pages, and case studies, images often have real value. The goal is not to remove useful images, but to serve the right size at the right time.

4. Implement caching and efficient backend code

Caching reduces repeated work. It can help with static assets, public pages, API responses, database lookups, and generated HTML. The right cache depends on the site: WordPress, Laravel, Astro, custom PHP, and ecommerce flows all need different rules.

Backend efficiency matters as much as frontend weight. Slow database queries, repeated API calls, and fragile plugin stacks create waste even when the visible page looks simple.

5. Keep design and content focused

A focused page is easier to read and more efficient to deliver. Clear headings, direct copy, useful internal links, and fewer decorative sections usually improve both usability and page weight.

This overlaps with broader website optimisation: an efficient page often performs better, converts more clearly, and needs less maintenance.

6. Reduce third-party scripts

Analytics, chat widgets, tracking pixels, maps, embeds, and marketing tools can make a small site heavy. Keep only what is needed and load scripts in a way that does not block the main content.

Measure the effect before and after. A script that does not support a real business decision may not deserve to run on every page.

7. Measure page weight and performance

Carbon calculators can be useful as rough indicators, but treat them as estimates. For practical work, also measure transferred bytes, requests, render-blocking resources, Core Web Vitals, cache hit rates, and pages that are unusually heavy.

Traffic now includes automated clients as well as people. Google says its AI search features use the normal Googlebot controls, while services such as Anthropic and Perplexity document different bots for different purposes. Lightweight, cacheable HTML and fast responses reduce repeated origin work for any legitimate visitor. Use robots.txt, verified bot rules, and rate limits to control unwanted traffic rather than assuming every AI product accesses a site in the same way.

The article on website analysis explains how those signals connect to real improvements.

AI and sustainable websites

AI has added another layer to sustainable web development. A normal page request may involve a cached HTML file and a few static assets. An AI interaction may also start model inference, retrieval, database searches, API calls, and the generation of a new response. The exact energy use varies by model, task, infrastructure, and response size, so simple claims about the footprint of one prompt are rarely useful. The important question is how often the work runs and whether it creates enough value to justify that work.

The International Energy Agency’s analysis of energy and AI makes the broader trade-off clear: individual tasks are becoming more efficient, but rapidly growing usage still increases total data-centre demand. Text generation, extended reasoning, image generation, video, and agentic workflows also have different requirements. Treating every AI call as equivalent hides the decisions developers can actually control.

Consider when the AI work happens

• During development: A coding or editorial assistant runs while the site is being created. The output can be reviewed, improved, and shipped as ordinary code or content.
• At build time: Summaries, translations, or metadata are generated once and stored with the built site. Visitors reuse the result without starting another model request.
• On a page request: Server-side generation runs whenever a page is requested, unless the result is cached. Traffic therefore increases the amount of computation.
• On every interaction: Chatbots, recommendations, and agentic tools can trigger several model and API calls during one visit. This needs the clearest user value and the closest measurement.

Development-time and build-time AI are not impact-free, but their cost can be shared across many visits. Runtime AI repeats work. Cache safe responses, store reusable results, and do not regenerate content merely because the technology makes it possible.

Use static-first delivery where it fits

Static Site Generation creates reusable HTML at build time. A CDN can then serve that HTML close to visitors without rendering the page again at the origin. Frameworks such as Astro make this a practical default while still allowing server-side rendering for account data, live inventory, checkout, or other genuinely dynamic features.

A static website is not automatically green. It can still ship oversized media, excessive client-side JavaScript, or unnecessary third-party code. Static-first architecture is useful because it removes repeated server work; it does not remove the need to optimise what is delivered.

Use AI to remove work, not create it

Responsible AI can help find inaccessible markup, draft alt text for human review, detect duplicate content, assist translation, explain code, or identify optimisation opportunities. Conventional tools should still handle deterministic jobs such as image resizing, compression, linting, and caching when they can do so more predictably and cheaply.

Poor uses include rewriting a stable page on every request, opening a chatbot before a visitor asks for help, generating decorative images with no clear purpose, or producing hundreds of search pages nobody needs. These features add computation, maintenance, and editorial risk without necessarily improving the experience.

Before adding runtime AI, ask:

• Does the visitor need AI for this task?
• Could clearer navigation, conventional search, filters, or a maintained FAQ solve it?
• Can the result be generated once and reused?
• What usage, quality, or business measure will show that the feature is worthwhile?

AI can support faster development and better optimisation, but those benefits are not automatic. Review generated code, verify generated content, and measure the implementation that reaches users. A feature is only an improvement when the result is useful, accessible, maintainable, and proportionate to the resources it consumes.

A practical AI sustainability checklist

• Prefer development-time or build-time AI to per-request generation
• Cache safe AI responses and reuse generated results
• Keep prompts, context, responses, and model choice proportionate to the task
• Do not generate text or images unless they serve a real purpose
• Measure usage, latency, cost, cache hits, and user value
• Review AI-generated code and content before publishing
• Remove AI functionality that is unused or does not solve the intended problem

Common Mistakes to Avoid

• Overloading with unnecessary libraries or plugins.
• Auto-playing background videos or high-bitrate animations.
• Ignoring caching or CDN implementation.
• Using “green hosting” as an excuse for heavy pages.
• Uploading uncompressed or oversized media assets.
• Running AI on every request when a stored or deterministic result would work.
• Publishing unreviewed, automatically generated pages that have no clear audience.

Frequently Asked Questions

Why does a website have a carbon footprint?

Delivering content uses servers, networks, and user devices. The impact depends on how much data is transferred, how much work the browser and backend do, and how the infrastructure is powered.

What is the best place to start?

Start with the heaviest pages and the pages that get real traffic. Reduce unnecessary scripts, optimise images, improve caching, and simplify templates before worrying about small cosmetic details.

Is a CDN necessary?

Not always, but it is often useful. A CDN can improve delivery and reduce origin load, especially when visitors are spread across regions. It does not replace efficient pages.

Is dark mode always more sustainable?

No. It depends on device, screen type, design, and user behaviour. Dark mode can be useful for accessibility and preference, but it should not be the main sustainability strategy.

Does using AI make a website unsustainable?

Not by itself. The impact depends on the task, model, frequency, surrounding infrastructure, and value created. Occasional build-time assistance is different from several model calls during every visit. Start with the simplest solution that meets the need, then measure any runtime AI you add.

Final thoughts

A CO2-friendly website is mostly the result of good technical decisions: fewer wasted bytes, fewer unnecessary scripts, efficient hosting, sensible caching, optimised images, maintainable code, and AI used only where it earns its ongoing cost.

The greenest website is not necessarily the one with the fewest features. It is the one where every feature has a clear purpose and uses resources in proportion to the value it provides.

If your website feels heavy or wasteful, I can review the practical improvements and identify useful next steps. Send me the URL and what you want to improve.