Solutions pour la performance

Quelles solutions pour l'écoconception ?

21/03/2021

Sommaire du dossier


Les axes de la performance

La performance est un élément essentiel d'un site que ce soit pour des raisons environnementales évidentes ou des raisons d'efficacité.
Si je crée un site, c'est bien dans l'optique que les internautes qui y viennent puissent le faire dans des conditions agréables. Je ne vise pas spécialement le nombre de visites mais plutôt la qualité du contenu pour des personnes intéressées. Le fait de pouvoir accéder rapidement à la lecture est de toute évidence un facteur important. Personne n'aime attendre et un contenu qui s'affiche rapidement est un pas de plus vers une lecture attentive.
Ce phénomène est bien connu sur les sites de e-commerce (1), dont certains vont même chercher à gagner des centièmes de seconde.

On le voit donc, la performance environnementale et un accès rapide vont de pair. On peut aussi montrer qu'une démarche d'écoconception implique aussi une amélioration de la sécurité mais ce ne sera pas l'objet de cet article.

Les axes de la performance sont multiples et présentés de manières diverses par les outils du marché. Toutefois, que l'on travaille selon un outil de mesure ou un autre, au bout du bout, une grande partie du travail sera fait et améliorera le score de chacun des autres outils.

Il est intéressant d'en avoir plusieurs malgré tout car chacun apporte son lot de conseils et de bonnes pratiques permettant d'améliorer l'impact environnemental au-delà de ses propres bonnes pratiques déjà acquises et appliquées naturellement.

Mais pourquoi parler de mesure alors que les axes ne sont pas définis ? C'est très simple. Sans mesure, il est vain de vouloir améliorer quoi que ce soit car on n'a ni référence de départ ni valorisation de l'amélioration. Il est donc illusoire de se définir un axe de performance si aucun moyen de mesure le concernant existe ou est facilement accessible.

Les outils de mesure

Ecoindex

Cet indice est une des références sur le web. Il permet de définir un score pour un site selon 3 critères et 3 niveaux d'impact (2) ; ils sont classés par ordre de pondération décroissante :

  1. L'internaute est directement impacté par la complexité de la page et donc de sa structure plus communément appelé DOM (Document Object Model) (3)
  2. Le serveur est lui impacté par le nombre de requêtes que la page génère que ce soit pour accéder aux feuilles de styles, aux images, aux scripts, ...
  3. Le réseau est impacté par la quantité de données transférées et donc le poids généré de la page

Il est évident que d'autres facteurs interviennent dans le calcul de l'impact mais ils ne sont pas à la portée d'un outil "grand public". Quel est le mix énergétique qui alimente le datacenter du serveur ? Quelle est la complexité du code qui génère la page, et donc son impact sur le processeur et la mémoire du serveur en amont de la génération finale de la page ? Quel est le taux d'optimisation des serveurs dans le datacenter ? Et bien d'autres questions peuvent se poser.

En tout état de cause, ces trois critères sont déjà un bon point de départ. Mais il faut faire attention toutefois à trouver les bons compromis. En effet, si on souhaite diminuer le nombre de requêtes, on peut imaginer embarquer tout le code dans le fichier html : intégration des feuilles de style, des images en base64, ... et faire une page qui ne comporte qu'une requête. Mais la moindre modification de code va obliger chaque internaute à recharger l'intégralité de la page. Alors qu'un découpage (à titre d'exemple) avec un fichier html, une feuille de style et une image embarquant toutes les illustrations de la page permet d'éviter un rechargement global.

On peut retrouver Ecoindex soit sur le site ecoindex.fr ⎋(4) (en cours de remaniement à l'heure où j'écris cet article) soit en tant qu'extension des navigateurs Firefox et Chrome ; elle se nomme GreenIT Analysis ⎋(5) et donne des résultats quasiment identiques à ceux obtenu sur le site.

GTMetrix et consorts

Sous ce nom, je regroupe GTMetrix ⎋(6) mais aussi FastOrSlow ⎋(7), PageSpeed Insights ⎋(8), LightHouse ⎋(9), WebPageTest ⎋(10) et sûrement d'autres. Leur mesure se base sur des éléments similaires à Ecoindex mais aussi sur :

Il est intéressant de varier les outils car ils offrent des visualisations de résultats différentes (même si la présentation en waterfall (12) est présente sur la plupart) ce qui permet de mieux aborder les optimisations. Par exemple, FastOrSlow offre une mappemonde des accès aux serveurs permettant d'identifier tout de suite quelles requêtes nous amène au bout du monde.

Ils offrent aussi pour certains de précieux conseils qui aident les gens comme moi qui n'ont pas une culture du développement.

En plus de ces conseils, GTMetrix ou WebPageTest permettent de définir le type de réseau d'accès à Internet côté utilisateur, allant du modem 56K (cela ne rajeunit pas) à une connexion sans limite (ce qui, au sens Numérique Responsable, ne devrait pas exister au moins côté internaute).

PageSpeed Insights ou LightHouse donnent aussi des informations sur la partie mobile.

Les navigateurs eux-mêmes

