- WordPress :5.8
- Statut : non résolu
- Ce sujet contient 7 réponses, 4 participants et a été mis à jour pour la dernière fois par
, le il y a 2 années et 9 mois.
-
Messages
-
Bonjour,
J’ai installé WordPress sur un nouveau serveur. Mon site n’a aucun visiteur pour l’instant. Tout fonctionne très bien, sauf que l’affichage des pages est beaucoup trop lent : 0.4s en moyenne…
A chaque chargement de page, il y a entre 130 et 150 requêtes sur la base de données. Chacune d’elle est très rapide, la plus lente étant exécutée en 0.0018s. Mais 132*0.001=0.132s. Donc environ 1/4 du temps de génération de la page est lié aux requêtes SQL.
D’où viennent les 0.3s qui restent ?
Je précise que j’ai installé et configuré le plugin W3 Total Cache. Sinon je n’ai pas d’autres plugins qui pourraient expliquer les 0.3s de chargement manquant.
En outre, WordPress est installé sur un serveur dédié 4 cœurs, avec un disque SSD de 100Go et 32Go de RAM. Comme il n’y a personne sur mon site actuellement, les ressources matérielles sont totalement sous utilisées, j’ai bien vérifié.
Question : comment le site peut générer entre 130 et 150 requêtes SQL à chaque chargement de page ? C’est dingue. Pourquoi WordPress n’utilise pas un cache des requêtes sur le disque dur ou en RAM ?
J’ai créé entièrement un autre site avec PHP et Mariadb, avec une très forte audience : 450 millions de pages dynamiques par mois. En moyenne, chaque page est chargée instantanément : 0.02s. Pourquoi ? Parce que je mets toutes les requêtes en cache sur des disques SSD Nvme ou des partitions en RAM. Alors je ne comprends pas comment WordPress a été codé… plus d’une centaine de requêtes à chaque page chargée, c’est fou…
Je précise que j’utilise la toute dernière version de WordPress.
Donc je récapitule les questions auxquelles j’aimerais bien avoir une réponse :
1. Pourquoi environ 0.150s de requêtes SQL à chaque page ?
2. D’où viennent les 0.3s de chargement de page qui reste ? Est-ce le temps d’accès au disque parce qu’il y a un nombre démentiel de fichiers à charger ?Merci d’avance.
PS : ce site sous WordPress est aussi horriblement lent…
Bonjour
sans informations précises (plugins, etc) impossible de vous répondre autre chose que « parce que ».
Néanmoins, dans les « parce que » il peut y avoir :
1- mauvaise configuration du plugin de cache
2- le fait que, normalement, le cache ne fonctionne pas pour les utilisateurs connectés
WordPress a été codé pour pouvoir s’installer sur un grand nombre de serveurs. Il y a des sites / thèmes / plugins codés avec les pieds.
Un simple waterfall doit vous permettre de savoir à quoi correspondent les temps de chargement, et le plugin Query Monitor vous permettra de voir les différentes requêtes.
Merci pour votre réponse.
Je n’ai que les plugins W3 Total Cache et Query Monitor d’installés. Et si je les supprime, le site reste pratiquement aussi lent. Par ailleurs, j’ai configuré soigneusement W3 Total Cache en faisant des tests de performance. Le problème ne vient pas de là.
Concernant le cache qui ne fonctionne pas pour les utilisateurs connectés, j’ai testé sans être connecté, et cela diminue les requêtes de façon très marginale : le nombre de requêtes diminue un peu, 120 au lieu de 130 à 150.
D’après tous les tests que j’ai effectués, c’est WordPress qui a été « codé avec les pieds », pour reprendre votre expression… d’ailleurs ce forum est aussi très, très lent : avez-vous déjà mesuré la vitesse de génération de chaque page (coté serveur bien sûr, pas côté client) ?
Et vous avez regardé ce que vous donne Query Monitor, pas juste le nombre de requêtes, mais le détail ?
Pour être honnête, côté serveur, je m’en fous. Ce qui compte pour moi et pour l’utilisateur, c’est le côté client. Et avec une dizaine de site WP avec des GT Metrix entre 95 et 99, je pense que les pieds de WordPress doivent être doués.
Bref.
Dans le etc. de ma remarque, il y a tout, le thème, les images, allez voir ce que ça donne.
Rentrer dans une discussion théorique ne me passionne pas. Et je ne vois pas en quoi elle peut vous être utile.
« côté serveur je m’en fous » : ben non, vous vous trompez totalement. Car si la génération du code HTML renvoyé par le serveur est trop lente, l’affichage coté client sera retardé et lent.
Il y a 2 étapes pour voir les pages d’un site :
1. La génération du code html du site coté serveur. C’est là qu’est mon problème.
2. L’affichage du site côté client : sa rapidité dépend de la puissance de la machine du client, et du contenu HTML/Js à charger.Moi, je m’en fiche de l’affichage du site côté client, car j’si fait des tests et tout va bien de ce côté. C’est la génération du code HTML du site par WordPress qui est dramatiquement lente à cause des problèmes que j’ai cités au-dessus.
« vous avez regardé ce que vous donne Query Monitor, pas juste le nombre de requêtes, mais le détail » : oui, bien sûr.
Wordpress génère plus d’une centaine de requêtes à chaque affichée, et ca, ca montre que le codage a été fait avec les pieds, désolé.
Roh le zouli mansplaining 🙂 (hint : cache, gzip, etc).
Bon cela dit… sur mon site le plus lourd, Query Monitor me montre 40 requêtes « coeur de WordPress » pour un total de 0,0113 s. Donc vos soixante autres viennent d’ailleurs…
et je me répète, discuter dans le vide de ce genre de choses ne m’intéresse absolument pas. L’optimisation, ça se fait sur des cas concrets, sinon ça tourne au troll ou à la conversation de salon de thé.
@Alex120075 :@Lumière a bien résumé la situation. Sans accès au site, on ne peut guère vous aider. La supputation n’amène rien de concret.
Hello,
2 questions :
- Ou est hébergé le site ? OVH ?
- Désactive ton thème et tes plugins, remet le thème twenty twenty two et dit nous si tu as toujours autant de requête ?
Il est probable que cela soit ton thème qui fasse des appels inutiles a la base de donnée, car codé avec les pieds comme l’indique Marie-Aude.
- Vous devez être connecté pour répondre à ce sujet.