Slow admin - attend et est bloqué pendant longtemps
J'ai un site wordpress et parfois, une fois connecté à l'administrateur, il peut être assez lent. J'ai joint une image pour montrer ce que je veux dire. La première demande attend environ 8 secondes avant qu'il ne se passe quoi que ce soit d'autre, ce qui représente généralement une attente d'environ 2,5 à 3 secondes. Toutes les autres demandes sont ensuite bloquées pendant plusieurs secondes.
J'ai pas mal de plugins (26) cela pourrait-il être la raison ou est-ce autre chose?
Que se passe-t-il réellement ici et que puis-je faire pour l'améliorer autant que possible?
Mise à jour: j'ai désactivé tous les plugins et les ai activés un par un. Les deux qui semblaient avoir le plus gros effet étaient Champs personnalisés avancés et Utiliser les bibliothèques Google . Voici ce que j'ai trouvé.
Ce sont les demandes et l'heure de chargement de la page de tableau de bord d'index en fonction de l'onglet net de firebug.
Sans plugins activés
26 demandes
6-7 secondes
Avec tous les plugins activés
64 demandes
13 secondes
Avec tous les plugins activés mais les deux mentionnés ci-dessus désactivés
36 demandes
8 secondes
Si j'active les champs personnalisés avancés
55 demandes
11-12 secondes
Si je désactive ACF et active Utiliser les bibliothèques Google
53 demandes
10 secondes
En réponse au commentaire de l'op:
Mise à jour: j'ai désactivé tous les plugins et les ai activés un par un. Les deux domaines qui semblaient avoir le plus gros impact étaient Advanced Customs Fields et Use Google Libraries. Voici ce que j'ai trouvé.
L'utilisation de Google Api devrait économiser temps et effort, ne vous coûte pas du temps et des efforts. Vous pouvez les charger dans l’un de vos fichiers de thème (c.-à-d. Functions.php) comme
<?php
// first, check to see if jquery-ui is already loaded
if( !wp_script_is('jquery-ui') ) {
// you don't have to use googleapi's, but I think it helps. It saves the user's browser from loading the same script again if it has already been loade>
wp_enqueue_script( 'jquery-ui' , 'https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.min.js' );
}
?>
(note: j'ai pris une partie de ceci à partir d'une autre réponse que j'ai soumise récemment. Le fil peut être trouvé ici .
En ce qui concerne le module Advanced Custom Fields, à quoi l'utilisez-vous?
Modifier:
1) assurez-vous à 100% que vous n’appelez aucune de ces bibliothèques deux fois. Il est certainement possible qu'un autre élément de code l'appelle déjà et que vous l'appeliez deux fois, cela peut poser problème. L'utilisation de google api pour jquery va probablement poser problème si wordpress utilise déjà jquery par défaut, par exemple (conseil: c'est le cas!)
Récemment, j'ai découvert que le cache rapide ralentissait !!! un des sites Web de mon client, ce qui est maintenant très important, car Google l'utilise pour vous classer dans le référencement.
Pour le résoudre j'ai fait ce qui suit:
1) Basculé sur W3 Total Cache mais n’a pas tout activé. 2) chaque fois que j'ai apporté une modification, je l'ai effectuée via un service de test de vitesse de site Web avec une poignée d'autres sites sur lesquels j'ai travaillé en tant que contrôle pour chaque test. 3) Au lieu d'utiliser googleapi, j'ai créé un compte avec CloudFlare, qui est inclus en tant qu'option pour W3 Total Cache. CloudFlare est un service CDN avec un niveau de service gratuit.
Les resultats:
L'activation de la base de données et du cache de fichiers, ainsi que de quelques autres modifications (telles que la minification), a rendu ce site particulièrement lent parmi les suivants:
Test 1: en utilisant Quick Cache, le chargement de ce seul site était de 15.07 secondes! Je l'ai désactivé et il est tombé à environ 6-7 secondes en moyenne. Test 2: Cache total W3 activé sans CloudFlare: le temps de chargement de la page a été réduit à 1,91 seconde. Toujours un peu brut, mais ce qui est bon, c'est l'hébergement partagé pour ce compte. Test 3: CloudFlare activé pour héberger des images, des fichiers multimédias, etc. et mon mot vole maintenant! Le chargement moyen des pages est maintenant réduit à 0,45 seconde.
Note finale:
Ce ne sont que des méthodes d'hébergement partagées. Effectuez une mise à niveau vers un VPS et configurez un cache d'opcode comme APC, ce qui réduira encore plus le temps de chargement (du moins, je l'espère). Ajouter un cache de proxy inverse Varnish et votre site sera en mesure de maintenir sous des niveaux de trafic plus lourds. Memcached est génial aussi, mais Varnish ne fait que voler à chaque fois que je l’implémente et la possibilité d’utiliser VCL est fantastique!
Qu'utilisez-vous pour la mise en cache? Avez-vous plusieurs plugins cache/performance/ou même SEO installés? Si tel est le cas, désactivez-les tous et réactivez les plus suspects un à la fois.
La meilleure première étape à prendre dans un cas comme celui-ci, peu importe ce qui consiste à désactiver TOUS les plugins et à vérifier si le problème existe toujours. S'il existe toujours, vous avez probablement un problème de configuration du serveur ou un problème central avec wordpress. Si le problème disparaît, vous êtes à mi-chemin. Commencez à réactiver les modules un par un et vérifiez si les résultats résolvent le problème.
L'exécution d'un grand nombre de plugins affectera votre performance à un certain niveau, mais la plupart des plugins ne sont pas si lourds. Cependant, si l’un de vos plugins pose un problème avec Wordpress, il pourrait en être à l’origine.
Si vous utilisez des plugins de cache, l'utilisez-vous pour toutes vos pages? Vous pourriez être à l'origine d'un problème. En réalité, aucune des pages d’administration ne devrait être mise en cache, car vous ne devriez avoir, pour commencer, qu’un nombre limité d’utilisateurs ayant accès à/wp-admin.