Green IT Tests: Measure the Actual Weight of Your Routes

The load transferred and the number of requests for a complete user journey, broken down by resource type and the proportion of third-party domains. This is objective data, measured during scenario execution, and comparable from one week to the next.

The test provides the input data for such a calculation, not the calculation itself. Converting kilowatts to carbon equivalent involves assumptions about the energy mix and the device fleet, which are part of your methodology rather than the test tool.

They overlap without being the same. A heavy page is often slow, but a light page can be slow due to a slow-responding backend service, and a heavy page can seem fast on a good connection. The two metrics should be considered together.

Start with your own history rather than an external standard. The primary goal isn't to reach a target weight, but to prevent weight gain: use your current weight as a baseline and refuse to let it increase without an explicit decision.

Yes, provided you define the scope. A series of dated measurements along identified routes constitutes solid, verifiable data—far more defensible than a general estimate produced once a year. Whether it’s CSRD reporting, a carbon footprint assessment, or a response to a request for proposals that requires numerical indicators, in all three cases, it is the dated measurements linked to an identified route that hold up to scrutiny.

Five: the size of loaded resources, the number of requests, the number of elements in the DOM, greenhouse gas emissions in grams of CO2 equivalent, and water consumption. Each metric is compared to a reference median, which places the page relative to typical usage.

A score out of ten and a rating from A to G. The score alone doesn't tell us much: it's the deviation from the medians that indicates where action is needed—most often regarding the weight of resources and the number of requests.

On pages that are part of a user journey. This means you’re measuring the footprint of the actual path your users take, not that of an isolated homepage, which accounts for only a fraction of the traffic.

Yes, a dashboard shows how page scores have changed over the selected time period. This allows us to verify that a site optimization effort is having an effect—and that a new feature isn’t undoing it three months later.

Yes, in the same scenarios. A dedicated block retrieves the Green IT score of the running application, and you set a threshold for it just as you would for any other check: if the score exceeds that threshold, the discrepancy is reported as an incident. A mobile session is therefore monitored just like a web session, without the need for a separate tool.

They do exist, and that's exactly what they're designed for. The difference here is that there are no additional tools to run and no test sequences to rewrite: the metrics are collected during the tests you're already running—both on the web and on mobile—at the same time and in the same report.