Why shrinking page weight is an effective way to lower CO2

Every byte transferred and every CPU cycle on a client or server produces an energy cost. Reducing page weight lowers network traffic, shortens device and server processing, and reduces time spent rendering. Those changes reduce electricity consumption and therefore the associated greenhouse gas emissions where the electricity has carbon intensity. Focusing effort on the largest sources of bytes and compute yields the biggest emissions reductions for the least developer time.

Measure before you remove

Start with measurement so you can prioritise with evidence. Run a mix of lab and field tests. Lab tools show asset breakdowns and waterfall timing. Field metrics capture the real distribution of devices, networks, and user flows and are necessary to estimate actual CO2 impact.

Minimum measurement checklist

Use these measurements to form your removal plan. Record baseline values for each page or template you will change.

1. Network transfer per page measured in transferred bytes from tools such as WebPageTest or Lighthouse.
2. Largest resource contributors by bytes and by load timing found in the waterfall view.
3. CPU and scripting time from Chrome DevTools or Lighthouse.
4. Real User Monitoring metrics such as average payload and TTFB segmented by device and network, if available.

How to prioritise removals for biggest CO2 wins

Rank assets by a combination of transferred bytes, client CPU cost, and frequency of the page being viewed. An asset that is large but appears on a single low-traffic page usually yields a smaller aggregate carbon benefit than a moderate asset present on all high traffic pages. Use this simple decision rule: impact equals bytes times visits plus CPU cost times visits. Prioritise the items with the highest aggregate impact.

First things to remove or change

These items typically give the largest carbon reduction per hour of engineering work. Apply them in this order and use the measurement checklist to confirm gains at each step.

1. Nonessential third party scripts that run on page load

Third party tags and widgets often add both network weight and synchronous JavaScript that blocks rendering. Many are not critical to the user experience or conversion funnel. Audit all third party code and temporarily disable any script that is not required for the primary user task. For scripts that are useful but not essential on every page, move them to specific pages, load them on user interaction, or load them asynchronously with defer or an async loader.

2. Large background videos and autoplay media

Autoplay video files and high bitrate background video are heavy and usually add significant bytes even when hidden or not visible in the initial viewport. Replace autoplay video with a poster image and an explicit play control, or convert the experience to an animated GIF or CSS animation only when it preserves the message while reducing bytes. If video is necessary, host a low bitrate web optimized source and lazy load higher quality variants on demand.

3. Oversized hero images and unresponsive images

Many sites serve a single large image to all devices. Switch to responsive images with srcset and sizes so each device requests an appropriately scaled file. Implement lazy loading for images outside the initial viewport. Where possible, replace raster images with vector formats for illustrations and SVG icons for UI elements.

4. Unused or underused web fonts

Web fonts can add multiple font files and several hundred kilobytes. Reduce font weight by subsetting glyph ranges, limit the number of font families, prefer system fonts for nonbrand copy, and use font display strategies such as swap to avoid long blocking behavior. If a unique brand appearance is required, consider converting very small amounts of decorative text to inline SVGs instead of loading full font families.

5. Large JavaScript bundles and unused code

Unused JavaScript increases CPU and memory usage on client devices as well as download size. Use bundler analysis tools to find code that is never executed on the critical path. Remove or split code so only necessary modules load initially. Defer nonessential scripts to after interaction or route change. Prefer small dedicated scripts that handle one feature over monolithic client frameworks for simple pages.

Second tier removals and optimisations

After the high impact items are handled, focus on these areas that yield steady returns.

1. Large or poorly encoded images

Convert images to modern formats such as WebP or AVIF where supported and ensure compression settings are tuned for visual acceptability rather than maximum quality. Where a modern format is not compatible, fall back to optimized JPEG or PNG. Use server or CDN features that support format negotiation to serve the best format automatically.

2. Excessive analytics and tracking sampling

Keep essential measurement but reduce the number of tags that fire on every page load. Where analytics are mandatory, consider sampling, server side collection, or batching to reduce client requests. Consolidate vendors where possible and gate tracking behind user consent so anonymous traffic does not trigger heavy network work.

3. Unnecessary fonts, icons and image sprites

Remove icon font libraries if they only provide a handful of icons. Replace with inline SVG sprites or component level SVG usage that reduces both payload and rendering complexity. Remove legacy sprites that were kept for compatibility but are no longer used.

Design and content changes that remove weight

Some effective changes require product or content decisions rather than purely technical fixes. These often produce high returns because they affect every page and every user.

Reduce image counts per page

Audit content pages for decorative images, redundant thumbnails, and analytics images. Remove nonessential images and collapse related visuals into a single informative graphic when possible. Encourage content authors to prefer fewer, higher quality images instead of many near-duplicates.

Avoid heavy decorative elements on repeat pages

Template elements that appear across many pages multiply their cost. Reassess the need for heavy carousels, large background images, and persistent animated elements. Replace with lighter alternatives or move them to landing pages rather than sitewide templates.

When removal is not possible: mitigation techniques

If an asset cannot be removed because it is necessary for legal, contractual, or business reasons, apply mitigation so the cost is lower.

Defer and lazy load

Defer noncritical work until after the largest content is visible or until user interaction. Lazy load images, iframes, and widgets outside the initial viewport. For scripts, use import on interaction patterns to move execution off the critical path.

Edge and CDN optimisations

Terminate heavy processing at the edge where it reduces origin work and can deliver optimized assets faster. Use CDN image resizing and format negotiation to avoid shipping oversized files. Configure cache headers so repeat visitors reuse previously fetched assets.

Adaptive delivery

Consider adaptive strategies that tailor content to device capability and network quality. Serve lower resolution assets or simpler UI on slow connections or on devices with limited CPU capacity. Adaptive delivery requires careful testing to avoid degrading core experiences for users who actually need the richer content.

How to validate CO2 wins

After changes, quantify the emissions difference using traffic weighted energy estimates. Combine reduced transferred bytes and reduced CPU work with your site traffic to estimate energy savings. If you have access to Real User Monitoring segmented by device and network, use before and after comparisons to estimate impact more accurately. Remember that precise CO2 depends on the electricity carbon intensity of the paths involved, which varies by geography and time.

Practical decision criteria for tough tradeoffs

When a feature contributes to business metrics but also increases page weight, use a structured tradeoff test. Measure the feature’s contribution to conversion or retention. If the value is small, remove it. If the value is significant, try lighter alternatives first. If no lighter alternative exists, consider conditional delivery that shows the feature only to users most likely to benefit.

Quick checklist to run during a sprint

1. Run a waterfall and identify the top five resources by transferred bytes and by main thread time.
2. For each resource, ask whether it is essential for the primary user task on that page.
3. If not essential, remove or defer it immediately and measure the change.
4. If essential, look for mitigation: responsive delivery, format conversion, subsetting, or edge optimisation.
5. Re-run field metrics after deployment and use traffic weights to estimate aggregate energy and CO2 reduction.

Implementation pitfalls to avoid

Do not remove assets without measuring impact on key business metrics. Removing a tracking pixel may reduce page weight but also blind you to conversions. Avoid unnecessarily splitting critical bundles that increase the number of requests and TTFB. When substituting formats, confirm cross browser and accessibility behavior. Finally, confirm legal and privacy obligations before disabling or moving tracking and analytics.

Where to go next

Apply the prioritised removals iteratively. Start with nonessential third party scripts and large autoplay media, then address oversized images and unused JavaScript. Use A B tests or experiments when the feature affects revenue. Track both performance and business metrics so sustainability decisions remain aligned with product goals.