Le référentiel

Ce référentiel a pour objectif de poser les bases d’un référentiel de bonnes pratiques opérationnelles qui peuvent être facilement mises en œuvre dans le cas d’un projet de conception ou de refonte de services numériques.

Ces pratiques peuvent impacter à la fois les interfaces et une partie de l’organisation qui porte le service.

Dans cette liste de bonnes pratiques, les éléments directement liés à l’accessibilité numériques sont absents. Les référentiels tels que le RGAA portent ces informations de manière détaillées.
Dans tous les cas, une démarche globale d’éco-conception notamment dans le cadre d’une démarche UX *Responsable ne peut pas s’affranchir d’une prise en compte stricte de l’accessibilité numérique.

Les fiches de ce référentiel ne sont pas « concurrentes » du Référentiel général d'écoconception de services numériques (RGESN), elles tentent d’être une expression opérationnelle et pratico-pratique de situations tangibles.

Ce référentiel est vivant et régulièrement mis à jour.

Filtrer les fiches

Les fiches

Il y a 34 fiches qui correspondent à votre filtre

1 - Limiter le nombre de requêtes HTTP
Limiter le nombre de requêtes HTTP
Catégories
#développement
Description
Le nombre de requêtes entre le client (navigateur) et les serveurs sont sources d'une consommation importante d'énergie :
- Sur le poste client lors de l'envoi ;
- Sur le poste client lors de la réception ;
- Sur l'ensemble des serveurs (et des couches serveurs) lors de la réception et de l'envoi ;
- Sur les disques ;
- Sur les infrastructures réseaux ;
En premier lieu, il est important d'éviter les requêtes inutiles, par exemple, l'appel à des données ou des scripts non utilisés par la page en cours simplement parce qu'on utilise un mécanisme de chargement non optimisé. Il est également nécessaire de trouver le juste équilibre entre des requêtes unitaires fines qui ne ramènent pas trop de données ou d'éléments non utilisés (mais qui peuvent multiplier de manière très importante le nombre de requêtes) et le chargement de ressources non différentiées qui représentent peu de requêtes mais de gros volume de données (trop souvent partiellement utilisées).
Les solutions
Il n'y a pas de solutions toutes faites, mais un certain nombre de principes :
- Gérer les interactions (en particulier les mises à jour de champs et l'auto-complétion) côté client ;
- Faire la chasse aux solutions toute faite "clef en main" sans optimisation des appels à des ressources tierces (JavaScript, CSS, informations, etc.) ;
- Regarder de près les appels à des éléments externes, ils peuvent être le fait de solution ou de composants tiers non optimisés et souvent non nécessaires ;
- Ne déclencher l'appel à des ressources qu'une seule fois par page. Il arrive très souvent que l'appel plusieurs fois au même composant dynamique dans une page entraîne l'appel plusieurs fois aux ressources de ce composant ;
- Faire le plus possible soi-même (c'est notamment le cas pour les liens et les appels vers les réseaux sociaux ou les captchas.
La preuve par l'exemple
en cours de rédaction
fiche suivante
2 - Stocker les données statiques localement
Stocker les données statiques localement
Catégories
#conception#développement
Description
- Utiliser un stockage local des données permet d’une part d’éviter les allers-retours inutiles avec le serveur, ce qui économise des ressources et du temps de réponse.
  D’autre part, comme les données sont locales, il est plus facile et plus rapide de les manipuler au sein de l’interface.
- Le gain potentiel est la réduction de la charge serveur, donc du nombre d’équipements nécessaires (de leur empreinte environnementale et économique), des serveurs HTTP jusqu’aux serveurs de base de données.
Les solutions
- Avec le support désormais généralisé sur tous les navigateurs des bases de données clé-valeur (IndexedDB, Web Storage), et de la mise en cache dans le Cache Storage API, il est possible de stocker localement des données structurées statiques.
- La possibilité de stocker de potentielles grandes quantités de données structurées localement peut permettre de lire et d'écrire des données issues de bases de données en 1 seule fois par session ou plus.
- En positionnant un indicateur de rafraîchissement des données en base, la ou les requêtes vers la base ne sont déclenchées que lorsque les données ont été mise à jour.
  Un exemple documenté est disponible sur la démo Access-Score.
La preuve par l'exemple
- Démonstration :Consommer local (moins de requêtes SQL)
- IndexedDB : DOM examples, Github
Quelques ressources
- IndexedDB : tutoriel pour la mémoire dans le navigateur
- La librairie Javascript LocalForAge (github)
- MdM : Window: localStorage property
- La démonstration : Consommer local (moins de requêtes SQL)
fiche précédente fiche suivante
3 - Choisir un format de données adapté
Choisir un format de données adapté
Catégories
#développement
Description
- Le type de données utilisé pour manipuler et stocker une donnée à un impact significatif sur la consommation mémoire et les cycles processeurs nécessaires lors des manipulations en base de données, au niveau du serveur d’applications et même dans le navigateur (manipulation via JavaScript), ainsi que sur l’espace de stockage nécessaire.
  Choisir un mauvais type de données entraîne :
  - Un gaspillage de mémoire (par exemple, si vous stockez de toutes petites données dans une colonne prévue pour stocker de grosses quantités de données) ;
  - Des problèmes de performance (il sera plus rapide de faire une recherche sur un nombre que sur une chaîne de caractères).
- Idéalement, les choix du type de données et de son dimensionnement doivent être fondés sur l’analyse d’un échantillon représentatif de données.
Les solutions
- Opérer une analyse rigoureuse des typologies de données stockées et base et leur définition dans la base de données.
- Il est très fréquent que des tables de références ne soient pas utilisées par manque de prise de recul ou que l'allocation du type proposée par défaut ne soit pas discutée.
- Si la solution apparaît technique, elle passe nécessairement par une revue de l'implémentation du modèle de données.
La preuve par l'exemple
- Dans le cas d’un établissement de formation, la taille du champ permettant de stocker le nombre d’élèves doit être basé sur une étude statistique.
- On peut ainsi déterminer s’il est possible d’utiliser un TINYINT (1 octet, jusqu’à 127) plutôt qu’un SMALLINT (2 octets, jusqu’à 32 767).
- Dans tous les cas, le choix par défaut d’un INT (4 octets, jusqu’à 2 147 483 647) voire un BIGINT (8 octets) est une aberration (qui reste encore très souvent utilisé).
- Gain potentiel : jusqu’à 8 fois moins de stockage.
  La consommation en cycle processeur est réduite dans les mêmes proportions.
Quelques ressources
- Les types SQL
fiche précédente fiche suivante
4 - L'auto-complétion
L'auto-complétion
Catégories
#conception#développement
Description
- L’auto-complétion peut être source d’un grand nombre de requêtes vers le serveur HTTP et la base de données.
- Par contre, son utilisation est source d’économie de requêtes lorsqu’elle est correctement paramétrée et utilisée de manière raisonnée (par exemple recherche de lieux, de noms propres ou d’entité avec des intitulés proches).
Les solutions
- Ne pas systématiquement utiliser l’auto-complétion, toujours évaluer les alternatives ;
- Ne pas lancer la recherche liée à l’auto-complétion dès le premier caractère saisi (attendre 3, voire 5 caractères) ;
- Intégrer un léger délai (en dixième de secondes) avant de lancer la recherche liée à l’auto-complétion ;
- Si les éléments résultats de l’auto-complétion sont prédictibles, privilégier le chargement en une fois et gérer localement le résultat en JavaScript ;
- Dans certains cas, il est possible de fournir un résultat équivalent en affichant – après avoir validé une première fois le serveur – la liste des intitulés acceptables en regard de la saisie.
- DataList est un moyen simple de transformer une boite de sélection en saisie avec auto-complétion.
La preuve par l'exemple
DataList, la démo Access-Score : Saisie assistée
Quelques ressources
- Fiche "Stocker les données statiques localement"
fiche précédente fiche suivante
5 - Remplacer les boutons officiels de partage des réseaux sociaux
Remplacer les boutons officiels de partage des réseaux sociaux
Catégories
#conception#développement
Description
- Les principaux réseaux sociaux tels que Facebook, Twitter, Pinterest, etc. fournissent des plugins à installer sur une page web pour y afficher un bouton Partager et un compteur de J’aime.
- Ces plugins JavaScript sont très gourmands en ressources : ils nécessitent un grand nombre de requêtes et de télécharger des fichiers lourds.
- Il est plus efficient d’utiliser les liens HTML directs vers les pages de partage.
Les solutions
- Il est possible de simplement générer ces liens à la main ;
- Il est possible d’utiliser un outil tel que https://www.sharelinkgenerator.com
  Mais pourquoi dépenser des ressources alors que l’on peut le faire directement à la main.
- Il est également possible d’écrire un petit script local de partage qui limite le code chargé sur la page.
La preuve par l'exemple
Exemple de code HTML fonctionnel pour 4 RS :
```
<aside id="shares">
   <h2 class="sr-only">Partager sur les réseaux sociauxh2>
   <ul>
      <li><a href="redirecte.php?c=0" target="EXT" title="partager cette page sur LinkedIn"><img src="pic/LinkedIn_LogoSmall.svg" alt="LinkedIn">a><li>
      <li><a href="redirecte.php?c=1" target="EXT" title="partager cette page sur Twitter"><img src="pic/Twitter-logo.svg" alt="Twitter">a><li>
      <li><a href="redirecte.php?c=2" target="EXT" title="partager cette page sur Diaspora"><img src="pic/Diaspora-asterisk.svg" alt="Diaspora">a><li>
      <li><a href="redirecte.php?c=3" target="EXT" title="partager cette page sur Facebook"><img src="pic/facebook.svg" alt="Facebook">a><li>        
   <ul>
<aside>
```
Le tout sans une ligne de JavaScript, sans tracker, accessible et ne pesant que quelques octets. La démo montre l'ensemble du code nécessaire.
Quelques ressources
La démonstration Access-Score : accueil
fiche précédente fiche suivante
6 - Découper les CSS en fonction des contextes d’utilisationTout en limitant leur nombre
Découper les CSS en fonction des contextes d’utilisationTout en limitant leur nombre
Catégories
#développement
Description
- Employer un ensemble de CSS plutôt qu’une seule, et appeler uniquement les CSS utiles en fonction du contexte.
  Cette méthode permet de limiter le poids de la page lors du premier téléchargement, donc d’économiser de la bande passante et de réduire la charge CPU.
- Ce découpage doit rester raisonné. Utilisé à l’excès, il devient contre-productif.
Les solutions
Par exemple, découper les CSS en fonction de la logique fonctionnelle :
- Habillage ;
- Contenu ;
- Module A ;
- Module B ;
- etc.
Attention à bien prendre en compte le contexte, dans cette liste exemple, si habillage et contenu sont systématiquement appelés, un seul fichier sera beaucoup plus efficient.
La preuve par l'exemple
La démo Access-score utilise 6 fichiers CSS :
- base.css : prend en charge tous les éléments communs aux pages (et aux sites de la galaxie access-score.org).
  Mis en cache systématiquement ;
- contexte.css : les variables CSS spécifiques au site de démonstration (permet une gestion industrielle dans un référentiel)
- edit.css : utile pour l’édition de contenu (chargé uniquement dans le mode d'édition) ;
- typo.css : permet une gestion des typos utilisées sur le site ;
- print.css : gère les impressions ou passage au PDF ;
- smart.css : gestion des éléments spécifiques à la démo des fonts variables.
Quelques ressources
- La démonstration en ligne
fiche précédente fiche suivante
7 - Préférer les CSS aux images
Préférer les CSS aux images
Catégories
#développement
Description
- Avant la mise en place CSS3, certaines formes simples avec des arrondis nécessitaient la mise en place de caches à partir d’images utilisées le plus souvent en fond.
- CSS3 a résolu l’ensemble de ces points. +Utiliser les propriétés CSS3 à la place d’images. En effet, le poids d’une feuille de styles est bien plus faible, surtout si elle est compressée.
- L’appel d’une feuille de styles ne génère qu’une seule requête HTTP, contre un grand nombre si l’on emploie beaucoup d’images (une requête HTTP pour chaque image).
Les solutions
- Les coins arrondis des cases doivent être gérés en CSS3 plutôt qu’avec des images.
- Mais au-delà, les propriété CSS peuvent une grande quantité d’effets graphiques :
  - Blend, ajouter un filtre de couleur à une image
  - Transform (rotate) : opérer la rotation d’un bloc
  - Etc.
La preuve par l'exemple
- Un simple bloc avec des coins arrondis
```
<style>
cadre { border-radius: 10px;}
</style>

<div id="cadre">
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
</div>
```
- La rotation d’un bloc
```
style>
.rotate {
  background-color: transparent;
  outline: 2px dashed;
  transform: rotate(45deg);
}
</style>

<div>Normal</div>
<div class="rotate">Tourné</div>
```
Quelques ressources
- Mozilla developper : rotate
- Mozilla developper : blend-mode
- Démonstration : Une animation avec une fonte variable et des CSS
fiche précédente fiche suivante
8 - De l'utilisation des typos variables
De l'utilisation des typos variables
Catégories
#conception
Description
- L’utilisation de fontes en dehors de celles installées par défaut sur les systèmes des utilisateurs demande le chargement de ces typos lors du chargement de la page.
- Le chargement de ces fontes peut représenter le chargement de plusieurs fichiers en fonction des « variations » utilisées, généralement un fichier par variante.
- Cela entraîne donc une quantité parfois importante de données et multiplie le nombre de requêtes HTTP.
Les solutions
- Les fonts variables permettent de résoudre ce point. +Les fonts variables permettent de réunir en un seul fichier l’ensemble des variations pour une famille.
- Cette solution permet également de mettre en œuvre des animations intéressantes à partir d’un fichier de fonte variable et de JavaScript / CSS.
- À titre d’exemple, la fonte variable « OpenType » permet de stocker / gérer toutes ses variations dans un seul fichier. Un test réalisé par Monotype a permis de combiner 12 variations pour huit poids avec 3 longueurs incluant italique et roman.
  Cette combinaison de 48 fontes individuelles en une seule variable a permis une réduction de 88% du poids de fichier.
La preuve par l'exemple
```
@font-face {
    font-family: 'Roboto Flex’;
    src: url('RobotoFlex-VF.woff2') format('woff2’) tech('variations'),      url('RobotoFlex-VF.woff2') format('woff2-	variations’);
    font-weight: 100 1000;
    font-stretch: 25% 151%;
}
```
Tous les styles en un seul fichier.

Quelques ressources
fiche précédente fiche suivante
9 - Optimiser l’écriture des CSS
Optimiser l’écriture des CSS
Catégories
#développement
Description
- Lorsque plusieurs éléments du DOM (Document Object Model) ont des propriétés CSS communes, les déclarer ensemble dans la même feuille de styles.
- Cette méthode permet de réduire le poids de la CSS.
Les solutions
- Utiliser les notations CSS abrégées pour réduire le poids de la feuille de styles.
- En termes d’efficience, utiliser les abstractions peut permettre de belles économies.
- Lors du passage en production, compressez les CSS (jusqu'à 20 % de réduction de taille).
- Et, n’oubliez pas de faire la chasse aux classes inutiles !!
La preuve par l'exemple
À la notation :
```
h1 { background-color: gray; color: navy; }
h2 { background-color: gray; color: navy; }
h3 { background-color: gray; color: navy; }
```
Préférer :
```
h1, h2, h3 { background-color: gray; color: navy; }
```
Ne pas écrire :
```
margin-top:1em; 
margin-right:0; 
margin-bottom:2em; 
margin-left:0.5em;
```
Mais préférer :
```
margin:1em 0 2em 0.5em;
```
Quelques ressources
fiche précédente fiche suivante
10 - CSS et javascript : à l’extérieur
CSS et javascript : à l’extérieur
Catégories
#développement
Description
- Veiller à ce que les codes CSS et JavaScript ne soient pas embarqués dans le code HTML de la page, à l’exception d’éventuelles variables de configuration pour les objets JavaScript spécifiques à la page.
- Lorsque du code CSS ou JavaScript est inclus dans le corps du fichier HTML, alors que ce dernier est utilisé par plusieurs pages (voire tout le site), ce code doit être transféré pour chaque page demandée par l’utilisateur, ce qui augmente le volume de données transmises.
  En revanche, si les codes CSS et JavaScript sont inclus dans leurs propres fichiers, le navigateur peut les stocker dans son système de cache local afin de ne pas les redemander.
Les solutions
- Externaliser les CSS et JavaScript ;
- Minimiser le code ;
- Découper efficacement ces ressources.
La preuve par l'exemple
Dans le code HTML, ne pas écrire :
```
<style type="text/css" media="screen">
    p { color: #333; margin: 2px 0 }
    /* Toutes les déclarations CSS du site */
<style>
```
Mais, utiliser :
```
<link href="css/styles.css" rel="stylesheet">
```
Quelques ressources
- Fiche 06 : Découper les CSS en fonction des contextes d’utilisation
- Fiche 19 : Minifier en production
fiche précédente fiche suivante
11 - Ne pas oublier la CSS d’impression
Ne pas oublier la CSS d’impression
Catégories
#conception#développement
Description
- Si l’utilisateur souhaite imprimer la page, la CSS d’impression par défaut du navigateur va prendre en charge l’impression.
- Cette CSS formate à minima, mais ne filtre pas les informations à afficher et ne cherche pas (pas encore) à optimiser l’impression.
  Un contenu qui peut être imprimé sur une page A4 peut arriver à en consommer 3 pour un résultat peu facile à lire.
- Le résultat est un gaspillage important de papier, d’encre et d’énergie.
Les solutions
- Mettre en place une CSS d’impression peut paraître paradoxale, car il n’est pas ici question de vouloir permettre l’impression des pages, mais de permettre une impression dans des bonnes conditions.
- Avec la mise en place d’une CSS d’impression efficiente, l’utilisateur n’imprimera que la partie « valorisée » du contenu avec une typographie adaptée.
- Pas d’impression de la navigation, des encarts ou autres pieds de page, le contenu, rien que le contenu.
La preuve par l'exemple
==>
Exemple de résultat d'impression de la page du site de démos.
fiche précédente fiche suivante
12 - Utiliser avec parcimonie les animations JavaScript / CSS
Utiliser avec parcimonie les animations JavaScript / CSS
Catégories
#conception#développement
Description
- Les animations JavaScript / CSS peuvent être très coûteuses en termes de cycles CPU et de consommation mémoire.
- Elles déclenchent toutes une action de type (re)paint/(re)ﬂow très coûteuse en ressources.
- Il faut donc éviter au maximum les animations, et ne les utiliser que lorsqu’elles sont indispensables.
Les solutions
- Si vous ne pouvez pas vous passer d’une animation, limitez-vous aux propriétés CSS3 « opacity » et transform », et aux fonctions associées « translate », « rotate », « scale » de transform.
  Ces deux propriétés sont automatiquement optimisées par le navigateur, et l’animation peut être prise en charge par le processeur graphique (GPU).
  Le site www.csstriggers.com liste les actions sur le DOM déclenchées par une animation.
- Pour que le navigateur puisse réduire au minimum les ressources consommées par l’animation, vous pouvez le prévenir qu’une animation va avoir lieu grâce à l'instruction « will-change ».
  Attention, trop d’utilisation de « will-change » va ralentir la page.
- Il n’y a pas de métriques réellement disponibles sur ce sujet, la solution la plus efficiente est de limiter les animations au nécessaire.
  Rappelez-vous que des écrans « sapin de Noël » sont rarement efficients d’un point de vue UX et souvent assez mauvais d’un point de vue accessibilité.
La preuve par l'exemple
- Solution possible :
```
.box { will-change: transform, opacity; }
```
- Solution alternative, vous pouvez aussi laisser le choix à vos utilisateurs, via les préférences de leurs navigateurs et la media « query prefers-reduced-motion », de jouer ou non l'animation.
  L'animation est jouée seulement si l'utilisateur n'a pas défini de préférence.
```
@media (prefers-reduced-motion : no-preference ) { .box { will-change: transform, opacity; } }
```
Quelques ressources
- Créer des animations CSS hautes performances
- CSS triggers
fiche précédente fiche suivante
13 - Jouer selon les règles
Jouer selon les règles
Catégories
#développement
Description
- Chaque modification de propriétés CSS est effectué par un couple fonctionnel : « repaint / reflow ».
- Ces actions de rendu de la page ont un coup en termes de temps de traitement et donc énergétiques.
- En résumé :
  - Certaines parties de l'arbre de rendu (ou l'arbre entier), le DOM, devront être revalidées et les dimensions des nœuds recalculées.
    C'est ce qu'on appelle une refonte (reflow), une mise en page ou une mise en page. Notez qu'il y a au moins une refonte - la mise en page initiale de la page.
  - Certaines parties de l'écran devront être mises à jour, soit en raison de changements dans les propriétés géométriques d'un nœud, soit en raison d'un changement stylistique, tel que la modification de la couleur d'arrière-plan.
    Cette mise à jour de l'écran est appelée "repaint" ou "redraw".
Les solutions
- Modifier plusieurs propriétés CSS en une seule fois.
  - Pour limiter le nombre de repaint / reﬂow, il est conseillé de ne pas modifier des propriétés une à une.
  - Préférer l’ajout ou la suppression de classes CSS, ce qui permet de modifier en une seule fois plusieurs propriétés, tout en ne générant qu’un repaint / reﬂow
- Les éléments avec un “display: none” ne génèrent ni repaint ni reflow lorsqu’on les modifie.
  Faites vos modification avant de les rendre visibles.
- À savoir :
  - Ajouter, ôter ou modifier un élément du DOM génère un reflow ;
  - "display none" génère à la fois un reflow et un repaint ;
  - « visibility: hidden » ne génère qu’un repaint ;
  - Changer la taille de fenêtre génère un reflow
  - Manipuler le DOM avec un script est très couteux car à chaque changement, le document est recalculé et génère un reflow et cela peut en déclencher des milliers par seconde !
La preuve par l'exemple
- Tout en une seule fois
```
<style>
	.in-error { 
		color: red;
		font-weight: bold;
   }
</style>

<script>
    $el.bind('error', function () {
        $el.addClass('in-error');
    });
    $el.bind('running'), function () {
        $el.removeClass('in-error');
    };
</script>
```
- Autre exemple
  - À éviter
    var left = 10, top = 10; el.style.left = left + "px"; el.style.top = top + "px";
  - Conseillé
    el.style.cssText += "; left: " + left + "px; top: " + top + "px;";
Quelques ressources
- How to create high-performance CSS animations
- Understanding Reflow and Repaint in the browser
fiche précédente fiche suivante
14 - Minifier en production
Minifier en production
Catégories
#développement
Description
+Le code HTML, CSS ou JavaScript – en production – n’est lu que par le navigateur. +Cette approche est également valable pour les fichiers SCG ou JSON. +Les retours chariots, les lignes vides, les longs commentaires et autres espaces non signifiants peuvent représenter jusqu’à 50 % du poids de ces ressources (cf. Jquery-ui.js). +Il y a donc une économie assez simple à réaliser avant de mettre ces fichiers en production.
Les solutions
- Minifier les fichiers CSS, JavaScript, HTML, JSON et SVG ou utilisez les versions minifiées des librairies externes
- Utiliser un outil de minification CSS, JavaScript, HTML, JSON et SVG permet de supprimer les espaces inutiles, les commentaires des développeurs, les sauts de ligne, les délimiteurs de blocs et ainsi réduire leur taille.
- Il existe différents outils pour minifier par exemple :
  - CSS: cssnano, csso ou clean-css ;
  - Javascript: Terser, UglifyJS ou Babel-minify ;
  - HTML: htmlnano, HTMLMinifier ;
  - SVG: SVGO, minify-xml ou équivalent.
La preuve par l'exemple
- La librairie Jquery est un bon exemple d’économies potentielles :
  - jquery-ui.js = 520,7 Ko (!)
  - jquery-ui.min.js = 251,8 Ko (48 %).
- Les exemples ne sont pas toujours aussi impressionnants, exemple avec access-score.org :
  - base.css = 23,6 Ko
  - base-min.css = 20,0 Ko (84 %)
    Cet exemple représente tout de même 16 %.
Quelques ressources
- Minify - JavaScript and CSS minifier ;
- Minifier.Com.
fiche précédente fiche suivante
15 - Vidéo : YouTube versus vidéos hébergées
Vidéo : YouTube versus vidéos hébergées
Catégories
#conception#développement#projet
Description
- L’intégration du code YouTube pour jouer une vidéo utilise une iframe.
  À priori, aucun souci, elle possède un titre et ne représente que quelques octets. En fait, l’iframe charge une page de 124 ko et au total plus de 200 Ko, ressources comprises et une bonne vingtaine de requêtes HTTP.
  Pour une vidéo de 5:36, on obtient 156 requêtes et le transfert de 33 Mo pour une vidéo de 28,4 Ko.
- La consommation de bande passante, d’énergie et de disque semblent disproportionnées.
- Sans compter que dès le chargement de la page et sans arrêt, même si la vidéo est mise sur pose, l’envoi de requête et de données continue afin d’alimenter les logs de Google.
Les solutions
- Privilégier la lecture directe de vidéo et non le streaming qui génère beaucoup plus de requêtes et de volume de données sur le réseau.
- Privilégier l’auto-hébergement des vidéos (ce n’est pas plus difficile que de stocker et afficher des images).
  D’autres services équivalents à YouTube génèrent au moins autant de requêtes. Certains services tentent de compenser ce point en adaptant la qualité de la vidéo au débit réellement disponible.
- Utiliser un lecteur vidéo / audio HTML5 qui permet d’ajouter librement et facilement des sous-titres ou de l’audiodescription et des options de téléchargement.
- Ne pas lancer automatiquement la lecture des vidéos ou des bandes sons.
Cela n'impacte en rien l'expérience utilisateur. Le seul cas où le streaming peut représenter un plus pour l'utilisateur est lorsqu'il est en situation de mobilité avec des variations importantes de qualité de connexion et de bande passante. Ce cas est très loin d'être le cas nominal.
La preuve par l'exemple
La version Streaming
L'utilisation d'une iframe fournie par Youtube pour un fichier vidéo en HD (cf. démo).
```
<iframe width="540" height="304" src="https://www.youtube.com/embed/4yXPmmuSlgQ" title="John Zorn and Bill Laswell: TURBINES | Sessions | Gagosian Premieres" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen>iframe>
```
Soit 66 requêtes et 46,4 Mo
La version lecture par bloc sur son serveur
```
<video controls width="540" height="358" poster="contenus/multimedia/vidLaswell.webp">
	video>
<div class="telechargement">
	<p>Fichier(s) à téléchargerp>
	<ul>
		<li>
			<a href="contenus/multimedia/Laswell.webp">Télécharger la vidéo au format WebP (Format multimédia ouvert pour le web, 28,9 Mo)a>
		li>
		<li>
			<a href="contenus/multimedia/Laswell.mp4">Télécharger la vidéo au format MP4 (Format MPEG-4, 46,1 Mo)a>
		li>
	ul>
div>
```
1 seule requête et 28,9 Mo
Et en fait, aucune différence d'expérience pour l'utilisateur final.
Quelques ressources
- La démonstration : un exemple audio et vidéo, lecteurs HTML5
fiche précédente fiche suivante
16 - Du standard, que du standard
Du standard, que du standard
Catégories
#conception#développement
Description
- Les erreurs de code nécessitent des corrections dynamiques réalisées à la volée par les navigateurs afin d’afficher correctement les pages.
  Ces ajustements dynamiques consomment inutilement des ressources à chaque chargement des pages concernées.
- En complément d’être énergivore, ces erreurs ou ces surcouches inutiles de code produisent le plus souvent :
  - Un surpoids de la page ;
  - Une difficulté de maintenance (moins durable) ;
  - Un moindre respect de la qualité et de l’accessibilité.
Les solutions
- Vérifier que le code HTML des pages est bien formé.
- Utiliser le validateur du W3C (World Wide Web Consortium).
- Une manière simple d’opérer une vérification rapide est d’afficher le code source d’une page dans le navigateur. Tous les éléments en rouge sont des erreurs de code.
- Et surtout, écrire du code simple, évident, dépouillé, facile à lire, sans surcouche inutile.
La preuve par l'exemple
Exemple 1
Appel d'un fichier javascript.
```
<script type="text/javascript" src="https://a.opmnstr.com/app/js/api.min.js" data-campaign="hklwbt7m8xxpyfmibq0t" data-user="50971" async>
```
Le type est inutile ;
Les données propriétaires sans doute également
Code proposé :
<script src="https://a.opmnstr.com/app/js/api.min.js" async>
Exemple 2
Bouton d'appel d'un réseau social
<span st_url="https://www.strategie.gouv.fr/debats/leco-conception-un-puissant-levier-maitriser-limp… l’impact environnemental des produits numériques" class="st_facebook_large" displayText="facebook">span>
Respecter la syntaxe et les attributs autorisés
Pas d’attributs propriétaires
Code proposé :
<span class="facebookLarge">Facebookspan>
Ou
<a href="redirecte.php?c=3" target="EXT" title="partager cette page sur Facebook"><img src="pic/facebook.svg" alt="Facebook">a>li>
Exemple 3
Abonnement à une lettre d'information
<a href="/actualite-de-france-strategie-de-reseau"><input type="button" value="JE M'ABONNE" class="newsletter-mini-button">a>
Un simple bouton ferait l’affaire avec une gestion d’événement en JavaScript, alors que mettre une balise <input> dans un lien…
<button id="BTabonnement" class="bouton">Je m’abonnebutton>
Quelques ressources
Markup Validation Service (W3C)
fiche précédente fiche suivante
17 - Être paresseux sur les chargements
Être paresseux sur les chargements
Catégories
#développement
Description
- Lorsqu’un utilisateur ne consulte pas la totalité d’une page web, par défaut toutes les ressources (images, iframes) sont chargées.
- Celles situées en dehors de la zone visible dans la fenêtre du navigateur, en dessous de la ligne de flottaison, sont ainsi chargées inutilement.
- Afin de ne charger que les ressources vues, il est possible d'utiliser la technique du chargement différé (« lazy loading »).
- Cette technique consiste à ne charger un élément que lorsque son emplacement devient visible dans la fenêtre du navigateur.
Les solutions
- +Il est possible, en HTML5, d'ajouter un attribut « loading » aux éléments, ressources chargées en complément (images, iframes) afin que le navigateur ne s'occupe de télécharger que les éléments visibles dans la fenêtre du navigateur.
- Le chargement différé fonctionne uniquement pour des ressources non bloquantes (non critiques).
  Cela se traduit par une réduction du temps de chargement de la page et potentiellement une économie de requêtes et de bande passante.
- Cependant, cet attribut n’est encore supporté totalement par l’ensemble des navigateurs (cf. ressources).
  Son utilisation avec des iframes n’est pas support par Firefox (référence V 115). L’utilisation de bibliothèques de code tiers pour palier ce point n’est pas conseillé, les pratiques d’éco-conception recommandent avant tout l’utilisation d’éléments natifs et standards.
- Le chargement différé se déroule typiquement lorsque l'internaute interagit avec la page, notamment lors du défilement de la page ou de la navigation.
La preuve par l'exemple
Dans ces exemples, l'image et l'iframe seront chargées en différé automatiquement par le navigateur, si l'image doit apparaitre à l'écran, elle sera téléchargée et affichée, si elle est en dessous de la ligne de flottaison, elle ne sera pas téléchargée.
```
<img src="pic/access-score.avif" decoding="async" loading="lazy">
```
```
<iframe src=« https://access-score.org" title=« le site Access-score" loading="lazy"></iframe>
```
Quelques ressources
- Mozilla developper : Le chargement différé
- Démonstration : Des boutons, images et typos (nouvelle fenêtre)
fiche précédente fiche suivante
18 - Des images en priorité vectorielles
Des images en priorité vectorielles
Catégories
#conception
Description
- Choisir le bon format d’image est crucial pour éviter de transporter des octets inutilement et économiser ainsi de la bande passante et du stockage disque.
- Avec la multiplication des terminaux, des tailles d’écran et l’augmentation de leur résolution, une approche vectorielle doit être privilégiée par rapport à des images matricielles.
- Grâce à cette bonne pratique, l’interface est indépendante de la résolution de l’écran.
Les solutions
- En remplaçant les images matricielles (GIF, PNG, JPEG, WebP, etc.) par des images vectorielles, l’utilisateur n’a aucune ressource supplémentaire à télécharger, la même image est toujours à la taille souhaitée.
- Les images vectorielles sont – de fait une description « textuelle » des chemins tracés pour l’image.
  Ces images (format SVG) sont de fait beaucoup plus légères que les images matricielles (bitmap).
- Le format vectoriel va également permettre un affichage dans toutes les tailles souhaitées à partir de la même ressource sans aucune perte en qualité !
- Il peut, de plus, permettre des animations en CSS sans plus d’impact environnemental.
- Dans le cas où l’image n’est pas adaptée pour un format vectoriel, les formats d’images matricielles « économes et légers sont à privilégiés :
  - WebP ;
  - AVIF.
Le tout, combiné à l’utilisation de la balise <picture>.
La preuve par l'exemple
Si l’on compare le poids de la même image à différents formats :

Il est à noter que dans ce cas, la version AVIF est plus légère que la version SVG (chemin) mais la version SVG garde l'avantage de s'adapter — sans perte — à toutes les tailles.
Ce point est dû au fait que la version « typo » stocke le nom de la typographie et ses caractéristiques et non le chemin du tracé. Mais, il est possible que l’absence de la typographie sur le poste modifie l’apparence d’une partie de l’image (cf. image d'illustration).
Quelques ressources
- Fiche 34: Le bon format d'image au bon moment
- La démonstration : des boutons, images et typos
fiche précédente fiche suivante
19 - Ne pas redimensionner les images coté navigateur
Ne pas redimensionner les images coté navigateur
Catégories
#développement
Description
- Ne pas redimensionner les images en utilisant les attributs height et width du code HTML.
  Cette approche impose en effet de transférer ces images dans leur taille originale, gaspillant ainsi de la bande passante et des cycles CPU.
- Une image de 350 × 300 pixels encodée en PNG 24 pèse 41 Ko. Redimensionnée dans le code HTML, la même image affichée en vignette à 70 × 60 pixels pèse toujours 41 Ko, alors qu’elle ne devrait pas dépasser 3 Ko !
  Soit 38 Ko téléchargés à chaque fois pour rien…
  Note : le redimensionnement étant fait par le navigateur peut aussi avoir un effet pixel sur le rendu final.
- La meilleure solution consiste à générer les images à la taille à laquelle elles sont affichées.
  Soit, vous le faites manuellement en utilisant un éditeur d'image, soit le CMS dispose d'une routine automatique qui va générer les images à la taille à laquelle elles sont appelées dans le gabarit.
Les solutions
- Prévoir des tailles d’images adaptées aux usages.
- L’industrialisation des tailles des images sur un site ou un service peut permettre de proposer à l’affichage une taille d’image adaptée au besoin et à l’usage.
- Utiliser la balise <picture> qui permet de charger à la demande la bonne version de l’image en fonction des caractéristiques de la fenêtre d’affichage.
- Mais la balise <picture> ne devrait pas être le premier réflexe, l’utilisation d’images vectorielles est une solution beaucoup plus efficiente lorsque l’image ou le pictogramme s’y prête.
La preuve par l'exemple
```
<picture>
	<source media="(min-width: 599px)" srcset="large.jpg">
	<source media="(max-width: 598px)" srcset="small.jpg">
	<img src="fallback.png" alt="">
</picture>
```
Quelques ressources
- Fiche 15 : Des images en priorité vectorielles
- Fiche 34 : Le bon format d'image au bon moment
- Démonstration : Des boutons, images et typos
fiche précédente fiche suivante
20 - Compresser les documents et choisissez le bon format
Compresser les documents et choisissez le bon format
Catégories
#conception#projet
Description
- Pour les documents en téléchargement, il est souvent plus efficient de les compresser.
- Compresser tous les documents pouvant être téléchargés depuis une page web.
  Sauf si la compression n’apporte pas un gain évident (par exemple, cas d’un PDF parfaitement optimisé pour le Web).
Les solutions
Solution immédiate
- Un document au format DOC pesant 7,8 Mo ne pèse plus que 5,5 Mo une fois compressé, soit un gain de 30 % (compression zip par défaut).
- Attention à fournir un résumé afin de s’assurer que le sujet, le contenu et la technicité potentielle du document sont bien compris dans le but d'être téléchargé.
Solution durable
- Multiplier les formats, légers et accessibles
- Il est très souvent simple de donner accès à une version HTML (ou EPUB) avant de proposer un document MS-Word ou PDF.
- Les versions PDF intégrant des images scannées sont une très mauvaise idée.
  Le plus souvent l’original bureautique existe sur un disque.
La preuve par l'exemple
Pour un même document, voici un aperçu des poids de ces différentes versions (les résultats ont été produits directement sans aucune optimisation) :
- Document MS-Word : 1,1 Mo ;
- Version MAS-Word compressé (ZIP) : 715 Ko ;
- Version PDF : 848 Ko (mais pose nativement des problèmes d'accessibilité) ;
- Version EPUB : 631 Ko ;
- Version PDF compressé (ZIP) : 619 Ko ;
- Version HTML : 430 Ko.
fiche précédente fiche suivante
21 - Limiter les outils d'analyse statistique et les données collectées
Limiter les outils d'analyse statistique et les données collectées
Catégories
#conception#développement#projet
Description
- Les outils utilisés pour suivre les actions des utilisateurs utilisent souvent beaucoup de ressources coté client :
  - Nombreuses requêtes serveur ou SQL ;
  - Fichiers JavaScript supplémentaires chargés ;
  - Utilisation de plusieurs domaines additionnels ;
  - Envoi de cookie ;
  - Etc.
- En complément, certaines solutions hébergent les données collectées sur un serveur tiers, pas nécessairement dans une zone de confiance (RGPD).
Les solutions
Solution immédiate
- Analyser les différents outils du marché et privilégier :
  - Le moins gourmand en ressources ;
  - L’outil installé en local sur votre serveur ;
  - Le paramétrage fin afin de ne collecter et stocker que les informations utiles et nécessaires.
Solution durable et immédiate
- Intégrer directement dans vos pages des scripts serveur (en PHP, Java, Ruby, Python, etc.) afin de stocker en base les informations nécessaires à l’analyse du suivi opérationnel de votre service.
  Le tout en prenant soin d’anonymiser les utilisateurs.
- Le site Access-score.org utilise un script de 20 lignes en PHP (1.2 ko) intégré aux différentes pages qui n’utilise ni requête distante, javascript ou cookie et 1 seule requête SQL.
  Le tableau de bord de suivi est un script de 50 Ko qui n’utilise qu’une requête SQL. Il permet de suivre (en fonction d’une période) avec des graphiques et des données chiffrées :
  - Le nombre de pages visitées (par des visiteurs ou par des robots) ;
  - Le nombre de visiteurs uniques ;
  - Le nombre de visites par pages ;
  - Les sources des visites ;
  - Le nombre de partages sur les réseaux sociaux à partir du site ;
  - La typologie technique des visiteurs (navigateurs, OS, etc.) ;
  - Le taux de visiteurs « mobiles ».
Il est temps de sortir d'un diktat installé depuis quelques années qui dit que seuls les outils du marché peuvent fournir un suivi du trafic et de l'efficience d'un espace Web.
C'est faisable – très facilement — dans le cadre de l'intégration ou du développement des services numériques et cela peut nettement réduire l'impact environnemental d'une page.
Quelques ressources
Fiche 02 du référentiel : limiter le nombre de requêtes HTTP
fiche précédente fiche suivante
22 - Limiter l'utilisation des GIFs animés
Limiter l'utilisation des GIFs animés
Catégories
#conception
Description
- Les GIFs animés sont encore beaucoup utilisés. Un peu sur des sites Web et énormément dans les outils d’échange et de discussion (Teams par exemple) ou sur des forums.
- Il existe des solutions plus légères et moins gourmandes en ressources.
  Ce format d’image animée date de 1995 dans sa version la plus contemporaine. Il est devenu lourd et lent.
Les solutions
- Il existe différentes alternatives aux GIFs animés, des fichiers plus petits pour une qualité identique ou supérieure :
  - SVG Animés ;
  - WebM ;
  - WebP.
- Si les 2 premiers peuvent être intéressants, le WebP est le format qui va permettre exactement les mêmes usages que le GIFs animé avec un gain de poids et de vitesse d’affichage parfois très important.
- Les gains moyens sont de 20 % avec une compression sans perte et de 60% avec une compression avec perte.
- WebP est plus riche en termes de couleurs (24 bits vs 8 bits) ;
Quelques ressources
- Remplacez les GIF animés par des vidéos pour accélérer le chargement des pages
- WebP expliqué
fiche précédente fiche suivante
23 - Éviter la lecture et le chargement automatique des vidéos et des sons
Éviter la lecture et le chargement automatique des vidéos et des sons
Catégories
#conception#développement
Description
- L'activation automatique des vidéos et des sons (autoplay) au chargement des pages web implique une utilisation de ressources sur chaque tiers (terminal, réseau, datacenter).
- Dans de nombreux cas, la lecture automatique n'est pas nécessaire. De plus, elle est source de distraction pour l’utilisateur. La lecture automatique peut ainsi entraîner une rupture de flux dans le parcours utilisateur.
- Le contrôle de la lecture de ces objets multimédia et la non-lecture automatique sont également des exigences de l’accessibilité numérique.
- La lecture automatique avec mise en pause immédiate, le navigateur et les plug-ins de type YouTube commence à charger la vidéo et à alimenter de manière constante (même si la vidéo n’est pas lue) les logs de ses serveurs !
Les solutions
- Supprimer l’attribut autoplay de la balise <video>
- Attribuer la valeur none à l’attribut « preload » afin d’éviter que la vidéo soit préchargée.
- Positionner l’attribut « muted » dans la balise <video>
- Positionner une imagette (attribut « poster ») pour éviter que le navigateur charge et traite la vidéo...
- Supprimer l’attribut « loop » qui entraine la lecture en boucle de la vidéo.
- L’attribut « control » permet de respecter les critères d’accessibilité numérique.
La preuve par l'exemple
- Vidéo
```
<video controls muted poster="contenus/multimedia/imagette.png" preload= "none">
	<source src="contenus/multimedia/video.mp4" type="video/mp4">
	<source src="contenus/multimedia/video.webm" type="video/webm">
	<track label="English : sous-titre et audio description" kind="subtitles" srclang="en" src="contenus/multimedia/subT.vtt">
	<track label="Français : sous-titre et audio description" kind="subtitles" srclang="fr" src="contenus/multimedia/subTf.vtt">
	<track kind="descriptions" src="descriptionsf.vtt" srclang="fr">
<video>
```
- Audio
```
<audio controls="true">
	<source src="contenus/multimedia/audio.mp3" type="audio/mpeg">
	<source src="contenus/multimedia/audio.ogg">
	<track label="English : sous-titre et audio description" kind="subtitles" srclang="en" src="contenus/multimedia/subT.vtt">
	<track label="Français : sous-titre et audio description" kind="subtitles" srclang="fr" src="contenus/multimedia/subTf.vtt">
	<track kind="descriptions" src="descriptionsf.vtt" srclang="fr">
<audio>
```
Quelques ressources
- Mozilla developper : la balise video
- Démonstration : Un exemple audio et vidéo, lecteurs HTML5
fiche précédente fiche suivante
24 - Mettre en place un sitemap efficient et à jour
Mettre en place un sitemap efficient et à jour
Catégories
#développement
Description
- Le sitemap (plan du site) permet de faciliter l'indexation des pages et des contenus d'un site web par les moteurs de recherche.
- Un sitemap non mis à jour peut contenir des URLs qui n'ont plus raison d'y être, car elles font référence à des pages ou des contenus peu visités et peu utiles.
- Un site non maintenu à jour augmente le risque d'avoir des utilisateurs – via les moteurs de recherche — qui arrivent sur des pages sans intérêt, générant des erreurs ou sur des pages orphelines.
- Lutter contre ce type d'erreur permet d'éviter un gaspillage de ressources informatiques.
- Le sitemap est un outil intéressant pour le référencement naturel
Les solutions
- Re-générer régulièrement le sitemap à partir d'un script présent sur le serveur. Si ce n'est pas possible, à partir d'outils en ligne.
  Cela permettra de faire un point intéressant de votre réelle arborescence et de faire le tri afin d'optimiser votre présence sur les moteurs de recherche aussi bien qu'une partie de votre impact environnementale.
- Vérifier les sources d'erreur (404 ou autres) et n'hésitez pas à supprimer le sitemap puis à en créer un tout neuf, tout beau.
Quelques ressources
- Le guide complet du fichier sitemap Google pour le SEO
fiche précédente fiche suivante
25 - Limiter le recours aux carrousels
Limiter le recours aux carrousels
Catégories
#conception
Description
- Le carrousel permet de mettre en avant plusieurs éléments de contenus en une seule place.
  Il est possible de discuter l'impact sur l'expérience utilisateur.
- Mais certains points techniques en font généralement un outil de piètre qualité pour son impact environnemental et son accessibilité :
  - Un alourdissement du poids des pages par la présence de CSS et JavaScript dédié, mais également par le contenu présent sur chaque écran du carrousel ;
  - Une utilisation plus importante des ressources processeurs dans le cas d'un carrousel automatique.
Les solutions
- Si le carrousel est constitué d'images, utiliser le chargement différé afin de ne pas inutilement appeler des images qui ne seront pas affichées.
- Utiliser des images SVG ou la balise et des formats adaptés.
- Animer le carrousel uniquement avec quelques éléments CSS, pas de ressources JavaScript (ou le minimum vital).
- Ne pas lancer automatiquement la lecture du carrousel, même motifs que pour la vidéo ou le son.
  Et laisser le contrôle à l'utilisateur.
- Faites coder un simple carrousel sans JS, puissant, léger et respectueux des normes et des bonnes pratiques.
- Les animations de certains attributs CSS impliquent un repaint/reflow des navigateurs qui demandent des ressources machines. Pour limiter cela, préférez les animations des carrousels par la propriété CSS transform.
- Limiter le nombre d'écrans présents dans le carrousel.
La preuve par l'exemple
```
<div class="carousel">
	<ul>
		<li><span class="enveloppe"><img src="pic/c1.svg" alt="">et du texte en prime</span></li>
		<li><span class="enveloppe">ou que du texte</span></li>
		<li><span class="enveloppe"><img src="pic/c2.svg" alt=""></span></li>
		<li><span class="enveloppe"><img src="pic/c3.svg" alt=""></span></li>
		<li><span class="enveloppe"><img src="pic/c4.svg" alt=""></span></li>
		<li><span class="enveloppe"><img src="pic/c5.svg" alt=""></span></li>
		<li><span class="enveloppe">on peut tout imaginer</span></li>
		<li><span class="enveloppe"><img src="pic/c6.svg" alt=""></span></li>
	</ul>
	<nav>
		<span class="nav précédent" tabindex="1">&lt;</span>      
		<span class="nav suivant" tabindex="1">&gt;</span>
	</nav>
</div>
```
Le reste du code est disponible sur la démonstration : Les carrousels
Quelques ressources
La démonstration : les carrousels
fiche précédente fiche suivante
26 - Avoir une stratégie de fin de vie des contenus
Avoir une stratégie de fin de vie des contenus
Catégories
#conception#projet
Description
- Les contenus multimédias (images, sons, vidéos) peuvent permettre d'améliorer l'expérience utilisateur et de rendre le service plus efficacement.
- Lorsque les contenus contenant ces éléments sont dépubliés, donc inaccessibles à l'utilisateur, ces éléments restent le plus souvent sur les serveurs.
- Continuer à les stocker, les gérer ne fait plus de sens, ils existent hors ligne et il n'est plus nécessaire de les conserver en ligne.
- Ce stockage représente une consommation inutile de ressources disques et d'énergie et le plus souvent ils continuent à être intégrés dans les stratégies de sauvegarde, doublant le gaspillage d'utilisation de disque, de la bande passante et de l'énergie pour la gestion.
Les solutions
- Mettre en place une politique de suppression ou d'archivage de ces contenus afin d'éviter la sollicitation inutile de stockage et permettre la libération d'espace pour de nouveaux contenus.
- Reprendre l'exemple des stratégies de gestion documentaire et mettre en place une stratégie d'archivage froid pour ces contenus.
- Si ces contenus sont directement stockés en base de données, la même politique peut être appliquée, cela libèrera également de l'espace disque et permet d'avoir une meilleure gestion de sa base de données.
fiche précédente fiche suivante
27 - Préférer la pagination au défilement infini
Préférer la pagination au défilement infini
Catégories
#conception
Description
- Lorsqu'on affiche une liste de produits, d'articles, sur un site, il est tentant de donner la possibilité au visiteur de tout voir en faisant simplement défiler la page, en chargeant le contenu petit à petit.
- Cette fonctionnalité demande au serveur d’afficher (et donc de servir / requêter) les contenus au fur et à mesure (ou par paquet de n éléments) en fonction de l’avancée de l’utilisateur.
- Cette fonctionnalité entraîne à la fois des problèmes de performances et de respect des normes environnementales (sollicitation inutile des serveurs, des disques et des ressources réseau), de référencement naturel (un robot d’indexation ne fait pas défiler la page).
- L’accessibilité est parfois comme un élément problématique, mais cela dépend largement de la manière de coder cette fonctionnalité.
Les solutions
- Mettre en place un affichage de liste classique (n élément par page) avec un système de pagination et des filtres afin de limiter (par le choix de l’utilisateur) le nombre d’éléments à afficher.
- Laisser l’utilisateur choisir le nombre d’éléments par page en proposant par défaut un nombre raisonnable (20 / 30, mais cela dépend également du contexte).
- L’utilisateur peut ainsi trouver plus facilement ce qu’il cherche avec la page comme point de repères.
- C’est aussi vrai pour les robots des moteurs de recherche.
- Cette solution peut aussi permettre de réduire légèrement le nombre d’éléments proposés par page en fonction de pic de sollicitation.
- La pagination intégrée à une page demande de plus de mettre en place des éléments de repères à destination des aides techniques dans le cadre du respect de l’accessibilité numérique.
Quelques ressources
La démonstration : les tabulations et pagination
fiche précédente fiche suivante
28 - Mesurer le poids des pages
Mesurer le poids des pages
Catégories
#conception#développement
Description
- Si le poids des pages n’est pas et ne pas être l’objectif majeur et une fin en soi. Il existe d’autres critères parfois plus important (charge CPU, GPU et RAM par exemple).
- Mais la mesure du poids des pages permet de s’assurer d’avoir un code durable et simple, permet de limiter les dépendances et le poids des contenus multimédia.
- La mesure du poids des pages est une des métriques à utiliser avec des objectifs partagés par tous les acteurs du projet.
- Vouloir – à juillet 2023 – être dans les 10% les plus légères est un objectif intéressant.
  Fixer un quota absolu devrait être également intégré à la démarche.
Les solutions
- Utiliser des outils de mesure de poids des pages tels que :
  - Web Site Carbon calculator
    Le site permet également d’installer un widget sur les pages
  - GreenPixie ;
  - Beacon ;
  - Karma metrix ;
  - EcoGrader
- Les résultats (cf. le bloc « exemples ») montrent que les résultats ne sont pas les mêmes. Les modes de calcul ne sont pas tout à fait les mêmes.
  Néanmoins, ces services permettent de comparer la mesure avec un ensemble de mesure.
- L’important n’est pas nécessairement la valeur absolue, mais le fait d’être parmi les plus durables / performants.
La preuve par l'exemple
Pour la page d’accueil de la démonstration, les résultats sont (en gramme de CO2 par visite) :
- Web site carbon : 0.08 (92 %) ;
- Greenpixie : 0,25 (97 %) ;
- Beacon : 0.115 (Impressionnant, moins de 0.25);
- Karma : 0,258 (84 %);
- Ecograder : 0,12 (92 %).
fiche précédente fiche suivante
29 - Afficher des pages d'erreur statiques
Afficher des pages d'erreur statiques
Catégories
#développement
Description
- Lorsque le navigateur demande une ressource qui n’existe pas (image, feuille de styles CSS, fichier JavaScript, etc.) ou que le serveur renvoie une erreur, la page d'erreur renvoyée peut être plus lourde que la ressource ou la page demandée.
- Si l’erreur est bloquante (404 - non trouvée pour une page, 500 – erreur serveur, etc.), une page message d’erreur est affichée.
- Dans le contexte d’un CMS, même si la ressource demandée est inexistante, la routine de recherche de contenu (dans la base de données) va rechercher une ressource à afficher.
  Par conséquent, du code serveur est exécuté, le serveur de base de données est sollicité, et la génération dynamique de la page HTML est exécutée.
  Tout ce processus aboutit à un gaspillage de cycles CPU, de mémoire vive et de bande passante.
Les solutions
- Les pages d'erreurs (40x, 50x), le serveur HTTP doit prendre en compte la gestion et afficher des pages les plus légères possibles.
- Dans la même logique, il convient d’éviter les pages 40x dynamiques, qui sont personnalisées en fonction du contenu de l’URL.
- Préférer une page d’erreur statique en HTML.
- Concernant les pages ou les erreurs du serveur d’application (et en dehors des erreurs 40x et 50x), une simple page d’information claire et informative est suffisante.
- Ce type de page devrait être légère et appeler le moins de ressources possibles.
- De plus, en production, en prenant en compte les dimensions UX, confort d’utilisation et sécurité, une page d’erreur doit aider l’utilisateur dans sa navigation et sa compréhension de l’erreur, mais ne doit pas donner de détail technique.
La preuve par l'exemple
Exemple d'une page d'erreur statique sur le site de démonstration.
fiche précédente fiche suivante
30 - Choisir un hébergeur et un fournisseur d’énergie éco-responsable
Choisir un hébergeur et un fournisseur d’énergie éco-responsable
Catégories
#projet
Description
- Le coût environnemental d’un hébergement (serveurs applicatifs et données) peut représenter une grosse partir de l’impact environnemental d’un service.
- Les six critères à prendre en compte sont :
  - Gestion des DEEE (déchets d’équipements électriques et électroniques) ;
  - Efficience énergétique du data center [Power Usage Effectiveness (PUE) / Carbon Usage Effectiveness (CUE) / Water Usage Effectiveness (WUE)] ;
  - Politique d’achat responsable ;
  - Respect de la dimension sociale ;
  - Alimentation aux énergies bas-carbone ;
  - Compensation carbone.
Les solutions
- Préférer un hébergeur qui combine des serveurs économes à une alimentation sans énergie fossile (pétrole, gaz, charbon) basé principalement sur des sources d’énergies renouvelables.
- De nombreux hébergeurs partagent leur politique environnementale, et diffusent la valeur de leurs indicateurs (PUE / CUE / WUE...).
  Ces points devraient être intégrés à la note d’analyse et de choix de l’hébergeur.
La preuve par l'exemple
- Préférer un hébergeur qui combine des serveurs économes à une alimentation sans énergie fossile (pétrole, gaz, charbon) basé principalement sur des sources d’énergies renouvelables.
- De nombreux hébergeurs partagent leur politique environnementale, et diffusent la valeur de leurs indicateurs (PUE / CUE / WUE...).
  Ces points devraient être intégrés à la note d’analyse et de choix de l’hébergeur.
Quelques ressources
- GreenIT : électricité
- Comment choisir un hébergeur vert
fiche précédente fiche suivante
31 - Un Captcha simple, accessible et local
Un Captcha simple, accessible et local
Catégories
#conception#développement#projet
Description
- L’utilisation d’un captcha (un utilisateur tente de démontrer qu’il n’est pas une machine afin d’accéder à un service ou des informations) est devenu très importante et pose à la fois des problèmes d’accessibilité et de gestion / consommation de ressources et d’énergie.
- Avant de mettre en place une solution accessible et plus durable, il est important de questionner l’utilisation d’un captcha et de poser la question de la nécessité de chercher à cacher la page ou les informations à des robots (y compris ceux des moteurs de recherche).
- Il est important de noter que les captchas ne sont pas la panacée : certains robots arrivent à passer les captchas.
  Il est possible d'écrire des programmes qui résolvent les tests de reconnaissance d'images.
  De plus, il est possible d’utiliser des fermes à clics pour passer les tests.
Les solutions
- La première des solutions serait d’utiliser le moins possible les captchas.
- Lorsque le captcha est jugé nécessaire, des solutions respectant l’accessibilité et l’environnement existent.
- La solution proposée n’est pas infaillible, mais fonctionne et a été testée par des utilisateurs en situation de handicap.
  - Il s’agit d’un simple test arithmétique qui propose une équation en mode littérale et demande une réponse chiffrée.
  - La question est générée à la volée après la construction du DOM (de la page) afin de ne pas être directement lisible par un robot.
  - Ce captcha ne fait appel à aucune ressource tiers, aucune image, il ne pèse que quelques octets et utilise uniquement HTML, CSS et JavaScript.
La preuve par l'exemple

Quelques ressources
- Histoire du captcha
- Démonstration : le captcha
fiche précédente fiche suivante
32 - Réapprendre à coder soi-même
Réapprendre à coder soi-même
Catégories
#développement
Description
- Historiquement, les variations d’interprétation du langage JavaScript par les différents moteurs de rendu des navigateurs a pu rendre l’utilisation de ce langage plus difficile que d’autres.
- Des Frameworks et des bibliothèques (Jquery par exemple) ont permis de s’affranchir de ces difficultés et de la syntaxe native de JavaScript pour une syntaxe cohérente.
- Mais, si l’usage du JavaScript se limite à bouger des blocs, modifier simplement le DOM ou les contenus de containers, voire jouer avec les propriétés CSS, la taille des fichiers supplémentaires à charger est disproportionné.
- De même, le recours systématique à des Frameworks JavaScript pour des pages majoritairement statiques ou pour des modules assemblables côté serveur est un gaspillage énorme de ressource et de temps d’exécution / affichage des pages.
- Le coût peut atteindre plusieurs Mo par page.
Les solutions
- Analyser le besoin et la nécessité de ces ajouts.
- Lors de l’utilisation d’éléments du DOM ou de quelques fonctions de calcul en JavaScript, l’utilisation d’une bibliothèque telle que JavaScript est totalement inutile, quelques lignes / fonctions natives en JavaScript suffisent largement.
- Le recours systématique au Framework JavaScript (reactJS, Angular ou Bootstrap, etc.) est une tentative déraisonnable de fausse simplification.
- Ces éléments ont été créés et popularisés par des groupes tels que Meta, Google et Twitter) et ensuite repris sans aucune approche critique par des cohortes de développeurs éblouis par de fausses promesses.
  Certains estiment que moins de 10 % des projets gagneraient à utiliser ces éléments.
- L’argument du respect de l’accessibilité grâce aux Frameworks est totalement erroné, aucune garantie au mieux, pas d’incompatibilité.
  La solution est simplement de coder directement en JavaScript en industrialisation des fonctions open-source ou du code d’entreprise (voire les 2).
  Le tout avec une maîtrise de ce qui est fait et de l’obsolescence du tout.
La preuve par l'exemple
- Vérification de l’état d’une case à cocher en jQuery
```
if ($("#"+quoi).prop("checked"))console.log("cochée !!" ); 
```
- Même fonctionnalité en pur Javascript
```
var selection = document.getElementById(quoi); 
if (selection.checked) console.log("cochée !!");
```
- Modification de classe CSS sur un ensemble d’éléments en jQuery
```
$(".entrée").removeClass("selection");
```
- Même fonctionnalité en pur Javascript
```
var liste = document.querySelectorAll(".entrée"); 
for (var l = 0; l <liste.length; ++l) {
     liste[l].classList.remove("selection"); 
}
```
  mais on peut industrialiser avec une fonction réutilisable :
```
function changeCSS(quoi,avec) { 
    var liste = document.querySelectorAll(quoi);
    for (var l = 0; l &lt; liste.length; ++l) {  
         liste[l].classList.remove(avec); 
    } 
}
```
  Ce qui donnerait :
```
changeCSS($(".entrée","selection") ;
```
  Simple ! Donc, pas de grosses différences mais à minima (car jQuery peut nécessiter plusieurs dépendances) 89,5 Ko et du trafic réseau économisés (jquery-3.6.0.min.js = 89.5 Ko).
fiche précédente fiche suivante
33 - Questionner les données affichées (et leur qualité)
Questionner les données affichées (et leur qualité)
Catégories
#conception#développement
Description
- Les données affichées sur une page le sont à la fois par efficience du parcours et la bonne compréhension d’un contexte par un utilisateur, mais il est fréquent que cet affichage soit le fruit d’une habitude, d’un sur-confort ou d’une duplication.
  C’est d’autant plus vrai pour des applicatifs de gestion.
  - Les habitudes : On a toujours affiché ces données, elles sont disponibles donc, les utilisateurs ne se plaignent pas, etc.
  - Le sur-confort : c'est plus simple, on fait une seule requête et on affiche tout, pour les utilisateurs, au moins, ils ne manquent pas d'infos, etc.
  - La duplication (en base) : En copiant les données chez nous, on est sûr qu'elles sont là, on fait notre possible pour qu'elles soient à jour, etc.
- Ce sur-affichage correspond à la fois à des requêtes supplémentaires, une surconsommation de bande passante, mais également – encore trop souvent – à un stockage dupliqué (une partie du détail de données d’un référentiel est également stockée comme donnée d’un objet géré).
- Les analyses UX des pages qui affichent ces données n’a été ni questionnées, ni optimisées. Ces pages montrent le plus souvent des irritants en termes d’efficience (lecture, saisie, bonne compréhension des données, etc.).
Les solutions
- Le simple fait de n’afficher que la donnée de référence qui fait sens pour l’utilisateur avec un lien par un ID technique vers un référentiel est généralement suffisant, principalement dans les interfaces de saisie ou de contrôle.
- La solution est à la fois fonctionnelle, de gestion et technique.
  - Fonctionnelle : quelles sont les données suffisantes et nécessaires à la bonne utilisation / compréhension du processus, de l’information, etc.
  - Gestion : la donnée est-elle bien unique, gérée et stockée dans un lieu unique et au bon format ?
  - Technique : comment permettre aux utilisateurs d’avoir accès à l’ensemble des données nécessaires en minimisant le nombre et le poids des requêtes
- C’est dans les écrans de restitutions que des détails utiles et signifiantes pourront être affichés.
- La possibilité de stocker de potentielles grandes quantités de données structurées localement peut permettre de lire et d'écrire des données issues de bases de données en 1 seule fois par session ou plus.
- En positionnant un indicateur de rafraîchissement des données en base, la ou les requêtes vers la base ne sont déclenchées que lorsque les données ont été mises à jour.
  Un exemple documenté est disponible sur la démo Access-Score.
La preuve par l'exemple
Pour un applicatif métier à haut enjeux de performance, l'application de cette règle a permis :
- De permettre l'affichage de l'écran principal sans ascenseur ;
- Réduire de 40 % les données consommées ;
- Simplifier les saisies et obtenir un gain d'efficience estimer à plus de 12% ;
- À réduire le coût des licences / coût d'accès à des logiciels tiers ;
- Réduire l'utilisation de la bande passante et du stockage.
Quelques ressources
- Fiche 03 : Stocker les données statiques localement
- La démonstration : consommer local (moins de requêtes SQL)
fiche précédente fiche suivante
34 - Le bon format d'image au bon moment
Le bon format d'image au bon moment
Catégories
#conception#développement
Description
- En fonction des conditions d’utilisation, il peut être plus approprié de charger une image d’une taille différente ou adaptée à l’orientation de l’écran.
- Des formats d’images apparaissent qui peuvent ne pas être reconnu et utilisé par certains navigateurs.
- D’un point de vue de la gestion et technique, coder les images de la même manière que les vidéos ou les sons pour traiter ces points pourrait être pratique.
Les solutions
Une solution technique est :
- Avoir la possibilité d'utiliser les média queries pour charger la bonne image
- Permettre un système de secours afin de toujours charger une image
- Avoir une balise équivalente à <video> avec un système de ressources
- La solution est l’utilisation de la balise <picture>
  - Le navigateur va essayer de charger / afficher dans l'ordre les images lister dans la liste des ressources avec une solution de secours avec la balise intégrée.
  - Il est possible (conseillé) d’appliquer un mode de chargement « économe (lazy) » et un traitement asynchrone de l’image.
  - Nous obtenons ainsi des performances maximales et impact environnemental minimal.
  - u niveau accessibilité, c'est simple, c'est l'attribut alt de la balise <img> qui prend en charge le sujet.
- Des tests de performances sur le poste client sont disponibles sur le référentiel de mesure AMIE
La preuve par l'exemple
Le chargement de l’image en fonction de la taille de la fenêtre et de l’orientation de la fenêtre :
```
<picture> 
    <source srcset="pictureV.avif" type="image/avif" media="(orientation: portrait), (max-width: 1080px)">
    <source srcset="pictureV.jpeg" type="image/jpeg" media="(orientation: portrait), (max-width: 1080px)"> 
    <source srcset="pic/picture/pictureB.webp" type="image/webp" media="(orientation: portrait), (min-width: 3300px)"> 
    <source srcset="pic/picture/picture.avif" type="image/avif"> 
    <source srcset="pic/picture/picture.webp" type="image/webp"> 
    <img src="pic/picture/picture.png" alt="" loading="lazy"> 
<picture>
```
Quelques ressources
- Fiche 15 : Des images en priorité vectorielles
- Mozilla Developper, : l'élément d'image adaptative
- Démonstration : des boutons, images et typos
- Le référentiel des images sur AMIE
fiche précédente

Le référentiel

Filtrer les fiches

Les fiches

Découper les CSS en fonction des contextes d’utilisation​Tout en limitant leur nombre​

Catégories

Description

Les solutions

La preuve par l'exemple

Quelques ressources

Découper les CSS en fonction des contextes d’utilisationTout en limitant leur nombre