Accélérer le backend de WordPress (wp-admin)

Oops...
Slider with alias none not found.

10 bonnes façons d’atténuer la lenteur de votre backend WP-admin.

Si vous êtes frustré par un backend lent prenant une éternité pour cliquer d’une page à l’autre, croyez-moi je vous entends. Les pages frontales sont tellement plus faciles à mettre en cache, mais le backend ne l’est pas.

Cela signifie-t-il que vous serez à jamais maudit avec des temps de chargement misérables et des fonctions d’administration qui prennent une éternité ?

NON !…ok, peut-être…mais je vais vous aider à tirer le meilleur parti de vos options.

La CAUSE de la lenteur des backends

Les backends sont lents parce qu’ils sont complètement dynamiques.

Et par “dynamique”, je veux dire qu’ils doivent interroger la base de données pour chaque demande de page. La base de données est appelée et chaque élément d’information est demandé à partir de zéro comme si elle ne l’avait jamais vu auparavant. Il n’y a pas de mise en cache.

Le fait que le backend montre parfois plus d’informations n’aide pas non plus. Quels utilisateurs, quel contenu, quels commentaires, combien de ventes, etc. Il calcule souvent des informations qui ne sont même pas affichées. Il y a aussi l’API Heartbeat qui fonctionne constamment en arrière-plan pour sauvegarder automatiquement vos modifications.

Les bases de données peuvent également devenir plus lentes au fur et à mesure que leur taille augmente. Tout comme trouver des objets dans votre maison devient plus difficile lorsque vous avez plus d’objets. Les bases de données prennent plus de temps lorsque vous commencez à rechercher des données très compliquées qui sont enfouies ou organisées de manière complexe et/ou inefficace.

Sachant cela… voyons comment nous pouvons optimiser ces requêtes backend dynamiques pour accélérer votre expérience WP-admin.

1. Vérifiez vos plugins

Chaque fois que quelqu’un vient me demander de l’aide pour un backend lent, il est immédiatement “coupable jusqu’à preuve du contraire” pour moi.

Vérifiez tous vos plugins et voyez lesquels contribuent à cette terrible lenteur du backend.

“Mais comment ? !”

Comme ça…

  1. Désactivez certains plugins non essentiels pour voir si ça fonctionne plus vite. Puis en désactiver d’autres. Continuez jusqu’à ce que vous n’ayez plus aucun plugin activé. Je suis sûr que vous avez déjà une idée de ceux qui sont en cause.
  2. Vous devriez également vérifier votre thème. Avec tous vos plugins habituels activés, essayez de passer au thème par défaut pendant une seconde. Cela a-t-il aidé ?

Hahaha, je plaisante… ignorez ces deux premières étapes (ne détruisez pas votre site en direct) et faites-le comme un pro. Installez Query Monitor et surfez sur quelques pages du frontend tout en étudiant le panneau de diagnostic au bas de votre navigateur. Il n’y a que deux choses que vous devez vérifier : les requêtes de flux et les requêtes par composant. Ces deux éléments vous indiqueront quels thèmes, plugins ou requêtes sont à l’origine des retards les plus importants. Vous devez également prendre note de l’utilisation de la mémoire (sur votre barre d’administration supérieure) et du nombre de requêtes effectuées par chaque plugin.

Une fois que vous aurez trouvé la cause du problème… vous devrez les remplacer !

  • Plugin slider lent ? – Changez de plugin pour les sliders !
  • Thème lent ? – prenez un autre thème !

Certains d’entre vous vont avoir du mal à se défaire de leurs précieux plugins… mais je vous promets ceci… quel que soit le plugin de merde que vous avez, il y a de fortes chances pour qu’il existe un plugin de qualité supérieure et sans les cauchemars des requêtes lentes.

2. Vérifiez les erreurs

  • Error.log – trouvez-le dans votre répertoire public_html et regardez dedans. Voyez-vous beaucoup d’erreurs ?
  • Erreurs de console – ouvrez les outils de développement et regardez s’il y a des requêtes 404 évidentes.
    En général, ce ne sont pas tant les erreurs qui causent le problème, mais les plugins liés à ces erreurs.

3. Vérifiez l’utilisation élevée de la mémoire

Trois choses que vous devez savoir :

  • La quantité de mémoire utilisée par l’ensemble de votre site. (Essayez WP Server Health Stats)
  • La quantité de mémoire utilisée par votre thème et vos plugins. (A partir de Query Monitor)
  • La quantité de mémoire utilisée par vos chargements automatiques.

A partir de là, nous avons deux tactiques.

