The Carbon Cost of Bad Code: How Technology Choices Shape the Web's Environmental Footprint

Data centers consumed 536 TWh of electricity in 2025 — 2% of global electricity, roughly equal to the entire power consumption of France. The median web page weighs 2.6 MB on mobile. Every megabyte of JavaScript alone emits up to 1.76g CO2e per pageview.

These aren't abstract numbers. They're the consequence of millions of individual technology choices — which CMS, which framework, which server, which hosting provider. Every <script> tag is an energy decision. Every unoptimized WordPress plugin is a carbon decision. Every Apache configuration that could have been nginx is an efficiency decision.

We mapped the technology stack of 1.4 million websites in LLMSE's database and cross-referenced it with published carbon research. This is the first large-scale study connecting real-world technology adoption to sustainability outcomes.

The headline finding: the web's greenest architecture — static site generators — powers only 2.6% of sites. The heaviest architecture — jQuery plus unoptimized CMS — powers over 40%. The web is built on its least efficient technology, at scale.

The Technology Map of 1.4 Million Websites

Every website in LLMSE's database has its technology stack detected through HTML signatures — wp-content paths for WordPress, CDN imports for jQuery, generator meta tags for Hugo, framework-specific class patterns for React and Angular. Here's what 1.4 million sites are actually built on:

CMS and Framework Distribution

WordPress alone accounts for 34% of the web in our dataset. jQuery — a library that predates modern JavaScript — still runs on 8% of sites. Static site generators (Hugo, Jekyll, Astro, Gatsby combined) collectively power just 2.6%.

The environmental implication: the web's technology distribution is inverted relative to efficiency. The lightest-weight architectures have the smallest market share. The heaviest have the largest.

Server Distribution

Cloudflare's edge network handles more traffic than any traditional server. Apache — the least efficient major server at scale — still serves 240,000 domains.

The Weight of JavaScript

JavaScript is the web's heaviest environmental tax. The median web page ships 697 KB of JavaScript — up from roughly 300 KB in 2015. That's a 132% increase in a decade. And JavaScript is uniquely expensive: unlike images, which can be lazy-loaded and decoded by hardware, JavaScript must be downloaded, parsed, compiled, and executed by the CPU. Every step consumes energy.

The carbon cost is measurable. The Sustainable Web Design Model (SWDM v4) estimates every MB of JavaScript emits up to 1.76g CO2e per pageview when accounting for the full data transfer and device processing chain. For a site receiving 100,000 monthly pageviews with 700 KB of JS, that's approximately 123g CO2e per month — from JavaScript alone.

Framework Bundle Sizes

Published data on framework bundle sizes reveals the range:

These are framework-only sizes before application code, dependencies, polyfills, and third-party scripts. Real-world Angular applications routinely ship 500 KB+ of JavaScript. React applications with common libraries (React Router, Redux, component libraries) land between 200-400 KB.

jQuery: The Legacy Carbon Problem

jQuery deserves special attention. It appears on 113,148 sites in our dataset — 8% of the web — despite being largely unnecessary since ES6 standardized the DOM APIs jQuery was created to smooth over.

jQuery's quality grades tell the story:

jQuery sites have the lowest SEO pass rate of any technology in our dataset — 77% below the web average. They also have the worst accessibility scores. These sites aren't just heavy; they're outdated across every quality dimension. And outdated sites tend to be bloated sites — loading jQuery alongside modern frameworks that duplicate its functionality, running unmaintained plugins, serving uncompressed assets.

Static vs Dynamic: The Efficiency Divide

The clearest environmental divide in web technology is between static and dynamic architectures.

Static site generators (Hugo, Jekyll, Astro, Gatsby) pre-build every page at deploy time. The server delivers plain HTML files. No PHP execution. No database queries. No server-side rendering on each request. The compute cost is paid once at build time, not multiplied by every visitor.

Dynamic CMS platforms (WordPress, Drupal, Joomla) execute server-side code and query databases on every pageview. WordPress runs PHP, queries MySQL, assembles the page, and sends it — for every single visitor, unless a caching layer intervenes.

The carbon difference is published: an unoptimized WordPress site emits approximately 0.77g CO2e per pageview. An optimized static site can achieve as low as 0.09g — an 88% reduction.

Quality as an Efficiency Proxy

Quality grades function as a proxy for efficiency. Higher-quality sites tend to be better optimized, load faster, and waste fewer resources. Here's how static generators compare to dynamic CMS platforms in LLMSE's data:

SEO Pass Rates (A+B)

Astro — the newest static site generator in our dataset — has an SEO pass rate nearly double that of WordPress. Gatsby, despite its declining popularity, still outperforms every traditional CMS.

WCAG Accessibility Pass Rates (A+B+C)

Jekyll sites have 61.5% WCAG pass rate — nearly double WordPress's 36.4%. Accessible sites tend to be leaner sites: they have proper semantic HTML, fewer unnecessary scripts, and cleaner DOM structures. The accessibility-sustainability correlation is real.

Static sites are greener and higher quality — but only 2.6% of the web uses them.

The combined SSG install base (Hugo 8.6K + Jekyll 16K + Astro 10.3K + Gatsby 2K = 36,908) is dwarfed by WordPress alone (477,792). For every site on a static generator, there are 13 on WordPress.

The Server Efficiency Spectrum

