12 eco web design best practices ranked by carbon impact:
Every page load has a cost. Data travels from a server through a network to a device — and at each step, electricity is consumed. When that electricity comes from fossil fuels, it produces CO2. Most web designers and developers have never been taught to think about this, which is why the average webpage in 2025 weighs 2.5 MB and produces about 0.5 grams of CO2 per visit.
That sounds tiny. A site with a million monthly page views emits roughly 6 tonnes of CO2 per year — the equivalent of about 25,000 km driven in a petrol car. The web collectively produces an estimated 3.7% of global greenhouse gas emissions, comparable to the aviation industry.
The good news: eco web design does not mean ugly or slow design. The practices below make sites faster, cheaper to run, and better for users — the environmental benefit is a consequence of doing good engineering. Use our carbon badge tool to measure your baseline before and after applying these changes.
Before optimizing, you need to understand the emissions model. The Sustainable Web Design Model v4 breaks a page view's energy consumption into three segments:
| Segment | Share of energy | Driver | How to reduce |
|---|---|---|---|
| End-user device | 41% | Screen-on time + data processing | Reduce page weight, load time |
| Network transfer | 31% | Bytes transferred over network | Reduce page weight, use CDN |
| Data center | 28% | Server electricity source | Switch to green hosting |
The key insight: 72% of your site's carbon footprint is driven by how much data you transfer. Page weight is the master variable. Halve your page weight and you roughly halve your device and network emissions. That is before you even touch your hosting.
The grid carbon intensity of your host's data center also matters. A server in Germany running on renewable energy emits roughly 0 gCO2/kWh. The same server in a coal-heavy grid might emit 800 gCO2/kWh. Hosting choice multiplies or divides the data center segment accordingly.
The highest-leverage single change you can make. Switching to a verified green hosting provider reduces your data center emissions by approximately 75% — cutting your total page view footprint by around 21%.
The key word is verified. Check the Green Web Foundation's directory before assuming a host's claims are legitimate. Providers like Infomaniak (100% Swiss hydro, PUE 1.08), Hetzner (100% renewable, PUE 1.15), and Google Cloud (PPAs, 24/7 CFE target) have documented evidence. Many others do not.
Migration is easier than it sounds. Most hosts offer free migration assistance, and the process typically takes 24-48 hours with no downtime for well-planned transfers.
Images account for roughly 45-65% of total page weight on most websites, according to HTTP Archive data from 2025. Converting from JPEG/PNG to WebP or AVIF delivers significant size reductions with no perceptible quality loss for typical web display sizes:
| Format | Typical reduction vs JPEG | Browser support (2026) | Best for |
|---|---|---|---|
| WebP | 25–35% | 97%+ global | Photos, general images |
| AVIF | 40–55% | 93%+ global | Photos, screenshots |
| SVG | 80–95% for icons | 100% | Icons, logos, illustrations |
A 500 KB JPEG hero image becomes roughly 180 KB in WebP and 120 KB in AVIF. Multiply across 10 images on a typical homepage and you are looking at savings of 2-4 MB per page load. Tools like Squoosh, Sharp (Node.js), or Cloudflare Images can automate this conversion at scale.
Always set explicit width and height attributes on images to prevent layout shift. Use srcset and sizes attributes to serve appropriately sized images for each device viewport — a 1,200 px image served to a 375 px phone screen wastes roughly 90% of its data.
The median website loaded 540 KB of JavaScript in 2025, according to HTTP Archive. A substantial portion of that — often 60-80% — is never executed on any given page view. Third-party scripts (analytics, chat widgets, social share buttons, A/B testing tools, ad tags) are the primary culprits.
Each third-party script adds two costs: the bytes transferred plus the server request to a third-party domain (which involves a full DNS lookup, TCP connection, and TLS handshake — adding 100-500 ms of latency and measurable energy per request).
The audit process:
Custom web fonts (Google Fonts, Adobe Fonts, self-hosted typefaces) add 100-400 KB per page and introduce render-blocking behavior that delays time-to-first-paint. The system font stack loads at zero cost because the fonts already exist on the user's device:
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, sans-serif;
This stack renders in Helvetica Neue on macOS, Segoe UI on Windows, and Roboto on Android — all high-quality typefaces that the user already has. The visual difference from a custom font is minimal for most sites; the performance and carbon difference is immediate and measurable.
If your brand genuinely requires a custom font, self-host it (avoid third-party CDN requests), use font-display: swap, and load only the weights and character subsets you actually use. A subset containing only Latin characters can be 60-80% smaller than the full font file.
Lazy loading defers the loading of images and iframes that are below the fold until the user scrolls near them. This reduces the initial page weight for every user — and for users who do not scroll, those below-fold assets are never loaded at all.
Implementation is a single HTML attribute: loading="lazy" on <img> and <iframe> elements. Browser support is now at 97%+ globally. No JavaScript library required.
Do not apply lazy loading to above-the-fold images — particularly the hero image or the Largest Contentful Paint element. Lazy loading these delays the most user-visible render and harms both Core Web Vitals and perceived performance.
Caching is the closest thing to free carbon reduction in web development. When a returning visitor's browser has a cached copy of your CSS, JS, and images, it does not download them again. That eliminates the network transfer and data center energy for those assets entirely.
Recommended cache configuration:
Cache-Control: public, max-age=31536000, immutableCache-Control: public, max-age=3600 (1 hour for frequently updated content)Cache-Control: public, max-age=900, stale-while-revalidate=86400The immutable directive tells browsers not to even check for updates on a file — it will be served from cache unconditionally until the max-age expires. Combined with cache-busting via content hashes (webpack, Vite, and most build tools handle this automatically), this is zero-risk.
A Content Delivery Network caches your content at edge locations around the world. When a visitor in Sydney requests your Paris-hosted site, the content is served from a Sydney edge node rather than crossing the Pacific — reducing both latency and network energy.
CDNs also dramatically increase cache hit rates: instead of relying on individual browser caches, the edge node serves cached responses to thousands of users simultaneously. Cloudflare (runs on 100% renewable energy), Fastly, and Akamai all report lower energy-per-request than origin serving.
For most sites, Cloudflare's free tier is sufficient and trivially easy to set up. Enable it, turn on "Auto Minify" for HTML/CSS/JS, and activate the image resizing feature — together these can reduce page weight by another 15-30% with no code changes.
Minification strips whitespace, comments, and unnecessary characters from code files. The size savings are modest compared to image optimization — typically 10-30% of code file size — but they add up across an entire site and require zero design or development trade-offs.
Every modern build tool (webpack, Vite, Parcel, esbuild) minifies by default in production mode. For PHP or server-rendered sites without a build step, plugins like WP Rocket (WordPress) or Autoptimize handle HTML/CSS/JS minification at the server level. Cloudflare's Auto Minify feature catches what slips through.
Pair minification with Brotli compression. Brotli (the successor to gzip) typically achieves 15-25% better compression ratios on text content. Most modern hosting and CDN configurations support Brotli by default; if yours does not, enable it — it is a single configuration line.
OLED screens — now on over 40% of smartphones globally — consume significantly less energy displaying dark content. Each pixel in an OLED display is individually lit: a black pixel is literally off. A predominantly dark-themed interface can consume 40-60% less energy on OLED screens than a white-background equivalent.
Implementing dark mode with CSS is straightforward using the prefers-color-scheme media query:
@media (prefers-color-scheme: dark) { body { background: #121212; color: #e0e0e0; } }
This respects the user's operating system preference automatically. For sites where a toggle is preferred, a small JavaScript snippet can handle the switch while storing the preference in localStorage. The CSS custom properties (variables) approach makes dark mode implementation systematic rather than requiring per-element overrides.
Autoplay video is one of the most carbon-expensive patterns in modern web design. A typical background video loops at 2-8 MB and plays continuously as long as the page is open. For a visitor who lands on your homepage and stays for 3 minutes, that might represent 30+ MB of transferred video data — more than the entire rest of the page combined.
The fix: replace autoplay video backgrounds with a static image or CSS animation. If video is genuinely necessary for the content, implement it with a play button requiring user interaction. Use the preload="none" attribute to prevent even the video metadata from loading until the user explicitly starts playback.
CSS animations and transitions run on the browser's compositor thread, which can hand off work to the GPU — separate from the main JavaScript thread and more energy-efficient for visual effects. JavaScript-driven animations (particularly those that force layout recalculation by reading and writing to DOM layout properties) keep the CPU busy and prevent the browser from optimizing power consumption.
Stick to animating CSS properties that the browser can handle via the GPU: transform, opacity, and filter. Avoid animating properties that trigger layout recalculation: width, height, margin, padding, top, left. Use the will-change property sparingly to signal to the browser which elements will animate, allowing it to optimize rendering ahead of time.
Every page on your site — even if never visited by humans — is crawled by search engine bots. Bots consume server resources and data center electricity with every request. A site with thousands of thin, duplicate, or outdated pages wastes crawl budget and generates unnecessary emissions.
Conduct a regular content audit using Google Search Console's "Coverage" report combined with your analytics. Pages with zero traffic over 12 months are candidates for consolidation or removal. Redirect removed pages appropriately (301 redirects to relevant content), and use noindex for pages that must exist but should not attract crawling (tag archives, filtered product pages, print versions).
A typical business website starts with these characteristics:
Apply the top 6 practices from this guide:
| Change applied | Page weight | CO2/year estimate |
|---|---|---|
| Baseline | 3.2 MB | 1,843 kg |
| + Green hosting | 3.2 MB | 1,456 kg (-21%) |
| + WebP images | 1.8 MB | 819 kg (-56%) |
| + Remove unused JS | 1.3 MB | 591 kg (-28%) |
| + System fonts | 1.1 MB | 500 kg (-15%) |
| + Lazy loading | 0.8 MB initial | 364 kg (-27%) |
| + Aggressive caching | 0.3 MB (returning) | 241 kg (-34%) |
Final result: 241 kg/year — an 87% reduction from the 1,843 kg baseline. The site is also faster, ranks better in Core Web Vitals assessments, and costs less to run at scale. Eco web design is not a trade-off; it is good engineering.
Eco-friendly web design (also called sustainable web design) refers to building websites that minimize energy consumption and carbon emissions. This includes reducing page weight through image optimization and leaner code, choosing green hosting providers, minimizing unnecessary scripts, and designing interfaces that require fewer server requests. The goal is to reduce the environmental cost of every page view.
The average website produces approximately 0.5 grams of CO2 per page view, based on a median page weight of 2.5 MB and the Sustainable Web Design Model v4. A site with 100,000 monthly page views emits roughly 600 kg of CO2 per year. Well-optimized sites on green hosting can get below 0.1g CO2 per page view.
End-user devices account for 41% of a page view's energy consumption, followed by network transfer at 31% and data centers at 28%. Since device and network energy scale directly with the amount of data transferred, page weight is the single biggest lever. Reducing your page size from 3 MB to 1 MB cuts device and network emissions by roughly 67%.
Use carbon-badge.com to measure your site's CO2 per page view. The tool checks your page weight, verifies whether your host uses renewable energy via the Green Web Foundation API, and calculates estimated annual emissions based on your traffic. You can also use the Website Carbon Calculator or Ecograder for independent estimates.
On OLED screens, yes — dark pixels consume significantly less energy than white pixels. With OLED screens representing over 40% of mobile displays globally, offering a dark mode option meaningfully reduces energy consumption for a substantial portion of your audience. On LCD screens, dark mode has minimal impact as the backlight illuminates the entire screen regardless of content color.
Enter your URL and get an instant carbon emissions estimate, green hosting verification, and a grade from A to F — in under 30 seconds.