Bien sûr, vous pouvez essayer d’augmenter les limites de mémoire de votre site. Ajoutez les lignes suivantes à votre fichier wp-config.php au-dessus de la ligne qui dit “C’est tout, arrêtez de modifier ! Bon blogage” :

La première augmente l’utilisation de la mémoire pour le frontend, la seconde pour le backend. Pour la plupart des sites bien construits, vous n’avez besoin d’aucun des deux. Vous pouvez même augmenter la seconde à 512 Mo ou même plus, mais le problème est que cette limite est toujours restreinte par la limite globale de mémoire PHP du serveur. Si vous avez votre propre serveur VPS, vous pouvez fixer une limite aussi élevée que vous le souhaitez. Si vous êtes sur un hébergeur mutualisé pourri, elle est probablement très limitée et essayer de la fixer plus haut ne servira à rien.

Si cela doit être dit, vous devriez vous débarrasser des plugins qui consomment tant de mémoire. Et n’oubliez pas de vérifier vos chargements automatiques. Très souvent, il y a beaucoup d’anciens thèmes ou plugins que vous n’avez plus et qui consomment encore votre mémoire ! Ils restent dans la base de données à charger leurs index même si aucun plugin ne les utilise !

4. Mettez à jour votre hébergement (ou votre serveur web)

Avez-vous remplacé tous vos plugins gonflés ? !

  • NON ? !
  • POURQUOI NON ? Parce que vous vouliez économiser de l’argent ?

Eh bien aujourd’hui, vous pouvez dépenser l’argent que vous avez économisé pour un meilleur hébergement. Désolé mon pote, tu dois payer pour une expérience de qualité !

Ok, soyons justes… peut-être que certains d’entre vous ont remplacé leurs plugins. Ou vous avez vu que vos plugins n’étaient pas le problème !

La réponse est la même… le moyen le plus simple et le plus rapide est de trouver un meilleur hébergeur ou un serveur web plus puissant. Gardez à l’esprit que je n’ai pas dit de prendre un hébergeur plus cher. Non !

Quel que soit le niveau d’hébergement dans lequel vous vous trouvez (hébergement mutualisé, VPS, etc.), je vous garantis qu’il y en a probablement un autre qui est meilleur et pas si loin en termes de prix.

Mais attention, ce simple bouton de renflouement ne fonctionne pas comme vous le pensez. Le nouveau serveur que vous obtenez ne doit pas seulement être plus cher ou plus grand, il doit aussi donner plus de ressources à votre site ! Ce n’est pas parce que vous optez pour un serveur plus grand ou plus puissant que votre site aura automatiquement accès à plus de CPU et de mémoire. J’ai vu de nombreuses personnes mettre à niveau et payer le double sans pour autant obtenir de meilleures performances.

  • Vous pouvez lire mes commentaires sur le meilleur hébergement WordPress.

Que doit avoir un bon serveur ?

C’est difficile à dire, car toutes les spécifications ou statistiques que je vous donne peuvent facilement faire l’objet d’un faux marketing (tout comme la façon dont vous vous êtes retrouvé dans votre situation actuelle). Le moyen le plus simple est de sentir s’il est rapide ou non.

Mais si vous insistez, il est bon de savoir s’il dispose des dernières versions de PHP et MySQL. Des disques durs rapides avec de bons taux d’E/S de disque. Et des paramètres agressifs. Il est également bon d’avoir des limites de mémoire PHP décentes.

5. Diminuer l’intervalle de l’API Heartbeat

Il s’agit d’une mesure facile à mettre en œuvre qui peut donner de bons résultats sans trop d’efforts. Il y a quelques plugins spécialisés qui font cela, comme Heartbeat Control… mais c’est beaucoup mieux si vous pouvez l’utiliser à partir de votre plugin de cache (comme Swift, Rocket, LiteSpeed).

Mes recommandations ci-dessous :

  • Vous pouvez (probablement) sans risque désactiver heartbeat sur toutes les pages frontend et backend sauf pour l’éditeur de post.
  • Ne le désactivez pas à partir de l’éditeur d’articles car Heartbeat y est utilisé pour effectuer des sauvegardes automatiques.
  • Si de nombreux rédacteurs se connectent et travaillent en même temps, vous pouvez allonger l’intervalle Heartbeat pour l’éditeur d’articles, mais ne le désactivez pas pour autant !
  • Cliquez ici pour en savoir plus sur l’API WordPress Heartbeat.

6. Mise en cache des objets

