The quick download:
A lighter website is faster, cheaper to deliver, and better for the planet.
-
Carbon Control in WebPageTest estimates emissions from the bytes transferred, the energy needed to move that data, and information about whether hosting providers use renewable energy.
-
Page weight drives the estimate, but hosting, caching, user geography, device, and browser scripts all shift the result.
-
Optimizations like compressing assets, right-sizing images, and removing unused code lower estimated emissions while improving Core Web Vitals and delivery costs.
-
Test your high-traffic pages under consistent conditions, then compare the results before and after each optimization.
Most of us associate carbon emissions with physical goods such as plastic bottles and coffee cups. Digital services also consume electricity across data centers, networks, and user devices. For website teams, one manageable source is data transfer: heavier pages usually require more network activity and device processing. They often load more slowly and cost more to deliver as well.
Estimates of the Internet’s total emissions vary because studies use different boundaries and calculation methods. The BBC has reported estimates near 2% of global emissions, often compared with aviation. Our World in Data reports that aviation produces about 2.5% of global CO2 emissions. The figures are not directly equivalent, but they show the scale of both activities. For website teams, the practical question is how to measure a site consistently and reduce avoidable data transfer.
How website emissions can be estimated
Carbon Control is an emissions-estimation capability within WebPageTest to help teams combine website performance data with modeled estimates of digital emissions.
The calculation considers the bytes transferred when a page loads, the estimated energy required to move that data, and whether the hosting provider uses renewable energy. Information about the hosting provider’s use of renewable power comes from The Green Web Foundation.
Each data source carries some uncertainty. Network energy use differs by region, provider, connection, and device, so the estimate uses averages instead of metering every request. Results may therefore vary across test conditions, even when the page itself has not changed.
The estimate is most useful when teams test the same page under the same recorded conditions and compare the results before and after an optimization. It is not an exact measure of emissions, a formal carbon-accounting system, or proof of regulatory compliance. Teams should use it as a practical guide and keep testing conditions consistent when tracking changes over time.
What changes a website’s estimated carbon emissions
Page weight has a strong influence on the estimate, but it is not the only factor. Several conditions can change the result:
- Hosting energy mix and the provider’s use of renewable power.
- Caching behavior, which changes how much data a returning visitor downloads.
- User geography, network connection, and device conditions.
- Processing demands from scripts running in the browser.
- Traffic volume, because total impact rises with the number of page views.
First and repeat views also produce different results. Browser caching usually reduces the data downloaded during a return visit. A page may therefore show a high estimate on its first load and a lower estimate on later loads. Teams should compare both views and record the test location, device, browser, and connection settings before drawing conclusions.
How to test website emissions
WebPageTest includes Carbon Control, an emissions-estimation feature that displays modeled emissions alongside page-performance data. A useful test should reflect the pages and conditions that matter to users:
- Test high-traffic templates and key journeys rather than only the homepage.
- Run each test several times to reduce the effect of normal variation.
- Test from locations that represent major user regions.
- Use devices and connection speeds that reflect common user conditions.
- Compare first and repeat views to measure the effect of caching.
- Keep the configuration consistent when comparing releases.
This reports estimated grams of carbon per minute and estimated CO₂ per new visit, alongside page-weight data. These figures become more meaningful when teams compare the same page under the same configuration.
WebPageTest performance summary showing page weight and estimated carbon emissions.
Pro users can also run no-code experiments in WebPageTest to compare proposed changes before deployment.
Which optimizations reduce data transfer
Many changes that lower estimated emissions also improve speed and reduce delivery costs. Common examples include:
- Compress HTML, CSS, and JavaScript.
- Remove unused JavaScript and CSS.
- Serve images at their display dimensions and use efficient formats.
- Subset fonts so browsers download only the characters a page needs.
- Optimize video format, resolution, and delivery behavior.
- Cache stable content to reduce repeated downloads.
- Lazy-load images and media below the visible page area.
- Review external service requests and remove those that do not justify their cost.
Consider a 2MB hero image served to every visitor. Replacing it with a compressed image sized for its display area can remove a large share of the page payload. The change can improve load speed, reduce bandwidth and CDN costs, and lower the modeled emissions estimate. Removing unused JavaScript can produce a similar result while also reducing browser processing.

Why website efficiency benefits performance and sustainability
Smaller page payloads can improve load times, reduce bandwidth and CDN costs, and lower modeled emissions. The same engineering work may also improve Core Web Vitals and the experience of users on slower or metered connections.
Carbon estimates should be treated as directional evidence, not exact accounting. Their strongest use is consistent comparison: test the same pages under the same conditions, prioritize the changes that remove unnecessary data or processing, and check the result after deployment.
For web-performance engineers, frontend developers, and platform teams, this creates a practical connection between sustainability and everyday engineering. A lighter site is usually faster and less expensive to deliver, while its modeled emissions estimate provides another signal for maintaining efficient digital services.
From page-level testing to continuous Internet visibility
A single page test establishes a baseline, but maintaining website efficiency requires a repeatable process. New images, scripts, tags, and external services can increase page weight with each release.
Teams can define performance and page-weight budgets for key templates, test those templates after significant changes, and compare the results with the baseline. Each test record should include the location, device, connection, first or repeat view, and WebPageTest configuration. Consistent settings make it easier to distinguish a code change from normal test variation.
WebPageTest supports page-level diagnostics and controlled experiments, helping teams evaluate specific website changes before deployment and verify the results afterward. For teams that need ongoing visibility, LogicMonitor Digital Experience extends this work across regions, networks, dependencies, and providers. This combination helps teams track individual website changes while also identifying broader delivery issues that may affect digital experiences.
Estimate your website’s carbon impact and find ways to reduce it.
LogicMonitor pairs performance data with modeled emissions estimates, so your team can deliver faster, leaner, and greener sites. Put Carbon Control to work on your highest-traffic pages today.
FAQs
How does Carbon Control estimate a website’s carbon emissions?
It models emissions using the bytes transferred when a page loads, the estimated energy needed to move that data, and whether the hosting provider uses renewable power (sourced from The Green Web Foundation). Because it relies on averages rather than metering every request, the result is directional evidence rather than exact accounting.
Why do carbon estimates change for the same page?
Network energy use varies by region, provider, connection, and device, so the estimate uses averages that can shift across test conditions. Caching also matters: a first view downloads more data than a repeat view, which can produce a lower estimate on later loads. For reliable comparisons, keep the location, device, browser, and connection settings consistent.
Which changes reduce a website’s estimated emissions?
Compressing HTML, CSS, and JavaScript, removing unused code, right-sizing images, subsetting fonts, caching stable content, and lazy-loading media all cut data transfer. These same optimizations usually improve load speed and lower bandwidth and CDN costs. Start with high-traffic templates and compare the results before and after each change.




