Data centers and data transmission networks consume roughly 1.5–2% of global electricity, according to the International Energy Agency — and that share is projected to double by 2030. Every HTTP request, every uncompressed image, every client-side JavaScript bundle that re-renders a static paragraph contributes to that number. Most developers don’t think about this. With Earth Day this week, it’s worth asking: what does your website actually cost the planet?

We’ve spent the last year building AlsheikhMedia.com and our product sites on a stack that prioritizes performance and minimal resource consumption. Not because we set out to be green — we set out to be fast. But it turns out that the fastest website is also the lightest, and the lightest website is also the most sustainable.

The Carbon Cost of a Webpage

The average webpage in 2026 weighs about 2.5 MB. That sounds small until you multiply it by billions of page loads per day. The HTTP Archive tracks this, and the trend line has gone in one direction for twenty years: up.

Most of that weight comes from three sources:

  1. JavaScript. The median page ships over 500 KB of compressed JavaScript. Much of it is framework overhead that the user never interacts with — hydration logic, state management for static content, analytics bundles that fire on every scroll event.

  2. Images. Unoptimized PNGs and JPEGs still account for roughly half of total page weight. Many sites serve desktop-resolution images to mobile devices. Few use modern formats like AVIF or WebP with proper srcset attributes.

  3. Third-party scripts. Chat widgets, analytics, A/B testing tools, cookie consent banners, social embeds. Each adds DNS lookups, TCP connections, and JavaScript execution. A typical marketing site loads 15–30 third-party scripts.

Every byte transferred requires energy at every step: the server, the CDN edge node, the cell tower or ISP, and the user’s device. A lighter page means less energy at every point in that chain.

Static-First Architecture

The single most impactful decision we made was choosing Astro as our framework — the same one powering our bilingual web apps. Not because it’s trendy — because it ships zero JavaScript by default.

That sentence is worth repeating. When you build a page in Astro, the output is plain HTML and CSS. No runtime. No hydration. No framework bundle. If a page doesn’t need interactivity, it doesn’t pay the cost of interactivity.

---
// This component renders to pure HTML at build time
// Zero JavaScript reaches the browser
const posts = await getCollection('blog');
---
<ul>
  {posts.map(post => (
    <li><a href={post.slug}>{post.data.title}</a></li>
  ))}
</ul>

When a component does need interactivity — a mobile menu toggle, a language switcher — Astro’s island architecture loads only that component’s JavaScript, only when it’s needed. The rest of the page stays static.

Compare this to a typical Next.js or Nuxt setup where the entire page hydrates on load, shipping the full component tree as JavaScript even when every element is static. The difference is not marginal. On our blog pages, we ship under 15 KB of total JavaScript. A comparable React-based blog would ship 80–150 KB of framework code before a single line of application logic.

Edge Delivery Eliminates Round Trips

We deploy to Cloudflare Pages, which means our static HTML is cached at 300+ edge locations worldwide. A user in Dubai doesn’t wait for a round trip to a server in Virginia. The page is served from the nearest edge node, often in under 50ms.

This matters for sustainability because network latency isn’t just about user experience — it’s about how long network infrastructure stays active for each request. A 200ms response keeps routers, switches, and radio equipment engaged four times longer than a 50ms response. At scale, this adds up.

Edge delivery also means we don’t run origin servers for most requests. No always-on Node.js process. No container sitting idle at 3 AM waiting for traffic. The edge cache handles it, and edge nodes serve thousands of sites simultaneously, amortizing their energy cost across all of them.

Image Optimization as Environmental Policy

Images are the easiest win and the most commonly missed. Our approach:

Build-time optimization. Every image is processed at build time into multiple formats (WebP, AVIF) and multiple sizes. The browser picks the smallest format it supports at the resolution the viewport actually needs.

<picture>
  <source srcset="/images/hero-400.avif 400w, /images/hero-800.avif 800w"
          type="image/avif" />
  <source srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w"
          type="image/webp" />
  <img src="/images/hero-800.jpg" alt="..." loading="lazy"
       width="800" height="450" />
