Bonnes pratiques d'écoconception web : ce que le code peut faire, critère RGESN par critère

En bref : pendant le développement, l’écoconception se joue sur ce que la page télécharge. Ne charger que ce qui sert, au moment où ça sert ; des images au bon format et à la bonne taille ; peu de polices, servies depuis votre domaine ; peu de JavaScript et peu de services tiers ; du cache et de la compression sur tout ce que vous servez ; des formulaires qui signalent les erreurs avant l’envoi. Chacune de ces pratiques correspond à un critère du RGESN, le référentiel général d’écoconception des services numériques.

Dans les volets précédents, nous avons fixé un éco-budget à nos pages, puis choisi la technologie avec laquelle les construire. Ce troisième volet passe au code : les pratiques ci-dessous ont été appliquées, mesurées et parfois corrigées sur ouzom.fr.

Le RGESN compte 78 critères, répartis en neuf thématiques. Ceux qui concernent directement le développeur sont surtout dans trois d’entre elles : UX/UI, Contenus et Frontend. Nous les avons regroupés ici par sujet plutôt que par numéro, avec chaque fois le critère correspondant, pour que vous puissiez retrouver sa méthode de test sur le site du référentiel.

Ne charger que ce qui sert

Le critère 6.5 (nouvelle fenêtre) pose la question : le service évite-t-il de charger des ressources et des contenus inutilisés pour chaque fonctionnalité ?

Pas de bibliothèque pour un seul usage. Un carrousel, une modale ou un menu déroulant ne justifient pas une bibliothèque de plusieurs dizaines de kilo-octets chargée sur toutes les pages.
Le JavaScript là où il sert, et seulement là. Le script d’un formulaire n’a rien à faire sur une page sans formulaire. Les outils récents découpent le code par page ; encore faut-il ne pas tout importer dans un fichier commun.
Les contenus hors de l’écran chargés plus tard. L’attribut loading="lazy" sur les images et les iframes laisse le navigateur attendre que l’élément approche de l’écran pour le télécharger. Il ne s’applique pas à l’image principale du haut de page, qu’il retarderait.
Pas de préchargement par défaut. Précharger les pages vers lesquelles pointent les liens accélère la navigation, mais télécharge aussi des pages que personne n’ouvrira.

Sur ouzom.fr. Lors de notre dernière refonte, nous avons retiré une demi-douzaine de dépendances, dont Lit, une bibliothèque de composants qui ne servait plus qu’à deux boutons. Le script de préchargement des liens, 2,5 Ko envoyés sur chaque page sans qu’aucun lien ne l’utilise, est parti aussi. Sur la page d’accueil, 14 des 15 images sont différées ; la bannière du haut est chargée en priorité.

Préférer les composants natifs

Le critère 4.5 (nouvelle fenêtre) demande si le service utilise majoritairement les composants natifs du navigateur. Le navigateur sait déjà faire beaucoup de choses qu’on reconstruit souvent en JavaScript : <details> pour un contenu dépliable, <dialog> pour une fenêtre modale, les types de champs (email, date, number) pour la saisie, les éléments personnalisés pour un composant réutilisable sans framework.

Un composant natif ne pèse rien de plus, il est maintenu par l’éditeur du navigateur, et il est en général accessible d’emblée : le clavier et les lecteurs d’écran savent s’en servir.

Sur ouzom.fr. Les trois boutons d’affichage du haut de page (images, animations, thème sombre) sont des éléments personnalisés natifs, sans dépendance. Hors mesure d’audience, la page d’accueil envoie 2,5 Ko de JavaScript compressé.

Limiter et maîtriser les services tiers

Une vidéo YouTube intégrée, un widget de réseau social, une carte, un outil de chat : chaque service tiers ajoute ses propres scripts, ses requêtes et souvent ses traceurs, sur lesquels vous n’avez pas la main. Deux critères s’en occupent :

le critère 4.4 (nouvelle fenêtre) : l’utilisateur peut-il décider de l’activation d’un service tiers ? Pour une vidéo, une simple vignette avec un bouton « Lire la vidéo » remplace l’intégration complète, qui ne se charge qu’au clic ;
le critère 6.7 (nouvelle fenêtre) : les ressources statiques dont vous êtes l’émetteur (polices, scripts, styles, images) sont-elles hébergées sur un même domaine ? Une police chargée depuis un service externe, c’est une connexion de plus à établir à chaque première visite.

Sur ouzom.fr. Le badge carbone affiché sur l’accueil était chargé depuis un service externe ; il est remplacé par une mesure faite dans votre navigateur. Il reste un script tiers sur nos pages, celui de notre outil de mesure d’audience, Umami : 2,3 Ko, sans cookie. Nous expliquons ce choix dans notre comparatif des outils de mesure d’audience.

