Website Carbon: Digital Sustainability and CSRD in 2026

Why Digital Sustainability Reaches the Agenda in 2026

For a long time the internet's energy use felt like a distant, abstract problem. The numbers have since become concrete. According to the Green Web Foundation, the information and communications technology sector causes roughly 1.8 to 2.8 percent of global greenhouse gas emissions, and up to 3.9 percent by upper estimates (The Green Web Foundation). Data centres alone consumed around 415 terawatt hours of electricity in 2024, about 1.5 percent of global electricity use, growing at roughly 12 percent per year over the past five years (IEA).

What raises the pressure is regulation. Through the Corporate Sustainability Reporting Directive, the EU requires large companies to disclose their climate impact in a structured way. The first wave-1 reports were published in 2025 for financial year 2024 (European Commission). And because the obligation covers the value chain, digital services - hosting, cloud, content delivery - fall into what is known as Scope 3 emissions. This turns your own website from a pure marketing instrument into a line item that at least needs to be roughly placed.

How an Estimation Model Turns Transferred Bytes Into Grams of CO2

The starting point of every serious estimate is an uncomfortable truth: nobody can measure the exact emissions of a single page load. There is no electricity meter uniquely assigned to an individual user. That is why the established approaches work with a proxy - a well-measurable stand-in quantity. The Sustainable Web Design Model uses the volume of data transferred as its central proxy for a page's energy use (Sustainable Web Design Model). The logic: more bytes mean more work for data centres, networks and end devices, and therefore more electricity.

In the current version 4 of the model, the energy demand per transferred gigabyte is split across three system segments: about 0.055 kWh for data centres, 0.059 kWh for network transmission and 0.080 kWh for users' end devices, totalling 0.194 kWh per gigabyte (Sustainable Web Design Model). Multiplying this energy demand by the average carbon intensity of the electricity grid - 494 grams of CO2e per kilowatt hour based on global grid data in the model (Sustainable Web Design Model) - yields an emissions estimate in grams of CO2e.

It is important to understand that this is a model, not a measurement. When the Green Web Foundation revised the model to version 4 in 2024, the estimated footprints came out 40 to 50 percent lower than before (The Green Web Foundation). The same page that scored 1.42 grams of CO2e under the old model computes to 0.781 grams under the new one (The Green Web Foundation). The page's reality did not change - only the assumptions did. That is precisely why absolute figures should be treated with caution, while the relative development over time remains meaningful.

Page Weight: The Sobering Numbers From the Real Web

If transferred bytes are the central lever, it is worth looking at how heavy websites have actually become. The Web Almanac by HTTP Archive measures this annually across millions of real pages. In October 2024, the median page weight was 2,652 kilobytes on desktop and 2,311 kilobytes on mobile (HTTP Archive). An average page therefore transfers roughly 2.3 to 2.6 megabytes - per load.

The long-term trend is clear and heading in the wrong direction. Ten years earlier, in October 2014, the median mobile page weight was still 505 kilobytes (HTTP Archive). It has therefore more than quadrupled in a decade. This growth is driven mainly by uncompressed images, extensive JavaScript and a growing number of embedded third-party scripts. Each of these ingredients increases the volume of data transferred and thus the estimated carbon proxy.

A Worked Example: From Transfer to Emissions Estimate

Let us run the numbers on an average page. A desktop load transfers 2,652 kilobytes at the median, that is about 0.00265 gigabytes (HTTP Archive). Multiplied by the energy intensity of 0.194 kWh per gigabyte, that comes to roughly 0.000514 kilowatt hours per load (Sustainable Web Design Model). This energy multiplied by the grid intensity of 494 grams of CO2e per kilowatt hour yields an estimate of about 0.25 grams of CO2e for a single, complete page load (Sustainable Web Design Model).

1. Capture the transfer: 2,652 KB corresponds to about 0.00265 GB of data transferred per load (HTTP Archive).
2. Convert to energy: 0.00265 GB multiplied by 0.194 kWh/GB yields about 0.000514 kWh (Sustainable Web Design Model).
3. Convert to emissions: 0.000514 kWh multiplied by 494 g CO2e/kWh yields about 0.25 g CO2e per load (Sustainable Web Design Model).
4. Extrapolate: At 100,000 loads per month this adds up to roughly 25 kilograms of CO2e - a rough order of magnitude, not an exact figure.

Why Heavy Pages Cost Twice: Energy and Load Time

The real reason the topic is practically relevant for operators lies not in the climate balance alone. The very bytes that push the estimated carbon proxy up also slow the page down. A megabyte that is not transferred costs neither energy nor extra load time. Here, sustainability and performance point in the same direction - a rare but welcome alignment of goals.