Je suis sûr que vous avez déjà entendu des mots à la mode comme “Memcache” et “Redis”. Redis (qui est le meilleur et le plus courant de nos jours) est un module serveur qui vous permet de mettre en cache les requêtes de votre base de données. Il est très rapide, puisqu’il enregistre ces informations en mémoire plutôt que sur le disque (comme la mise en cache typique des pages).

Il y a beaucoup de mises en garde et de variables à prendre en compte… Je vais laisser des recommandations générales ci-dessous et vous pouvez faire des recherches sur le reste si vous êtes curieux :

  • La mise en cache des objets nécessite beaucoup de mémoire. Par conséquent, il n’est généralement autorisé qu’avec les plans VPS et presque jamais avec l’hébergement partagé. Même si votre hébergement mutualisé autorise la mise en cache d’objets, elle est probablement neutralisée.
  • Un bon délai d’expiration du cache d’objets est compris entre 5 et 60 minutes. S’il est trop court, le cache expire avant que vous puissiez en profiter. S’il est trop long, votre contenu dynamique sera périmé jusqu’à l’expiration du cache d’objet (mais peut-être que cela vous convient).
  • La mise en cache des objets agit comme la mise en cache des pages, mais avec des temps de “bénéfice” plus courts. Les premiers accès sont lents, les accès suivants sont rapides jusqu’à ce que le cache expire (et doive être reconstruit).
  • La mise en cache des objets est utile si vous travaillez beaucoup dans le backend. Si vous n’entrez et ne sortez que quelques minutes par jour, vous êtes probablement plus rapide sans la mise en cache des objets.

Au cas où vous vous poseriez la question, on parle de mise en cache d’objets parce qu’elle met en cache les requêtes de la base de données (alias “objets de la base de données”)… ce qui vous permet de conserver la plupart de vos fonctionnalités dynamiques tout en bénéficiant de vitesses plus rapides (puisque certaines requêtes sont déjà construites et ne doivent pas être recherchées à chaque clic).

7. Mise en cache des zones d’administration et des utilisateurs connectés.

D’accord, c’est le mode désespéré ici. C’est généralement une mauvaise idée, mais cela peut fonctionner dans certaines situations. Voici dans quels cas cela peut et ne peut pas aider :

AIDE si…

  • Vous avez beaucoup d’utilisateurs connectés.
  • Vos utilisateurs connectés voient principalement du contenu statique.

N’EST PAS UTILE si…

  • Vous n’avez pas beaucoup d’utilisateurs connectés.
  • L’ensemble de votre backend dépend entièrement de données dynamiques en direct.

Si vous y réfléchissez bien, la mise en cache ne vous aide qu’à charger plus rapidement un contenu répété. Si vous n’avez pas de contenu backend statique ou suffisamment d’utilisateurs pour en bénéficier, alors la mise en cache de la zone d’administration ne sera pas d’une grande utilité. Au contraire, cela rendra votre site encore plus lent ! (Plus lent parce que les ressources de votre serveur sont maintenant gaspillées pour construire et purger un cache qui n’est même pas utilisé).

COMMENT mettre en cache le backend ?

Activez les fonctionnalités suivantes dans votre plugin de cache :

  • Cache de la zone d’administration – cela devrait être assez facile.
  • Cache pour les utilisateurs connectés – vous devrez peut-être décider quelles zones sont publiques ou privées. Public signifie que tous les utilisateurs voient le même contenu. Privé signifie que tous les utilisateurs voient un contenu différent (comme leurs pages “Compte”).
  • Cache ESI – vous pouvez jouer avec cette technologie de perforation mais je vous préviens que ce n’est pas pour les bricoleurs. Vous avez besoin d’un développeur pour bien faire les choses. Si vous utilisez le serveur et la mise en cache LiteSpeed, le moyen le plus simple d’utiliser ESI est de déployer votre contenu via des shortcodes ou dans un widget.

8. Vérifiez votre plugin de sécurité

Avez-vous Wordfence ou Sucuri ? Vous n’êtes pas obligé de vous en débarrasser, mais sachez qu’ils ralentissent considérablement le backend. Puisqu’ils vérifient chaque chargement de page pour les exécutions de pirates et autres.

Bien sûr, vous avez peut-être vu des guides vous disant de ralentir le scan… mais en réalité, cela n’a pas beaucoup d’importance. C’est parce que ces plugins de sécurité enregistrent chaque chargement de page, et vérifient les exécutions de code potentiellement mauvaises.

9. Empêcher la charge inutile des plugins sur le backend

