Why targeted removal yields the biggest CO2 wins

Every byte transferred and every millisecond a device CPU spends processing a page contributes to per visit carbon. Removing weight blindly can waste time and harm experience. Prioritising removals by expected transfer reduction, frequency of use and business value produces the fastest wins for carbon and speed. The list that follows helps teams perform a fast triage and then validate real impact with measurements.

How to prepare before you start removing things

Measure current state so you can prioritise and prove savings. Capture at minimum the following for representative pages and traffic types: total transfer size, number of requests, time to interactive, largest contentful paint, main-thread CPU time and which third-party domains are contacted. Use repeatable tools such as Google Lighthouse, WebPageTest and a server access log or a synthetic tracing system to capture transfer bytes and requests. Record a baseline carbon estimate using a public calculator or your organisation’s method so changes map to concrete CO2 outcomes.

Quick checklist to establish a baseline

1. Run Lighthouse and WebPageTest for primary page templates and representative connection profiles.
2. Record transfer bytes and main thread CPU for both mobile throttled and desktop scenarios.
3. List third-party scripts by domain and note their transfer size and execution time.
4. Capture media assets larger than 100 kilobytes and any autoplaying media.

Prioritised removals: the order that usually yields the largest CO2 reduction

The following ordered list is a practical triage. Each item includes why it matters, how to verify its cost, and replacement or mitigation options. Treat this as a starting framework and adapt based on your measured baseline.

1. Remove unnecessary third-party trackers and pixels

   Why first. Third-party trackers commonly load multiple resources and execute JavaScript that runs on every page view. They are often loaded site wide but provide limited incremental value for many pages, so removing them often cuts both transfer and CPU across the whole site.

   How to verify. Inspect network waterfall and identify script domains with the highest combined transfer and blocking time. Compare transfer and CPU with and without the script by selectively disabling it in a test environment or via a tag manager.

   Alternatives. Keep only essential analytics and measurement. Consider server-side measurement or privacy focused analytics that send fewer client side bytes.

2. Remove or defer non-critical JavaScript

   Why. Large JavaScript bundles increase transfer and force device parsing, compilation and execution. Non-critical code that runs after initial interaction is often a major source of main-thread work and device energy.

   How to verify. Identify large bundles and slow parse/compile times in developer tools or Lighthouse. Use code coverage reports to find unused code sections.

   Mitigation. Split code with dynamic imports, mark non-essential scripts with defer or async, and enforce a strict performance budget to prevent regressions.

3. Eliminate autoloading video and large hero media

   Why. Video and high resolution hero images typically create the largest single transfer items on a page and often play or preload unnecessarily on initial view.

   How to verify. Find media resources by size in the network panel. Test page load with media blocked to see the delta in transfer and time to interactive.

   Alternatives. Replace autoplay video with a poster image and user-initiated playback. Use adaptive streaming for necessary video or defer loading until user interaction or viewport intersection.

4. Remove unused or rarely used web fonts

   Why. Each font file is additional bytes often fetched on every page view. Multiple weights and character subsets multiply the cost.

   How to verify. Audit font requests and group by file size and weight. Compare transferrable bytes with subsets or by removing fonts temporarily.

   Mitigation. Use a system stack for low value pages, subset fonts to required characters and weights, prefer WOFF2, and preload only critical fonts needed for initial render.

5. Replace large raster images or multiple image variants with efficient formats and lazy loading

   Why. Images usually account for a large portion of transfer. Unnecessary high resolution images serve bytes that may never be displayed, especially on mobile.

   How to verify. Use the element sizes and network panel to map image file size to displayed size. Run an audit for images larger than their display size.

   Mitigation. Serve responsive images with width descriptors, use modern formats such as AVIF or WebP where supported, deliver properly compressed images, and lazy load offscreen images.

