Quelles fonctions de Yoast désactiver pour alléger l'administration ?

Une administration WordPress qui met quatre secondes à afficher la liste des articles finit par coûter des heures sur une année, et la cause en est rarement le serveur. Sur les sites que nous reprenons, Yoast SEO figure presque toujours parmi les trois extensions qui pèsent le plus lourd sur le back office, non pas à cause de ses fonctions essentielles, qui sont légères, mais à cause d'une accumulation de modules secondaires activés par défaut et que personne n'utilise. Les désactiver relève de l'hygiène d'exploitation, à condition de savoir précisément ce qui touche au référencement et ce qui n'est que confort d'interface. La distinction n'est pas évidente au premier coup d'œil, et couper au hasard revient à supprimer des balises dont dépend l'indexation.

Ce que Yoast ajoute réellement à une administration

Avant de couper quoi que ce soit, il faut mesurer où part le temps. L'extension intervient à une dizaine d'endroits différents du back office, et tous ne se valent pas. La lecture du tableau de bord de Yoast SEO donne déjà une bonne idée des modules réellement actifs sur une installation.

Des colonnes dans toutes les listes

L'extension ajoute plusieurs colonnes aux listes d'articles, de pages et de produits : score de lisibilité, score de mot clé, titre et méta description en aperçu. Chacune déclenche un calcul ou une lecture de métadonnée pour chaque ligne affichée, soit vingt fois par écran avec les réglages par défaut. Sur un catalogue de plusieurs milliers de produits, cette seule addition suffit à faire passer l'affichage de la liste de moins d'une seconde à plusieurs secondes. Le détail qui surprend est que ces colonnes restent calculées même lorsqu'un utilisateur les a masquées dans ses options d'écran, puisque le masquage agit sur l'affichage et non sur la requête. Il faut donc les retirer là où elles sont déclarées, et non simplement les faire disparaître de sa propre vue.

Une boîte sous chaque éditeur

La boîte d'analyse placée sous l'éditeur charge sa propre interface, son propre jeu de scripts et son propre moteur d'analyse de texte qui s'exécute à chaque frappe. Sur un article long, l'analyse tourne en permanence et rend l'éditeur perceptiblement moins fluide. Une partie des rédacteurs ne la consulte jamais, une autre s'en sert quotidiennement, ce qui fait de ce module un cas typique de réglage à décider par profil plutôt qu'en absolu. Le compromis raisonnable consiste à conserver l'analyse pour les rôles qui rédigent et à la retirer pour les rôles d'administration et de gestion de catalogue, qui ouvrent des fiches produit par dizaines sans jamais lire un score de lisibilité.

Des tables et des tâches planifiées

Les versions récentes maintiennent un index interne, stocké dans des tables dédiées, qui recense les contenus et leurs relations pour accélérer la génération des données structurées et du plan de site. Cet index se construit par lots via des tâches planifiées, et sur un site volumineux ces tâches tournent régulièrement en arrière plan. Le mécanisme est utile en production, mais son coût devient visible lorsqu'il se déclenche pendant une navigation dans l'administration. La reconstruction complète de cet index, provoquée par certaines mises à jour, peut occuper le serveur pendant plusieurs heures sur un site de quelques dizaines de milliers de contenus, et c'est souvent à ce moment que l'on découvre son existence.

Des appels réseau sortants

Plusieurs modules interrogent des serveurs distants : vérification de licence, fil de nouvelles, suggestions, statistiques d'usage. Chacun de ces appels est plafonné et mis en cache, mais lorsque le serveur distant répond lentement, l'écran d'administration attend. C'est la cause la plus fréquente des lenteurs intermittentes et impossibles à reproduire, celles que l'on constate un matin et plus du tout l'après midi. Un serveur dont les connexions sortantes sont filtrées par un pare feu aggrave encore le phénomène, puisque l'appel n'échoue pas immédiatement mais attend la fin du délai de connexion, soit plusieurs secondes ajoutées à chaque écran.

Le poids réel sur le back office

Mesuré sur une installation ordinaire, l'écart entre une configuration par défaut et une configuration allégée se situe entre trente et cinquante pour cent du temps de génération des écrans d'administration, et la différence porte presque entièrement sur des modules qui n'ont aucun effet sur les pages vues par les visiteurs. Autrement dit, on gagne du confort quotidien sans toucher au référencement, ce qui est exactement le compromis recherché.

Les fonctions que l'on désactive presque toujours

Cette liste correspond aux modules que nous coupons systématiquement en reprise de site, sans qu'aucun client n'ait jamais constaté de régression. Ils relèvent tous du confort d'interface ou du suivi éditorial, jamais du balisage. Le même raisonnement s'applique aux autres extensions installées, qui ajoutent souvent les mêmes couches inutiles.

Les compteurs de contenu lié

