Publié initialement à : https://korben.info/comment-optimiser-un-vieux-wordpress-obese.html
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…
Plus simple : changer de moteur de blog 
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.
“Changer de moteur de blog” --> Tu es le premier d’une longue série à faire ce commentaire 
Au suivant !
1 « J'aime »
Bah d’un autre côté, tu crois que tu ne vas pas devoir faire du ménage régulièrement ?
Après, il existe tellement de moteurs différents (CMS ou blog)…
Hello,
En même temps pour un blog simple sans trop de trafic, tout peut fonctionner.
Le sujet ici c’est d’optimiser une installation WordPress, parce que ce choix de CMS permet d’assurer bien plus que la gestion d’un blog.
Concernant les plugins, c’est comme toujours : ça dépend desquels. Les options doivent être supprimées par le plugin si le développeur y a pensé. Mais c’est comme les fichiers temporaires/profil des applications Windows : ça dépend.
Merci pour l’article @Korben ! (et pour la mention de WP Rocket ;p)
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.
Je ne suis pas un grand connaisseur de wordpress mais tu pourrais t’essayer au partitionnement de tables MySQL: 1 partition = 1 fichier.
Par exemple la table wp_posts, actuellement tu en affiches 6 par page, si tu fais des partitions de 6 x 6 sur les ID, chaque fichier ne contiendra que 36 billets. Moins de datas à parcourir sur le disque => plus de performance.
Une fois configuré MySQL se démerde tout seul, c’est transparent pour Wordpress.
On peut aussi supprimer la pub ou désactiver les widgets inutiles, faut penser au visiteur qui a l’ADSL et qui n’a pas un i7 octo-core
"La légende veut que ce TTFB soit inférieur à 1 seconde. Personnellement, je pense que inférieur à 0,2 seconde, c’est mieux "
–> Tu n’es as le seul à le penser, Google recommande un temps de réponse serveur (pas tout à fait le TTFB donc) < 200ms. (source ici notamment : https://developers.google.com/speed/docs/insights/mobile)
Le seuil d’une seconde existe actuellement : reco Googe sur le Visually Complete, c’est donc effectivement loin d’être sur le TTFB.
Je ne suis pas objectif du tout, mais www.dareboost.com (vs GT Metrix), est une solution française, sur laquelle vous pourrez retrouver les indicateurs de WebPageTest également (speedindex, etc) et des conseils plus nombreux
A mon tour aussi 
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/
Allez ma première pierre à l’édifice sur un site que je lis assez régulièrement.
Il y a déjà pas mal d’optimisations qui ont été abordés.
J’opterais pour un varnish car c’est son but premier de faire du cache. En plus, au travers de la configuration on peut gérer assez facilement les requêtes cacher, avec où sans cookies (yummy). Bref, hormis la doc illisible, ça fait très bien le taf.
Le passage par AWS S3 et cloudfront pour les images. Plus besoin de les backuper où de gérer la volumétrie (même si faire du ménage c’est bien^^) Pour faire le taf : https://wordpress.org/plugins/amazon-s3-and-cloudfront/
En passant par du php 5.5/5.6 on récupère opcache qui permet d’optimiser l’execution du php (pas vraiment une optimisation puisque qu’il fait son propre code à lui), il faut penser à le vider en cas de mise à jour où lors de l’utilisation de symlink.
Après les moteurs static, c’est super pratique, mais il n’y a pas de BO (à moins d’utiliser un éditeur type cloud9 sur son serveur), mais je plussoie l’idée de Jekyll.
EDIT : Il y a des cache-control, assez étrange sur korben.info.
Tu pourrais directement faire le redirect de l’admin par varnish (si l’IP n’est pas la tienne), tu t’éviterais de faire du traitement PHP.
Il reste aussi HHVM, si le coeur te dit à essuyer surement quelques incompatibilitées
Il reste mySQL tuner et le montage des tables en RAM.
Changer de visiteurs ?
1 « J'aime »
Pourquoi tu n’utilises pas un template responsive design plutôt qu’un plugin WP-Touch?
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
Je dois pas être le premier à y avoir pensé, mais tout en conservant Wordpress, cela soulagerait significativement le serveur…
En parlant de cache::
“Website is offline No cached version of this page is available.” en allant sur la page 2 de korben.info
edit: bon le temps de poster c’est revenu
Perso je suis passer sur du NGinx/HHVM/MariaDB et c’est pas mal du tout.
Juste une incompatibilité avec un plugin qui s’est résolu en mettant la dernière mise à jour.
Le temps de chargement est beaucoup plus rapide en back-office !
Pour test -> www.lsa-clan.fr
Le partitionnement de table ça se fait généralement sur des volumétrie importante , pas sur une table de 6Mo ^^ ou de 1500 lignes.
J’ai déjà bossé avec des tables de plusieurs Go et millions d’enregistrements (non partitionnés) sur mysql sans problème particulier.
C’est juste que effectivement si les données sont mal ou pas indéxées et qu’on essai de récupérer 10k enregistrement d’un coup ça marche mal , mais c’est valable pour n’importe quel SGBD.
Le fond du problème c’est la conception de wordpress vieillissante et ultra permissive. Comme tu peux à peut près tout modifier au travers des plugins forcément ça à un prix et c’est pas forcément adapté à des volumétries importantes et/ou au bidouillage sans avoir à mettre les mains dedans par la suite.
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 ^^
1 « J'aime »
très bon article très complet, merci 
ça va me servir autant pour moi que pour mes clients !