Des images au bon format et à la bonne taille

Sur notre page la plus lourde, la liste des articles, les images représentent 211 des 302 Kio transférés. Trois critères les concernent :

5.1 (nouvelle fenêtre), le format : WebP ou AVIF pour les photos et les illustrations, SVG pour les icônes et les logos, qui restent nets à toutes les tailles pour quelques centaines d’octets ;
5.2 (nouvelle fenêtre), la compression : une qualité réglée à l’œil, image par image, plutôt que le réglage maximal par défaut ;
6.4 (nouvelle fenêtre), les dimensions : une image de 2 000 pixels de large affichée dans une colonne de 400 pixels transfère cinq fois trop de largeur. Les attributs srcset et sizes laissent le navigateur choisir la version adaptée à l’écran.

Avant tout cela, il y a le critère 4.7 (nouvelle fenêtre) : l’image est-elle le choix le plus sobre pour ce contenu ? Un tableau de chiffres reste plus léger, et plus accessible, en texte qu’en capture d’écran.

Sur ouzom.fr. Les images passent par le composant d’images d’Astro, qui génère au moment de la construction du site plusieurs largeurs en WebP. La bannière de l’accueil existe ainsi en 900, 1 400 et 1 950 pixels de large. Nous avons aussi ajouté un bouton « Images » en haut de chaque page : désactivé, il évite réellement le téléchargement des images différées. Sur l’accueil, au moment de la refonte, les requêtes passaient de 14 à 2 et le poids baissait d’environ 40 %. C’est notre réponse au critère 4.15 (nouvelle fenêtre), qui demande de donner à l’utilisateur un moyen de réduire l’impact de son usage.

Peu de polices, servies par votre domaine

Le critère 4.8 (nouvelle fenêtre) demande de limiter le nombre de polices téléchargées. Chaque graisse (normal, demi-gras, gras) et chaque style (italique) est un fichier à part. Une famille déclinée en six graisses, c’est six fichiers.

En pratique :

deux familles au plus, et seulement les graisses réellement utilisées ;
le format WOFF2, le plus compressé ;
un sous-ensemble de caractères : le jeu « latin » couvre le français sans embarquer le cyrillique ou le grec ;
font-display: swap, pour afficher le texte avec une police système en attendant la police du site, plutôt qu’un texte invisible ;
le fichier hébergé sur votre domaine, pour le critère 6.7 vu plus haut.

Sur ouzom.fr. Deux familles, Quicksand pour les titres et Athiti pour le texte, en cinq fichiers WOFF2 de 13 à 20 Ko, soit environ 80 Ko au total. Les deux polices qui portent le titre principal sont préchargées, parce qu’elles conditionnent le premier affichage utile. Cinq fichiers, c’est déjà beaucoup : c’est le prix d’une identité visuelle que nous avons choisie, et notre budget de 100 Ko pour les polices nous empêche d’en ajouter sans le voir.

Des animations qui ne s’imposent pas

Les animations, les vidéos et les sons coûtent à la lecture : calcul, batterie, et données pour les vidéos. Le critère 4.1 (nouvelle fenêtre) demande que leur lecture automatique soit désactivée, et le critère 4.6 (nouvelle fenêtre) qu’elles portent une information. Une vidéo en fond de bannière ne remplit ni l’un ni l’autre.

Côté code, la préférence système prefers-reduced-motion dit si le visiteur a demandé moins d’animations à son système. La respecter est un minimum ; l’accessibilité demande en plus de pouvoir arrêter une animation en boucle depuis la page elle-même.

Sur ouzom.fr. Les animations sont légères et décoratives : des vagues et une cascade en SVG. Elles suivent prefers-reduced-motion, et un bouton « Animations » en haut de chaque page permet de les arrêter, ce que demande aussi le critère 13.8 du RGAA.

Mettre en cache et compresser

Une ressource déjà téléchargée n’a pas à l’être une deuxième fois. Le critère 6.2 (nouvelle fenêtre) demande une mise en cache de tous les contenus dont vous avez le contrôle, et le critère 6.3 (nouvelle fenêtre) leur compression.

Le plus simple est de donner aux fichiers statiques un nom qui change à chaque modification de leur contenu (une empreinte, ou « hash », dans le nom), et les servir avec une durée de cache d’un an. Quand le fichier change, son nom change, et le navigateur télécharge la nouvelle version. Les outils de construction actuels le font tout seuls ; il reste à régler les en-têtes du serveur. Pour la compression, gzip ou Brotli sur le HTML, le CSS, le JavaScript et le SVG ; les images et les polices WOFF2 sont déjà compressées.

