Pourquoi votre site WordPress est si lent et un guide pratique pour accélérer les choses

Je voulais commencer cet article en vous faisant savoir qu'il ne s'agit PAS simplement d'un autre article générique "Comment accélérer WordPress".

Je ne vais pas régurgiter tout ce que l'on peut déjà trouver sur le web. Je ne vais pas vous dire qu'il faut installer un plugin de mise en cache, activer la compression, minifier vos css/js etc….

Après tout, vous devriez déjà savoir comment faire ces choses. Et si vous ne le faites pas, vous pouvez trouver ces informations génériques sur des centaines d'autres blogs.

Au lieu de cela, cet article contient tout ce qui est personnalisé/semi-personnalisé que j'ai implémenté au cours du mois dernier pour accélérer mon propre blog WordPress et empêcher les accès malveillants de faire tomber mon serveur.

Et la raison pour laquelle c'est "peu connu" est que les techniques que je vais décrire seront très spécifiques à votre propre blog en fonction des modèles de trafic que vous voyez.

Remarque : si vous avez un blog lent et que vous ne voulez vraiment pas gérer les aspects techniques de l'accélération d'un site Web, vous devriez probablement vous inscrire à un service comme WP Engine .

Ces gars-là se spécialisent dans l'hébergement WordPress et s'assureront que votre blog fonctionne aussi vite que possible. Mais naturellement, cela a un prix. Vous devriez les vérifier si ce post vous dépasse :)

Quoi qu'il en soit, avant de pouvoir vous expliquer comment et pourquoi j'ai fait ce que j'ai fait sur mon blog, vous devez comprendre quelques concepts fondamentaux sur WordPress et la mise en cache que je décrirai ci-dessous.

Quelques faits intéressants sur WordPress

Disons que vous avez déjà suivi toutes les directives sur la façon d'accélérer WordPress. Votre blog se sent zippy. Webpagetest.org vous dit que votre blog est rapide comme l'enfer. Tout va bien non ? Pas nécessairement .

J'avais l'habitude de ressentir exactement la même chose à propos de mon blog. Après tout, je suis la plupart des protocoles d'accélération standard. J'exécute très peu de plugins et mon blog semble assez rapide dans des conditions d'utilisation normales du point de vue d'un lecteur humain (les réseaux publicitaires ralentissent mon blog, donc je charge les annonces en dernier).

Mais ensuite, j'ai commencé à analyser mes graphiques d'utilisation du processeur et j'ai souvent remarqué des périodes de charge élevée du serveur malgré des niveaux de trafic faibles à modérés. Parfois, mon serveur devenait même inutilisable ou ne répondait plus pendant de longues périodes.

Notez que la seule raison pour laquelle j'ai commencé à prêter attention à ces statistiques était qu'il y a quelque temps, j'exécutais ma boutique en ligne sur le même serveur que mon blog. Et périodiquement, les clients se plaignaient que le magasin était extrêmement lent. Quand j'ai finalement fait quelques recherches, j'ai découvert que mon blog WordPress optimisé et entièrement mis en cache mettait mon serveur à genoux !

Morale de l'histoire? Ce n'est pas parce qu'un test de vitesse vous dit que votre blog est rapide que tout va bien.

Voici quelques faits amusants sur WordPress et les plugins de mise en cache comme WP Super Cache et W3 Total Cache que vous devez connaître.

