Why prioritize by CO2 impact and effort

Not all bytes are equal. The carbon tied to a page view depends on how many bytes are sent, where they are sent from, how often they are requested, and the device compute required to render and run code. A small number of large or frequently requested resources often account for the majority of transferred data and runtime work. Use that concentration to find actions that deliver measurable CO2 reductions with modest effort.

Fast triage to spot the biggest opportunities

1. Collect a breakdown of bytes by resource type and by individual file using a lab tool such as WebPageTest or Lighthouse.
2. Check real user telemetry for top requests by total transferred bytes and request frequency. Prioritize items that are both large and frequently requested.
3. Inspect third party scripts and widgets for synchronous loading, large payloads, and repeated network calls. These often cause both network transfer and extra CPU on client devices.
4. Identify cache behavior and CDN rules. Assets that miss caches multiply origin work and network transfer and should be fixed early.

Items to remove or change first for the biggest CO2 wins

Below items are ordered by typical return on effort. Each entry explains why it matters, what to remove or alter first, how to measure the effect, and the usual implementation risk.

• Large images and video

  Why it matters: Images and video are usually the largest contributors to bytes on a page. What to remove or change first: Eliminate decorative images that add no value, defer or replace auto playing background video with a static poster, and serve responsive images so users only download the size they need.

  How to measure: Compare total page transfer in lab tests before and after changes and validate real user metrics for bytes and load times. Implementation risk: Low to moderate depending on CMS and content workflow.

• Third party scripts and trackers

  Why it matters: Analytics, social widgets, ad tags, and personalization scripts can add both bytes and CPU. They also create additional network round trips and cache complexity.

  What to remove or change first: Defer nonessential scripts, gate trackers behind consent, replace heavy providers with lightweight analytics, and remove duplicate or unused tags.

  How to measure: Measure requests and CPU time attributed to third party origins in lab runs and track their share of transferred bytes in RUM. Implementation risk: Moderate because business teams may rely on some providers.

• Unused CSS and JavaScript

  Why it matters: Shipping code that is not executed wastes network transfer and device energy.

  What to remove or change first: Remove legacy components that no longer render on a page, split code by route, and eliminate large monolithic bundles where possible.

  How to measure: Use coverage tools in browser DevTools or bundler reports to find unused bytes. Validate bytes transferred and evaluation time in lab tests. Implementation risk: Moderate to high for large codebases but high impact when code is genuinely unused.

• Web fonts

  Why it matters: Multiple font families and variable weights increase requests and bytes and can block text rendering.

  What to remove or change first: Limit font families and weights, use system stacks where acceptable, and use font loading strategies that avoid render blocking such as rel preload plus a swap strategy.

  How to measure: Track font file sizes and requests. Observe first meaningful paint and layout shifts in performance tests. Implementation risk: Low to moderate depending on design constraints.

• Large above the fold assets with poor caching

  Why it matters: Assets that are not cached and appear on many pages create repeated transfer and origin work.

  What to remove or change first: Ensure common assets are cached at the CDN and have long cache lifetimes. Replace rarely changing large images with smaller optimized versions.

  How to measure: Count cache misses and origin requests in logs and measure bytes served from edge versus origin. Implementation risk: Low.

• Auto playing media and high bitrate streams

  Why it matters: Auto play increases initial bytes and device energy, particularly on mobile networks.

  What to remove or change first: Disable auto play for nonessential videos, provide lower bitrate fallbacks, and lazy load preview content.

  How to measure: Compare transferred bytes and playback related network activity in lab tests. Implementation risk: Low to moderate depending on product expectations.

• Heavy visual frameworks and polyfills

  Why it matters: Large UI frameworks and polyfills add both download and runtime cost, especially on older devices.

  What to remove or change first: Remove unused framework modules, load polyfills conditionally based on feature detection, and consider lighter alternatives for specific components.

  How to measure: Bundle size reports and client CPU profiling show savings. Implementation risk: Moderate to high if frameworks are tightly coupled to product logic.

Decision criteria to choose removal versus optimization

1. Start with high impact low risk changes that are easy to measure. Those deliver clear wins and build momentum.
2. Prioritize resources that are both large and requested across many pages. A single large asset reused sitewide multiplies benefit.
3. Consider user experience and business dependency. If a resource is critical to conversion, prefer optimization over removal and run an experiment to measure user impact.
4. Prefer changes that reduce repeated work. Fix cache headers and long lived CDN policies before spending time on micro optimizations that only affect cold caches.
5. When in doubt, A B test the change or run a staged rollout and monitor both performance and business metrics.

Measurement plan to validate CO2 reductions

1. Establish a baseline using both lab tests and real user monitoring for bytes transferred, CPU time, and key performance metrics such as largest contentful paint and total blocking time.
2. Map the largest bytes to specific files and origins and document their request frequency across common user journeys.
3. Apply changes behind a feature flag or on a subset of traffic to measure real user differences in bytes and performance. Use the same instrumentation to compare before and after.
4. Translate reductions in transferred bytes and device CPU into CO2 estimates with a documented methodology. Use a consistent conversion approach and report uncertainty rather than precise absolute numbers.

Four practical quick wins with implementation steps

1. Replace a heavy analytics provider with a lightweight alternative Identify the events you actually need for measurement. Implement a privacy focused, lightweight analytics solution for page view counts and essential engagement metrics. Gate detailed tracking behind consent so default page loads avoid extra scripts.

2. Lazy load offscreen images and defer noncritical CSS Apply native loading attributes for images where supported and use intersection observers for older browsers. Defer CSS that affects below the fold content and inline only critical CSS to speed first render.

3. Limit web fonts to essential weights and use font display swap Audit used font weights and remove unused variants. Preload the most important font file and use a swap strategy to avoid long blocking of text rendering.

4. Audit and eliminate unused JavaScript Run bundle analyzer and browser coverage reports to find dead code. Remove or lazy load rarely used modules and consider route based splitting to avoid shipping code to users who do not need it.

Operational checklist to keep page weight low over time

• Include a page weight budget in pull request checks so big increases are flagged before release.
• Require public justification for adding new third party scripts and include an expiration review date.
• Automate image optimization in the build or at the CDN edge to avoid manual mistakes.
• Monitor real user bytes and cache hit rates and trigger a review when a resource becomes a repeated top contributor to transfer.
• Run periodic audits of fonts and libraries to confirm they are still needed and update documentation for content editors so they avoid uploading unoptimized media.

Next steps for teams

Start with a short discovery sprint that combines a single lab audit and a review of top real user requests. Apply one high impact low risk change such as removing an unnecessary script or introducing image lazy loading. Measure, share results, and embed the changes into developer workflows so the savings persist as the site evolves.