25 Oct 2021

Écoconception web / Les 115 bonnes pratiques

Je viens de finir la lecture du livre « Écoconception web / Les 115 bonnes pratiques » (3^e édition) par Frédéric Bordage (la liste, sans les détails).

Je ne peux que recommander ce livre, bien que je pense qu’une bonne partie de ces pratiques (surtout celles techniques) est déjà censée être connue de la majorité des développeurs et ingénieurs logiciels vue qu’elles touchent aussi à la performance. À mon avis, comme l’indique le livre, le plus gros à gagner est sur la partie métier/fonctionnelle des développements informatiques. Combien de fonctionnalités complexes et gourmandes qui n’ont quasiment jamais servies ai-je dû développer ? Beaucoup trop.

Ceci étant dit, j’ai aussi quelques petites remarques et améliorations à faire à ce livre :

• Remplacer l’anglicisme « digital » par « numérique ».
• Remplacer Ko par ko ou Kio.
• Bonne pratique n°9 : les références aux autres bonnes pratiques n’ont pas été mises à jour. La 18 est maintenant la 30, 23 → 20, 81 → 79.
• Bonne pratique n°9, 20 et 79 : l’utilisation de HTTP/2 (standardisé en 2015) rend l’impact de ces bonnes pratiques très limité (limite contredites par la bonne pratique n°21), voire contre productif (fichiers plus gros, priorisation des ressources, gestion du cache moins fine).
• Bonne pratique n°12 et 115 : tous ces plugins sont déjà morts. Adobe a annoncé la fin de Flash sur mobile en 2011, et Adobe a annoncé en 2017 qu’ils allaient complètement abandonner Flash en 2020. Les Applets Java sont dépréciés depuis 2017. Microsoft a commencé à abandonner Silverlight en 2015 avec une fin de support de Silverlight en 2021. Ce sont donc des bonnes pratiques inutiles, ça fait des années qu’il est insensé d’utiliser Silverlight, Flash et les Applets Java. Bref, au moins supprimer la 115 et s’il y a encore des plugins existants, mettre à jour la 12.
• Bonne pratique n°15 : l’exemple n’est compréhensible que par des personnes ayant une certaine connaissance des deux technologies citées. Il faudrait soit donner une explication plus détaillée, soit donner un autre exemple.
• Bonne pratique n°16 : mettre un benchmark fait par Percona pour comparer MySQL et Percona… c’est potentiellement biaisé. Supprimer ou remplacer cet exemple. MariaDB semble avoir des performances encore meilleures que Percona mais à la base n’est pas un fork orienté performances.
• Bonne pratique n°22 : 2 pratiques en 1, c’est la 9 et la 78, à supprimer.
• Bonne pratique n°27 : il y a des gens qui impriment encore ? Peut-être la meilleure solution serait cette CSS d’impression (comment ça j’empêche les gens de faire ce qu’ils veulent ? 😉).
• Bonne pratique n°28 : les commentaires conditionnels fonctionnent qu’avec Internet Explorer il me semble. Et comme Internet Explorer n’existe plus, cette pratique peut probablement être supprimée.
• Bonne pratique n°29 : il faudrait peut-être mentionner les polices systèmes.
• Bonne pratique n°32 : mentionner qu’avec des règles CSP adéquates (interdisant les CSS et JS embarqués), c’est aussi une bonne pratique de sécurité.
• Bonne pratique n°33 : heu… quoi ? Il y a des gens qui mettent des images avec une source vide ? Mais pourquoi ? 😱
• Bonne pratique n°37 : mentionner en priorité l’utilisation de la valeur lazy pour l’attribut loading de l’image (encore expérimentale, mais fonctionne sur les navigateurs principaux).
• Bonne pratique n°48 : pratique en contradiction avec le principe DRY et donc une augmentation de bugs et des coûts de maintenance. D’autant plus que beaucoup de langages sont capables d’optimiser les appels à des fonctions simples pour les inliner dans le code compilé. Ici le livre parle spécifiquement de JavaScript et c’est une optimisation que V8 (Chrome) et SpiderMonkey (Firefox) font. A minima, il faudrait indiquer les inconvénients liés à cette pratique.
• Bonne pratique n°63 : c’est une bonne pratique, ne serait-ce que d’un point de vue lisibilité et maintenabilité. En revanche lui mettre un impact écologique fort m’étonne. Le compilateur devrait être capable d’optimiser des cas simples comme celui-là (l’exemple est en PHP et PHP gère ce genre d’optimisations). Si ce n’est pas le cas, la solution est clairement d’ouvrir un ticket chez les responsables du développement du compilateur.
• Bonne pratique n°72 : l’exemple utilise une fonction qui n’existe plus mysql_* au lieu de mysqli_*, mais surtout est vulnérable à des attaques de type injection SQL. Il faudrait mettre un meilleur exemple.
• Bonne pratique n°84 : il faudrait indiquer que c’est aussi une bonne pratique de sécurité et que dans beaucoup de cas avoir le site accessible uniquement en HTTPS (modulo cette redirection de HTTP vers HTTPS) est une obligation légale.
• Bonne pratique n°91 : mise en œuvre facile, mais les pictogrammes indiquent difficile.
• Bonne pratique n°94 : plusieurs bonnes pratiques parlent de mettre les données statiques sur un domaine séparé pour ne pas avoir à transporter de cookie, avec une politique de cache plus agressive, etc. À noter, comme dans l’exemple donné, ce n’est pas un sous-domaine qui est utilisé, mais un domaine différent, et ce, pour des questions de sécurité. Dans cet exemple, il s’agit de données téléversées par des utilisateurs et donc potentiellement compromises ou malveillantes. L’utilisation d’un domaine différent couplé avec les bonnes règles CSP permet de limiter les attaques de type XSS. Par ailleurs, il faudrait indiquer que cette bonne pratique n’est pas à appliquer aveuglément non plus. Par exemple, elle ne s’applique pas pour les ressources statiques dont l’accès est soumis à autorisation.
• Bonne pratique n°98 : remarque similaire que pour la 94, attention à la sécurité. La plupart des CDN offrent la possibilité de restreindre l’accès aux ressources via des tokens, à utiliser pour les ressources nécessitant un contrôle d’accès.
• Bonne pratique n°99 : « On constate également qu’un cache généraliste comme APC n’est pas adapté »… Le graphique est difficile à lire, mais, à vue de nez, APC double (au moins) le nombre de requêtes traitées par seconde et réduit la latence (au moins) de moitié. APC n’est certes pas suffisant, mais cette phrase est juste fausse (ou très mal formulée).
• Bonne pratique n°106 : il faudrait ajouter que c’est une bonne idée uniquement dans le cas où le serveur de base de données n’est pas répliqué. Sans logs binaires, la réplication ne fonctionne plus.
• Bonne pratique n°107 : l’exemple site beaucoup de formats déjà compressés. Les fichiers docx et xlsx sont des fichiers zip, les recompresser est inutile. De même, les contenus multimédias (images, audio et vidéo) sont en général déjà très compressés et les compresser davantage n’apporte rien, voire consomme du temps processeur en plus inutilement. Dans la mesure du possible, pour les fichiers que l’on peut compresser, utiliser une technique comme dans la bonne pratique 78, pré-compresser les fichiers de sorte qu’ils soient décompressés à la volée par le navigateur du destinataire de façon transparente. Ça évite d’avoir l’antivirus qui décompresse le fichier pour le scanner, puis le système d’indexation du système d’exploitation, puis l’utilisateur pour accéder au contenu et que dans beaucoup de cas l’utilisateur oubliera de supprimer le fichier zip (consommation d’espace disque). Attention tout de même, la compression de données sur une connexion chiffrée n’est pas forcément une bonne idée (cf. CRIME et BREACH), à coupler avec la bonne pratique 94 pour limiter les risques.
• Bonne pratique n°109 : j’aurais tendance à dire que c’est déjà fait par tous les services d’emailing et que si ce n’est pas le cas, les utilisateurs concernés vont vite se plaindre.
• Bonne pratique n°110 : avec le RGPD, c’est plus ou moins une obligation légale et souvent une obligation contractuelle avec les services d’emailing.
• Bonne pratique n°112 : il faudrait peut-être donner plus d’explications théoriques sur la compression avec perte et peut-être parler aussi de formats comme Opus pour des fichiers audio contenant que de la voix, voire contenant de la musique.
• Bonne pratique n°114 : parler de DASH.
• Réorganiser les 112, 113 et 114 en 113, 112 et 114.

Les outils et techniques de développement évoluent rapidement et il est difficile d’être à jour longtemps dans un livre, c’est pourquoi ce livre en est à sa troisième édition en seulement sept ans. Mais, même comme ça, certaines pratiques semblent obsolètes. Vivement une quatrième édition 😉.

Certains frameworks de développement modernes intègrent une bonne partie de ces bonnes pratiques techniques par défaut.

Ce qui me désole, c’est que pour le moment nous n’avons pas de bonne alternative au web. Les technologies du web ont beaucoup de problèmes (de sécurité, de vie privée, de performance, de complexité…) et qu’il faut déployer des moyens extra-ordinaires pour limiter les dégâts. Et par conséquence, l’obésiciel numéro 1 est le navigateur web.

Quoi qu’il en soit, ce livre est une référence de bons conseils, à mettre entre toutes les mains et pas seulement celles des techos (à faire lire à l’équipe marketing qui veut mettre une vidéo en fond de la page d’accueil parce que « tu comprends, ça dynamise la page et ça fait joli » 😉).

Update 2021-11-22 : je conseille aussi de consulter le référentiel général d’écoconception de services numériques de la DINUM.