I get this question at least once a week from clients: "Our leadership team wants to know our website's carbon footprint. Where do we even start?" It is a reasonable question with a slightly uncomfortable answer — the methodology is not perfect, but it is good enough to identify problems and measure progress. And the fixes that reduce carbon also make your site faster, which makes everyone happy.
What Creates Carbon Emissions From a Website?
Every time someone loads a page on your website, a chain of energy consumption occurs. The data center serving your content uses electricity to run and cool servers. The network infrastructure — routers, switches, cables, cell towers — consumes energy to transmit data. And the user's device — laptop, phone, tablet — uses electricity to receive, process, and display the page.
The Sustainable Web Design (SWD) model, now in version 4, breaks this down into segments: data centers account for about 15% of total energy, networks about 14%, and end-user devices about 52%, with production energy (manufacturing of infrastructure) making up the remaining 19%.
The key variable you can directly control is data transfer — the total weight of your pages in bytes. Heavier pages require more energy at every stage of the chain. A page that transfers 3MB produces roughly 6x the emissions of a page that transfers 500KB. This is not a linear relationship (there are fixed energy costs regardless of page weight), but page weight is the strongest lever you have.
How to Measure: Tools and Methodology
Several tools can estimate your website's carbon emissions. They all follow roughly the same methodology but make different assumptions, which is why results vary between tools.
The Measurement Process
Most carbon measurement tools work like this: they load your page (or use cached data about page weight), measure the total data transferred, apply the SWD model to convert bytes to kWh, multiply by a carbon intensity factor (grams CO2 per kWh) — either a global average or a location-specific figure, and express the result as grams CO2 per page view.
To estimate annual emissions, multiply by your annual page views. A site with 100,000 monthly page views and 0.8g CO2 per page view produces about 960 kg CO2 per year — roughly equivalent to a round-trip flight from London to Madrid.
Recommended Tools
Carbon Badge Scanner: Our own tool at /scan measures real-time per-page emissions and lets you display a public badge. Useful for ongoing monitoring and transparency.
Website Carbon Calculator (v4): The most widely referenced tool. Uses the SWD model with global average grid carbon intensity. Good for benchmarking.
Ecograder: Combines carbon measurement with performance and UX recommendations. Useful if you want a combined improvement roadmap.
Beacon by Mightybytes: Open-source, uses the CO2.js library with configurable grid intensity. Best for developers who want control over assumptions.
Digital Carbon Online: Maps carbon by page type across an entire site. Best for large sites where different sections have different footprints.
What the Numbers Mean
Benchmarks for 2026: under 0.5g CO2 per page view is excellent (cleaner than 80%+ of websites). Between 0.5g and 1.5g is average. Above 1.5g indicates significant optimization opportunities. Above 3g suggests fundamental architectural issues — heavy video, excessive scripts, unoptimized everything.
But raw grams per page view is only half the story. A page with 0.3g per view but 10 million monthly views produces more total emissions than a page with 2g per view and 1,000 monthly views. Both per-page efficiency and total traffic volume matter.
The Quick Wins: What to Fix First
After measuring hundreds of websites, I can tell you that the same issues come up again and again. Fix these first — they typically deliver 50-70% of the total possible reduction.
Images
Unoptimized images are the single biggest source of page weight on most sites. The fix is usually straightforward:
Convert to modern formats — WebP gives 25-35% smaller files than JPEG with equivalent quality. AVIF is even smaller but browser support is still catching up. Implement responsive images with srcset so mobile users do not download desktop-sized images. Use lazy loading (loading="lazy") for images below the fold. Compress properly — most images look identical at 80% quality vs 100%. A 4000×3000 hero image at 100% quality JPEG might be 4MB. The same image at WebP, 80% quality, resized to 1600×1200, could be 150KB. Same visual result, 96% less data transfer.
Third-Party Scripts
Analytics trackers, chat widgets, marketing pixels, social share buttons, A/B testing tools, heatmap recorders — each one adds HTTP requests, JavaScript parsing, and data transfer. I have seen sites with 30+ third-party scripts adding 2-3MB of JavaScript.
Audit ruthlessly. For each script, ask: does this provide measurable business value? Is there a lighter alternative? Can it be loaded conditionally (only on pages where it is needed)? Can it be deferred or loaded asynchronously?
Consent management platforms are particularly ironic here — the cookie banner that asks permission to load tracking scripts often weighs more than the tracking scripts themselves. Choose a lightweight CMP.
Hosting
The carbon intensity of your hosting depends on two factors: the energy efficiency of the data center (measured as PUE — Power Usage Effectiveness) and the carbon intensity of the electricity grid powering it. A site hosted on 100% renewable energy from an efficient data center can cut the data center component of its carbon footprint to near zero.
The Green Web Foundation maintains a database of verified green hosting providers. Switching from a conventional hosting provider in a coal-heavy grid to a green provider is one of the highest-impact single actions you can take.
Caching
Effective caching reduces data transfer on repeat visits. Browser caching stores static assets locally. CDN caching serves content from geographically closer servers. Both reduce the energy consumed per page view — especially for returning visitors, who on most sites represent 30-60% of traffic.
Set aggressive cache headers for static assets (CSS, JS, fonts, images). Use a CDN for global distribution. These are basic web performance practices that happen to be sustainability practices too.
The Structural Changes: Longer-Term Impact
Web Fonts
Custom web fonts add 100-500KB per page, depending on how many weights and styles you load. Solutions: self-host fonts (avoid Google Fonts for both privacy and performance), use font-display: swap to prevent render-blocking, subset to only the characters your site actually uses, and consider system font stacks for body text — modern system fonts (Inter, SF Pro, Segoe UI) look perfectly professional.
Video
Autoplay video is the nuclear option for page weight. A 30-second autoplay background video at 1080p can add 5-20MB per page view. Replace with a static poster image plus click-to-play. If video is essential, use efficient codecs (AV1 or VP9 over H.264), adaptive bitrate streaming, and never autoplay with sound.
JavaScript Architecture
Single-page applications (SPAs) with large JavaScript bundles force every visitor to download the entire application on first visit. Consider: server-side rendering for content-heavy pages, code splitting to load only what each page needs, tree shaking to eliminate unused code from bundles, and evaluating whether you really need that JavaScript framework for what is essentially a content site.
Measuring Progress
Carbon measurement should be ongoing, not a one-time audit. Set up monitoring that tracks page weight and carbon per page view over time, alerts you when new pages or features significantly increase footprint, and reports total estimated emissions monthly or quarterly.
Our Carbon Badge provides ongoing measurement with a visible badge — which also creates public accountability.
Set a target. A reasonable goal for most sites: reduce per-page emissions by 50% within 12 months. Ambitious but achievable if you tackle images, scripts, and hosting systematically.
Why This Matters Beyond Compliance
The CSRD requires large EU companies to report on digital carbon as part of scope 3 emissions. But even without regulatory pressure, the business case is clear: every change that reduces carbon also reduces page load time, improves Core Web Vitals, reduces bounce rates, lowers hosting costs, and improves SEO rankings. Carbon optimization is not in conflict with business objectives — it is aligned with them.