The audit

Run an audit

The simplest way is the free trial at the top of the home page, which measures a page without installing anything or creating an account and returns the full report, with its score and everything that needs fixing. The same measurement can also be run through the API, three times a day per domain, and it is in fact exactly the same engine that then runs in your CI, where it has no limit at all since it runs on your side.

curl -s https://api.getgrammage.com/v1/tests \
    -H 'content-type: application/json' \
    -d '{"url": "https://example.com/"}'

include:
    - project: solyzon/products/grammage/grammage
      ref: prod
      file: ci/grammage.gitlab-ci.yml

grammage:
    extends: .grammage
    needs: [preview]
    variables:
        GRAMMAGE_CATEGORY: auto

grammage audit https://example.com/ --mode fast --format html,agent
grammage audit --site https://example.com/ --category auto --parallel 4

Try it for free

A real visit, in five steps

Grammage does not read the code of the page to guess what it weighs, it really visits it, and always in the same way, following a fixed protocol called grammage-1.

Each page is measured three times, and the report keeps the middle value of each quantity, so that one pass that happens to be slow or heavy does not distort the result. The simulated phone has a 412 × 823 pixel screen and a processor slowed down four times, to look like a mid-range model, and the computer has a 1,920 × 1,080 pixel screen. In our September 2026 tests, the weight, the requests and the number of elements are reproduced to within 1% from one measurement to the next, except when the page itself changes from one load to the next.

What is recorded

During these passes, Grammage records everything that weighs on the footprint of the page. Part of it goes into the score, and the rest is still shown in the report, either because it varies too much from one measurement to the next to be scored honestly, or because it is more about speed than about footprint, but it really helps to understand where the energy goes.

What goes into the score

What is shown without being scored

The score out of 100

The score adds up five parts, weight, requests, the number of DOM elements, good practices and hosting, and compares the page with those of its category. The weight of each part, the curves and the benchmarks are detailed on the method page.

The fifteen good practices

The rules come from the 115 web eco-design good practices of the Green IT collective (the RWEB references), from the general eco-design framework of Arcep and Arcom (the RGESN) and from the W3C Web Sustainability Guidelines (WSG). Each is worth 1, 2 or 3 depending on what it really weighs on the footprint, a rule that is half followed earns half of its weight, and a rule that does not apply to the page, a rule about videos for a page without video for example, simply leaves the calculation.

Each rule that is not followed comes with its fix and with the gain you can expect on every view, in bytes and then in carbon, calculated on the real weight of the offending files, so that you start with what really weighs.

Fixes written for your framework

The score never depends on the framework, since Grammage measures the page as the browser receives it. What changes with the framework is the way to fix, and advice that only says to “serve images as WebP” does not gain much for someone working on Nuxt, whereas <NuxtImg format="webp"> saves them time right away. Grammage therefore recognises the framework of each page during the measurement, through the markers it leaves in the page, the addresses of its files, its cookies and its generator tag, and it accompanies each generic fix with the one that is specific to it.

• Nuxt
• Next.js
• Astro
• WordPress
• SvelteKit
• Laravel
• Shopify
• React
• Vue
• Gatsby
• PrestaShop
• Django
• Symfony
• Drupal
• Joomla
• PHP
• Remix
• Angular
• Webflow
• Wix
• Hugo

<picture>
    <source srcset="/hero.avif" type="image/avif" />
    <img src="/hero.webp" alt="" width="1200" height="630" loading="lazy" />
</picture>

<template>
    <NuxtImg src="/hero.jpg" format="webp" sizes="100vw md:50vw" loading="lazy" />
</template>

import Image from 'next/image';

export function Hero() {
    return <Image src="/hero.jpg" alt="" width={1200} height={630} sizes="100vw" />;
}

---
import { Image } from 'astro:assets';
import hero from '../assets/hero.jpg';
---

<Image src={hero} alt="" format="webp" />

A Symfony without its bundles/ or a Django that sets no cookie often leave no trace in the page, and Grammage then gives the generic fixes, which remain right for everyone. It never guesses a framework it has not really recognised.

The whole site

For a whole site, Grammage reads its sitemap or follows its links, groups the pages by template and measures each one as a separate page, then draws a result for the site. The rules behind this choice and this weighting are on the method page.

Sites protected against robots

A page protected by an anti-robot service is declared not measured rather than scored, and Grammage never passes itself off as a human visitor. What to allow on your service is explained on the method page.

The report

The same report comes out in several formats, chosen with --format, and it is the same everywhere, whether the measurement comes from the site, from the API or from your CI.

Handing the work to a coding agent

The grammage-agent.md brief says which site and which framework you are working on, then lists the fixes in the order in which they pay off the most, with the files to touch, the fix for the framework, the expected gain and the command that checks that the rule passes. It only contains what the measurement established, and never advice it does not back up.

Preparing an eco-design declaration

The RGESN helper takes, for each of the eight criteria of the framework that the measurement touches, the question asked, the Grammage rules that relate to it, what they give on your pages and the files recorded. It is not the declaration itself, which covers seventy-eight criteria, but rather the measured evidence to attach to it.