The server a website runs on determines the energy cost of delivering every page.

Published benchmarks: - nginx handles 2.5x more concurrent connections than Apache and uses 5-6% less memory under equivalent load - Cloudflare's global CDN reduces network carbon by up to 96% by serving content from the nearest edge node instead of routing to origin - LiteSpeed claims 75% less resource usage than Apache for equivalent WordPress workloads

Server Quality Grades

LLMSE's quality data aligns with these efficiency benchmarks. SEO pass rates by server:

The pattern is stark: CDN-edge servers outperform traditional servers 3-5x on SEO quality. Netlify (1.37%) is 4.6x Apache (0.30%) and 7.2x IIS (0.19%).

This isn't coincidental. CDN-edge architecture inherently optimizes for the same metrics that SEO grades measure — fast load times, proper caching headers, HTTP/2+ support, TLS by default. Sites that choose Netlify or Vercel are also making an architectural choice that reduces carbon per pageview.

The server your site runs on is an environmental choice. 240,000 sites in our dataset still run on Apache — the least efficient major server for concurrent traffic. Every one of those sites could reduce its energy consumption by migrating to nginx or fronting with Cloudflare.

The Industry Technology Diet

Not all sectors choose their technology equally. LLMSE's category data reveals which industries carry the heaviest technology stacks:

WordPress Adoption by Sector

jQuery Persistence by Sector

SSG Adoption by Sector

The tech sector practices what it preaches. Computer & Electronics has the highest SSG adoption (6.2%) and lowest jQuery persistence. Health and Business — sectors with the highest WordPress dependency — carry the heaviest technology stacks.

This matters at scale. If the Health sector's 14,200 WordPress sites are unoptimized (0.77g CO2e/pageview) rather than running static architecture (0.09g CO2e/pageview), the sector-wide excess carbon from technology choice alone is measurable.

The Full Scorecard

Using quality grades as an efficiency proxy and published carbon research, we can rank technologies into sustainability tiers:

Tier 1: Efficient (Highest quality, lowest resource overhead)

Tier 2: Moderate (Above-average quality, manageable overhead)

Tier 3: Heavy (Below-average quality, highest resource overhead)

The pattern is consistent: technologies with higher quality scores also have architectures that consume less energy per pageview. This isn't a coincidence — the same engineering practices that produce accessible, well-structured, fast-loading sites (semantic HTML, minimal JavaScript, proper caching, CDN delivery) also minimize energy consumption.

The Regulatory Direction

The web's environmental footprint is transitioning from a voluntary concern to a compliance requirement:

EU Corporate Sustainability Reporting Directive (CSRD): Companies with 250+ employees must report on environmental impact, including digital operations. Scope 3 emissions — which include the energy consumed by end users loading your website — are in scope. First reports were due in 2025, with enforcement expanding through 2026.

California SB 253 (Climate Corporate Data Accountability Act): Companies with $1B+ revenue doing business in California must disclose Scope 1, 2, and 3 greenhouse gas emissions. Your website's technology stack and hosting infrastructure fall under Scope 3.

W3C Web Sustainability Guidelines: The W3C published 93 guidelines for sustainable web design covering everything from image optimization to JavaScript efficiency to green hosting selection. These aren't enforceable yet — but they establish the standard that regulation will likely reference.

Green hosting adoption remains low. The Green Web Foundation's directory shows only about 12% of websites run on verified green hosting — providers powered by renewable energy or purchasing credible offsets. 88% of the web runs on hosting with unknown or fossil-fuel-based energy sources.

The intersection of these regulations means: organizations will increasingly need to justify their technology stack choices on sustainability grounds. "We use WordPress because we always have" may not satisfy a CSRD auditor asking why you chose a dynamic CMS over a static generator with 88% lower per-pageview emissions.

What This Means

The web's environmental footprint is not primarily a hosting problem or a data center problem. It's a technology choice problem.

Our dataset shows that:

• 34% of the web runs on WordPress — a dynamic CMS that, unoptimized, emits 3x more CO2e per pageview than static alternatives
• 8% still loads jQuery — a library with the lowest quality scores in every dimension, associated with the most outdated and bloated stacks
• Only 2.6% uses static site generators — the architecture with the lowest carbon footprint per pageview
• 28% routes through Cloudflare — the most efficient delivery method — but 17% still runs on Apache, the least efficient major server
• The tech sector leads SSG adoption at 6.2% while healthcare and business lag at 1-3%

The technology choices that produce higher-quality websites — better SEO, better accessibility, better performance — are the same choices that reduce energy consumption. Quality and sustainability are not competing priorities. They're the same priority.

The median web page emits 0.36g CO2e per pageview. Multiply that by the billions of pageviews happening every day, and the aggregate carbon cost of the web's technology choices becomes significant. When EU CSRD auditors start asking about digital carbon footprints, the answer will be found in your package.json and your server configuration — not just your hosting provider's energy source.

The greenest code is the code you don't ship.

This analysis was conducted using LLMSE, which has classified over 1.4 million websites across SEO, EEAT, WCAG accessibility, readability, and GARM brand safety dimensions. Technology detection covers 368+ web technologies. Carbon estimates reference the Sustainable Web Design Model v4, IEA data center energy reports, and HTTP Archive page weight statistics. All quality data reflects the LLMSE database as of March 2026. To analyze your own site, visit llmse.ai/classify.