• Les réponses WordPress 404 sont lentes . Chaque fois que votre blog reçoit un accès à une page qui n'existe pas, votre pauvre serveur doit charger WordPress, exécuter un tas de code php, faire un tas de requêtes MySQL, puis cracher votre page WordPress 404 personnalisée. C'est une tâche très gourmande en ressources et la mise en cache ne va pas aider.
• Votre plugin de mise en cache ne fonctionne pas très bien lorsqu'il y a des paramètres GET dans l'URL. Par exemple, j'avais l'habitude de remarquer que mon blog ralentissait à chaque fois que j'envoyais une explosion à ma liste de diffusion. En théorie, avec la mise en cache de fichiers statiques, mon serveur devrait être presque invincible.

  Mais comme Aweber insère des paramètres de suivi dans l'URL, aucun de mes fichiers n'est super mis en cache. En conséquence, WordPress doit générer un tout nouveau fichier de cache (même s'il existe déjà), le compresser et l'envoyer à chaque fois. Le pire est que ces fichiers en cache ne sont utilisés qu'une seule fois, ce qui en fait un gaspillage de ressources du serveur

• Les accès malveillants sont lents. Étant donné que les accès malveillants nécessitent le chargement de WordPress par défaut, un mauvais bot ou un robot d'exploration qui décide de spammer votre site avec de mauvaises demandes peut supprimer votre blog assez facilement.
• Votre plugin de mise en cache peut avoir un bogue ou une incompatibilité avec la façon dont vous avez configuré votre blog . Par exemple, pendant 3 ans, j'ai pensé que WP Super Cache faisait la bonne chose jusqu'à ce que je commence à regarder mes journaux et remarque un bogue dans le code. En raison de la façon dont j'ai configuré les choses, j'ai eu un problème où WP Super Cache vidait mon cache trop souvent.

Le point clé que j'essaie de faire avec les puces ci-dessus est que chaque fois qu'un accès non standard se produit sur votre blog, il utilise beaucoup de ressources de serveur, quelle que soit la configuration de votre blog WordPress. Et ce sont ces types d'accès qui mettront votre serveur à genoux, pas le trafic régulier.

Détection des accès malveillants

La première clé pour optimiser votre blog WordPress est de comprendre les modèles de trafic que votre blog reçoit. Je suis prêt à parier que 99% des utilisateurs de WordPress ne le font pas. Au lieu de cela, ils suivent et installent aveuglément divers plugins et supposent que tout fonctionne correctement. Ne te sens pas mal, j'étais pareil.

La première étape consiste donc à découvrir ce qui se passe. Il existe de nombreuses façons de le faire, mais le plus simple est d'utiliser le mode de débogage fourni par le plugin WP SuperCache. A quoi sert ce mode ? Fondamentalement, chaque fois qu'un accès est directement géré par WordPress (grande consommation de ressources), il apparaîtra dans le journal WP Super Cache. Voici comment activer ce mode.

Sous l'onglet de débogage de votre plugin WP Super Cache, cliquez simplement sur la case à cocher « Débogage activé » et vous êtes prêt à partir !

Une fois la journalisation activée, vous pouvez cliquer sur le lien « logfile » qui vous dirigera vers un fichier détaillant votre trafic WordPress. Il ressemblera au texte ci-dessous.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

La chose importante à noter est que chaque fois que vous voyez quelque chose dans ce journal, c'est une mauvaise chose car cela signifie que WordPress doit faire du travail. Et parce que WordPress est un gros consommateur de ressources, vous voulez qu'il fasse le moins de travail possible.

Que rechercher dans les journaux

Les journaux WP Super Cache sont géniaux car ils vous disent tout ce qui se passe. Mais la quantité d'informations peut être écrasante à moins que vous ne sachiez quoi rechercher. Voici ce à quoi vous devez faire attention dans ces journaux.

• Erreurs 404 – Il s'agit essentiellement d'accès à des pages qui n'existent pas sur votre blog. Chaque accès 404 géré par WordPress prend beaucoup de ressources du serveur, vous voulez donc les étouffer dans l'œuf si possible
• Accès ponctuels - Ce sont des requêtes qui amènent votre serveur à mettre en cache et à compresser des pages qui ne seront utilisées qu'une seule fois (nous y reviendrons plus tard)
• Strange Bursts Of Traffic – Ce sont généralement des robots qui martèlent votre blog en même temps
• Comportement de mise en cache étrange – Vos caches sont-ils vidés quand ils le devraient ? Tout est-il correctement mis en cache en toutes circonstances ?

Après avoir tenu un journal du trafic de mon blog pendant une période de 2 semaines, j'ai découvert de nombreuses inefficacités que je vais décrire ci-dessous.

Les bots martelaient mes archives

La première chose que j'ai faite a été de consulter les journaux de mon serveur pour les périodes de charge CPU élevée. Ensuite, j'ai analysé mes super journaux de cache pendant exactement ces mêmes périodes pour voir s'il y avait des affaires amusantes en cours. Il s'avère qu'une fois tous les deux jours environ, un groupe de bots venait marteler toutes les pages d'archives de mon blog en même temps !

Parce que ces pages d'archives ne sont pas mises en cache par défaut, un tas d'accès simultanés était suffisant pour augmenter la charge de mon serveur et rendre les choses extrêmement lentes. Et parfois, cela faisait même planter mon serveur.

J'ai donc examiné de plus près ma sortie HTML et j'ai remarqué que j'avais un tas de liens d'archives dans mon en-tête WordPress. Par conséquent, les robots et autres robots d'exploration Web venaient et essayaient de parcourir les archives.

Après une grande recherche sur Google, j'ai découvert que quelques autres webmasters avaient des problèmes similaires.

Lorsque nous constatons plusieurs fois des problèmes de chargement avec votre site, il y a un grand nombre d'accès aux adresses IP de serveur proxy et la théorie est que ces proxy mettent en cache votre site et frappent tous ces liens d'archive. La plupart des adresses IP que nous voyons lorsque votre site cause des problèmes de chargement sont des adresses IP proxy d'entreprise, éducatives et gouvernementales/militaires qui semblent prélever le contenu lorsque quelqu'un accède à un site.

Solution : vérifiez si vous avez la déclaration php "wp_get_archives" dans le code d'en-tête de votre blog et supprimez-la. Après avoir supprimé ce petit extrait, tous mes accès aux archives ont disparu.

Les bots accédaient à des fichiers inexistants

La deuxième chose importante que j'ai remarquée était qu'il y avait un tas de robots qui accédaient à des fichiers sur mon serveur qui n'existaient pas. Le problème est que chaque fois qu'un accès à un fichier se produit, votre serveur doit charger WordPress, exécuter un tas de code PHP, puis émettre une page 404.

La solution à ce problème est de modifier le fichier .htaccess (Google si vous ne savez pas ce que c'est) et d'ajouter les lignes suivantes.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz) ?)
RewriteCond %{REQUEST_FILENAME} \.(css|js|html|htm|rtf|rtx|svg
|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc
|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|
m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf
|png|pot|pps|ppt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma|wri|
xla|xls|xlsx|xlt|xlw|zip)$ [NC]
RewriteRule .* – [L]