Deux colonnes indiquent le nombre de liens entrants et sortants de chaque contenu. Leur calcul repose sur l'analyse de tout le corps du texte au moment de l'enregistrement et sur une table de correspondances mise à jour en continu. La fonction est intéressante sur le papier, elle est en pratique consultée une fois par an, et elle ralentit chaque enregistrement d'article sur les sites au maillage dense. Sur un site documentaire où chaque page cite dix à quinze autres pages, l'enregistrement d'un contenu déclenche autant de mises à jour de la table de correspondances, et le rédacteur perçoit très bien la seconde supplémentaire qui sépare le clic de la confirmation.

Les suggestions de contenu apparenté

Le module qui propose des contenus similaires à lier interroge un service distant à chaque ouverture d'éditeur. Il ne fonctionne d'ailleurs correctement qu'avec l'édition payante et sur des contenus en anglais pour une partie de ses analyses. Sur un site francophone, il consomme du temps de chargement pour un résultat que le rédacteur ignore, et sa désactivation ne retire strictement rien au contenu publié. Le maillage interne se construit de toute façon bien mieux à partir d'une réflexion éditoriale sur les familles de contenus qu'à partir d'une suggestion automatique fondée sur une similarité de vocabulaire.

L'onglet de suivi des mots clés

Le suivi de position, présent sous forme d'invitation ou de module selon les versions, appartient à l'offre commerciale et n'a d'intérêt que pour qui l'a souscrite. Sur une installation gratuite, il ne produit que des encarts promotionnels chargés à chaque affichage. Le couper supprime plusieurs requêtes et rend l'interface nettement plus lisible pour les personnes qui rédigent. Sur les sites que nous livrons à des équipes non techniques, ce nettoyage réduit aussi de façon notable le nombre de questions posées au support, puisque plus rien dans l'écran ne ressemble à un avertissement qui n'en est pas un.

Le fil de nouvelles et les notifications commerciales

L'extension affiche un fil d'actualités et des invitations régulières à passer à l'édition supérieure. Ces éléments déclenchent des appels sortants et occupent une place non négligeable dans le tableau de bord. Ils font partie des premières choses à retirer sur un site confié à un client, ne serait ce que pour éviter qu'une invitation commerciale ne soit prise pour une alerte technique. La confusion est réelle : un encart orange annonçant une fonctionnalité manquante est régulièrement remonté comme un incident, et il faut alors expliquer que le site fonctionne parfaitement et qu'il s'agit d'une publicité.

Les widgets du tableau de bord

Le tableau de bord de WordPress accueille par défaut un ou deux blocs issus de l'extension, qui recalculent leurs données à chaque affichage de l'écran d'accueil. Comme cet écran est le premier chargé à chaque connexion, il concentre l'essentiel de l'impression de lenteur. Le retrait de ces blocs est probablement le réglage au meilleur rapport entre effort et bénéfice ressenti. Il tient en une case à décocher ou en trois lignes de code, et il agit sur l'écran que chaque utilisateur voit plusieurs fois par jour, ce qui est rarement le cas des optimisations plus sophistiquées.

La colonne d'analyse dans les listes

Les colonnes de score peuvent être masquées écran par écran depuis le menu des options d'écran, ou retirées globalement par un réglage de l'extension. La seconde méthode est préférable, puisque le masquage par options d'écran est propre à chaque utilisateur et n'empêche pas le calcul côté serveur. La distinction entre masquer et désactiver est ici décisive et souvent confondue. Elle explique pourquoi une intervention menée depuis un compte administrateur donne parfois l'impression d'avoir réglé le problème, alors que les autres comptes continuent de subir exactement le même délai d'affichage.

Ce qu'il ne faut surtout pas couper

La moitié des régressions que nous constatons après un allègement vient d'une confusion entre un module d'interface et un module de sortie. Les fonctions suivantes produisent du balisage lu par les moteurs, et leur retrait a des conséquences immédiates. La mécanique du graphe JSON-LD généré par Yoast mérite d'être comprise avant toute intervention.

Le graphe de données structurées

C'est la contribution la plus précieuse de l'extension et la moins visible dans l'interface. Elle produit un ensemble de nœuds reliés décrivant le site, l'organisation, l'auteur, la page et le contenu, dans un format que les moteurs consomment directement. Le désactiver fait disparaître d'un coup tout le balisage sémantique du site, souvent sans que personne ne s'en aperçoive avant plusieurs semaines et une baisse d'affichages enrichis. Sur une boutique, la disparition du balisage produit entraîne en outre la perte des prix et de la disponibilité dans les résultats, avec un effet direct et rapide sur le taux de clic.

Le plan de site XML

Le plan de site peut légitimement être désactivé, mais uniquement si un autre dispositif prend le relais, extension dédiée ou génération sur mesure. Le couper sans remplacement prive les moteurs du signal le plus simple dont ils disposent pour découvrir les contenus nouveaux, ce qui se paie surtout sur les sites publiant régulièrement, où le délai d'indexation s'allonge de plusieurs jours. La vérification est immédiate : l'adresse du plan de site doit répondre en deux cents et lister les contenus récents, et ce contrôle mérite d'être fait avant comme après toute modification de la configuration.

