Website Energy Consumption: The 5 Biggest Factors Driving Your Digital Footprint

When I audit websites for energy consumption, the same five culprits appear in roughly the same order, across industries, across CMS platforms, across design styles. Understanding these five factors — and their relative impact — is the fastest path to reducing your website's environmental footprint.

Factor 1: Images (Typically 40-60% of Page Weight)

On the average website, images account for more data transfer than all other content types combined. The HTTP Archive's Web Almanac consistently shows that images represent 40-60% of total page weight for median websites, and up to 80% for image-heavy sites like e-commerce, travel, and media.

What makes this frustrating is that most image weight is wasted. A hero image served at 4000×3000 resolution to a user on a 375-pixel-wide phone. A portfolio gallery loading 50 high-resolution images on page load even though only 4 are visible. A product page with 12 JPEG images when the same visual quality could be achieved at one-third the file size with WebP.

The energy cost flows through the entire chain: more bytes transferred means more energy at the data center, more energy in the network, and more energy on the user's device to decode and render.

The fix: Convert to WebP/AVIF (30-60% savings with no visible quality loss). Implement responsive images with srcset (serve appropriate sizes for each device). Lazy load below-the-fold images. Compress at 80-85% quality (imperceptible difference from 100%). Use CSS for simple decorative elements instead of images.

Impact: fixing image strategy alone typically reduces total page weight by 30-50%.

Factor 2: JavaScript (Most Energy-Intensive Per Byte)

JavaScript is more energy-intensive per byte than any other web content type. Unlike images (which are decoded and rendered once), JavaScript must be downloaded, parsed, compiled, and executed — each step consuming CPU cycles and therefore energy. On mobile devices, JavaScript parsing and execution is the single largest contributor to battery drain from web browsing.

The median website in 2026 loads approximately 500KB of JavaScript. The 90th percentile exceeds 1.5MB. For single-page applications (SPAs) with large framework bundles, 2-3MB of JavaScript on initial load is not uncommon.

But raw file size understates the problem. A 200KB image takes microseconds to decode. A 200KB JavaScript file might take hundreds of milliseconds to parse and execute on a mid-range phone — keeping the CPU (and battery) working much longer.

The fix: Audit your JavaScript. Remove unused code and unnecessary libraries. Code-split to load only what each page needs. Defer non-critical scripts. Consider whether you actually need a heavy JavaScript framework — a content-heavy site rendered server-side with minimal interactivity can be 90% lighter on JS. Use native browser APIs instead of polyfills and libraries where possible.

Impact: reducing JavaScript by 50% typically improves energy efficiency by 15-25% — more than the raw byte reduction would suggest, because of the processing overhead.

Factor 3: Third-Party Scripts (The Hidden Tax)

Analytics trackers, advertising scripts, social media widgets, live chat tools, A/B testing platforms, heatmap recorders, consent management platforms, customer review widgets, retargeting pixels — each of these is a third-party script that adds HTTP requests, data transfer, and processing load.

The average commercial website loads 15-25 third-party scripts. E-commerce sites routinely load 30-50. Each script typically adds 20-100KB of JavaScript plus additional network requests for tracking pixels, iframes, and API calls.

What makes third-party scripts particularly problematic: you do not control them. The vendor can update their script at any time, adding weight, changing behavior, or introducing performance regressions. You are effectively giving dozens of external companies permission to run code on your pages — and paying the energy cost for it.

The fix: Audit every third-party script. For each one, answer: does it provide measurable, documented business value? Is there a lighter alternative? Can it be loaded only on pages where it is needed (not globally)? Can it be consent-gated (loaded only after user permission)?

Most sites can remove 30-50% of their third-party scripts without any measurable business impact. The scripts were added at some point for a specific campaign or initiative, and nobody removed them when the campaign ended.

Factor 4: Hosting Infrastructure (The Constant Baseline)

Your hosting infrastructure consumes energy 24/7, regardless of traffic. Servers need power and cooling. Network equipment runs continuously. Storage systems spin or maintain flash cells. This baseline energy consumption is independent of how efficient your pages are — it is a function of your hosting setup.

Three factors determine the hosting energy impact: the data center's Power Usage Effectiveness (PUE) — the ratio of total facility energy to IT equipment energy (1.2 is excellent, 1.6 is average), the carbon intensity of the electricity grid powering the data center, and whether you are using appropriate infrastructure for your traffic (an over-provisioned dedicated server for a low-traffic site wastes energy).

The fix: Choose a hosting provider with strong PUE ratings and verified renewable energy sourcing. Consider whether your traffic justifies dedicated infrastructure or whether shared/serverless hosting is more appropriate. Use auto-scaling that matches resources to actual demand rather than peak capacity.

For the carbon intensity piece, see our green hosting guide.

Factor 5: Video and Rich Media (The Nuclear Option)

Video is in a category of its own. A single autoplay background video can add more page weight than every other element combined. A 30-second 1080p video at reasonable compression is 5-15MB. Some sites embed multiple videos. Some autoplay at 4K resolution.

The energy impact is extreme: massive data transfer, intensive GPU processing for decoding, sustained CPU usage during playback, and continuous network activity for streaming.

The fix: Never autoplay video unless there is a genuinely compelling reason (and there almost never is). Use poster images with click-to-play. If video is essential, use efficient codecs (AV1 or VP9 over H.264), adaptive bitrate streaming, and thumbnail previews. Host on dedicated video platforms (YouTube, Vimeo) rather than self-hosting — their infrastructure is optimized for video delivery.

Replacing a single autoplay hero video with a static image and click-to-play can reduce page weight by 80-95% on that page.

Prioritization: What to Fix First

Based on hundreds of audits, here is the typical priority order for maximum impact with minimum effort:

1. Images — highest impact, lowest effort. Image optimization can often be done in an afternoon with batch tools.

2. Third-party script audit — high impact, moderate effort. Removing unnecessary scripts is mostly a decision, not a technical challenge.

3. Video optimization — very high impact per affected page, but only relevant if you use video.

4. JavaScript architecture — high impact, higher effort. Refactoring JS requires development work.

5. Hosting switch — moderate impact, moderate effort. A hosting migration is a project but a one-time event.

Measure before and after each change using Carbon Badge to quantify the improvement. The data tells you whether your efforts are working — and where to focus next.