Une fois ces lignes insérées dans votre fichier .htaccess, votre serveur web vérifiera d'abord si un fichier existe. Sinon, il émettra une réponse 404 SANS charger WordPress.

Les bots accédaient à des URL qui n'existaient pas

Ce qui est malheureux dans la façon dont WordPress est écrit, c'est que s'il y a un accès à un article qui n'existe pas dans votre base de données, votre serveur devra charger WordPress, exécuter un tas de code PHP et faire un tas de recherches MySQL avant d'émettre un réponse 404.

Si vous regardez attentivement vos journaux, vous remarquerez probablement certains modèles d'accès que vous pouvez exclure avant qu'ils n'atteignent WordPress.

Par exemple, j'ai remarqué qu'un groupe de robots accédaient à mon site avec l'URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . Et à chaque fois, mon serveur chargeait WordPress et émettait une réponse 404.

Donc, au lieu de laisser WordPress gérer ces demandes, j'ai ajouté les lignes suivantes à mon fichier .htaccess

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} www\.facebook\.com/plugins [NC]
RewriteRule .* 404.html [L,R=404]

Dans les lignes ci-dessus, je demande à mon serveur Web de rechercher "www.facebook.com/plugins" dans l'URL et d'émettre immédiatement une réponse 404 sans charger WordPress. En parcourant vos journaux, vous trouverez de nombreux accès malveillants comme celui que j'ai décrit ci-dessus. Écrivez une règle .htaccess pour chacun et ces accès ne chargeront plus votre serveur.

Les bots martelaient mes liens de commentaire

Vous vous souvenez quand je vous ai dit que les URL avec des paramètres GET sont gérées différemment par votre plugin de mise en cache ? J'ai découvert qu'il y avait une tonne de bots qui martelaient mes articles avec le jeu de paramètres « répondre au commentaire ».

Lorsque cela se produit (en fonction de vos paramètres de mise en cache), wordpress est chargé et un fichier mis en cache/zip est servi même s'il ne sera probablement plus jamais accessible. C'est un gaspillage de ressources.

Exemple tiré de mon journal
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

La solution consiste à rediriger tous les robots et robots d'exploration avec ces paramètres GET vers la page principale de l'article. Voici le code que j'ai ajouté à mon fichier .htaccess.

RewriteCond %{QUERY_STRING} replytocom
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|crawl|spider|slurp) [NC]
RewriteRule .* https://mywifequitherjob.com%{REQUEST_URI} ? [L]

Ce code recherche le paramètre GET « replytocom » puis supprime ce paramètre de l'URL finale avant de présenter l'accès à WordPress.

Les robots accédaient aux publications sans barre oblique finale