Les canoniques et les directives d'indexation

Les réglages qui déterminent quelles archives, quels types de contenu et quelles pages d'auteur sont indexables produisent des directives lues à chaque passage des robots. Une désactivation trop large de ce bloc rend d'un coup indexables des dizaines de pages d'archives vides, avec le risque de dilution qui va avec. C'est la partie de la configuration à ne modifier qu'en connaissance de cause, et jamais dans un mouvement d'allègement global. Le bon réflexe consiste à relever, avant intervention, la liste des types de contenus déclarés indexables, puis à la comparer à la même liste après coup, ce qui prend deux minutes et rend toute dérive immédiatement visible.

Les métadonnées sociales

Les balises destinées aux réseaux sociaux n'ont pas d'effet direct sur le classement, mais elles déterminent l'apparence de chaque lien partagé. Leur retrait laisse les plateformes deviner un titre et une image, ce qu'elles font mal. Sur un site dont une partie du trafic vient du partage, la perte est immédiatement mesurable dans le taux de clic, pour un gain de performance nul dans l'administration.

Les redirections de l'édition payante

Sur une installation disposant du module de redirections, celui ci contient l'historique complet des adresses modifiées depuis la mise en ligne. Le désactiver rend d'un coup inaccessibles des dizaines d'adresses encore liées depuis l'extérieur. Avant toute intervention sur ce module, l'export de la table de correspondances est un préalable non négociable, quel que soit le plan retenu ensuite. Les règles peuvent ensuite être reportées dans la configuration du serveur, où elles s'exécutent plus tôt et coûtent moins cher qu'un traitement applicatif, mais ce transfert demande une relecture attentive des correspondances comportant des paramètres.

Comment procéder proprement

Un allègement se conduit comme une intervention technique ordinaire : mesure avant, modification unitaire, vérification après. Le faire en une seule passe non mesurée conduit invariablement à ne plus savoir quel réglage a produit quel effet.

Mesurer avant de couper

Un relevé du temps de génération de trois écrans représentatifs, l'accueil du tableau de bord, la liste des articles et l'éditeur, donne la base de comparaison. Une extension de profilage ou simplement l'onglet réseau du navigateur suffit à obtenir des chiffres exploitables. Sans ce relevé, l'évaluation du gain se fera au ressenti, et le ressenti se trompe presque toujours sur ce genre de mesure. Il faut par ailleurs mesurer plusieurs fois et à des moments différents de la journée, puisque les appels sortants font varier fortement les résultats d'une exécution à l'autre.

Passer par les réglages avant le code

La grande majorité des modules évoqués se désactive depuis les écrans de configuration de l'extension, sous les rubriques de fonctionnalités et d'intégrations. Cette voie est réversible, survit aux mises à jour et ne demande aucune compétence particulière. Elle doit être épuisée entièrement avant d'envisager la moindre ligne de code, ce qui suffit dans huit cas sur dix. Les deux cas restants concernent presque toujours des colonnes de liste et des blocs du tableau de bord, pour lesquels aucun réglage n'est prévu et où le retrait passe forcément par un point d'entrée du code.

Un fichier d'extension plutôt que le thème

Pour ce qui reste, les points d'entrée permettant de retirer une colonne ou un bloc du tableau de bord se placent dans une petite extension propre à l'installation, jamais dans le fichier de fonctions du thème. Un changement de thème ne doit pas ramener silencieusement des modules retirés, et la séparation rend le diagnostic possible pour la personne qui interviendra ensuite.

Désactiver l'index interne avec précaution

L'index interne se désactive, mais le faire déporte le calcul des données structurées sur chaque affichage de page, ce qui déplace le coût du back office vers le front. Sur un petit site, l'opération est neutre voire bénéfique. Sur un catalogue important, elle est franchement défavorable, et il vaut mieux conserver l'index en limitant la taille des lots traités par les tâches planifiées.

Vérifier après coup

Le contrôle porte sur trois points : le balisage structuré d'un article et d'une page reste présent et valide, le plan de site répond toujours, et les directives d'indexation n'ont pas changé sur un échantillon d'adresses. Un outil de test de données structurées et un simple affichage du code source suffisent. Cette vérification prend dix minutes et évite de découvrir une régression trois semaines plus tard.

Documenter et rejouer après mise à jour

Une mise à jour majeure réactive parfois un module retiré par réglage, en particulier lorsqu'un nouveau module apparaît activé par défaut. La liste des réglages appliqués, tenue dans une note de quelques lignes, permet de rejouer le contrôle en cinq minutes après chaque mise à jour importante. Sans cette note, la configuration dérive lentement et le site retrouve en un an l'état dont on l'avait sorti.