What World Environment Day means for the digital projects you are building right now

Every year, World Environment Day passes through the industry calendar, statements get published and commitments get restated, and then the sprint board fills back up and the digital projects continue exactly as before. 

That cycle is worth breaking this year. Not because the commitments are insincere, but because the decisions with the most environmental impact in digital are not made in sustainability reports. They are made in project briefs, platform selection meetings, and architecture reviews. Most of them are made without any carbon consideration at all. 

The full picture 

Digital technology now accounts for between 1.5 and 4 per cent of global greenhouse gas emissions, roughly equivalent to the entire aviation industry. The environmental cost sits across three interconnected system segments: data centres, networks, and end user devices. According to the Sustainable Web Design Model, the current breakdown of allocated energy across those segments is 22% for data centres, 24% for networks, and 54% for end user devices. 

On top of those operational emissions, the manufacturing and disposal of devices adds a further layer. And with AI now embedded in almost every digital platform, inference workloads are adding a new and largely unmeasured cost on top of the existing baseline. 

That is the full scope of the problem — larger than any one agency or client project can address in isolation. 

This post does not attempt to cover all of it. It focuses on three areas where the decisions made during a digital project have a direct and measurable impact: hosting and infrastructure, web performance, and AI integration. Other areas matter too, but these three are where an agency and its clients have genuine control. 

Hosting and infrastructure 

Every page your website serves is delivered from a data centre, and every data centre draws power. Where that power comes from is set by your infrastructure and platform choices, frequently before anyone weighs the carbon cost. 

Cloud providers vary significantly on renewable energy commitments and the transparency of their reporting. Microsoft Azure, Google Cloud, and AWS all publish carbon and energy data, but the figures are not equivalent and the region your workload runs in matters. A UK South deployment has a different carbon profile to one running in a region with a higher fossil fuel dependency. 

This is a procurement question as much as a technical one. When you are selecting a platform, hosting provider, or cloud region, the carbon profile of that infrastructure is a legitimate evaluation criterion. For most organisations, it is currently invisible. 

Data centres can account for more than half of an enterprise's digital carbon footprint. The practical starting point is your existing platform. Do you know which region your workload runs in? Do you know your provider's renewable energy position? For many clients, the answer to both questions is no.  

Web performance 

Web performance and carbon efficiency are the same problem viewed from different angles. 

A page that loads fast does less work. Less work means fewer server cycles, less data transferred, less energy consumed on both the server and the end user's device. A page bloated with unoptimised images, redundant JavaScript, and a pile-up of third-party tags is slow to load and expensive to serve, and it pays that cost on every request for as long as the site is live. 

The numbers compound quickly. Over the last ten years, the median weight of web pages has increased by 210% on desktop and 594% on mobile. At scale, that growth in data transfer is a primary driver of unsustainable device turnover as well as energy consumption. 

Core Web Vitals are how you measure this. Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint aren't only SEO numbers; they tell you how efficiently your site does its job, and a site that scores well is doing less unnecessary work. 

A handful of areas move the needle most: image format and compression, JavaScript bundle size, third-party scripts, and font loading. None require a platform rebuild, and most fit inside a standard delivery sprint. 

AI integration 

AI is now a standard component of digital platform builds, shipped into CMS platforms by default and requested by clients in their briefs. Whether AI features will appear in your projects is no longer the question; whether the teams building them understand the carbon cost of running them is. 

The scale of the problem is specific. Over 80% of AI electricity consumption comes from the use phase, inference on live systems, not the headline training runs that dominate coverage. The most energy-intensive models exceed 29 watt-hours per long prompt, more than 65 times the most efficient alternatives. By 2030, global electricity demand from data centres is projected to more than double to around 945 terawatt-hours, with 60% of that growth met by fossil fuels. 

The decisions that control this are architectural, not ethical. Which model tier does the task actually require? Are agent responses being cached, or does every request hit the model fresh? Are AI tools returning the minimum data needed, or full API responses that flood the model with tokens it does not need? 

These are solvable problems. They require deliberate design decisions at the point where the AI integration is built, not retrospective reporting. Architects and developers working on AI-integrated platforms have more control over the carbon cost of those platforms than anyone else in the project team. 

The question to ask before the next project starts 

World Environment Day is a useful forcing function, creating a moment to ask questions that do not naturally surface in a project kickoff. 

The questions are not complicated. Where does this platform run, and what is the carbon profile of that infrastructure? What is the current performance baseline, and what would a meaningful page weight reduction require? Does this AI feature need the model tier we have defaulted to, and are we caching responses? 

None of these questions require a specialist sustainability consultant. They require the people already in the room to treat carbon as a design constraint alongside performance, security, and cost. 

At MSQ DX, we build this thinking into how we approach platform and architecture decisions. World Environment Day is a good moment to make that visible. The rest of the year is where it actually matters.