Bienvenue dans la “joie” de la gestion de la charge des actifs. Ici, nous désactivons tous les appels CSS/JS inutiles depuis le backend.

Je retire ce que j’ai dit à propos de l’étape précédente. Il y a une étape encore plus désespérée que la précédente. J’avais l’habitude d’essayer d’optimiser à ce point mais j’ai réalisé que c’était stupide. Votre vie est plus précieuse que de perdre du temps à faire ça. Il n’y a aucun intérêt… c’est comme si vous nettoyiez la semelle de vos chaussures la nuit avant d’aller courir dans la boue le lendemain.

Vous n’auriez JAMAIS dû avoir à faire cela.

  • Vous auriez dû avoir un thème de qualité.
  • Avec des plugins de qualité.
  • Sur un bon serveur web.
  • Et avec vos autoloads nettoyés de tous les restes d’anciens thèmes/plugins.

Si vous êtes ici en train d’essayer de remonter le temps et de passer d’un actif CSS/JS à l’autre… c’est parce que vous vous êtes entêté sur une étape précédente. Je vous invite à revenir en arrière et à faire tout le reste. Vous finirez par faire beaucoup plus de travail ici que si vous remplaciez simplement vos thèmes/plugins. Et vous risquez de casser votre site par inadvertance ou d’affecter les opérations futures en oubliant que vous avez désactivé quelque chose.

Vous voulez toujours aller de l’avant avec cela ? *Soupir* Ok, vous avez gagné. Recommandations ci-dessous :

  • Je préfère Asset CleanUp : Page Speed Booster plutôt que tous les autres chargeurs d’actifs ou organisateurs de plugins qui existent.
  • Perfmatters peut également être utile.
  • WP Gonzalez et Plugin Load Filter sont également corrects.
  • Le reste est soit 1) trop compliqué et l’interface utilisateur pauvre à utiliser, ou 2) ils ajoutent leur propre charge qui annule la charge qu’ils ont supprimé !
  • N’essayez pas de supprimer chaque atout de chaque plugin. Concentrez-vous sur les principaux plugins gonflés !

La seule façon professionnelle de supprimer les charges de ressources inutiles des plugins :

Fork le plugin et le hacker.

10. Résistez aux idées stupides

J’ai entendu des clients imaginer de temps en temps des tactiques stupides. Ils lisent des mots au hasard sur Internet et pensent que cela s’applique. Je suis heureux de les dissiper pour vous ci-dessous :

  • Obtenir un meilleur plugin de cache – désolé, non. Les plugins de cache sont généralement conçus pour une utilisation frontale.
  • Installer des plugins de performance – J’ai vu tous les plugins booster débiles pour WooCommerce, les constructeurs de pages, et ainsi de suite. Au mieux, ils ne font qu’accaparer plus de mémoire via des chargements automatiques, ce qui permet au plugin en question de fonctionner plus rapidement alors que le reste de votre site ralentit.
  • Augmenter les limites de mémoire – cela permet seulement à votre site lent de fonctionner au lieu de tomber en panne. Cela ne permet pas à votre site de réduire son utilisation de la mémoire [gaspillée].
  • La mise en cache de votre administration par Cloudflare – DUMB ! NON ! *battez votre main au loin*.
  • Site statique – non, les sites statiques ne sont que pour le frontend.
  • Équilibrage de charge, ou configuration de cluster – si votre site est trop gonflé pour être chargé sur un serveur, ajouter un autre proxy ne va pas aider ou redistribuer la charge de quelque manière que ce soit. C’est comme essayer de faire cuire un gâteau en utilisant deux cuisines au lieu d’une. L’équilibrage de charge est pour la charge de trafic élevé, pas pour la charge de code lent.
  • Base de données distante – lol, non ! Votre base de données lente fonctionne encore plus lentement maintenant puisqu’elle n’est pas sur le même serveur.
  • Organisation des actifs (étape 7 ci-dessus) – car même si vous supprimez les actifs, vous ne supprimez toujours pas les requêtes. Et gardez à l’esprit que la gestion des ressources n’aide principalement que les utilisateurs frontaux, car les utilisateurs backend n’utilisent même pas ces ressources pour les charger.
  • Réglage des configurations MySQL – Je doute fortement que ce soit votre problème.

L’optimisation de la vitesse n’est pas du ressort des non-développeurs. Même si vous ne cassez pas votre site, vous ne pouvez améliorer votre vitesse lente que de 10 % (voire l’aggraver). Je vous recommande d’engager un développeur si vous en êtes arrivé là.

Photo de pixelcreatures sur Pixabay

Similar Posts