Depuis que WPML est devenu commercial, wpml.org gère beaucoup plus de trafic. Il y a deux semaines, notre serveur fonctionnait à 95 % de charge et le temps de réponse dépassait les 10 secondes. Avec W3TC, notre charge est revenue à 5 % et le temps de réponse est d’environ 300 ms.
Si vous ne la connaissez pas, W3TC est une extension d’optimisation des performances de site. Elle inclut le cache de page, mais ce n’est que le début. Au-delà de la mise en cache de base des pages, elle minifie également les fichiers JS et CSS, compresse tout et gère un CDN (réseau de diffusion de contenu). Ensemble, ces fonctions peuvent considérablement accélérer un site, permettant aux sites WordPress complexes de faire face à un trafic important.
Pourquoi est-ce si important pour les sites WordPress ?
Une image vaut mille mots. Voici comment notre site se charge sans aucune mise en cache (généré par Pingdom Tools) :
Si vous trouvez cela effrayant, gardez à l’esprit qu’en réalité, c’était pire. Ce graphique de temps de chargement a été pris alors que notre serveur fonctionnait en réalité à 5 % de charge. Lorsqu’il fonctionnait vraiment sans cache, le serveur surchauffait à 95 % de charge et le temps de traitement était beaucoup plus long. Le premier octet a mis 5 secondes à arriver et non 1/2 seconde comme vous le voyez sur ce graphique.
Pour afficher complètement notre page d’accueil, notre serveur a dû envoyer 77 fichiers. Même ce graphique, fonctionnant à 5 % de charge du serveur, se termine par un délai d’attente dépassé à 30 secondes (voir les lignes rouges).
Est-ce dû à une programmation négligée et à de mauvaises pratiques de conception ? Non.
La puissance de WordPress vient de sa modularité. Vous pouvez choisir n’importe quel thème, avec n’importe quelle combinaison d’extensions. Cela signifie que chacune d’elles est développée indépendamment et fonctionne avec ses propres ressources. La plupart des extensions que vous activez incluent plusieurs fichiers CSS et JavaScript et contribuent aux efforts de traitement de PHP et de MySQL. Vous pourriez l’optimiser manuellement, mais vous perdriez alors toute cette formidable modularité et nous serions de retour à la case départ.
Analysez votre site avec les outils de Pingdom ou une autre mesure du temps de chargement des pages (il existe un module complémentaire Firefox pour cela). Voyez quels fichiers se chargent et dans quel ordre. Vous remarquerez que les fichiers CSS chargent des images et d’autres CSS, et qu’il y a des tas de fichiers JavaScript chargés pour chaque page.
Pour vous mettre en appétit, voici ce que nous avons obtenu en utilisant toutes les options de W3TC :
Les chiffres que vous voyez ici sont corrects. Au total, 28 fichiers sont récupérés pour afficher la page. 5 fichiers proviennent de wpml.org (notre propre serveur) et le reste provient du CDN (réseau de diffusion de contenu). PHP n’a presque rien à faire pour servir cette page, à part vérifier qu’elle est dans le cache et effectuer quelques autres petites vérifications.
La page entière se charge en moins de 2 secondes et entraîne une charge que nous pouvons à peine mesurer sur le serveur. Nous sommes ravis, les visiteurs sont ravis et même Google est ravi.
Étape 1) Cache de page
La première chose et la plus élémentaire que vous voudrez faire est d’activer la mise en cache des pages. Accédez à Performance, activez W3TC et configurez la section Page Caching.
Pour la mise en cache des pages, nous sommes restés sur les paramètres de base. Une chose que nous avons ajoutée a été d’exclure le compte client et les sections de téléchargement du cache de page, afin que W3TC n’interfère pas avec les comptes clients WPML et les téléchargements WPML.
Si vous utilisez un cache d’opcode, W3TC en tirera parti pour accélérer davantage votre site. Nous ne l’utilisons pas, mais cela en vaut la peine si vous exécutez des traitements PHP complexes qui ne sont pas mis en cache.
Étape 2) Minify – regrouper et compresser les CSS et JavaScript
Vous vous souvenez de tous ces fichiers CSS et JS que le thème et les extensions ajoutent ? Il est maintenant temps de corriger la charge qu’ils provoquent.
Minify collecte plusieurs fichiers de ressources, les regroupe dans un seul fichier et le compresse. Le résultat est un fichier plus volumineux au lieu de dizaines de petits fichiers.
Même si la taille totale ne diminue que de 50 %, la charge que cela permet d’économiser est énorme. Au lieu que le navigateur doive émettre plusieurs requêtes HTTP et obtenir de nombreux petits fichiers, il émet une seule requête et les obtient tous ensemble. Ce changement est probablement le facteur qui contribue le plus à l’amélioration de la réactivité de votre site, en particulier pour les nouveaux visiteurs (qui n’ont pas encore vos CSS et JS en cache).
Cliquez sur le bouton Help en haut de la page. W3TC va parcourir l’ensemble de votre site et rechercher les fichiers de ressources. Ensuite, il vous permet de choisir ceux à combiner. Normalement, vous pouvez tout sélectionner, mais vous devez prêter attention à ce que vous faites, car cela peut modifier l’ordre de chargement.
Une fois que vous avez sélectionné les fichiers CSS et JS à minifier, vous devez vous assurer que leur ordre est correct.
Pour les fichiers CSS, faites glisser les fichiers vers le haut et vers le bas dans la liste.
L’ordre que vous voyez dans cette liste doit correspondre à l’ordre dans lequel les fichiers CSS sont chargés sans Minify. Vous pouvez le voir dans le code source de votre page HTML.
Les fichiers JavaScript sont un peu plus délicats. Ici, l’ordre de chargement est encore plus critique car un mauvais ordre entraînera des erreurs JS et des fonctionnalités défectueuses.
W3TC vous permet de choisir quels fichiers JS vont dans la section d’en-tête et lesquels vont dans le corps. Par exemple, les scripts Google Analytics iraient juste avant, tandis que jQuery va dans l’en-tête, car il doit s’exécuter en premier (et en dehors de la liste de minification).
Étape 3) Réseau de diffusion de contenu (CDN)
Pour nous, la cerise sur le gâteau prend la forme d’un CDN merveilleusement fonctionnel.
La configuration et l’exécution d’un CDN dépassent le cadre de cet article, car cela nécessite la création d’un compte sur un service tiers.
Pour nos propres sites, nous utilisons Amazon S3 pour le stockage et CloudFront pour la diffusion. Il existe d’autres excellentes options que vous pouvez explorer et comparer.
Une fois votre compte CDN configuré, W3TC envoie vos fichiers locaux au CDN et remplace les liens de votre serveur par les fichiers du CDN. Ensuite, votre serveur n’envoie que les fichiers HTML et le CDN s’occupe du reste.
Alors que votre serveur est une machine unique, le CDN est en fait un réseau de serveurs. Il enverra les fichiers à partir du serveur le plus proche de chaque visiteur. Les CDN peuvent servir des fichiers statiques beaucoup plus rapidement que n’importe quel serveur unique. En utilisant un CDN, vous améliorez l’expérience de vos visiteurs et réduisez considérablement l’utilisation de la bande passante et du réseau de votre serveur.
Vous devriez suivre l’assistant de configuration du CDN dans W3TC. Il vous aidera à transférer la médiathèque, ainsi que les ressources du thème et des extensions vers le CDN.
Vous aimez optimiser les performances de votre site ? Faites-le-nous savoir en laissant un commentaire ici !