</picture>

Lazy loading everything below the fold. The loading="lazy" attribute is free performance. Images that the user hasn’t scrolled to yet don’t consume bandwidth. This alone can cut page weight by 40–60% on image-heavy pages.

No hero videos on landing pages. Autoplay background videos are beautiful and expensive. A 10-second hero video at 1080p is 5–15 MB — more than the rest of the page combined. We use static images with CSS animations for visual interest. The energy difference is significant.

CSS Over JavaScript

A pattern we’ve adopted: if you can do it in CSS, don’t do it in JavaScript. CSS animations run on the compositor thread and are GPU-accelerated. JavaScript animations run on the main thread and block rendering.

Our navbar hide-on-scroll behavior uses position: sticky with CSS transitions and a minimal scroll listener — not a React state update that re-renders the header on every scroll event. Our dark mode toggle is a CSS custom property swap, not a context provider that re-renders the entire component tree.

/* Theme switching with zero JavaScript re-renders */
:root {
  --bg: #ffffff;
  --text: #1a1a1a;
}

[data-theme="dark"] {
  --bg: #0a0a0a;
  --text: #e5e5e5;
}

body {
  background: var(--bg);
  color: var(--text);
  transition: background 200ms ease, color 200ms ease;
}

Every DOM update avoided is CPU cycles saved. Every CPU cycle saved is energy saved. The math is simple even if the numbers are small per-page — they compound across millions of page views.

Measuring Your Site’s Carbon Footprint

Several tools exist to estimate the environmental impact of a webpage:

  • Website Carbon Calculator estimates CO₂ per page view based on data transfer. Our homepage scores in the top 10% of tested pages.
  • Lighthouse performance score is a reasonable proxy. A score above 95 generally means minimal waste — small bundles, optimized assets, fast rendering.
  • Core Web Vitals align almost perfectly with sustainability. A low LCP means less data transferred. A low CLS means fewer re-renders. A low INP means less CPU work.

The correlation is no accident. What’s good for the user is good for the planet. Google’s performance metrics are, inadvertently, environmental metrics.

The Business Case

Sustainability isn’t just ethics — it’s engineering economics.

Hosting costs scale with compute and bandwidth. A static site on edge CDN costs a fraction of a server-rendered application. We pay effectively nothing for hosting this site. An equivalent dynamic site with server-side rendering would cost $20–50/month and require monitoring, scaling, and maintenance.

Performance converts. Every 100ms of load time improvement increases conversion rates. Amazon famously measured a 1% revenue decrease per 100ms of added latency. The fastest sites win in both search rankings and user engagement.

Longevity. A static HTML file from 2005 still works perfectly today. A React app from 2020 often won’t build without significant dependency updates. Simpler architecture lasts longer, which means less rebuilding, less re-deploying, and less cumulative energy spent over the lifetime of the project.

What You Can Do This Week

You don’t need to rewrite your stack. Start with the highest-impact changes:

  1. Run your site through WebPageTest. Look at total transfer size. If it’s over 1 MB, you have easy wins available.

  2. Audit your third-party scripts. Remove anything you’re not actively using. That analytics tool you installed six months ago and never check? It’s loading on every page view for every visitor.

  3. Convert images to WebP or AVIF. A single command with sharp or squoosh can cut image sizes by 50–70% with no visible quality loss.

  4. Add loading="lazy" to below-fold images. Five minutes of work, immediate bandwidth savings.

  5. Question your framework choice for your next project. If the page is mostly content, does it need a client-side runtime? Astro, Eleventy, and Hugo all produce static output with zero or minimal JavaScript. The right tool for content sites is the one that ships the least code.

The web doesn’t have to keep getting heavier. Every site we build is a choice — to add complexity or to resist it, to ship megabytes or kilobytes, to consume energy thoughtlessly or deliberately. The tools for building lighter are mature, well-documented, and often simpler than the heavy alternatives.

Build fast. Ship light. The planet is one of your users too.

SustainabilityPerformanceAstroEdge ComputingGreen WebWeb Development