Forecasting website emissions before release
Shipping a new page element or API change can change bytes transferred, client CPU work, server compute and cache behaviour. Those changes translate into energy use and greenhouse gas emissions. Forecasting emissions ahead of deployment makes trade offs visible, reduces the risk of hidden climate cost, and helps teams choose lower impact alternatives without guessing.
When a forecast helps and who should own it
Forecasting is most useful for features that materially change network transfer, client runtime work, server compute, or request patterns. Examples include a new analytics integration, richer media experience, third party widgets, server side rendering changes, and API back end that increases call volume. Product managers should trigger the forecast. Engineers and performance or sustainability specialists should run the measurements and document the model.
High level approach
At a glance the method is simple. First establish a baseline for the affected pages or API endpoints. Second measure the incremental technical impact of the proposed change using lab tests and small scale experiments. Third apply traffic and device distribution to convert per visit or per request changes into aggregate energy. Fourth apply local grid carbon intensity to convert energy into CO2. Finally record uncertainty and acceptance thresholds so the result guides decisions.
Step by step forecast
- Define scope and metric
Decide the precise scope. Is the change a single page template, a set of API endpoints, or a site wide library? Choose a metric that aligns with decision making. Candidate metrics include bytes transferred per page, client CPU time per page, server CPU seconds per request, origin bytes per unique user, or CO2 per 1000 page views. Keep scope small for early features and expand as you gain confidence.
- Measure the baseline
Collect baseline data for the scoped pages or endpoints. Use lab tools such as WebPageTest or Lighthouse to capture network waterfalls and CPU timing for representative pages. Use server logs and APM to record current request count, average response size, and server CPU seconds per request. Capture typical device and network profiles that reflect your audience distribution.
- Measure the change in isolation
Create a test variant that implements only the proposed change. In a local or staging environment capture the same metrics as the baseline. For client side changes record additional bytes loaded, increase in main thread time, and change in layout or paint costs. For server side changes record additional CPU seconds, memory usage if it affects power significantly, and extra bytes served from origin versus CDN.
- Model real world exposure
Convert per visit or per request deltas into expected site level impact. Multiply the per event delta by projected event counts over the chosen reporting window. Apply audience weights for device class and network type if those affect client power. For server work apply cache hit ratio and expected traffic volumes to estimate additional origin compute.
- Convert resource use to energy
Translate network bytes and CPU work into energy. Use a clear formula for each resource. For network transfer use energy equals bytes transferred times network energy intensity in Wh per GB. For client CPU use energy equals CPU seconds times average device power in watts. For server compute use energy equals server CPU seconds times server power draw in watts times data center overhead factor such as PUE. Avoid hidden conversions. Record the source for every factor you use.
- Convert energy to CO2
Multiply energy by the carbon intensity of the electricity grid supplying the work. For client side that is the grid where the user is located if known. For server side use the hosting provider region. If exact location is unknown use weighted averages over your user distribution. Use the same time frame as your forecast because grid intensity varies hourly.
- Report results with uncertainty
Report a range instead of a single number. Include low, central, and high scenarios based on traffic, cache hit ratio, device mix, and grid intensity variation. Explain the assumptions and where additional measurement would reduce uncertainty.
Formulas to implement in a spreadsheet or script
Network energy per release equals additional bytes per event in GB times number of events times network energy intensity in Wh per GB.
Client CPU energy per release equals additional client CPU seconds per event times number of events times device power draw in watts converted to Wh.
Server energy per release equals additional server CPU seconds per request times number of requests times average server power draw in watts times data center overhead factor PUE converted to Wh.
Total CO2 equals total energy in kWh times grid carbon intensity in kg CO2 per kWh applied per region. If client and server electricity grids differ, compute each separately then sum.
Where to get the factors and measurements
Network energy intensity can be taken from published studies or measured providers. If you cannot find a measured value for your specific CDN and network, document the source you chose and why. Device power draw can be estimated from lab tests with the device class most common in your audience or from vendor specifications applied conservatively. Server power draw is best obtained from your hosting or cloud provider or from on premises power meters. Use the data center PUE published by your provider or a sector average if unavailable. Grid carbon intensity can be taken from open datasets that publish hourly values for regions.
Handling user distribution and geography
Apply a weighted distribution of users by device class and geographic region. For client side forecasts that are sensitive to device power, bucket users into device classes that reflect typical CPU power. For electricity carbon intensity use region level hourly or daily averages and weight them by traffic share. If you do not have precise geo data, use conservative defaults and document them.
Practical gating rules and acceptance criteria
Define thresholds aligned with business goals. For example set an acceptable increase in CO2 per 1000 page views, or require that any feature increasing bytes by more than a percentage must include a mitigation plan. Acceptance criteria should be simple, measurable and actionable. Embed the forecast into your pull request template so every feature that changes delivery or compute invites a forecast attachment.
Accuracy, verification and continuous improvement
A forecast is a model not an oracle. Reduce risk by validating forecasts after release using RUM and server telemetry. Compare the forecasted delta with observed delta and update your model factors where consistent bias appears. Over time store historical forecasts and outcomes to improve device power profiles, network intensity assumptions, and cache behaviour estimates.
Example illustrative calculation
Imagine a feature that adds 200 kilobytes of additional assets to a page. If the page sees 50 thousand views per month the aggregate additional transfer is 200 kilobytes times 50 thousand. Convert that to gigabytes and multiply by a chosen network energy intensity in Wh per GB to get additional Wh. Apply the grid carbon intensity for the hosting and for user countries to convert the energy to kg of CO2. Label every value as hypothetical and show both a low and high scenario that vary traffic and energy intensity. Use this worked example as a template for your spreadsheet so you replace placeholders with measured values from your site.
Tooling recommendations
Use lab tools such as WebPageTest and Lighthouse for per page measurements and to capture resource sizes and CPU timing. Use real user monitoring for deployment verification. Use server logs and application performance monitoring for origin request counts and server CPU seconds. Use public datasets for grid carbon intensity and your provider reports for PUE and data center region mapping. Automate the basic forecast in a script so it can be run in CI as part of a pull request check.
Common pitfalls to avoid
Do not treat bytes and CPU work as interchangeable. Network transfer and CPU both affect energy but map to different infrastructure and grids. Do not ignore cache hit ratio because a small increase in origin bytes can have a large effect if cache headers are not adjusted. Do not hide assumptions. If you guess a factor document it and tag it for validation after release.
Next steps to adopt forecasting at scale
Start with a simple spreadsheet template that captures baseline, delta, traffic and regional weighting. Add the forecast template to your feature request and pull request workflows. Run a verification check after release and maintain a log of forecast versus observed so your team can tighten assumptions. Over time you can convert the spreadsheet to a small service that pulls metrics from your analytics and server telemetry to produce forecasts automatically.
Forecasting is a pragmatic way to make environmental impact visible before code reaches production. The process is most valuable when it is lightweight, repeatable and paired with post release verification so the team learns and improves its assumptions.