Makina Blog
Mon site est trop lent : que faire ?
Résolution des problèmes de performance les plus courants.
Quand nous réalisons un audit de performance, une des premières choses à faire est d'identifier où se situe le problème, ou au moins le principal problème.
Source des problèmes de performance
En effet, Il est courant (et c'est bien normal) que les gens qui ne sont pas formés à la technique ne puisse diagnostiquer leur problème (c'est même la principale raison d'effectuer un audit ;-)). Notamment, il est fréquent qu'on nous appelle en nous disant "mon site Drupal est très lent !", alors que la cause n'est pas "Drupal" en tant que tel, mais la couche de front-end (c'est le cas dans plus de 2/3 des cas).
Différents types de site
Pour simplifier, nous allons considérer principalement 2 types de sites :
- les sites "vitrine", où l'ensemble des visiteurs sont anonymes et voient la même chose ;
- les portails plus "métier" (e-commerce, intranet, extranet, …), où la composante authentifiée est importante et où les pages sont différentes selon les profils des utilisateurs.
Dans le premier cas, le front-end est le plus souvent en cause, dans le deuxième cas, on trouve au contraire le back-end (voire même les deux).
Le test du pauvre
Comment diagnostiquer rapidement si c'est le back ou le front qui est la source du problème ? Un simple outil peut rendre bien des services : curl. Et notamment sa très pratique option "-I" (i majuscule) qui renvoie uniquement les en-têtes de la réponse. Chronométrer le temps de réponse de curl est à peu près équivalent à obtenir le fameux "Time-To-First-Byte" de votre site, et donc, environ le temps de réponse de votre back-end (attention, ici, on veillera à faire la requête directement sur l'IP du site si possible, pour ne pas tenir compte du temps de réponse du DNS, assez lent).
Donc, si time curl -I http://192.0.2.42 vous donne moins de 400ms (ou moins de 500ms en incluant la réponse DNS), vous pouvez considérer que le back-end n'est pas responsable. Bien sûr, il est toujours possible d'améliorer les choses, mais ce n'est pas forcément pertinent (en terme d'efforts à fournir par rapport au gain estimé).
Améliorer les performances du back-end
Nous retrouvons ici nos deux types de site. Les sites "métier", de par leur nature, nécessitent probablement une analyse plus poussée, du moins, il n'y a pas de règle générale… Ici, rien ne vous sauvera de l'audit ;-) !
Dans le cas du site vitrine, plusieurs choses sont possibles, mais en priorité : ajouter du cache (plein) !
Par exemple, si nous reprenons Drupal, dans le menu d'administration "Configuration" / "Performance" se trouvent des cases à cocher pour activer le cache pour les utilisateurs anonymes (dans Drupal 8, c'est transformé en module et activé par défaut), ainsi que le cache des blocs. Certains modules comme Views ou Panels comportent également des caches plus ciblés, qu'il faut activer.
Enfin, il est possible d'ajouter devant votre site un reverse proxy cache comme Varnish, parfait pour l'absorption de la charge d'un back-end et du coup son accélération.
Et pour vérifier si le cache est activé sur un site, on retrouve notre "curl -I" qui peut retourner des en-têtes :
X-Drupal-Cache: HIT
X-Cache: HIT
Améliorer les performance du front-end
Énormément d'optimisations sont possibles sur la couche de front-end, mais certaines ont plus d'impact que d'autres.
Optimiser les images
En moyenne, les images constituent environ 65% du poids du site. Les optimiser même un petit peu diminuera donc sensiblement le poids de votre page, et donc le temps de téléchargement pour l'utilisateur. Pour les optimiser, vous pouvez par exemple utiliser Trimage.
Bibliothèque de tierces parties
L'utilisation de scripts externes (Google (Analytics), Facebook (Share, Like), …) cause de nombreux problèmes de performance, en plus de vous ôter le contrôle sur les performances de votre site (si la bibliothèque met du temps à répondre, votre site rame, et vous ne pouvez rien y faire). Réfléchissez bien avant de les utiliser (notamment les boutons de partage sur les réseaux sociaux qui peuvent aisément être remplacés par des liens mis en forme).
Compression
La compression des contenus de votre sites (par l'utilisation de mod_deflate sur Apache, ou en activtant gzip sur Nginx) diminue le temps de transfert entre votre serveur et le navigateur du client, et donc accélère la récupération et l'affichage des éléments sur le navigateur.
Expiration
Enfin, pour diminuer les temps de transferts entre votre serveur et le client, le mieux est encore de les supprimer complètement ! En positionnant des dates d'expiration de vos fichiers statiques assez loin (1 semaine, ou même 1 mois, par exemple), le navigateur ne les téléchargera pas lors des visites futures de votre site, économisant ainsi de précieuses millisecondes.
L'importance de la perception
Mais finalement, peu importe le temps réel de transfert de l'ensemble des éléments du site, et la durée complète de la récupération de ces éléments, ce qui compte, c'est la perception qu'ont les utilisateurs du temps de réponse de votre site. Il existe quelques techniques pour améliorer cela également.
Côté serveur
Si certaines parties de votre page prennent beaucoup plus de temps que d'autres à être générées (parce qu'une partie de la page est en cache et l'autre dépend du retour d'un web-service, par exemple), il est possible de générer la page petit à petit, en utilisant la technique BigPipe (implémentée par un module en Drupal 8).
Côté client
Dans la mesure où le JavaScript ne constitue qu'une surcouche ergonomique sur votre site (car vous appliquez cette bonne pratique, n'est-ce pas ?), il n'y a pas de raison de le charger le plus tôt possible sur votre page, d'autant que le chargement de Javascript "bloque" le rendu de la page par le navigateur. Si vous le pouvez, placez donc vos scripts le plus loin possible dans le code de votre page.
D'autre part, il est également possible d'utiliser les attributs "aysnc" "defer" sur vos scripts pour indiquer au navigateur de les charger / exécuter plus tard. De cette façon, votre page commencera à s'afficher avant que l'ensemble des éléments de la page ne soient chargés. Et la perception de l'utilisateur n'en sera que meilleure.
À vous de jouer
En appliquant simplement des bonnes pratiques, il est parfois possible d'accélérer sensiblement votre site. Et si vous rencontrez toujours des problèmes… et bien contactez-nous, nous serons ravis d'intervenir !
Formations associées
Actualités en lien
Comment compresser son code applicatif de manière efficace avec Nginx et Brotli ?
Dans cet article, nous allons mettre en place un algorithme de compression des données textuelles plus efficace, que celui utilisé habituellement, pour réduire le poids d'une page web.
SSO Keycloak : Ajouter un contrôle d'accès au niveau des flux d'authentification
Découvrez ici comment ajouter un contrôle d'accès grâce au SSO Keycloak
Accéder à sa base de données PostgreSQL depuis QGis ou pgAdmin de manière sécurisée
Comment interconnecter ses outils de travail sans mettre en péril la sécurité du système informatique ? L’objectif de cet article est de présenter une manière sécurisée de connecter QGis ou pgAdmin à une base de données PostgreSQL, afin d’atteindre le meilleur compromis entre praticité et sécurité.