6. Remove heavy visual effects and complex animations

   Why. Excessive animations can cause sustained main-thread activity and GPU work on devices. They add runtime cost even if the transfer size is small.

   How to verify. Use the performance profiler to identify long-running animation frames and paint lists. Measure CPU during animations on representative devices.

   Mitigation. Prefer CSS transforms with will-change sparingly, reduce animation duration and frequency, and avoid continuous JS-driven animations on mobile.

7. Trim CSS and remove legacy polyfills and frameworks not used by users

   Why. Large CSS bundles increase transfer and can delay render. Legacy polyfills may be unnecessary for modern browsers and add both bytes and execution time.

   How to verify. Generate coverage reports for CSS and JS. Check browsers in use to decide if polyfills are still required.

   Mitigation. Run tree shaking, purge unused CSS in the build step, and conditionally load polyfills using feature detection.

8. Reduce or rationalise advertising and real time personalization payloads

   Why. Ad networks and personalization systems often inject multiple scripts, trackers and large creatives. They can also trigger frequent network activity after initial load.

   How to verify. Map ad-related domains and resources. Measure transfer and CPU attributable to these components and compare revenue per byte where possible.

   Mitigation. Limit the number of ad vendors, lazy load ads until view, and set size and request limits for creative assets.

9. Remove client side rendering where server rendering is sufficient

   Why. Full client side hydration of large frameworks can dominate main-thread time even after the network payload is delivered.

   How to verify. Compare the CPU time for hydration in a profiling trace and run an A/B where pages render server side without hydration.

   Mitigation. Adopt server rendering, partial hydration or island architectures so only interactive parts hydrate on the client.

How to decide what to remove first for your product

Apply a simple prioritisation formula that combines three factors. Multiply estimated transfer reduction by annual page views for the template and then divide by the estimated business value lost if the asset is removed. This ranks changes by potential carbon impact per unit of business cost. Where you cannot compute exact numbers, use categories such as high, medium and low for each factor and prioritise high impact, low cost items.

Decision criteria to guide trade offs

1. Is this loaded on every page or only a few pages? Site wide elements have higher priority.
2. Does the asset meaningfully affect user conversion or legal compliance? If yes, prefer mitigation over removal.
3. Is there a lightweight alternative that preserves value? If yes, plan substitution rather than removal.

How to measure CO2 impact responsibly

Link changes to carbon using an agreed method. The most defensible approach captures two elements. First measure bytes transferred and device CPU impact for a page view. Second map those measurements to a carbon intensity value appropriate for the hosting and predominant user regions. If a precise regional carbon intensity is not available, use an established public calculator for comparability. Report both the raw change in bytes and CPU time and the derived change in estimated CO2 so stakeholders see both technical and environmental improvements.

Testing and rollout guidance

Always run changes behind experiments or feature flags. Start with a small traffic slice and monitor both performance metrics and business metrics such as conversions and engagement. For assets that affect measurement or ad revenue, run controlled experiments that track revenue per visit in addition to technical metrics. Use synthetic tests for steady state measurement and field metrics for real world validation.

Monitoring to prevent regression

Integrate transfer size and main thread time into continuous monitoring. Enforce thresholds in pull requests with automated Lighthouse checks and fail the pipeline when budgets are exceeded. Maintain a lightweight registry of third-party scripts with owner, purpose and an expiry review date so scripts are audited regularly.

Practical examples of immediate, low-risk removals

Examples that commonly deliver quick wins without harming user experience include removing non-essential marketing pixels from low funnel pages, disabling autoplay on hero media, switching non-critical pages to system fonts, and lazy loading offscreen images. These changes are typically reversible and easy to A/B test.

Operational rules to keep pages light over time

Adopt a performance budget, require a justification and owner for every new third-party script, run periodic audits of fonts and media, and include transfer size targets in design handoffs. Make performance and carbon metrics part of the release checklist so regressions are caught early.

Next steps for teams

Start with the triage list, measure the baseline, remove one high priority item for a single template, and measure impact. Use the results to refine the prioritisation and formalise the policy changes needed to prevent reintroduction of heavy assets. Small, repeated removals across templates compound into substantial CO2 reductions over time.