Que ce soit Chrome (ou ses dérivés) ou Firefox, il est tout à fait possible d'accéder à une console Développeur qui distille de très nombreuses informations sur les performances, comme le font les outils de mesure précédents.
Pour y accéder, il faut faire :

La mesure LightHouse présentée plus haut se décline aussi en extension pour Firefox ou Chrome.

Divers

J'aime utiliser WebSite Carbon ⎋(13) car c'est un bon élément de diffusion de l'information. Il donne à l'internaute l'équivalent en poids CO2 de la page (14) afin de le sensibiliser. Toutefois, cela représente une requête de plus et qui plus est sur un serveur distant (même si c'est géré pour ne solliciter le calcul qu'une fois par jour). J'ai donc décidé de le mentionner mais pas de l'intégrer.

Pour information, les pages que je génère produisent aux alentours de 0,01 g de CO2 par visite soit dans le top 2% des sites testés. Est-ce que le 0,01 g est exact ? Alors que le calcul Ecoindex donne plutôt 1,3 g. Sachant que WebSite Carbon a changé sa méthode de calcul pour prendre en compte l'évolution des technologies et du parc amenant une division par 3 de l'impact, on peut imaginer que la vérité est entre les deux mesures.

Mais ce n'est pas important.

Mesure absolue ou relative ?

Se baser sur une mesure de manière absolue n'est pas une fin en soi. L'intérêt des mesures est de donner un référentiel qui va permettre de mesurer non pas l'impact réel mais la progression de l'amélioration.

La mesure est donc réalisée, pour chaque outil, initialement pour définir la base de départ et réitérée régulièrement pour évaluer l'impact du plan d'actions mis en œuvre. Bien évidemment, il faut aussi mesurer l'effort fourni pour réaliser les améliorations par rapport aux gains obtenus.

Les solutions et décisions prises

Les outils de mesure étant identifiés avec le périmètre qui leur est associé, les axes de travail sont maintenant à définir.

La structure du site

Avant toute chose, la manière dont je veux organiser mon site est classique :

Ce site doit être au maximum en html sauf pour certaines pages qui devront rester dynamiques : par exemple la page de contact qui va réaliser des contrôles et envoyer un mail. Comme je ne compte pas embarquer de javascript, il faut donc que je conserve un minimum de pages dynamiques.
Le fait d'être en html va permettre de ne plus regénérer une page sauf en cas de modification ; cela évite donc que le processeur côté serveur travaille inutilement.

L'organisation d'une page ou d'un article

Une page (j'utilise le terme au sens générique comprenant donc les pages et les articles) va être constituée après optimisation de :

Toutefois, à l'écriture de la page, et donc avant toute optimisation, les feuilles de style sont embarquées dans un fichier de style associé à la page décrivant les imports nécessaires (hors feuille de styles générale). C'est durant l'optimisation que les feuilles de styles sont concaténées, minifiées et intégrées dans le code html.

Si je demande à ne pas optimiser la page, je conserve une structure très classique d'une page avec toutes les requêtes correspondant à l'intégralité des appels et je peux ainsi analyser plus facilement les problèmes.

Avant optimisation, la structure d'une page est :

Optimisation des images

J'ai déjà abordé le cas des illustrations légères (comme sur la page d'accueil) concaténées dans une seule image.

Les optimisations pour les autres images sont les suivantes, toutes faites en PHP :

Et bien évidemment, tous les éléments nécessaires comme le titre, le texte alt, la largeur, ... sont positionnés en fonction des informations fournies.
Ainsi, lors de la rédaction d'un article, je ne dois mettre que l'origine de l'image, son titre et son texte alternatif et l'application se charge de réaliser toutes les autres actions d'optimisation.

