Every page that gets delivered consumes energy - in the data center, across the network and on the visitor's device. And wherever energy flows, CO2 is produced. According to the model calculation in the HTTP Archive Web Almanac (2024), a single page view emits a median of around 0.33 grams of CO2 on mobile (HTTP Archive Web Almanac, 2024). That sounds tiny - but scaled to millions of views a month it becomes a measurable figure. The good news: the very factors that make a page heavy and slow also drive its energy demand. Whoever slims down images, reduces JavaScript and caches efficiently cuts loading time and CO2 footprint at once, while improving the Core Web Vitals. This article connects the digital footprint with concrete performance levers and places the new framework of ISO/IEC TS 20125 and the CSRD in context.
Key takeaways
- A mobile page view causes a median of about 0.33 grams of CO2 (HTTP Archive Web Almanac, 2024); the German electricity mix stood at 363 grams of CO2 per kilowatt-hour in 2024 (Umweltbundesamt), and data centres consumed 20 billion kilowatt-hours (Bitkom).
- Images account for 69.6 percent of page emissions, JavaScript for 20.8 percent, and fonts, CSS and HTML together for under 10 percent (HTTP Archive Web Almanac, 2024). Median mobile page weight is 2.0 megabytes against a target corridor of 500 kilobytes.
- Image potential is largely untapped: only 12 percent (HTTP Archive Web Almanac, 2024) of images ship as WebP, 1 percent as AVIF, 42.4 percent of pages use srcset and 34 percent use native lazy loading (HTTP Archive Web Almanac, 2024).
- JavaScript costs twice – transfer over the network and processing time on the device. At the 90th percentile, mobile pages carry around 812 kilobytes of unused JavaScript (HTTP Archive Web Almanac, 2024), which a coverage analysis makes visible.
- Caching shortens response time and saves repeated computation in the data centre. Efficiency gaps there are wide: the least efficient data centre studied emitted ten times more greenhouse gases per compute operation (Umweltbundesamt).
- Published on 27 February 2026, ISO/IEC TS 20125-1:2026 (ISO) describes ecopractices for the ecodesign of digital services, while the CSRD requires disclosure of indirect emissions via ESRS E1. Emissions per page view thus become a reportable figure.
The digital footprint: why every page costs energy
Behind every website sits physical infrastructure that draws power. The electricity consumption of data centers in Germany reached around 20 billion kilowatt-hours in 2024 - in 2014 it was still 12 billion (Bitkom). For 2025 the survey already reports 21.3 billion kilowatt-hours, and on a linear projection demand rises to about 31 billion kilowatt-hours by 2030 (Bitkom). In a survey, 80 percent of operators expect the increased use of artificial intelligence to push consumption further (Bitkom). These figures make one thing clear: digital services are anything but immaterial.
Electricity turns into CO2, and today in a quantifiable amount. For each kilowatt-hour of electricity consumed in Germany, generation emitted an average of 363 grams of CO2 in 2024; in 2023 the figure was 386 and in 2022 it was 433 grams (Umweltbundesamt). So the power mix is getting greener - yet rising demand eats up part of that progress. Globally, data centers consumed between 200 and 1,000 terawatt-hours in 2020 according to an evaluation of various studies, corresponding to roughly 100 to 500 million tonnes of CO2 equivalents (Umweltbundesamt). The wide range shows how uncertain global estimates are - the direction, however, is unambiguous.
Three places where a page consumes energy
From byte to gram: how web emissions are estimated
To estimate a website's emissions, the open Sustainable Web Design Model (SWD) has become established. It converts the transferred data volume into a CO2 figure per page view via assumptions about data center, network and device. The HTTP Archive Web Almanac applies this model to millions of real pages. The result for 2024: at the median a mobile page view emits 0.33 grams of CO2, and 0.37 grams on desktop (HTTP Archive Web Almanac, 2024). At the top end, the 90th percentile, it is already 1.36 grams on mobile and 1.47 grams on desktop (HTTP Archive Web Almanac, 2024). The main driver behind this is page weight: the median is around 2.0 megabytes on mobile, while the model recommends an upper limit of 1 megabyte and a target corridor around 500 kilobytes (HTTP Archive Web Almanac, 2024).
A worked example for the order of magnitude
What matters is how that weight is split across the resource types, because not all contribute equally to emissions. The following breakdown comes from the Sustainable Web Design model at the 90th percentile and shows where the lever is greatest - the same order is familiar to any structured Lighthouse audit from practice.
| Resource type | Share of emissions | Typical measure | Effect on the vitals |
|---|---|---|---|
| Images | 69.6 percent (HTTP Archive) | Modern formats, responsive sizes, lazy loading | LCP, CLS |
| JavaScript | 20.8 percent (HTTP Archive) | Code splitting, remove unused code | INP, LCP |
| Fonts | 4.8 percent (HTTP Archive) | Subsetting, WOFF2, font-display | LCP, CLS |
| CSS | 3.1 percent (HTTP Archive) | Critical CSS, remove unused rules | LCP |
| HTML | 1.7 percent (HTTP Archive) | Compression, clean delivery | LCP, TTFB |
Image weight: the single biggest lever
Images are by far the largest item for both loading time and emissions. In the model they account for 69.6 percent of page emissions at the 90th percentile (HTTP Archive Web Almanac, 2024), and on the typical mobile homepage images alone load around 900 kilobytes - more than any other resource type (HTTP Archive Web Almanac, 2024). This is exactly where the savings potential is greatest, and it costs no functionality: an image in a modern format and the right size looks identical yet weighs a fraction.
It is striking how much potential still lies idle. According to the HTTP Archive field data, only 42.4 percent of pages use responsive images via the srcset attribute, and just 34 percent employ native lazy loading (HTTP Archive Web Almanac, 2024). On formats the gap is even wider: merely 12 percent of images are delivered as WebP and just 1 percent as AVIF (HTTP Archive Web Almanac, 2024). Whoever tackles this cuts weight and emissions at once - the article on image optimization with WebP and AVIF describes the technique in detail.
Modern formats
WebP and AVIF compress far more strongly than older formats at comparable quality. Since only 12 percent of images are delivered as WebP (HTTP Archive), switching is one of the fastest wins for weight and CO2.
Responsive sizes
With srcset every device gets exactly the resolution it needs - no 2000-pixel image on a smartphone display. That saves bytes without hurting the presentation and stabilises the layout at the same time.
Lazy loading
Images outside the viewport load only when the user reaches them. This relieves the initial loading path and prevents energy being spent on content that many visitors never see.
Image optimization is thus the model case for the double benefit: it improves Largest Contentful Paint and layout stability while reducing the largest emission block. In image optimization we weigh quality, format and delivery against each other, rather than cranking up compression across the board and accepting visible artefacts.
Reducing JavaScript and third-party ballast
After images, JavaScript is the second-largest emission block - 20.8 percent at the 90th percentile in the model (HTTP Archive Web Almanac, 2024). The median mobile JavaScript payload is 558 kilobytes, and 613 kilobytes on desktop (HTTP Archive Web Almanac, 2024). JavaScript is doubly expensive: it has to be transferred - costing energy on the network - and it has to be parsed and executed on the device, which additionally consumes compute time and therefore power. Unlike an image, script code burdens not only the line but also the user's processor.
Unused code is especially frustrating. At the 90th percentile, mobile pages carry around 812 kilobytes of unused JavaScript and 212 kilobytes of unused CSS (HTTP Archive Web Almanac, 2024) - bytes that are transferred and partly executed without serving any purpose. Third-party scripts sharpen the picture further because their behavior is hard to control. How to reduce this load systematically is shown in the articles on trimming third-party scripts and on JavaScript performance budgets.
- Track down and remove unused JavaScript and CSS via a coverage analysis
- Split code so each page loads only what it actually needs
- Load non-critical scripts with defer or only after the first interaction
- Inventory third-party tags and drop those without a nameable purpose
- Set a performance budget for the delivered JavaScript volume and check it at deployment
Every kilobyte of script saved works twice: it lowers the energy for transfer and execution and relieves the main thread, which directly improves Interaction to Next Paint. It is precisely this connection that makes frontend optimization a measure that addresses sustainability and responsiveness in a single step.
Data center, caching and efficient delivery
It is not only what goes to the browser that counts - how the page is generated has an energy price too. If every request is computed from scratch, the database and application server work anew on each call. Efficient caching serves finished results instead and saves the repeated computation. That lowers both the server response time (TTFB) and the load in the data center. How to combine cache layers sensibly is covered in the article on caching strategies; the server-side foundation for it is laid by a targeted server optimization.
How large the efficiency differences within the data center can be is shown by a study using the KPI4DCE methodology: in the least efficient of three examined data centers, ten times more greenhouse gases were emitted per compute operation than necessary (Umweltbundesamt). Choosing an efficient operator and a power-saving architecture is therefore a real lever. At the same time, green hosting is still spreading slowly: according to the HTTP Archive Web Almanac (2024), only 10 percent of mobile-delivered pages run on servers rated as green, while among the largest websites it is already more than half (HTTP Archive Web Almanac, 2024).
Caching works in both directions
Why performance and CO2 pursue the same goal
The common thread of this article is the congruence of the levers. Fewer bytes, less JavaScript and efficient caching cut energy demand and improve the Core Web Vitals at the same time. This is no coincidence but follows from the shared cause: both the emission and the perceived speed depend on how much has to be transferred, processed and rendered. A light page is therefore almost always a fast page - and vice versa.
On the web, sustainability and speed are not competing goals but two sides of the same optimization. Whoever removes ballast wins both at once: a more responsive page and a smaller footprint.
Faster vitals
Smaller images and less script code improve LCP and INP directly. The page responds to input sooner and renders content faster - which acts straight on perception and conversion.
Lower emissions
The same saved bytes reduce energy at all three stations: data center, network and device. The CO2 figure per page view falls without any loss of functionality.
Lower costs
Less transferred data means lower bandwidth and compute load. Efficiency thus also cuts operating expense - sustainability and economy point in the same direction.
That speed pays off economically is well documented - the article on loading time, conversion rate and revenue deepens this link. And whoever prepares navigations in advance rather than loading resources twice also works more efficiently, as the article on speculation rules for instant navigation shows. The connection of efficiency, speed and emission savings sits at the heart of any sustainable performance service.
ISO 20125 and CSRD: the regulatory framework
Sustainable software design is now standardised. With ISO/IEC TS 20125-1:2026, a Technical Specification on the ecodesign of digital services was published on 27 February 2026 - Part 1 is titled Ecopractices for life cycle stages and describes practices for reducing the environmental impact of a digital service across its life cycle (ISO). The specification is deliberately worded independently of methodology and applies to classic as well as agile development processes (ISO). It thus provides, for the first time, an internationally agreed frame of reference for what performance optimization does anyway in practice: avoid ballast and use resources efficiently.
At the same time, reporting pressure is rising. The European Corporate Sustainability Reporting Directive (CSRD) requires a growing circle of companies to disclose their environmental impacts along the value chain; the associated climate standard ESRS E1 also addresses indirect emissions from purchased digital services (Scope 3). Websites and online services are part of this chain. A robustly low emission value per page view is therefore not just a quality feature but increasingly a reporting-relevant metric - and an argument in the competition for environmentally conscious customers.
What this means for operators
Anchoring sustainability in operations for the long term
A page slimmed down once does not stay light by itself. New campaigns bring new scripts, uncompressed images creep into editorial workflows, and over time the weight grows again. That is why efficiency belongs in a recurring process rather than a one-off project. A performance budget sets upper limits for page weight and JavaScript that are checked at every deployment; real user monitoring watches the vitals in the field so that regressions surface early.
- Budget page weight and JavaScript volume per template and check them automatically
- Deliver images in modern formats, responsively and with lazy loading as standard
- Regularly track down and remove unused code
- Establish caching and efficient delivery as the standard, not the exception
- Measure the emission value per page view and document it alongside the Core Web Vitals
- Factor hosting efficiency and the operator's power mix into the selection
The starting point is a stocktake that considers loading time and emissions in one step. Our performance analysis surfaces exactly the ballast that costs speed and causes CO2 at the same time, and prioritizes the measures by impact. Comparable starting situations meet us across industries - from the corporate website to the online shop, as the references show. The result is a page that loads faster, consumes less and stands up to the requirements of standard and reporting duty.