Table des matières
Nettoyer les options de la base de données pour améliorer le temps de réponse du serveur
Vous êtes confronté au problème de l’optimisation de la vitesse des pages de votre site, notamment au reproche que vous fait Google PageSpeed : « Réduire le temps de réponse initial du serveur » ?
Ou bien, l’écran de santé de WordPress vous indique que « le temps de réponse du serveur est lent » ?
J’ai trouvé, quasiment par hasard, la cause et la solution.
Je viens de passer des semaines à optimiser 4 de mes principaux sites. J’ai trituré LiteSpeed Cache dans tous les sens, je me suis arraché les cheveux à force d’être confronté à des absurdités, à comprendre des explications qui n’expliquent rien, à lire des tutos qui m’induisent en erreur en me recommandant des solutions commerciales ou en s’abstenant de m’informer.
D’ailleurs, dans ces tutos inutiles, la doc de Google PageSpeed me fait bien rire : pas un mot sur les options de la base de données des sites WordPress, qui représentent pourtant quasiment 1 site web sur 2 dans le monde !
Et puis, je suis tombé sur SweepPress, un plugin qui, même en version gratuite, permet d’analyser les entrées présentes dans la table Option.
Installez-le, activez-le et allez dans SweepPress > Manage Options.
Là, cliquez sur le menu déroulant « All statuses » et choisissez « Missing ».
Puis lancez la recherche en cliquant sur le bouton « Trier ».
Ensuite, cliquez deux fois sur la colonne « Value size » : ça va vous trier les options par taille.
Maintenant, scannez tout ça, googlez les indicatifs des options pour savoir à quels plugins ça correspond. (ça marche dans 90% des cas. Dans le doute, abstenez-vous !)
Ces plugins existent, sont installés, vous sont toujours utiles ? Alors, ne touchez surtout pas à leurs options ! Vous pourriez casser votre site. D’ailleurs, FAITES UNE SAUVEGARDE DE VOTRE BASE DE DONNEES avant de toucher aux options.
Mais, si ces plugins n’existent plus sur votre site depuis longtemps, s’ils sont inactifs et que vous n’avez pas l’intention de les réactiver, alors supprimez les, et supprimez aussi toutes leurs options.
Cochez une par une les cases des options fantômes des plugins défunts, puis dans le menu déroulant « Actions groupées » cliquez sur Supprimer puis sur le bouton Appliquer.
Plus vos options sont grosses en taille, plus il importe des les supprimer si elles ne servent à rien, d’autant plus si elles sont en mode Autoload.
Exemple de nettoyage des options avec SweepPress et d’optimisation des performances Core Web Vitals
La version mobile charge en 6 secondes !!
Et Pagespeed indique bien sûr : « Réduire le temps de réponse initial du serveur ».
Or, quand j’inspecte les options avec SweepPress, je découvre que plusieurs de ces options pèsent très lourd :
- ast-block-templates-sites-1 charge 387k de données pour rien
- ast-block-templates-blocks-1 en rajoute 52k
- etc
Qu’est-ce que ast-block-templates ? Il s’agit de restes d’un plugin que j’ai désinstallé, Astra Starter Templates. Ces options sont donc non seulement lourdes, mais totalement inutiles.
Vous n’imaginez pas le nombre de plugins mal codés qui vont ainsi laisser des traces un peu partout après désactivation et même après désinstallation :
- dans vos dossiers et fichiers
- des tables dans la base de données
- et des entrées dans la table des options, y compris des données en mode « autoload », qui se chargent en mémoire vive
Au total, c’est pas loin d’1 mo qui sont chargées dans la table des options.
Sur un autre site, c’est le plugin WooCommerce Payments, que je n’utilise plus, qui me laisse plus de 120 ko de données périmées dans la table option. Même des plugins liés à des entreprises très connues font ce genre de boulot d’amateur, qui vous force à faire le nettoyage vous-même et à la main. Par exemple Jetpack…
Bref, je fais le ménage, et je relance un test avec PageSpeed : voici les résultats avant / après :
Eh oui, des secondes gagnées en Speed Index, 60ms économisés en Total Blocking Time (du temps que le serveur passait à fouiller dans les données périmées de la table options !!) Les résultats ci-dessus sont trompeurs car ils changent à chaque mesure. Mais globalement, en moyenne, le nettoyage de mes options, l’optimisation des tables de ma base de données, et d’autres optimisations, ont fait remonter mes notes.
Le diagnostic PageSpeed est en partie faux
Un truc important que j’ai observé lors de mon marathon d’optimisation, c’est que les diagnostics de Google PageSpeed, plutôt que de nous informer de manière claire, nous orientent souvent dans la mauvaise direction.
Par exemple, dès lors qu’on a réglé le problème des options obsolètes dans la base de données, plusieurs reproches que faisait Google PageSpeed disparaissent comme par enchantement.
Par exemple, la taille excessive du DOM était un problème mais ne l’est plus dès lors que le serveur réagit plus rapidement.
De même, le Total Blocking Time repasse du rouge au vert pour la même raison.
Une optimisation ici fait disparaitre deux problèmes là.
Imaginons par exemple que vous ayez publié un article avec une image à la une qui pèse 2mo. Là, PageSpeed va vous reprocher un long temps de rendu, un long temps de chargement (time to first byte), etc. Et il va vous signaler des tas de petits problèmes qui s’additionnent.
C’est un peu comme si vous vous présentiez dans un ascenseur intelligent capable de peser son propre contenu, et limité à 500 kilos. Vous arrivez avec une enclume de 450 kilos, une brosse à dent, une peluche, et vous-même : là, l’ascenseur vous listerait tout ce qui contribue à dépasser le poids : vous, l’enclume, la brosse à dent, la peluche. Or, éliminez juste l’enclume et la liste des reproches disparaîtra !
Méfiez-vous donc quand vous lisez ces diagnostics et la doc trompeuse et incomplète qui l’accompagne : les problèmes ne sont souvent pas forcément là où PageSpeed les signale.
Un autre exemple : j’avais un menu avec des icônes, grâce au plugin Menu Icon. C’était joli, mais ça me coûtait un peu de CSS, du blocking time, un temps supplémentaire de First Contentful Paint et de Cumulative Layout Shift. J’ai viré les icônes et tout ça a redescendu. Nulle part Google ne disait que les icônes en étaient responsable. Il faut réfléchir et tester par essai-erreur, c’est long, très long, mais on peut y arriver.
Bon courage si vous optimisez !
