Introduction
Pour améliorer les performances techniques du site, nous allons utiliser le plugin* autoptimize*, vérifier l’activation du Gzip*, la capacité du serveur* et de la bande passante*. De plus, nous allons tester la mise en place de l’AMP*.
1. Autoptimize
Pour l’optimisation de la partie frontend*, partie du site visible par les visiteurs (images, CSS*, JavaScript*), j’ai installé le plugin* Autoptimize*. Ce plugin* permet de nombreuses optimisations :
a. Concaténation et minification
Dans un premier temps, tous les fichiers HTML*, CSS* et JavaScript* sont concaténés et minifiés. La concaténation* est le fait de regrouper plusieurs fichiers de même type en un seul afin d’avoir un minimum de fichiers à la fin à télécharger et gagner du temps de chargement. La minification* a pour but d’alléger le code en utilisant le moins de caractères grâce à la suppression des sauts de ligne et des commentaires sans altérer le contenu. Un fichier plus léger est plus rapide à charger. Cette procédure doit être réappliquée après chaque mise à jour du site.
b. Cache
Ensuite, ce plugin* m’a permis d’activer la mise en cache* des fichiers par WordPress*. Le principe du cache* est de faire télécharger en local au visiteur le contenu qu’il voit pour la première fois et de le recharger quand il revient le voir. Le cache* fonctionne en deux temps. En premier, chaque contenu mis en cache* obtient une date limite d’expiration. Celle-ci est vérifiée à chaque appel des fichiers. Dans un deuxième temps, si la date limite est dépassée, le serveur* vérifie si la version du client est identique ou différente de la sienne. Si celle-ci est identique, le serveur* ne renvoie pas les fichiers. Si celle-ci est différente, le serveur* renvoie les fichiers et met à jour le cache*. La mise en cache* permet d’éviter de télécharger à chaque fois tous les fichiers depuis le serveur* et donc de gagner du temps lors de connexions ultérieurs. Cette procédure aussi doit être réappliquée après chaque mise à jour du site.
c. Lazy-loading
Les images ont été mises en lazy-loading*, un état qui permet de retarder l’affichage des images non visibles pour optimiser le chargement des ressources audessus la ligne de flottaison*. La ligne de flottaison* est une ligne virtuelle qui délimite la partie inférieure d’une page web vu par l’internaute sans scroller. Selon une étude[1], 80% des internautes ne regardent pas les informations en dessous de la ligne de flottaison*. Il est donc important que les informations essentielles se situent au-dessus de cette ligne et se chargent le plus rapidement possible.
d. Polices
Enfin, les polices Google sont combinées et chargées de manière asynchrone. Dans les configurations habituelles, les polices sont chargées en même temps que tous les éléments de la page de manière synchrone. Cela créé une requête et un délai de réponse variable. De ce fait, quand un navigateur* a besoin d’afficher une police personnalisée, si celle-ci n’est pas chargée dans les 3 secondes, le navigateur* n’affiche aucun contenu puis se rabat sur une police alternative sur l’appareil de l’utilisateur. Donc pendant les trois premières secondes, le contenu n’est pas accessible. Mais charger les polices de manières différées, asynchrones permet de toujours afficher le contenu au visiteur car le navigateur* va d’abord afficher une police alternative puis la police personnalisée utilisée.
Pour l’optimisation de la partie backend*, serveur*, j’ai vérifié trois choses :
L’activation de Gzip*, la configuration du serveur* et la capacité du serveur* par rapport à nos besoins.
2. Gzip
Gzip* est un outil de compression et décompression de fichiers gratuit et open source. Cette compression s’effectue côté serveur* et la décompression s’effectue côté navigateur*. Gzip* utilise le principe de factorisation* en mathématique. C’est-à-dire que l’algorithme* cherche toutes les parties de fichiers identiques, note leurs emplacements et ne garde qu’une occurrence de ces parties. Puis il enregistre dans un autre fichier les noms des fichiers originaux et leurs permissions. Cela permet d’obtenir un taux de compression qui se situe entre 63% et 88%. Le service Gzip* est bien activé sur notre serveur*.
3. Capacité serveur
Le site en production de l’entreprise est sur un serveur* dédié avec un processeur Intel Xeon E5620 avec 32 Go de mémoire vive. La mémoire vive (RAM*) est la mémoire informatique dans laquelle peuvent être stockées provisoirement les informations traitées par le serveur*. Pour comparer avec notre cerveau, c’est notre mémoire à court terme. L’espace disque disponible est de 136 Go pour l’ensemble des sites du groupe et de leurs bases de données correspondantes. En sachant que sur le site de L’entreprise, nous avons presque 40 000 pages avec un poids moyen de 2 Mo, cela demande déjà un espace de 80 Go. L’espace disque semble un peu faible par rapport à notre utilisation.
Ce serveur* sert de support à notre multisite* WordPress* comprenant 24 sites actifs.
Au vu de l’utilisation du serveur*, sa configuration est bien assez puissante pour l’utilisation que nous en faisons d’après mes collègues en réseau malgré un espace de stockage un peu juste.
4. Bande passante
La bande passante* allouée pour le serveur* est de 8 Mbps. En utilisant l’outil mis à disposition sur le site binghost.com permettant d’estimer la bande passante* nécessaire à chacun des 24 sites web actifs sur notre serveur* et grâce aux données récoltées par Google Analytics*, nous obtenons un total nécessaire estimé de 18,6 Mbps. Cette estimation comprend une sécurité pour un pic de trafic. Donc le serveur* a besoin de plus de deux fois la capacité de la bande passante* actuelle.
En effet, il n’existe qu’une seule bande passante* pour les 24 sites actifs du serveur*. Donc si un des sites a un pic de trafic après une campagne de publicité et prend presque toute la bande passante*, les autres sites seront obligés de se répartir le débit restant de la bande passante*. Or cela va créer des temps d’attentes importants, voire des délais dépassés qui vont nuire à l’expérience utilisateur et faire fuir des potentiels clients.
Cela crée un plafond de verre qui est encore plus compliqué à traiter dans le cas d’un multisite* WordPress* sur un seul serveur*. Et malheureusement, je n’ai pas la possibilité d’agir sur la capacité de la bande passante*.
5. Résultats
En octobre dernier, le temps de chargement sur les tablettes et les ordinateurs était de 9,55 secondes. Après un premier travail d’optimisation, en janvier il est descendu à 7,41 secondes. Donc le temps de chargement moyen a diminué de 22%. Dans un même temps, le score du site de l’entreprise avec l’outil PageSpeed Insights*, sur ordinateur, est passé de 28 à 41 sur 100, soit une augmentation de 46% entre octobre 2019 et janvier 2020.
Les deux optimisations qui ont été les plus efficaces sont les mises en place du cache* et du lazy-loading* sur les images du site. Cependant, la bande passante* crée un plafond de verre en termes d’optimisation.
Sur téléphone et mobile, les résultats ont été très décevants. En octobre dernier, le temps de chargement sur mobile était de 9,23 secondes. En janvier, il est descendu à 8,21 secondes, soit une diminution de 11%, deux fois moins que sur tablettes et ordinateurs. Le score sur l’outil PageSpeed Insights* est passé de 7 à 17 sur 100, soit une augmentation très faible et insuffisante.
De ce fait, en parallèle des tests effectués sur mes hypothèses sur le moyen et long terme, j’ai cherché à optimiser la version mobile du site.
6. Mise en place de l’AMP sur mobile
Malgré les améliorations précédentes, le temps de chargement mobile reste décevant. Par exemple, sur le site, le temps de chargement après l’optimisation était de 8,21 secondes en janvier. D’après une étude Google, le temps de chargement doit être inférieur à 3 secondes sinon le risque d’augmenter le taux de rebond* du site est proportionnel à son temps de chargement. De plus, la taille de la page ne devrait pas excéder 500 Ko. La page d’accueil de L’entreprise pèse 3 394 Ko, soit 6,7 fois la taille maximum recommandée.
Pour pallier ce problème, nous avons choisi d’essayer l’AMP* sur le site de .fr dans un premier temps. L’AMP* : Accelerated Mobile Page, est un format de publication en ligne proposé par Google en open source qui permet d’obtenir des pages accélérées pour les terminaux mobiles. Pour cela, l’AMP* utilise une version allégée de l’HTML* et du CSS*, les images ne sont chargées que lorsque l’utilisateur arrive à leurs emplacements, la bibliothèque JavaScript* est très limitée et les formulaires ne sont pas pris en charge. Dès que Google reconnait les pages comme des pages AMP*, celles-ci sont stockées en cache* par Google lui-même et distribuées via un CDN*. De plus, les pages AMP* sont mises en avant par Google dans les pages de résultats de recherche.
L’entreprise a un site de prospection et ses formulaires sont nombreux et essentiels à son objectif. Or, l’AMP* ne prend pas en charge les formulaires. Cependant, nous avons un site qui génère énormément de visiteurs pour l’entreprise : son blog qui est parfaitement adapté pour le format AMP*. De plus, le site a été créé afin de générer du trafic vers le site de l’entreprise. Ainsi, augmenter la visibilité du blog permet d’augmenter le nombre de visiteurs sur le site de l’entreprise.
Pour transformer les pages en format AMP*, j’ai installé le plugin* AMP*sur le multisite* et l’ai activé seulement sur le site avant de le configurer.
7. Résultats
Les résultats sont très bons. Sur le PageSpeed Insights*, le score du site sur mobile est passée de 16 à 66 immédiatement soit une augmentation de 312%. Pour rappel, les données de champ* sont recueillies au cours des 30 derniers jours. A chaque changement, il est nécessaire d’attendre 30 jours afin d’observer un résultat final pertinent.
| Avant | Après | |
| Score | 16 | 66 |
| First Contentful Paint | 4,5 s | 3,2 s |
| Indice de vitesse | 16,8 s | 3,9 s |
| Largest Contentful Paint | 5,6 s | 3,8 s |
| Délai avant interactivité | 21,6 s | 4,7 s |
| Total Blocking Time | 2 860 ms | 110 ms |
Figure 14 : Tableau avant et après optimisation mobile avec l’AMP
Le temps de chargement du site était de 6,09 secondes sur mobile avant le passage à l’AMP*. Après le passage à l’AMP*, il est de 2,27 secondes, soit une diminution de son temps de chargement de 62%.
Pour conclure, l’AMP* est très performante pour optimiser les sites mobiles et nous pouvons l’envisager pour le site de l’entreprise à condition de solutionner le problème d’accessibilité des formulaires.
Conclusion
Les optimisations effectuées donnent des résultats positifs sur le court-terme mais demandent des efforts quotidiens. Nous avons besoin de solutions optimales sur le long terme.
