Vous venez de créer votre site WordPress, vous en êtes fiers, vous avez meilleur thème du monde, et vous avez installé tous les plug-ins-de-la-mort-qui-tue. Seulement, vous constatez que vos temps de chargement ne sont pas au top. Dans ce tutoriel, on va regarder quels outils sont disponibles pour mesurer efficacement ce temps de chargement, le comprendre, et voir ce qu’on a comme levier à notre disposition pour le réduire au maximum.
Comment une page web est envoyée au navigateur
La résolution DNS
Prenons un exemple tout bête : Madame Michu a besoin de commander un manteau pour son chien. Elle se rend sur son navigateur préféré, rentre directement l’adresse de son site, et appuie sur « entrée ». Dans un premier temps, son navigateur, connecté à Internet, va interroger un serveur dit « DNS », dont le travail est de traduire un nom de domaine en adresse IP correspondante.
L’adresse IP, c’est simplement l’adresse de la machine qui héberge le site consulté sur le réseau Internet. Une fois l’adresse IP résolu, le serveur DNS oriente la connexion vers le serveur qui héberge le site demandé.
Virtual hosting et serveur mutualisé
Un serveur, c’est un ordinateur. Et bien souvent, c’est une machine sur laquelle on peut héberger plusieurs sites Internet. Afin d’orienter les requêtes vers les bons sites, qui sont tout simplement des dossiers (comme sur votre ordinateur de bureau), le serveur utilise une technologie appelée « virtual host ». En gros, il agit comme un aiguilleur et oriente le visiteur vers la bonne « boîte » sur la machine.
Ce temps d’orientation du visiteur peut être plus ou moins long, en fonction du nombre de sites sur le serveur, et de sa puissance (nombre de processeurs, fréquence des cœurs, RAM disponible, type de disque dur utilisé etc.).
Si on ne trouve qu’un seul site sur un serveur, on parlera de serveur dédié. Si en revanche on peut trouver de nombreux sites, on parlera d’un serveur mutualisé. Cette notion est très importante, car un serveur mutualisé a toujours le même nombre de cœurs et la même quantité de RAM, le même nombre de disques durs etc, tout ça pour tout le monde. Les ressources sont donc partagées.
La négociation SSL
Avant de connecter l’utilisateur au conteneur demandé, le serveur vérifie le protocole utilisé. En général, pour du Web, on est sur un protocole appelé « http » (HyperText Transfer Protocol).
Mais si la page est sécurisée, on est sur du « https » (HyperText Transfer Protocol Secured). La couche de sécurité apportée par le HTTPS nécessite l’utilisation d’un fichier qu’on appelle « un certificat SSL ».
Afin de chiffrer la connexion, le serveur doit d’abord s’assurer que le certificat SSL est valide, et va travailler en concomitance avec le navigateur de l’utilisateur : plusieurs échanges de données sont effectués entre le client, le serveur, l’autorité racine du certificat etc. C’est ce qu’on appelle « la négociation SSL ». Et tout ça évidemment, ça peut prendre du temps. Si la négociation SSL échoue, vous aurez une jolie alerte bien anxiogène dans le navigateur
Si la négociation SSL se passe bien, on peut continuer, et la connexion au site Internet est effective.
La compilation d’une page PHP
Dans notre cas, le site consulté par Mme Michu tourne sur WordPress. WordPress, comme de nombreux CMS, utilise des fichiers PHP (« PreHypertext Processor » ou « Hypertext Preporcessor »), ainsi qu’une base de données SQL (et tout un tas d’autres trucs : des fichiers CSS, des fichiers JavaScript etc).
Pour créer la page demandée par Madame Michu, le serveur doit d’abord la « compiler » c’est-à-dire qu’il doit la créer. Le PHP et la technologie SQL, ça fonctionne un peu comme un texte à trou : le serveur va « lire le texte » en l’adaptant en fonction de ce qu’il trouvera dans la base de données SQL consultée. Le résultat dépend donc principalement des réglages rentrés par l’utilisateur dans son système de gestion de contenu.
Et compiler une page PHP, ça prend du temps. Surtout sur un serveur mutualisé, où les ressources sont partagées.
Il faut aussi prendre en compte la « charge » sur le serveur : si tout le monde demande la même page en même temps, ou bien un grand nombre de pages sur un laps de temps réduit, le processeur va tirer la langue, un peu comme votre ordinateur quand vous ouvrez plein de fichiers en même temps, ou que vous regardez une vidéo, que vous lancez de la musique, qu’il y a un jeu qui tourne en tache de fond etc. etc.
Tandis que sur un serveur dédié, on résout déjà la problématique du partage des ressources : le propriétaire du site dispose de tout !
La composition d’une page HTML
Les pages qui sont envoyées au navigateur de Madame Michu sont écrites dans un langage appelé HTML. Mais, pour que le site soit joli, on va utiliser aussi des fichiers appelés « CSS ». Ces fichiers sont stockés à part, dans un autre répertoire du site.
Et pour que certaines fonctions du site marchent, on va également utiliser une autre technologie appelée JavaScript. Là aussi, les fichiers JavaScript sont stockés à part.
De temps en temps, on trouvera quand même du langage CSS et du langage JavaScript directement dans le code source HTML de la page (c’est pas top-top, mais c’est pas la mort non plus).
Évidemment, on trouvera aussi sur la page des images : ça permettra d’avoir quelque chose de plus joli. L’ensemble de ces fichiers constitue une page Web.
Servir les éléments constitutifs de la page au navigateur
Une fois que la page est créée, c’est-à-dire une fois que le code source est compilé, la page est envoyée au navigateur de Madame Michu, grâce à une autre couche applicative qu’on appelle « un serveur de page ».
On en trouve plusieurs sur le marché, mais les deux plus courant, ce sont tout de même Apache et Nginx. Ces deux logiciels tournent sur les serveurs à noyau Linux. Pour les serveurs Microsoft, on trouvera la plupart du temps un logiciel qui s’appelle IIS.
Le serveur de page à une tache très simple : servir les pages (sans déc). C’est lui qui envoie la page HTML en elle-même, et tous les fichiers qui la constituent : les fichiers CSS, les fichiers JavaScript, les images, les fichiers de typographie etc.
Apache ou Nginx fonctionnent un peu comme des mitraillettes « multicanaux ». Ils peuvent tirer plusieurs fichiers en même temps, en mode « machine-gun » s’il y a beaucoup de fichiers à envoyer. Le nombre de coups à la minute et le nombre de coups simultanés dépendent bien entendu de la puissance du serveur, de sa configuration etc. On va voir par la suite que ça une importance extrême dans les temps de chargement.
Comment réduire les temps de chargement ?
Pour réduire les temps de chargement d’une page, on va pouvoir utiliser plusieurs leviers, certains étant très facile à mettre en place, d’autres étant un peu plus compliqués.
Le serveur
Si votre hébergement est un serveur mutualisé qui vous coûte un euro par mois, que ce dernier contient 150 sites Internet, qu’il un tout petit processeur, peu de RAM, et qu’il utilise un disque dur qui tourne à 5000 tr/m, votre site sera lent. C’est un peu comme une voiture : si vous avez un tout petit moteur, même si la voiture n’est pas chargée, ça ne roulera pas vite.
Tandis que si vous avez un serveur dédié, avec huit cœurs, 32 giga de RAM, deux disque dur SSD, et que votre machine n’héberge qu’un seul site, ça ira déjà nettement plus vite !
Si vous montez un petit site, qui ne fera que peu de trafic, vous pouvez prendre un hébergement mutualisé. Par contre, si vous montez une grosse boutique e-commerce qui doit réaliser plusieurs milliers de visites par jour, il faudra prendre un serveur plus puissant, donc un serveur dédié a priori.
Sachant que, quel que soit le cas, il sera possible d’apporter des améliorations pour booster tout ça !
La charge
Quel que soit le type de serveur, plus on va le solliciter, plus il aura de mal à travailler. Il faut donc veiller à avoir une machine suffisamment puissante pour la charge de travail qu’on va lui imposer. Celle-ci dépendant majoritairement du nombre de connexions, de la taille des pages etc.
Mais ici, il faut nuancer : on a en effet plusieurs entités qui travaillent sur le serveur : la compilation PHP, la base de données SQL, le serveur de page etc.
- Si votre thème WordPress est une véritable usine à gaz, qui nécessite plusieurs milliers de calculs à la seconde, ça va piquer.
- Si les fichiers que vous envoyez sont extrêmement lourds et extrêmement nombreux, ça va piquer.
- Et si pour créer la page le serveur doit vérifier des millions de tables par seconde, ça va piquer.
Il est impossible de connaître la charge côté serveur à l’avance. La seule façon de savoir ce que ça va donner, c’est d’installer le CMS ou votre site, le thème (si vous en utilisez-un) et de faire des tests.
Avec l’habitude, vous saurez si la configuration de votre machine sera suffisante en fonction du projet, du trafic attendu etc.
Grosso modo, plus le processeur sera puissant, plus vous aurez de RAM, plus disque dur sera performant, et plus vous pourrez atteindre des performances dignes de ce nom. Pour tester la capacité d’un serveur a encaisser sur les connexions, vous pouvez utiliser ces outils de benchmark :
Le nombre de fichiers sur une page
Vous avez une super page d’accueil, avec un beau background vidéo, 154 images sur la page, vous envoyez 35 CSS et 54 fichiers JavaScript au navigateur distant, cinq typographies différentes, vous avez moult Google Maps et trois vidéos YouTube qui doivent se lancer au scroll de l’utilisateur : même avec un monstre, ça va ramer.
Une page Web doit être la plus légère possible. Vous aurez beau avoir un serveur ultra-puissant, il faut prendre compte des variables sur lesquels vous n’avez pas la main : la connexion de l’internaute, la puissance de sa machine, ses capacités à traiter des éléments graphiques etc.
Comme on est sur un marché où on trouve de tout, il faut donc penser aux plus démunis, et user de bon sens pour créer des pages les plus légère possible, utilisant le moins de fichiers possibles.
Par exemple, pour les images de fond, on utilisera des Sprite CSS dès qu’on pourra le faire. Ça permet de n’envoyer qu’une seule image, qui contiendra toutes les images du Sprite, plutôt qu’envoyer plein de petites images (on n’en reparlera dans un autre tutoriel).
Pour les CSS et les Javascripts, les plugins qu’on utilisera dans les tutos qui vont suivre vous permettront de mettre en place la « concaténation-minification-compression » : plutôt que d’envoyer 50 fichiers à la queue-leu-leu, on les joindra dans un seul et unique fichier (un pour les CSS, un pour les Javascripts), ça fera beaucoup moins d’appels http au serveur (donc temps de chargement beaucoup plus courts).
La conception du site en lui-même
J’ai eu un exemple cette semaine d’un site qui est un peu comme dans mon exemple : vidéo dans le fond, plein de plug-in, très lourd, pleins de CSS, pleins JavaScript etc. Rien que la vidéo, ça pesait 20 méga sur la page ! Si en plus on rajoute un code source ultra lourd, et de très nombreuses images, y a rien à faire : ça ramera quoi qu’il arrive.
La conception du site a une importance phénoménale dans la réduction des temps de chargement.
Ça demande un peu d’expérience, et il faut très souvent regarder le code source pour estimer l’impact d’un plug-in sur les temps de chargement (nombre et taille des fichiers CSS, JavaScript etc.).
Les images
De la même façon, si vous envoyez sur votre serveur des images qui font 5400 pixels sur 3000 pixels, et qu’elles sont redimensionnées sur votre page en 540 x 300, vous alourdissez inutilement votre contenu pour rien.
Donc, autant que possible, on envoie les images aux bonnes dimensions, et en version compressée si possible. On privilégiera le JPG à d’autres formats plus lourds, comme le PNG. On verra dans un prochain article quand utiliser les différents formats d’images qui s’offrent à nous. Quelques pistes tout de même pour avoir des images comme il faut :
- Photoshop, pour tailler des images sur mesure, et les compresser
- Smush it, un outil pour compresser vos images déjà en place sur le site (attention, le processeur de votre serveur va prendre cher)
- imageoptimizer.net, un outil dispo en ligne pour réduire la taille des images et les compresser
Le mieux, c’est évidemment de travailler directement avec des images qui sont à la bonne taille.
Un site rapide, c’est avant tout de bonnes pratiques !
Vous avez compris : pour avoir un site rapide, il faut simplement user de bon sens, et y aller mollo sur les contenus poids-lourds (les images, la vidéo etc). Dans les prochains tutos, on mettra tout ça en action, avec guide vidéo et captures d’écran.
L’important ici, c’était que vous compreniez d’où vient le poids d’une page…
Comment mesurer le temps de chargement de son site ?
Pour mesurer vos temps de chargement, vous pouvez utiliser de nombreux outils disponibles en lignes.
Pingdom Tools
Pingdom tools vous donnera de nombreux indicateurs pour optimiser vos temps de chargement, et vous pourrez le faire tourner depuis plusieurs serveurs un peu partout dans le monde (Etats-Unis, Australie, Europe etc).
Comme de nombreux outils de ce type, vous pourrez visualiser la « Waterfall » de vos fichiers, histoire de voir dans quel ordre ils sont chargés, s’il n’y a pas un « bouchon » quelque part, trier les fichiers par type, par poids, avoir les codes de réponse du serveur etc.
GT Metrix
GT Metrix vous permettra de réaliser le même type de test que pingdom, mais il vous donnera en plus deux notes :
- Google Speed, l’indicateur de vitesse de Google
- Yslow, l’indicateur de Yahoo
GT Metrix donne également de nombreux conseils pour résoudre tous les points bloquants rencontrés, sous forme de fiches techniques très pratiques pour se former à l’optimisation des temps de chargement.
webpagetest.org
Un grand classique du web, un peu plus vieux que les outils cités ci-dessus. Là aussi, vous aurez une Waterfall, un diagramme circulaire pour voir comment est réparti le poids de votre page (images, CSS, JS etc). Cet outil donne également le TTFB (voir ci-dessous) de votre page. Dispo par ici !
ByteCheck
ByteCheck outil vous indique le TTFB de votre page : c’est le temps que mets votre serveur à envoyer le tout premier byte de donnée. Ultra-important pour le référencement. Visez un TTFB inférieur à 500 ms à tout prix. Si vous êtes au-dessus, c’est qu’il y a un souci (à priori, votre serveur qui rame). Attention, vous ne pourrez pas atteindre un tel temps si vos pages ne sont pas statiques (html, pages en cache etc) !
Le meilleur plugin, c’est quoi ?
Maintenant qu’on a un peu fait le tour de la chose, la question qui tue : quel est le meilleur plugin de cache pour WordPress ? W3 Total Cache ? Autoptimize ? WP Super Cache ? WP Rocket ?
Réponse : ça dépend ! Si votre thème est léger, que votre site est sobre, et que vous n’avez pas beaucoup de fichiers de CSS ou de JS à concaténer, pourquoi s’embêter à configurer un plugin qui va gérer la concaténation, la minification etc ? Un simple plugin pour rendre vos pages statiques fera parfois l’affaire !
Par contre, si vous avez une véritable usine à gaz, pleins de plugins, des vidéos youtube etc, là, il faudra passer sur un système plus complexe, pour gérer efficacement le chargement des images (avec le lazy-load), les appels DNS (DNS Prefetch), les CSS / JS (avec la compression-concaténation-minification), et mettre tout ça proprement dans un cache.
Dans les prochains tutos, nous allons donc examiner en détail :
- Simple Cache
- W3 Total Cache
- WP Rocket
- WP Supercache + Autoptimize
- WP Fastest Cache
Et tout ça avec le comparatif pour « élire » le meilleur plugin de cache sur WP ! Mais attention, je le répète, le meilleur plugin de cache, c’est celui qui fait bien son taf, sans trop vous prendre la tête : si votre site est bien conçu et que votre hébergement est correct, vous n’aurez pas besoin d’une usine à gaz pour avoir des performances au top !
Enfin, on se fera le tuto ultime pour gérer un cache efficace, et virer tous les trucs qui pourrissent un thème wordpress (inline CSS dans le head de la page notamment). Stay Tuned !
ps : pour ceux qui veulent être en relation avec un obsédé de la vitesse sur WordPress, je vous conseille l’excellent site d’Alexei Kutsko, WP-SpeedGuru !