Sur ouzom.fr. Les fichiers produits par Astro et nos polices sont servis avec un cache d’un an. La page d’accueil pèse 65 Ko de HTML, ramenés à 18 Ko par la compression gzip. Notre article sur le poids de la page montre ce que le cache change au chiffre affiché en bas de nos pages.

Des formulaires qui ne sollicitent pas le serveur pour rien

Trois critères visent les formulaires :

4.9 (nouvelle fenêtre) : pas de requête au serveur à chaque frappe. Une recherche qui propose des résultats en direct doit attendre quelques caractères et une courte pause ;
4.10 (nouvelle fenêtre) : le format attendu est annoncé avant la saisie, et les erreurs sont signalées dans le navigateur, avant l’envoi. Un formulaire envoyé trois fois pour une adresse mal tapée, ce sont trois allers-retours inutiles ;
4.11 (nouvelle fenêtre) : le poids et le format attendus d’un fichier à joindre sont indiqués avant le transfert.

Ces trois critères rejoignent les exigences du RGAA sur les formulaires : indiquer le format attendu et signaler clairement les erreurs.

Sur ouzom.fr. Le formulaire de contact annonce le format attendu de l’adresse e-mail sous le champ, et vérifie les champs obligatoires dans le navigateur. Il n’appelle le serveur qu’une fois le formulaire complet.

Garder la page simple

Une page simple est plus légère à construire pour le navigateur, à chaque affichage et à chaque interaction. Notre éco-budget plafonne le DOM, l’arbre des éléments de la page, à 600 éléments. Pour rester sous ce plafond, évitez les conteneurs imbriqués qui ne servent qu’à la mise en page, que la grille CSS rend inutiles, et n’affichez pas d’un coup des centaines de cartes qu’une pagination présenterait mieux. Le critère 4.2 (nouvelle fenêtre) écarte d’ailleurs le défilement infini.

Sur ouzom.fr. La page la plus chargée, l’accueil, compte 557 éléments pour un plafond de 600. Lors de la refonte, nous avons aussi changé la façon dont Astro rattache les styles aux composants : une classe au lieu d’un attribut sur chaque élément, pour environ 11 % de HTML en moins.

Faire le ménage dans les contenus

Le dernier critère n’a rien de technique. Le critère 5.8 (nouvelle fenêtre) demande une stratégie d’archivage et de suppression des contenus obsolètes. Une page périmée continue d’être indexée, visitée et hébergée.

Sur ouzom.fr. Nous datons nos mises à jour et signalons en tête d’article ce qui a changé, comme pour l’article sur le choix des technologies, révisé depuis sa première publication. Nous n’avons pas encore de règle pour supprimer ou archiver un article : c’est un chantier encore ouvert.

Récapitulatif

Pratique	Critères RGESN	Sur ouzom.fr
Ne charger que ce qui sert	6.5	14 images sur 15 différées sur l’accueil, préchargement des liens retiré
Composants natifs	4.5	Boutons d’affichage en éléments personnalisés, 2,5 Ko de JavaScript sur l’accueil
Services tiers	4.4, 6.7	Badge carbone externe remplacé par une mesure locale, Umami seul script tiers
Images	4.7, 5.1, 5.2, 6.4	WebP en plusieurs largeurs, mode sans images
Polices	4.8, 6.7	2 familles, 5 fichiers WOFF2, environ 80 Ko, sur notre domaine
Animations	4.1, 4.6	Décoratives, arrêtables depuis la page
Cache et compression	6.2, 6.3	Cache d’un an sur les fichiers statiques, HTML compressé
Formulaires	4.9, 4.10, 4.11	Format annoncé, erreurs signalées avant l’envoi
Page simple	4.2, 6.1	557 éléments sur l’accueil pour un plafond de 600
Contenus obsolètes	5.8	Mises à jour datées, pas encore de règle d’archivage

Une page légère au lancement s’alourdit au fil des ajouts. Les deux volets suivants sortent du code : l’hébergement, puis la mesure à chaque déploiement, qui vérifie que ces pratiques tiennent dans la durée.

Si vous voulez savoir où en est votre site sur ces critères, notre analyseur gratuit en contrôle une partie automatiquement, et l’audit RGESN couvre le reste.

Transparence : comment cet article a été produit

Nous utilisons l’intelligence artificielle dans notre travail éditorial, et nous préférons le dire clairement.

Pour cet article, elle nous a accompagnés dans la rédaction. Les intitulés des critères ont été relus sur le site officiel du RGESN, et les liens de l’article permettent de retrouver chacun d’eux. Les chiffres d’ouzom.fr viennent de nos propres mesures : celles de notre refonte et de notre serveur Lighthouse CI, et pour le poids du HTML et les en-têtes de cache, une mesure faite sur le site en ligne.

L’illustration en tête d’article est générée par intelligence artificielle.

Sources

← Tous les articles