Korben, roi d’internet, logo bébé avec des lunettes en mode thug life Korben, roi d’internet, logo bébé avec des lunettes en mode thug life

Korben Upgrade your mind

Comment optimiser un vieux WordPress obèse ?

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 :

wprocket

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 🙂

cf2cf1

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 🙂

k

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.

6mb

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’;

utoload

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.

transients

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.

transient

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…

13

Ç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…

top

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 !


Amazon Music 3 mois à 0,99 €

Offre à durée limitée

Avec Amazon Music profitez de plus de 50 millions de titres sans publicité et en écoute illimitée.
Un mode hors connexion est également proposé, avec notamment la connexion aux appareils de la gamme Echo pour une commande vocale de toute votre bibliothèque musicale.

En Savoir +



Réponses notables

  1. Plus simple : changer de moteur de blog :smile:
    Je suis content de PluXml et pour un blog simple, ça marche.

    Sinon rigolons : si on installe une extension WordPress, on change les options, on teste, on supprime l’extension… la base contient toujours les options.

  2. “Changer de moteur de blog” --> Tu es le premier d’une longue série à faire ce commentaire :wink:

    Au suivant !

  3. Pour la table d’options c’est surement l’installation/suppression de plugin qui l’a rempli inutilement. J’utilise Clean Options pour nettoyer ça. Pour ma part quand je veux tester un plugin, je fais une copie du blog en local, je test mon bordel et si ça marche bien je réplique sur la prod.
    Sinon pour cleaner la base de données Wordpress j’utilise CleanFix et WP-Optimize pour voir le poids des tables.

    Merci pour l’article, j’ai pas tout lu mais ça peut être utile.

  4. A mon tour aussi :stuck_out_tongue:
    Pourquoi pas un site statique? A la [Jekyll][1]

    Plus sérieusement tout dépend de l’utilisation et des gouts de chacun, mais pour ma part c’est fini je n’installerai plus Wordpress que si le site a VRAIMENT besoin d’un gros CMS (et clairement ce n’est presque jamais le cas je trouve).

    Les avantages du sites statiques : Rapidité d’affichage, pas de BDD et plus sure

    Sinon comme toujours merci pour l’article et ta transparence
    [1]: http://jekyllrb.com/

  5. Changer de visiteurs ? :stuck_out_tongue:

  6. MySQL est vraiment ce qui prend le plus de ressources, la longue tirade de l’article qui en fait allusion ne m’étonne pas. J’ai déjà vu dans plusieurs entreprises lors d’anciens stages, que les salles serveurs comprennent à chaque fois un serveur spécialement dédié a l’hébergement BDD. Et ce, pour des applications internes.

    Tonton, je pense que la solution devrait être de mettre complètement ton blog en cache pour éviter de rappeler les scripts de Wordpress et donc éviter de faire des requêtes SQL… Un peu comme si on visite archive.org, mais actualisé beaucoup plus souvent, pour au final avoir un site statique. Par contre certaines fonctions comme la page “Au hasard” risque de ne plus bien fonctionner :wink:

    Je dois pas être le premier à y avoir pensé, mais tout en conservant Wordpress, cela soulagerait significativement le serveur…

  7. Nym says:

    En parlant de cache::

    “Website is offline No cached version of this page is available.” en allant sur la page 2 de korben.info :stuck_out_tongue:

    edit: bon le temps de poster c’est revenu :smile:

  8. Alors qu’il suffirait de publier des billets bien pourri pour que les visiteurs fuis et que la charge serveur revienne à 100% !

    Vous aimez bien vous casser la tête vous autres ^^

Continuer la discussion sur Korben Communauté

14 commentaires supplémentaires dans les réponses

Participants

LNAV – Un visualisateur de fichiers de logs libre et pratique

LNAV (Logfile Navigator) est un outil dispo pour Linux et macOS qui permet de visualiser et de parcourir des fichiers de logs de manière agréable et efficace.
En plus de la coloration syntaxique, de la prise en charge de formats de logs standards (Syslog, CUPS, dpkg, sudo, strace…etc), LNAV est aussi capable de décompresser à la volée des logs zippés (ou gzippés ou bzippés) mais aussi de rassembler (merge) des logs segmentés pour en faciliter la visualisation.

Lire la suite



Une faille de sécurité dans les processeurs risque de diminuer jusqu’à 30% les performances des machines

La grosse news d’hier, ce n’était pas Logan Paul filmant un pendu au Japon, mais plutôt ce gros « problème » qui touche l’ensemble des processeurs Intel fabriqués durant ces 10 dernières années. Le problème est en réalité 2 failles de sécurité très importantes qui permettent à n’importe quel programme malicieux d’accéder en lecture à la mémoire utilisée par le kernel (le noyau de l’OS et ses modules interagissant avec le hardware).

Lire la suite



Bandwidth Hero – Surfez compressé pour économiser de la bande passante

Si vous êtes un peu juste en bande passante et que vous voulez accélérer un peu les choses, je vous propose aujourd’hui de jeter un œil à Bandwidth Hero.

Il s’agit d’une extension open source pour Chrome et Firefox qui fonctionne de concert avec un serveur proxy. Ce serveur proxy récupère chaque image que votre navigateur demande, la compresse au format WebP/JPEG en basse résolution et vous la renvoie ensuite directement.

Lire la suite