Il est évident aussi que selon l'usage final de l'image d'origine, il faudra aussi l'optimiser en taille (celle sur laquelle elle doit être visualisée en résolution d'origine) et en compression. Plusieurs solutions existent depuis l'outil de traitement d'image sur le poste de travail (c'est la meilleure solution pour optimiser finement l'image) jusqu'à l'optimisation en ligne avec des sites comme : Imagify ⎋(16) ou CompressPNG ⎋(17) ; de nombreux sites proposent ce type de service ; à vous de trouver celui qui vous convient ; la plupart, de toute manière, arrivent aux mêmes résultats.

Le code initial d'une image est :

qui se transforme en (le lien est optionnel) :

Une autre possibilité d'optimisation est la conversion des images au format webp ; ce format a été créé afin de diminuer, à qualité visuelle équivalente, le poids des images par rapport aux formats jpeg et png. Il faut vraiment faire le test pour identifier si cela est utile ou pas ; les gains que j'obtiens sur mes images ne justifient pas de proposer ce type d'optimisation.

Optimisation du code

Tout le code php côté serveur est sûrement à optimiser mais ce n'est pas encore ma priorité. Le code html généré est, comme vu précédemment, optimisé mais il reste encore du travail à faire pour minifier les fichiers CSS (gain de 25% à 30% actuellement sur un CSS sans fioritures) ou le code HTML lui-même.

L'optimisation du code passe aussi par la limitation des fonctionnalités proposée par chacun des modules ; l'objectif est de répondre à un besoin précis et utile.
Par exemple, les notes de bas de page ont pour objectif de proposer soit un accès à la bibliographie ou aux références, soit pour annoncer un lien qui s'ouvre dans un autre onglet avec information si nécessaire de la langue utilisée, soit encore pour apporter un complément pas obligatoirement intéressant dans le texte lui-même. Et leur présentation est unique dans le thème. Il n'y a pas d'option.

Principe général et conclusion de cet article

Je n'aborde pas la partie gestion du projet de conception du site mais uniquement la partie mesure de performance.

Après avoir choisi les outils qui conviennent le mieux (rien n'interdit d'évoluer dans le temps ; il suffit de repositionner correctement son référentiel), il ne reste plus qu'à établir sa base de départ. Elle peut-être un site à migrer depuis WordPress ou tout simplement le tout premier jet de votre conception de site. C'est la phase d'évaluation.
En fonction des écarts, les outils vont signaler des pistes d'amélioration. Et comme pour tout processus d'amélioration continue, la balance entre les efforts à produire pour corriger par rapport aux gains à réaliser se fait et permet de prendre la décision.

Comme je n'avais ni un objectif de coût ni un objectif de délai, j'ai décidé de pousser au maximum les améliorations. Mon objectif était et reste toujours d'obtenir la meilleure note possible sur chacun des outils.

Tout est loin d'être parfait car il manque un vrai front-end pour l'écriture et l'intégration des modules par exemple. Toutefois, je commence par écrire mon texte dans Composeur de Seamonkey ⎋(18) et je copie-colle le texte dans le fichier idoine issu du modèle ; il ne reste ensuite qu'à ajouter les notes de bas de page par exemple.

Et les résultats obtenus ? me demandez-vous.
Ils sont à la hauteur de mes attentes. Que ce soit Ecoindex, GTMetrix, FastOrSlow, PageSpeed Insights, LightHouse, WebPageTest, ..., le site atteint les notes maximales sans contrainte sur le réseau. Si le réseau est forcé en 2G, cette page se charge en trois secondes.
Mission accomplie pour les performances vues côté internaute !
Est-ce que le travail est terminé ? Non. Il reste encore quelques optimisations à faire côté internaute et d'autres côté serveur. Cela se fera petit à petit.



Notes et renvois

(1) : 57% des visiteurs d’une page mettant plus de 3 secondes à s’afficher assurent qu’ils quittent purement et simplement le site, pour ne plus jamais y revenir pour 80% d’entre eux ; voir l'article Pourquoi optimiser la vitesse de chargement de votre site e-commerce ? ┃ retour au texte, note (1) ䷀
(2) : voir le mode de calcul sur le site ecoindex.fr dans un autre onglet : Qu’est-ce que EcoIndex ? ┃ retour au texte, note (2) ䷀
(3) : voir les explications sur Wikipedia dans un autre onglet : Document Object Model ┃ retour au texte, note (3) ䷀
(4) : lien envoyant dans un autre onglet sur le site ecoindex.fr ┃ retour au texte, note (4) ䷀
(5) : lien envoyant dans un autre onglet sur le dépôt GIT de l'extension ┃ retour au texte, note (5) ䷀
(6) : lien envoyant dans un autre onglet sur le site GTMetrix en anglais ┃ retour au texte, note (6) ䷀
(7) : lien envoyant dans un autre onglet sur le site FastOrSlow en anglais ┃ retour au texte, note (7) ䷀
(8) : lien envoyant dans un autre onglet sur le site de Google PageSpeed Insights ┃ retour au texte, note (8) ䷀
(9) : lien envoyant dans un autre onglet sur le site de Google LightHouse en angais ┃ retour au texte, note (9) ䷀
(10) : lien envoyant dans un autre onglet sur le site de WebPageTest en angais ┃ retour au texte, note (10) ䷀
(11) : découvrez ce qu'est un CDN sur le site de IONOS dans un autre onglet : Qu’est-ce qu’un CDN (Content Delivery Network) ? ┃ retour au texte, note (11) ䷀
(12) : découvrez ce qu'est un waterfall et comment l'utiliser sur le site de Fasterize dans un autre onglet : Waterfall : comment le lire et en tirer des recommandations ? ┃ retour au texte, note (12) ䷀
(13) : lien envoyant dans un autre onglet sur le site WebSite Carbon en anglais ┃ retour au texte, note (13) ䷀
(14) : découvrez la méthode utilisée sur le site de WebSite Carbon dans un autre onglet en anglais : How does it work? ┃ retour au texte, note (14) ䷀
(15) : découvrez la technique des sprites CSS sur le site de alsacréations dans un autre onglet : Les sprites CSS ┃ retour au texte, note (15) ䷀
(16) : lien envoyant dans un autre onglet sur le site Imagify ┃ retour au texte, note (16) ䷀
(17) : lien envoyant dans un autre onglet sur le site CompressPNG ┃ retour au texte, note (17) ䷀
(18) : lien envoyant dans un autre onglet sur le site en anglais de Seamonky ┃ retour au texte, note (18) ䷀