WordPress est un CMS au poil quand on veut se monter un petit site sympa avec plein de fonctionnalités cools. Seulement voilà, au bout d’un moment, WordPress s’alourdit, s’encroute et commence à faire ramer MySQL, entrainant une charge serveur importante et provoquant un bouchon côté Apache (ou Nginx ou peu importe).
C’est mon cas et bien que j’ai un serveur super costaud, il ne fait pas exception. Toutefois, ce n’est pas une fatalité et il existe différentes possibilités pour optimiser la charge de votre WordPress, y compris lorsque vous avez beaucoup de trafic et pas mal de plugins. Il est évident que je ne pourrais pas tout aborder, mais je vais déjà passer en revue ce que je connais et mis en place sur mon site.
Je vais donc commencer de l’option la plus facile à l’option la plus délicate.
Le cache
On commence par le cache… Le concept de mettre en cache une page côté serveur, c’est de distribuer uniquement du contenu statique, qui ne fait pas appel à la base de données. En gros, lorsqu’un premier visiteur se connecte à votre site, ce dernier génère une copie de la page visitée pour ensuite la resservir aux visiteurs suivants sans solliciter à nouveau la base de données.
En ce qui me concerne, j’utilise le plugin payant Wp-Rocket développé par des Français et plutôt efficace en terme de performances. Avant cela, j’utilisais Wp-super-cache qui fonctionne bien aussi. W3 Total Cache, j’ai déjà testé, mais je n’ai eu que des problèmes avec, et le support (payant) est merdique. Bon, concrètement, un plugin de cache, ça permet donc de stocker des copies des pages, et de les purger lorsque celles-ci sont trop vieilles. Ensuite, ça propose aussi, le plus souvent, des options de minification (concaténation du HTML, des CSS et des JS), de la compression (gzip), du préchargement, du chargement au scroll, du support de CDN…etc., etc.
Voici ce que j’ai dans Wp-Rocket, mais il y a sensiblement la même chose dans les autres plugins :
Pour moi, c’est ce que je vous conseillerai de mettre en place en premier. C’est rapide à faire et ça soulagera déjà pas mal votre serveur.
Les commentaires
Alors je suis désolé de le dire, mais les commentaires, c’est un vrai gouffre niveau charge serveur. Ça force le cache à se régénérer souvent, et ça sollicite beaucoup la base si vos visiteurs sont bavards. Ma préconisation, c’est donc de dissocier les commentaires de WordPress.
Pour cela, je vous recommande au choix :
- Disqus – Service gratuit, mais qui peut poser des problèmes éthiques à vos visiteurs, car ce service est hébergé aux États-Unis. Toutefois, comme vous pouvez synchroniser en douceur les commentaires Disqus avec votre base de commentaire WordPress, les données restent quand même chez vous et vous pouvez vous barrer à tout moment sans perdre un seul message.
- Un clone de Disqus – Je vous ai fait une liste ici… Certains sont encore un peu au stade expérimental.
- Un forum comme IPB (payant) ou Vanilla ou encore Discourse que j’utilise ici sur ce blog. À vous de voir. Ensuite, vous pouvez l’intégrer avec le plugin qui va bien, dans WordPress. Évidemment, pour éviter une charge serveur, je vous recommande de prendre un petit VPS (Server virtuel privé) à côté pour mettre ça. Et ça vaut aussi pour les clones de Disqus…
Le tracking via WordPress
Tout ce qui est tracking via WordPress est à proscrire… dès qu’un plugin vous propose des stats, de compter un nombre de clic, d’affichages ou que sais-je encore, vous devez vous en débarrasser ou désactiver l’option de comptage. En effet, chaque stat collectée équivaut à une écriture en base de données… Vous l’avez compris, ça fait ramer… Avant j’avais par exemple un compteur de lecture sur mes articles. C’était sympa, mais j’ai dû le retirer pour des questions de charge serveur.
Cloudflare
Cloudflare est un genre de cyber bouclier pour votre site. Il propose des options d’optimisation, de sécurité et de CDN pour soulager la charge de votre serveur, vous faire économiser de la bande passante et absorber les attaques DDoS. C’est un outil très complet, et gratuit pour les options de base. Comme Disqus, c’est soumis à débat, car c’est une société américaine, mais évidemment, vous restez maitre de votre domaine et vous pouvez tout stopper au moment où vous le désirerez.
Par exemple, rien que depuis un mois, Cloudflare m’a protégé de 24 867 attaques (potentielles) et permis d’économiser 5,56 TB de bande passante. Je pense que mon hébergeur lui dit merci 🙂
Votre thème WordPress
Bon, je ne suis pas développeur, mais en ce qui concerne votre thème, vous pouvez aussi l’optimiser. Testez d’abord le temps de chargement de vos pages avec des outils comme GTMetrix ou WebPageTest puis regardez ce qu’on appelle le TTFB (Time To First Byte). C’est le temps que met le premier byte de donnée à vous arriver. La légende veut que ce TTFB soit inférieur à 1 seconde. Personnellement, je pense que inférieur à 0,2 seconde, c’est mieux 🙂
Si vous êtes au-dessus de la seconde, c’est catastrophique. Si vous êtes entre 0,2 et 1 seconde, c’est pas mal, mais vous pouvez encore mieux faire. Et en dessous de 0,2 secondes, c’est très bien, mais ça ne vous dispense pas de continuer à optimiser un peu ;-)))
Bon grâce à ces outils de mesure, vous allez pouvoir voir ce qui met du temps à charger. De plus, ils vous donneront des conseils d’optimisation. Je vous recommande de les suivre. En gros, c’est optimiser les images (compression, sprite CSS, redimensionnement …etc.), placer les JavaScript dans le footer pour ne pas bloquer le chargement du site, minifier les CSS et le JS (mais ça votre plugin de cache a du s’en charger), réduire le nombre de connexions HTTP, paralléliser les chargements d’images …etc., etc. Déjà, rien que ça, vous en avez pour plusieurs heures de boulot.
Le serveur
Alors côté serveur, on peut aussi faire des choses. Déjà si vous utilisez Apache, je vous recommande de placer un Nginx ou un Varnish en reverse-proxy devant. Vous pouvez aussi virer directement Apache et passer sur un couple Nginx + Php5-fpm. Cela va permettre de faire servir à Nginx ou Varnish tous les fichiers statiques (CSS, images… y compris les HTML du cache) et de garder le reste pour Apache. J’avais fait un article là dessus pour Nginx en reverse proxy y’a plusieurs années, mais j’ai peur qu’il soit un peu périmé. Faudrait que je refasse la même chose avec Varnish. Quoi qu’il en soit, vous trouverez plein de tutos très bien à ce sujet.
Ce point n’est pas à négliger. Il est technique certes, mais une fois que c’est en place, vous allez vraiment sentir la différence.
La base MySQL
Bon, on va passer maintenant aux trucs sérieux (à la base, c’est sur ce point unique que j’avais prévu d’écrire mon article). Si votre site rame, c’est probablement parce que vous avez des tas de plugins qui le ralentissent. La première étape consiste donc à dégager tous les plugins dont vous ne vous servez pas, ou peu. Les machins inutiles que vous avez installés il y a plusieurs années et que vous gardez parce qu’ »on ne sait jamais ».
Ce qu’il faut savoir avec WordPress, c’est qu’il y a une table maudite qui est sans cesse appelée par le CMS. Il s’agit de la table wp_options. Et au fil du temps, cette table a tendance à s’alourdir à cause des plugins qui viennent y écrire sauvagement leurs données.
Je vais donc vous expliquer comment réduire la taille de cette table pour soulager WordPress. Mais avant de commencer, faites une sauvegarde de votre base de données. En effet, en cas de fausse manip, vous pourrez ainsi la restaurer à tout moment.
Bon, je suis passé par PhpMyAdmin pour que ça soit plus visuel, mais il y aura quand même quelques commandes SQL à taper… (enfin, à copier-coller 😉 ). Rendez-vous d’abord sur votre base et observez la taille de la table wp_options.
Chez moi c’est un peu la cata. Au moment où j’ai pris cette capture-écran, ma table wp_options pesait 6,3 Mo. Cela signifie qu’à chaque fois qu’une page WordPress est générée, qu’un module est chargé, qu’un article est posté, MySQL se tape une lecture de toutes les lignes marquées comme « autoload = yes » (options qui se chargent automatiquement) dans la table wp_options. Et chez moi, ça représente un peu plus de 6 Mo à chaque fois. C’est hyper lourd !
Afin de compter le nombre de lignes chargées automatiquement par WordPress (celles en « autoload = yes »), il vous suffit d’entrer la commande suivante :
SELECT count(*) FROM wp_options WHERE autoload=’yes’;
Bon, moi j’en avais plus de 1500 et après un début d’optimisation, je suis descendu à 1449… Y’a encore du boulot, car ce nombre est énorme… Mais c’est un vrai travail d’enquête policière qu’il vous faudra mener pour tout nettoyer. Avant de poursuivre, vérifiez aussi que vous avez bien un index sur le champ autoload de la table wp_options (ici surligné en vert clair).
Si ce n’est pas le cas, vous pouvez en ajouter un comme ceci :
CREATE INDEX autoload ON wp_options (autoload);
WordPress dispose d’une fonctionnalité baptisée Transient qui lui permet ainsi qu’aux plugins de mettre en cache des infos directement en base. Cela lui permet d’éviter de régénérer sans cesse les mêmes choses et donc de faire mouliner la base. Même si ça ne remplacera jamais un cache côté serveur, c’est quand même utile. Seulement, les transients ne sont pas forcement toujours « nettoyés » proprement et au bout d’un moment, ils s’accumulent et viennent faire grossir la table wp_options.
La solution la plus simple consiste donc à dégager ces transients. Vous pouvez le faire directement en base en supprimant les valeurs qui commencent par « _transient_ », ou alors en installant le plugin Smart Cleanup Tools (payant) qui permet de faire le ménage régulièrement en base.
J’en ai profité pour virer aussi les commentaires dans spam, à la poubelle ou non validé…etc. Et hop, d’un seul coup, ma table wp_options est passée de 6,3 Mo à 1,4 Mo. Sachez aussi que Smart Cleanup Tools permet de programmer des nettoyages automatiques réguliers…
Ça soulage ! Mais ce n’est pas encore suffisant… Car vous ne le savez pas, mais dans cette table wp_options, il y a des tas de lignes qui ne vous servent plus à rien et pour certaines, qui contiennent beaucoup de données. Il convient donc de les supprimer. Et c’est là que l’enquête policière dont je vous parlais tout à l’heure peut commencer.
Tout d’abord, on va isoler le top 50 des lignes de wp_options qui prennent le plus de place dans la table. Pour cela, utilisez la requête SQL suivante :
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload=’yes’ ORDER BY option_value_length DESC LIMIT 50;
Surprise !!! Voici un exemple de ce qu’on peut obtenir. Comme c’est classé de la plus grosse à la moins grosse, vous pouvez déjà commencer par ça…
Repérez d’abord les lignes qui appartiennent à des extensions. On les reconnait la plupart du temps, car elles sont préfixées. Par exemple pour moi, wpts_ c’est le plugin WP-Touch pour la version mobile du site. Si ce plugin abuse avec la table wp_options, je dois donc (sauf si je ne peux faire autrement) :
- 1/ Arrêter de l’utiliser (donc, le supprimer du répertoire wp-content/plugins)
- 2/ Supprimer toutes les lignes qui commencent par ce préfixe. C’est comme ça qu’on peut vraiment nettoyer cette table, car les plugins ne font pas le ménage quand on les enlève.
À chaque ligne, si vous ne savez pas à quoi ça correspond, vous devrez mener une petite recherche (les moteurs de recherche sont vos amis) et décider si oui ou non, il convient de les supprimer.
Et au fur et à mesure, vous arriverez peut-être à supprimer toutes les lignes inutiles dans wp_options. En ce qui me concerne, j’ai déjà viré pas mal de choses appartenant à des anciens plugins que je n’utilise plus. Ce n’est pas toujours simple de tout retracer tout, mais c’est possible. Restez quand même prudent et en cas de doute, abstenez-vous de supprimer telle ou telle ligne, sauf si remonter la base mutilée ne vous fait pas peur.
Conclusion
Voilà en ce qui concerne les conseils que je peux vous donner sur l’optimisation de site WordPress. C’est loin d’être complet, mais c’est déjà un bon début, je trouve. Évidemment, tout ceci s’applique aussi bien aux sites en souffrance qu’à ceux qui ne sont pas particulièrement chargés, mais vous remarquerez beaucoup plus les effets sur des WordPress anciens qui reçoivent beaucoup de trafic ou qui ont / ont eu beaucoup de plugins.
J’espère que cet article vous aura été utile et si vous avez d’autres conseils d’optimisation, surtout en ce qui concerne la base de données, n’hésitez pas, je suis preneur !
D’avance merci !