Produit
L'audit
Une analyse complète de votre site, page par page, dans un vrai navigateur
Sommaire
Lancer un audit
Le plus simple, c'est l'essai gratuit en haut de l'accueil, qui mesure une page sans rien installer ni créer de compte et rend le rapport complet, avec sa note et tout ce qu'il faut corriger. La même mesure se lance aussi par l'API, trois fois par jour et par domaine, et c'est d'ailleurs exactement le même moteur qui tourne ensuite dans votre CI, où il n'a plus aucune limite puisqu'il tourne chez vous.
curl -s https://api.getgrammage.com/v1/tests \
-H 'content-type: application/json' \
-d '{"url": "https://exemple.fr/"}'include:
- project: solyzon/products/grammage/grammage
ref: prod
file: ci/grammage.gitlab-ci.yml
grammage:
extends: .grammage
needs: [preview]
variables:
GRAMMAGE_CATEGORY: autogrammage audit https://exemple.fr/ --mode fast --format html,agent
grammage audit --site https://exemple.fr/ --category auto --parallel 4Une vraie visite, en cinq temps
Grammage ne lit pas le code de la page pour deviner ce qu'elle pèse, il la visite vraiment, et toujours de la même façon, en suivant un protocole fixe qu'on appelle grammage-1.
Le chargement
Chromium ouvre la page sans fenêtre, comme le ferait le navigateur de votre visiteur, et attend qu'elle se déclare chargée, une minute au plus.
L'attente du calme
Une page moderne continue souvent de travailler après son chargement, le temps que son JavaScript prenne la main, donc Grammage attend une seconde sans aucun échange réseau et presque sans calcul, quinze secondes au plus, parce que certaines pages ne se calment jamais.
Le défilement jusqu'en bas
La page défile écran après écran, par le même geste que la molette, pour déclencher les images différées et tout ce qui attend qu'on s'en approche. Grammage ne répond jamais au bandeau de cookies, ni pour accepter ni pour refuser, donc la page mesurée ressemble plutôt à celle d'un visiteur qui refuse, et le rapport le dit.
Trois secondes d'observation
Tout ce qui arrive encore est compté, un carrousel qui tourne ou une publicité qui se recharge par exemple, alors que la page ne devrait plus rien faire.
La visite de retour
Grammage revient sur la page avec le cache déjà rempli, pour voir ce qu'elle fait retélécharger à quelqu'un qui revient la voir.
Chaque page est mesurée trois fois, et le rapport garde la valeur du milieu de chaque grandeur, pour qu'un passage accidentellement lent ou lourd ne fausse pas le résultat. Le téléphone simulé a un écran de 412 × 823 pixels et un processeur ralenti quatre fois, pour ressembler à un modèle de milieu de gamme, et l'ordinateur un écran de 1 920 × 1 080 pixels. Sur nos essais de septembre 2026, le poids, les requêtes et le nombre d'éléments se reproduisent d'ailleurs à moins de 1 % près d'une mesure à l'autre, sauf quand la page change elle-même d'un chargement à l'autre.
Ce qui est relevé
Pendant ces passages, Grammage relève tout ce qui pèse sur l'empreinte de la page. Une partie entre dans la note, et le reste est quand même affiché dans le rapport, soit parce que ça varie encore trop d'une mesure à l'autre pour être noté honnêtement, soit parce que ça parle plutôt de vitesse que d'empreinte, mais ça aide vraiment à comprendre où part l'énergie.
Ce qui entre dans la note
| Grandeur | Ce qu'elle dit |
|---|---|
| Poids transféré | les octets qui ont vraiment circulé sur le réseau, compression comprise |
| Requêtes | leur nombre, une redirection comptant pour une requête de plus |
| Éléments du DOM | comptés comme EcoIndex, sans l'intérieur des dessins SVG |
| Bonnes pratiques | quinze vérifications, détaillées juste en dessous |
| Hébergement | vert selon la Green Web Foundation, et le pays du serveur |
Ce qui est affiché sans être noté
| Grandeur | Ce qu'elle dit |
|---|---|
| Page entière | le poids une fois la page défilée jusqu'en bas, qui sert au carbone |
| Temps de calcul | le temps de processeur de toute la visite |
| Activité au repos | le processeur et les octets qu'une page défilée consomme encore |
| Code inutilisé | le JavaScript jamais exécuté et le CSS jamais utilisé, fichier par fichier |
| Trames WebSocket | ce qu'échange un widget de discussion ou un fil en direct |
| TTFB, FCP, LCP, CLS | la vitesse du premier octet et du premier affichage, et la stabilité |
| Visite de retour | ce que la page retélécharge avec le cache déjà rempli |
| Carbone | les grammes de CO₂ éq. par visite, selon Sustainable Web Design v4 |
La note sur 100
La note additionne cinq morceaux, le poids, les requêtes, le nombre d'éléments du DOM, les bonnes pratiques et l'hébergement, et compare la page à celles de sa catégorie. Les poids de chaque morceau, les courbes et les repères sont détaillés sur la page de la méthode.
Les quinze bonnes pratiques
Les règles viennent des 115 bonnes pratiques d'écoconception web du collectif Green IT (les références RWEB), du référentiel général d'écoconception de l'Arcep et de l'Arcom (le RGESN) et des Web Sustainability Guidelines du W3C (WSG). Chacune vaut 1, 2 ou 3 selon ce qu'elle pèse vraiment sur l'empreinte, une règle à moitié tenue rapporte la moitié de son poids, et une règle qui ne concerne pas la page, une règle sur les vidéos pour une page sans vidéo par exemple, sort simplement du calcul.
| Règle | Poids | Réussie quand | Références |
|---|---|---|---|
text-compression | 3 | au moins 95 % des octets de texte de plus de 1 Ko arrivent compressés en Brotli, gzip ou zstd, et à moitié entre 90 et 95 % | RGESN 6.3, RWEB_0076, WSG 5.3 |
static-cache | 2 | chaque image, police, feuille de style, script ou média a une durée de cache, à moitié quand le navigateur ne peut que la deviner | RGESN 6.2, RWEB_0075, WSG 5.2 |
http2 | 1 | aucune ressource ne passe encore par HTTP/1 | RWEB_0083, WSG 5.12 |
redirects | 2 | une redirection au plus | RWEB_0112, WSG 5.4 |
http-errors | 2 | aucune requête ne répond une erreur, une 404 ou une 500 par exemple | WSG 5.4 |
domains | 1 | cinq domaines au plus | RGESN 6.7, RWEB_0082, WSG 3.5 |
no-polling | 2 | aucune adresse n'est redemandée deux fois pendant les trois secondes d'observation | WSG 5.11 |
image-formats | 3 | plus de trois images matricielles sur quatre sont en WebP ou en AVIF | RGESN 5.1, WSG 4.9 |
image-resized | 2 | aucune image n'est plus de deux fois plus large que son affichage, densité de l'écran comprise | RGESN 6.4, WSG 4.9 |
image-lazy | 2 | chaque image hors du premier écran porte loading="lazy" | RGESN 6.5, RWEB_0051, WSG 4.9 |
font-families | 2 | deux familles de polices au plus | RGESN 4.8, RWEB_0032, WSG 4.12 |
font-woff2 | 1 | chaque police est servie en WOFF2 | WSG 4.12 |
no-autoplay | 3 | aucune vidéo ni aucun son ne se lance tout seul | RGESN 4.1, RWEB_0106, WSG 4.9 |
no-infinite-animation | 1 | aucune animation sans fin ne tourne encore à la fin de la mesure | RGESN 4.1, RWEB_0009, WSG 4.10 |
meta-description | 1 | la page a une description, qui évite des recherches à répétition | RWEB_0011, WSG 3.8 |
Chaque règle non tenue arrive avec son correctif et avec le gain qu'on peut en attendre à chaque vue, en octets puis en carbone, calculé sur le poids réel des fichiers fautifs, pour que vous commenciez par ce qui pèse vraiment.
Des correctifs écrits pour votre framework
La note ne dépend jamais du framework, puisque Grammage mesure la page telle que le navigateur la reçoit. Ce qui change avec le framework, c'est la façon de corriger, et un conseil qui dit seulement de « servir ses images en WebP » ne fait pas gagner grand-chose à quelqu'un qui travaille sur Nuxt, alors que <NuxtImg format="webp"> lui fait gagner du temps tout de suite. Grammage reconnaît donc le framework de chaque page pendant la mesure, par les marqueurs qu'il laisse dans la page, les adresses de ses fichiers, ses cookies et sa balise generator, et il accompagne chaque correctif générique de celui qui lui est propre.
- 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" />| Framework ou CMS | Correctifs propres |
|---|---|
| Nuxt | images, compression, cache, polices, domaines, description |
| Next.js | images, compression, cache, polices, domaines, description |
| Astro | images, compression, cache, polices, domaines, description |
| WordPress | images, compression, cache, domaines, description, chargement à la demande |
| SvelteKit | images, compression |
| Laravel | images, compression, cache |
| Shopify | images, cache |
| React | images, requêtes répétées |
| Vue | images, requêtes répétées |
| Gatsby | images |
| PrestaShop | images |
| Django | compression et cache avec WhiteNoise |
| Symfony | correctifs génériques et ceux de PHP |
| Drupal | correctifs génériques et ceux de PHP |
| Joomla | correctifs génériques et ceux de PHP |
| PHP | compression et cache, au serveur |
| Remix | correctifs génériques |
| Angular | correctifs génériques |
| Webflow | correctifs génériques |
| Wix | correctifs génériques |
| Hugo | correctifs génériques |
Un Symfony sans ses bundles/ ou un Django qui ne pose aucun cookie ne laissent souvent aucune trace dans la page, et Grammage donne alors les correctifs génériques, qui restent justes pour tout le monde. Il ne devine jamais un framework qu'il n'a pas vraiment reconnu.
Le site entier
Pour un site entier, Grammage lit son sitemap ou suit ses liens, regroupe les pages par gabarit et mesure chacune comme une page à part, puis en tire un résultat pour le site. Les règles de ce choix et de cette pondération sont sur la page de la méthode.
Les sites protégés contre les robots
Une page protégée par un service anti-robots est déclarée non mesurée plutôt que notée, et Grammage ne se fait jamais passer pour un visiteur humain. Ce qu'il faut autoriser chez votre service est expliqué sur la page de la méthode.
Le rapport
Le même rapport sort dans plusieurs formats, choisis par --format, et c'est le même partout, que la mesure vienne du site, de l'API ou de votre CI.
| Format | Fichier | Ce qu'il contient |
|---|---|---|
html | grammage.html | le rapport à lire, page par page, avec les correctifs et leur gain |
pdf | grammage.pdf | le même rapport en A4, avec sa pagination, pour le transmettre |
json | grammage.json | le rapport complet, dont la forme ne change pas tant que schemaVersion vaut 1 |
agent | grammage-agent.md | le brief de correction à donner tel quel à un agent de code ou à un collègue |
rgesn | grammage-rgesn.md | les huit critères du RGESN 2024 que la mesure touche, en Markdown et en HTML |
gitlab | rapports de CI | l'onglet Tests, le widget Code Quality et le widget Metrics de la demande de fusion |
Donner le travail à un agent de code
Le brief grammage-agent.md dit sur quel site et sur quel framework on travaille, puis liste les correctifs dans l'ordre où ils rapportent le plus, avec les fichiers à toucher, le correctif du framework, le gain attendu et la commande qui vérifie que la règle passe. Il ne contient que ce que la mesure a établi, et jamais un conseil qu'elle n'appuie pas.
Préparer une déclaration d'écoconception
L'aide RGESN reprend, pour chacun des huit critères du référentiel que la mesure touche, la question posée, les règles de Grammage qui s'y rapportent, ce qu'elles donnent sur vos pages et les fichiers relevés. Ce n'est pas la déclaration elle-même, qui couvre soixante-dix-huit critères, mais plutôt la preuve mesurée à y joindre.
Voyez ce que votre site pèse vraiment
Grammage réunit dans un seul outil l'audit dans un vrai navigateur, l'analyse du code dans la CI/CD et un résultat signé que chacun peut vérifier.
Essai gratuit, sans engagement.
Essayez gratuitement