Because both goals rest on the same metric, it pays to treat page weight as a fixed budget - just as one continuously optimises Core Web Vitals and sets up a performance budget for Web Vitals. A defined transfer budget per page type makes regressions visible before they become habit.

CSRD, ESRS E1 and Scope 3: Where Digital Services Belong

For its substantive disclosures, the CSRD refers to the European Sustainability Reporting Standards. The ESRS E1 standard covers climate change and requires, among other things, the disclosure of greenhouse gas emissions across the three familiar scopes. Scope 1 captures direct emissions, Scope 2 purchased energy, and Scope 3 the remaining value chain. It is precisely in Scope 3 that purchased digital services such as hosting, cloud resources and content delivery fall.

The regulatory framework, however, is in motion. With the so-called Omnibus package, published in the Official Journal of the EU in February 2026 (European Commission), timelines and scope were adjusted. For wave-2 companies, a stop-the-clock measure pushed the first reporting obligation back by two years - from originally 2026 to an expected 2028 for financial year 2027 (European Commission). At the same time, the obligation is set to apply mainly to companies with more than 1,000 employees and over 450 million euros in net turnover (European Commission).

Companies that are not directly obligated themselves feel the effect too. As a supplier or service provider to a reporting group, they are indirectly drawn in via that group's Scope 3 requests. An agency running websites, or a shop supplying a large retailer, is therefore well advised to keep its own digital metrics cleanly documented.

Staying Honest: An Approximation, Not a Certified Account

The most important sentence in this article is also the most inconvenient: a website carbon value computed via an estimation model is an approximation, not an audited account. Writing it into a sustainability report as an exact figure overstretches its meaning. The Green Web Foundation itself, with the jump from version 3 to version 4, makes clear how strongly the results depend on the underlying assumptions (The Green Web Foundation).

An estimation model does not replace a life-cycle assessment. But it makes visible and steerable a quantity that otherwise stays hidden - the weight of your own pages. For internal steering, that is exactly the point: not the third decimal place, but the direction.

— XICTRAQ editorial team (project experience)

• Model dependence: Absolute gram values shift with every model version, as the 40 to 50 percent jump from version 3 to 4 shows (The Green Web Foundation).
• Cache and return visits: Returning visitors load less data. A pure first load overestimates the average burden.
• Electricity mix: The global average of 494 g CO2e/kWh (Sustainable Web Design Model) matches a specific region and time of day only approximately.
• Green hosting: Server electricity from renewable sources lowers part of the calculation, but not the network and end-device shares.
• System boundaries: Device manufacturing, office operations and other indirect effects remain out of scope.

These limits are not an argument against measuring, but for the right expectation. As a steering quantity within your own organisation, transfer size is excellent. As an attested figure for an external report, it takes additional diligence, clear methodological documentation and often professional guidance.

Page Weight and Transfer Bytes as Steerable Levers

The practical consequence of all this is pleasingly simple: whoever has the transferred bytes under control improves load time and carbon proxy in one move. Unlike many sustainability topics, this requires no major investment, but consistent technical discipline in familiar places.

• Define a transfer budget per page type and treat overruns as a regression, just like a Web Vitals budget.
• Deliver images modernly in WebP or AVIF, responsively via srcset and with lazy loading below the fold.
• Reduce JavaScript by removing unused code, code splitting and critically reviewing every third-party script.
• Compression and caching with Brotli or gzip plus sensible cache headers, so returning visitors transfer less.
• Shorten delivery paths via a content delivery network that serves content closer to the user.
• Inventory third-party scripts, because unknown scripts are not just byte ballast but also a client-side security risk, as PCI DSS 4.0.1 for payment pages shows.

Tracking the Same Metrics Over Time

A single measurement is a snapshot. Page weight only becomes meaningful as a time series: a new campaign script, an uncompressed image upload or a theme update can push transfer size up unnoticed. This is exactly where continuous monitoring comes in - it measures the same metrics again and again and makes changes visible before they take hold.

XICTRAQ's browser monitoring loads your pages regularly in a real browser and captures page weight, transfer bytes and load times over time - precisely the quantities that determine both performance and the digital carbon proxy. Combined with performance and uptime monitoring and automated reports and status pages, this builds a solid history from which trends and regressions can be read.

Want to keep an eye on your website's page weight over time? Take a look at browser monitoring in the live demo or try XICTRAQ for free and set a transfer budget for your most important pages - as a basis for faster load times and an honest, traceable placement of your digital footprint.