The method

The measurement protocol

Grammage opens the page in a real browser and lets it live as it would at a visitor’s, always following the same protocol, called grammage-1. Everything that follows is therefore fixed in advance, and this is what allows someone else to repeat the measurement under the same conditions and find the same bytes.

The conditions

The network is not throttled, which does not change the bytes counted but can change what a page decides to load depending on the speed of its connection, and we come back to this in the limits. As for the phone processor, it is slowed down four times to look like a mid-range model.

The five steps

Scrolling is used to trigger everything that only loads when you get close to it, such as deferred images. When a page blocks the gesture, as a consent banner often does as long as it has not been answered, Grammage scrolls it by script, as EcoIndex does, without ever answering the banner, neither to accept nor to refuse, and the report says so. The measured page then looks more like the one seen by a visitor who refuses cookies. When the content scrolls inside a large block of the page rather than in the window, as in some applications, it is that block that Grammage scrolls.

The initial load and the whole page

Grammage keeps two views of each pass. The initial load gathers what arrived during loading and while waiting for calm, so before scrolling, and it is the one the score compares, because that is how the HTTP Archive measures the pages our benchmarks come from. The whole page adds scrolling and observation, and it is the one carbon counts, since what a visitor makes the browser download while scrolling down also counts for energy. An image loaded only at the bottom of the page therefore does not weigh on the score, just as it does not weigh on the benchmarks, whereas it does weigh on the carbon estimate.

What is recorded

The pages of a site and their templates

Grammage tests one page when it is given its address, and the score it returns then only applies to that page. For a whole site, it reads the sitemap, or follows the links of the page when there is none, then keeps three pages per template and fifty in all, and each one is measured as a separate page, with its own score.

