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
:
- 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)
- 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, ...
- 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 :
- L’optimisation des images et le bon usage des résolutions
adaptées à la taille de l'écran
- La minification des feuilles de style, du javascript
- L'utilisation d'un CDN (11)
- La rapidité de réception des données
- ...
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 :
- clic droit sur la page à analyser
- Inspecter pour Chrome ou Examiner l'élément pour Firefox
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 :
- Des pages portant les informations "institutionnelles" :
mentions légales, gestion des cookies, plan du site...
- Des articles associés à la partie communément appelée blog ;
il doit y avoir des articles isolés et des articles regroupés en
dossier (comme cet ensemble d'articles)
- Un thème facilement modifiable constitué a minima d'un haut de page, d'un bas de page et d'un corps de page auxquels viennent s'ajouter la gestion des titres, la page "sommaire" des articles, le menu principal et l'ensemble des styles associés directement à ce thème
- Des modules pour apporter des fonctionnalités supplémentaires : notes de bas de page, présentation de services, ... auxquels sont associés leur propre feuille de style ; cela doit permettre d'ajouter ou enlever un moddule par une seule action
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 :
- Un fichier html portant l'intégralité de l'affichage
- Le fichier de styles du thème
- Toutes les autres feuilles de style, étant très légères
puisqu'elles correspondent à ce que je souhaite, sont
embarquées dans le fichier html dans la section head
- Toutes les autres feuilles de style, étant très légères
puisqu'elles correspondent à ce que je souhaite, sont
embarquées dans le fichier html dans la section head
- Les illustrations ou images si nécessaire
- Si les illustrations sont légères, je les regroupe toutes
en une seule image pour limiter les requêtes et ensuite les
présenter avec du css ; c'est la technique des sprites CSS (15)
à n'utiliser pour des problématiques d'accessibilité que sur
des images ne portant pas de réel message de valeur
- Si les illustrations sont légères, je les regroupe toutes
en une seule image pour limiter les requêtes et ensuite les
présenter avec du css ; c'est la technique des sprites CSS (15)
à n'utiliser pour des problématiques d'accessibilité que sur
des images ne portant pas de réel message de valeur
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 :
- un fichier index.html comprenant un commentaire demandant à
générer le cache et ensuite une simple redirection vers le
fichier index.php ; après optimisation, ce fichier est remplacé
par le contenu optimisé issu des fichiers index.php,
contenu.php, styles.css (y compris tous les styles importés)
- un fichier php constitué de simples includes : header, modules à inclure (notes de bas de page, gestion de dossier, ...), titre de page, contenu, footer plus quelques actions associées aux modules
- un fichier php de contenu comprenant le corps de la page
- un répertoire d'assets avec les images et le fichier css appelant les fichiers css des modules plus un éventuel fichier css local
- un répertoire de configuration fournissant toutes les
informations nécessaires à la génération de la page : titre de
la page et SEO, description, dépendances, image mise en avant,
...
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 :
- Génération de trois tailles pour adapter la taille de l'image
à celle de l'écran (ou tout au moins s'en approcher au mieux) ;
l'originale est conservée et elle est servie si demandée comme
cible du lien associé à l'image insérée dans la page
- Compression de toutes les images JPEG à 60%
- Mise à jour des informations de taille de l'image (width et
height)
- Mise en place de la collection d'images (srcset) à la place de l'image d'origine
- Ajout systématique du lazy loading
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 :
- <img src="assets/images/xxxx.jpg" alt="Alternative" title="Titre" />
qui se transforme en (le lien est optionnel) :
- <a href="assets/images/xxxx.jpg" title="Titre" target="_blank"><img src="assets/images/xxxx.jpg" title="Titre" alt="Alternative" margin="auto" loading="lazy" srcset="assets/images/xxxx_m.jpg 300w, assets/images/xxxx_M.jpg 512w, assets/images/xxxx_P.jpg 1024w" sizes="(max-width: 1024px) 100vw, 1024px"></a>
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) ䷀