Je ne sais pas pourquoi c'est le cas, mais j'ai remarqué un groupe de robots d'indexation qui semblaient essayer légitimement d'accéder aux articles de mon blog sans barre oblique finale dans l'URL.

Comme vous le savez peut-être ou non, une URL écrite comme http://yourblog.com/article/ est différente d'une URL écrite comme http://yourblog.com/article .

En conséquence, lorsqu'une URL sans barre oblique de fin est rencontrée, WordPress doit intervenir, exécuter un tas de code PHP, puis émettre une redirection 301 vers l'article avec la barre oblique de fin. Afin de retirer WordPress de l'image, vous pouvez simplement insérer la règle suivante dans votre fichier .htaccess.

# Ajouter une barre oblique
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{QUERY_STRING} !.*=.*
Règle de réécriture ^(.*)$ $1/ [L,R=301]

En ajoutant une barre oblique à la fin, vous émettez la redirection 301 vers l'URL correcte avant qu'elle ne parvienne à WordPress, ce qui économisera les ressources du processeur.

J'ai trouvé un bug dans WP Super Cache

Contrairement à la plupart des gens, mon blog WordPress n'est pas installé à la racine de mon répertoire public_html. De plus, la page d'accueil de mon blog n'est pas non plus ma page « posts ». Lorsque vous avez configuré votre blog de la même manière que moi, il existe un bogue dans WP Super Cache où tous vos fichiers de cache peuvent être supprimés prématurément, même si vous préchargez votre cache.

Je ne sais pas si l'auteur du plugin est conscient de ce problème, mais en gros, j'ai découvert que chaque fois qu'un commentaire de spam était publié sur mon blog, tout mon cache était vidé par erreur. Comme je reçois tout le temps des spams de commentaires et de rétroliens, mon cache était constamment vidé, ce qui rendait la mise en cache beaucoup moins efficace.

J'ai donc passé un week-end à déboguer ce problème et j'ai finalement développé une solution de contournement. Si l'un d'entre vous rencontre le même problème, faites-le moi savoir et je vous montrerai ma solution. La morale de l'histoire ici est de ne jamais supposer que votre plugin de mise en cache fonctionne. Il faut regarder les logs !

Désactiver les plugins gourmands en CPU

Même si vous avez suivi toutes mes étapes ci-dessus, il est impossible de filtrer tous les accès malveillants avant qu'ils n'atteignent votre blog WordPress.

Par conséquent, vous allez toujours recevoir des visites sur votre site qui ne seront pas gérées efficacement. Il n'y a aucun moyen de contourner cela.

Mais la chose importante à réaliser est que vous n'aurez probablement pas de problème de bande passante, vous aurez un problème de CPU.

En conséquence (et cela peut être contre-intuitif), vous ne voulez en fait pas faire quoi que ce soit de gourmand en CPU comme « minifier » ou « compresser » vos pages à la volée. La réduction et la compression contribuent à la bande passante au détriment de l'utilisation du processeur.

La dernière chose que vous voulez faire est de minimiser et de mettre en cache les accès malveillants. En fait, vous devriez probablement envisager de ne pas réduire ou compresser les URL avec les paramètres GET non plus.

Plus important encore, vous ne devriez pas exécuter de plugins gourmands en CPU sur votre site. WP-Engine a une excellente liste de plugins gourmands en CPU que vous devriez probablement essayer d'éviter.

En parcourant ma liste de plugins, j'ai remarqué que j'utilisais un plugin « articles similaires ». Et quand j'ai jeté un coup d'œil au code source, j'ai été consterné de découvrir que le plugin effectuait des comparaisons de texte intégral pour trouver des articles similaires, ce qui représente une consommation importante de processeur et n'est pas évolutive.

Dès que je trouve un remplaçant convenable, ce plugin va définitivement à la poubelle.

Morale de l'histoire

Le simple fait qu'un test de vitesse en ligne vous indique que votre blog est rapide ne signifie pas grand-chose dans le grand schéma des choses.

Ne vous méprenez pas. La vitesse de chargement des pages est importante pour les moteurs de recherche et pour vos clients réguliers, mais vous devez également tenir compte des accès malveillants qui peuvent contourner votre cache et mettre votre serveur à genoux.

Alors ne vous contentez pas d'installer votre mise en cache et d'autres plugins d'accélération à l'aveuglette. Prenez le temps d'analyser votre trafic et écrivez autant de règles .htaccess que possible pour minimiser le travail que WordPress doit effectuer. Bonne chance!