The template is first read from the address, so /blog/an-article and /blog/another-one share /blog/*. When a site puts its pages at the root, the address no longer says anything, so Grammage compares the skeleton of the HTML, the tags and classes of the content without the text, the header, the menu or the footer. An application drawn in the browser, whose HTML is almost empty, is not grouped this way, and without a sitemap the same grouping is done on the page rendered while following the links.

The weight of each page in the site

The result of the site, its score, its average carbon per page and its average initial weight, is the average of its measured pages, in which each one counts for the share of the site it represents. A product page measured among three, on a sitemap that has two thousand of them, thus weighs about 667 pages, and the home page weighs one. When the site is discovered through its links rather than through a sitemap, the size of each template is not known and each page counts equally. Since Grammage does not know the traffic of each page, the carbon of a site is an average per page of the site, never per page view, and nothing is said about a whole site from its home page alone.

Pages that cannot be measured

A page that answers with an anti-robot challenge, the one from Cloudflare or DataDome, or with a refusal from Akamai, Imperva, HUMAN or Kasada, is declared not measured rather than scored, since what would have been weighed is not the real page. In our corpus, these services refused twelve of the thirty online shops and six of the thirty news sites. A customer whose site is protected this way adds to the allow list of their service the agent that contains Grammage/, because Grammage never tries to pass itself off as a human visitor.

From weight to carbon

Directly measuring the energy a page consumes, at each visitor, on each network and in each data centre, is impossible from the outside. Grammage therefore estimates it with a published model, Sustainable Web Design in its version 4, which the collective of the same name maintains and which the CO2.js library of the Green Web Foundation implements, in its version 0.19. The model starts from the bytes transferred, translates them into energy spread between the data centres, the network and the visitor’s device, hardware manufacturing included, then translates that energy into carbon with the intensity of the electricity.

The constants of the model

A gigabyte here is one billion bytes. The model spreads 1,581 TWh per year, of which 1,021 for use and 560 for manufacturing, over the traffic of the Internet, and it obtains 0.300 kWh per gigabyte, that is 0.194 for use and 0.106 for manufacturing.

Manufacturing is counted in terawatt-hours of electricity equivalent, which explains why it is then multiplied by an intensity like use. These totals come from estimates that differ a lot from one source to another, and with another traffic denominator, the use coefficients of data centres and networks would be about 20% higher, which is why carbon is kept as an estimate and not as a measurement.

The formulas

GB            = bytes / 10⁹
use           U(s) = GB × ε_use(s) × I(s)
manufacturing F(s) = GB × ε_manufacturing(s) × 494
first view    = U(centre) × (1 − H) + F(centre) + U(network) + F(network) + U(device) + F(device)

s   the segment: data centre, network or visitor’s device
ε   the energy per gigabyte from the table, in kWh
I   the electricity intensity of the segment, in g of CO₂ eq. per kWh (494 by default)
H   1 when the host is recognised as green, 0 otherwise

Use takes the electricity intensity of the segment, 494 g per kWh by default, the world value of the 2022 Ember set that Sustainable Web Design recommends. Manufacturing always keeps 494, even when a local intensity is set, because almost all digital hardware goes through a worldwide supply chain. A host that the Green Web Foundation recognises as green only removes the electricity use of the data centre, never its manufacturing nor the rest of the chain, which takes 0.055 out of 0.300 from the world factor, that is 18.3% of the total.

Grammage counts a first visit, so without any reduction for the cache, which matches the CO2.js defaults for version 4. This is the figure, the most cautious one, that Grammage puts forward and that the badge displays, because it depends on no assumption about your audience and it can be compared with the Web Almanac statistics, which use the same calculation. It counts the whole page, scrolling included, whereas the score only looks at the initial load.

A step-by-step calculation

Take a page that transferred one megabyte, that is 0.001 GB, to a host that the Green Web Foundation does not recognise as green, with the world intensity of 494 g per kWh everywhere. The data centre consumes 0.001 × 0.055 kWh of use, that is 0.000055 kWh, which we multiply by 494 to find 0.0272 g, and the same operation is repeated for each segment and for manufacturing.

Use and manufacturing added together give 0.1482 g, which comes down to 0.3 kWh per gigabyte multiplied by 494 g per kWh, that is 148.2 g per gigabyte. A page of 2.4 MB gets 0.356 g in the same way.

The local estimate

Next to the main figure, the report gives a local estimate, which uses the electricity of the country of your audience for the network and the device, France by default, and the one of the country of the server for the data centre when it is known. The country of the server is deduced from its IP address, and when it is not known, the data centre keeps the 494 g of the world. Manufacturing always stays at 494, so that, for an audience and a server in France, use becomes almost negligible and the result hardly depends on anything but manufacturing. This estimate never replaces the main figure, because it depends on assumptions that we choose, but it gives an order of magnitude closer to the reality of a French site.

These annual intensities are those of 2025, built into CO2.js, and France illustrates their fragility well since Electricity Maps gives 60, 91, 49, 33 then 31 g per kWh from 2021 to 2025. Finally, the report translates the grams into equivalences drawn from the public factors of ADEME, in kilometres by car or in web searches for example.

Putting the grams in context

The verification page places the grams of a site on the Sustainable Web Design carbon rating scale, per view. The steps are inclusive, a page of 0.079 g is still an A.

Categories and their thresholds

An online shop does not have the same needs at all as a presentation site, so Grammage never compares a page with the whole web but only with the pages of its category. There are six of them, and each one has its own benchmarks, taken from the Web Almanac data, the yearly HTTP Archive study of millions of sites. Since the Web Almanac sorts sites by technology rather than by kind, each category takes up the technologies that fit it best, and its benchmark is computed from them.

How the category is chosen

Whoever measures can declare the category, with the --category option of the command line or the category field of the API, where it is showcase by default. They can also write auto, and Grammage then deduces the category of each page itself, rather than letting someone pick the most lenient one. To do so it reads what the page already publishes for search engines, its schema.org types, in JSON-LD or in microdata, its og:type and its generator tag, as well as the platform it has recognised. It looks for the hints in the order of the table, and the first category for which it finds one wins.

The presentation and application categories are never deduced, they have to be declared. Each page keeps its own category, so on the same site a product page is compared with product pages while the blog article is compared with articles, and the report states through score.context.inferred when the category was deduced.

Where the benchmarks come from

Each category has two weight benchmarks, the “good” one, which is the 25th percentile, that is the weight under which the lightest quarter of pages sit, and the median. The median comes from the Web Almanac 2024, Sustainability chapter, which gives the median weight of each technology, separately on phone and on computer. Grammage averages these medians over the technologies of the category, weighting each by its number of pages, which gives for example 2,688 KB for showcase on phone. The 25th percentile is then deduced from this median, by multiplying it by the ratio that the Web Almanac 2025, Page Weight chapter, gives between the 25th percentile and the median of the home pages of the whole web, that is 0.497 on phone and 0.507 on computer. The “good” benchmark is therefore about half the median, with 1,336 KB for showcase on phone.

The request benchmarks come from the Web Almanac 2025, Page Weight chapter, and those for the DOM from the Web Almanac 2024, Markup chapter. The former depend on the type of page, the home page when the address is the root and an inner page otherwise, the latter only on the device, and neither changes with the category.

The same technology can feed two categories, WordPress, Drupal and Joomla for showcase and editorial, Gatsby for presentation and application, which explains why showcase and editorial have almost identical weight benchmarks.

A curve set by two benchmarks

For weight, requests and the DOM, Grammage places the page on a log-normal curve, the same as Lighthouse, set by two real benchmarks of the category. A page as light as the lightest quarter of pages, the 25th percentile, gets 0.9, a page in the average, that is at the median, gets 0.5, and the score slides gently between the two and beyond, with no staircase step. A page as far above the median as the good benchmark is below it gets 0.1, which comes down to about twice the median, and an almost empty page approaches 1 without ever exceeding it.

z     = ln(measure / median) × 0.9062 / ln(median / good)
score = erfc(z) / 2

good     the “good” benchmark, the 25th percentile of the category
median   the “median” benchmark of the category
erfc     the complementary error function
0.9062   the value that gives 0.9 to the page equal to the “good” benchmark

From benchmarks to letters

The letter thresholds are the points where this curve crosses real benchmarks. An A starts at 90, the score of the “good” benchmark, so at the level of the lightest quarter of pages. A C starts at 50, the score of the median, and an E at 10, the score of a page about twice as heavy as the median, then below 10 the page gets an F. Between these three benchmarks, a B starts at 70 and a D at 30, which cut in half the score gap between two neighbouring benchmarks. Take the weight of a showcase page on phone, whose median is 2,688 KB and whose “good” benchmark is 1,336 KB, and look at which weight the curve gives each threshold.

These weights are read on the score of the weight alone. The score of the page then adds up its five parts, so it reaches 90 only when the page is at the level of the lightest quarter on every criterion, which is what an A means. Requests and the DOM follow the same curve with their own benchmarks, which gives them other thresholds, for example 43 requests for the A and 75 for the C on the home page of a phone.

The score out of 100

The score goes from 0 to 100 and compares the page with those of its category, which the previous section explains. It adds up five parts, with the following weights.

The five parts

Each part receives a score between 0 and 1, which is multiplied by its weight, and the score of the page is the sum of these points divided by the weights counted only, then rounded to the nearest integer, with halves going to the even integer. These weights are a choice of method, which we publish. Weight wins out because it is the quantity that the carbon model multiplies, requests and the DOM each count for half as much, good practices catch what neither the weight nor the count sees, and hosting weighs less than what the page makes thousands of visitors download. Weight, requests and the DOM are those of the initial load, before scrolling.

Good practices and hosting

The good practices part is the sum of the weights of the rules that pass, a rule that is half followed counting for half, divided by the sum of the weights of the rules that apply to the page, and the full list is in the next section. The hosting part is 1 when the Green Web Foundation recognises the host as green or when the server is in a country whose electricity emits less than 100 g of CO₂ per kWh, 0 otherwise. When the hosting cannot be known, behind a CDN like Cloudflare that hides the real server, this part leaves the calculation, and the score is computed on 90 points scaled up to 100, because we prefer to say nothing rather than punish a page for something we do not know.

A worked example

On 29 September 2026, the home page of solyzon.com was measured with the phone profile, in the showcase category. The four parts counted earn 28.2, 11.85, 0.75 and 24 points, that is 64.8 out of 90, and 64.8 multiplied by 100 and divided by 90 gives 72, a score of 72 out of 100. Almost everything that is missing comes from the DOM, with twice as many elements as the median.

The letters

The report and the badge only display the score out of 100, because a letter on its own reads like an official verdict that Grammage has no business giving. The letter is used to place the score on the verification page, next to the Sustainable Web Design scale, and as a threshold in your CI, through GRAMMAGE_FAIL_UNDER.

The fifteen rules

The rules come from the 115 web eco-design good practices of the Green IT collective, which we identify by their RWEB number, from the general eco-design framework for digital services of Arcep and Arcom, the RGESN 2024, and from the W3C Web Sustainability Guidelines, the WSG, in their December 2025 draft. Each rule is worth 1, 2 or 3 depending on how much it really weighs on the footprint. A rule that passes earns its whole weight, a rule that is half followed, what we call “to watch”, earns half, a failed rule earns nothing at all, and a rule that does not apply to the page, a rule about videos for a page without video for example, leaves the calculation.

Vector images, the SVGs, are left out of the resizing and lazy loading rules, since a vector drawing is drawn at any size without weighing more, but their bytes are still counted in the weight of the page like those of any other resource. For fonts, font-families only counts those that are downloaded, the local() fallbacks do not enter into it. The RGESN references point to eight criteria of the framework, which the report uses in an eco-design declaration aid.

What each fix would bring

Each good practice that is not met comes with its fix and with the gain you can expect from it on every view, so that you start with what really weighs. This gain is computed on the real weight of the offending files, recorded during the measurement, to which we apply a deliberately cautious share, drawn from published studies rather than from the best case, then it is translated into carbon by the same model as everything else, with the same host.

bytes saved      = sum, over each offending file, of bytes transferred × share
carbon saved     = Sustainable Web Design v4 applied to the bytes saved

oversized image share = 1 − (useful width / real width)²
                  useful width = min(real width, displayed width × screen density)

For images that are too large, we do not take a fixed share but the surplus area, since an image twice too wide in each direction carries four times the useful pixels, and we compute it with the width it has on screen, multiplied by the density of the simulated screen. The other good practices, a missing description or too many domains for example, have no gain that can be put in bytes, and the report does not invent one. The report also replays the score with the fix applied, on the initial load, to say how many points it would bring, and this is what allows the advice to be ranked.

What validates the method

A published method is only worth something if its figures can be reproduced and agree with what others measure, so we checked three things, that the measurement repeats, that the benchmarks hold up against real pages, and that our way of measuring finds the same as other tools.

The measurement is reproducible

On 29 September 2026, we measured eight sites three times during the night, with the phone profile, on an Apple M4 Pro with Chromium 153 and Playwright 1.63, through three successive versions of the engine that share the same protocol. Each cell gives the three values in order.

Weight, requests and the DOM repeat within 0.6% on seven sites, the largest gap being one more request out of 167 for zetelecom.fr. The only exception is kmc-events.fr, whose page changes by itself from one load to the next. Computing time varies from simple to double and up to almost six times for kmc-events.fr, which explains why it is shown but not scored. A measurement made from the CI Docker image also gives the same figures as one made on a workstation, 1,584 KB, 66 requests and 1,215 elements for solyzon.com in both cases, within one kilobyte.

The benchmarks against real pages

During the night of 29 to 30 September 2026, we measured one hundred and eighty home pages, thirty per category, mostly French and European, with a single pass per page, four pages at a time and the category of each list declared. The table compares the measured initial weight with the Web Almanac benchmarks.

Showcase, editorial and application hold their benchmarks, with a median score between 51 and 52 whereas the average page of a category gets 50. Presentation and documentation measure about 30% less than the Web Almanac, but our corpus there is made mostly of tool sites for developers, probably more frugal than average, so this gap says something about the corpus rather than about the benchmarks. E-commerce is the least reliable category, because twelve shops out of thirty refused the measuring browser and the remaining eighteen are mostly large retailers, which does not allow a conclusion. A modified benchmark changes scores already published, and this comparison did not modify any.

Against other tools

The same day, we read the latest public results of EcoIndex and Digital Beacon on seventeen pages, without relaunching anything on their side. When ecoindex.fr tested the page recently, the EcoIndex that Grammage computes on its own measurement falls exactly on theirs, and the gaps come from old results or from pages whose content moves from one day to the next.

Digital Beacon goes through PageSpeed Insights, so through Lighthouse, which does not scroll the page, and it weighs about the same the pages that load nothing while scrolling. On a page that loads while scrolling, it stays at the initial load and is far from the whole page.

Digital Beacon’s grams are on the other hand two to three times higher than ours for the same weight, 0.164 g against 0.07 g for gohugo.io, because it still applies the former Sustainable Web Design v3 model, which counted much more energy per byte than v4. The three tools rank the pages in the same order, docs.python.org first, doctolib.fr and framasoft.org last, but they differ on the letter, because they do not ask the same question. EcoIndex judges the whole page in absolute terms, on quantiles fixed since 2016, Digital Beacon judges the grams on the Sustainable Web Design scale, and Grammage judges the initial load against the pages of the same category.

The limits of the measure

It is not an energy measurement. Carbon is an estimate based on a model, which takes bytes as an indicator of energy without measuring the processor or the memory of the device, and its own authors consider it poorly suited to spotting what should be optimised in a page. Two pages of the same weight therefore get the same estimate, even if one makes the phone work much harder. The authors also do not publish a quantified margin of error, and their sources differ a lot from one another.

The server remains partly invisible. Grammage does not see what the server does to build the page, and behind a CDN, that is a network of relay servers, it does not even know where the origin server is, so it leaves it unknown rather than guess. Six of the eight sites of our September 2026 campaign went through Cloudflare, for which the Green Web Foundation answers in place of the real host, whereas Website Carbon counts them as green, which takes 18% off its figure.

The carbon of the whole page assumes that a visitor scrolls to the bottom, which probably overestimates long pages, such as those of media sites. And the return visit, measured from 0% to 10.3% of the first load depending on the site, is not deducted from the main figure.

Computing time is not scored, because it still varies from simple to double from one measurement to the next. The network is not throttled during the measurement, which does not change the bytes counted but can change what a page decides to load depending on the speed of the connection. A page that changes by itself, with randomly drawn content or ads, does not weigh the same at each visit, and the median of three passes only erases part of this gap.

The benchmarks come from the Web Almanac, that is from real sites, and not from a target. A page that holds the median of its category gets 50, which does not say it is frugal. And a page protected by an anti-robot service cannot be measured at all.

The versions

Each report carries three versions, the one of Grammage, the one of the measurement protocol and the one of the scoring method. The protocol only changes if what is measured changes, and the scoring changes when the benchmarks, the weights, the reference data or what is compared change. Two scores can only be compared if they share the same protocol and the same method, and an old report always keeps the letter and the benchmarks of the method it names, in its score.method field.

The sources

Each figure on this page comes from one of these sources, from a measurement that Grammage made itself or from a calculation that can be redone from them. The country of a server is deduced from its IP address by RIPEstat, and the intensity data are those that CO2.js embeds.

• Sustainable Web Design, emissions estimation model
• Sustainable Web Design, carbon rating scale
• International Telecommunication Union, Internet traffic in 2022
• Malmodin, 2023, split between use and manufacturing of hardware
• Green Web Foundation, CO2.js and the verification of green hosts
• Electricity Maps, annual electricity intensity methodology
• HTTP Archive, Web Almanac 2024, Sustainability
• HTTP Archive, Web Almanac 2024, Markup
• HTTP Archive, Web Almanac 2025, Page Weight
• Lighthouse, performance scoring calculation
• EcoIndex, published method
• ADEME, Impact CO2, equivalence factors
• Green IT, 115 web eco-design good practices
• Arcep and Arcom, RGESN 2024
• W3C, Web Sustainability Guidelines
• European Union, directive (EU) 2024/825