Indépendamment de toutes les mesures de mise en cache et d’optimisation de la vitesse de WordPress que vous avez appliquées, tout cela ne sert à rien dans les cas où votre site doit encore lancer des processus PHP dynamiques pour répondre à certains types de demandes de pages. Ces processus dynamiques consomment plus de CPU et de mémoire que les requêtes mises en cache, ce qui peut parfois entraîner une lenteur de traitement, que ce soit sur le front-end ou dans l’administration de WordPress.
Voici les cas les plus courants où le traitement dynamique est utilisé :
Si, dans l’un de ces cas, vous constatez que le chargement de la page est plus lent que 3 à 5 secondes, c’est que le traitement dynamique est en cause et les étapes décrites ici vous aideront.
Le temps nécessaire au chargement dynamique d’une page varie en fonction de l’utilisation de votre site. Par exemple, les sites WooCommerce avec certains types d’extensions auront besoin de plus de puissance CPU pour fonctionner, en particulier dans l’administration de WordPress.
Pourquoi le traitement dynamique crée-t-il des performances lentes ?
Le traitement dynamique présente deux facettes qui peuvent entraîner une lenteur des performances :
Nous devons soit arrêter complètement ces demandes de traitement dynamique, en les mettant en cache ou en les bloquant, soit les rendre plus légères.
Il ne faut pas oublier que si votre traitement est très lent en raison d’un processus lourd, l’activation de la mise en cache ne fera que retarder l’inévitable. L’utilisation d’un code mieux optimisé, que nous décrivons dans cet article, reste la meilleure solution pour obtenir des performances optimales. Si vous décidez de ne pas supprimer ou remplacer les fonctionnalités peu performantes du site (plugin, thème, code personnalisé, etc.), la mise à niveau vers un VPS pour obtenir plus de puissance CPU peut être votre seule option viable.
Même avec seulement 1 à 5 processus dynamiques, si votre site est mis en cache, utilise un code/des plugins/des thèmes bien optimisés et soigneusement sélectionnés, et se trouve sur un hébergement WordPress de bonne qualité, vous pouvez toujours atteindre plus de 1 000 visiteurs simultanés avec un impact minimal sur les ressources de votre serveur.
Si vous rencontrez un problème où une page prend soudainement plus de 30 secondes avant de commencer à charger le contenu, il y a souvent un problème sous-jacent avec WordPress ou la configuration de l’hébergement que vous devez résoudre avant de procéder à l’une des étapes de ce guide. Cliquez ici pour obtenir de l’aide afin de résoudre les problèmes de chargement soudain très lent des pages.
Nous allons d’abord passer en revue les contrevenants les plus courants qui occupent des créneaux de traitement dynamique, car l’identification de ces derniers et la mise en œuvre d’une solution spécifique pour eux permettront souvent de résoudre les problèmes de performance sans avoir à plonger dans les problèmes de performance. trop dans le code et le processus de dépannage exhaustif.
Voici 7 façons de limiter rapidement les types de traitement dynamique les plus courants :
1. Plugins et thèmes découragés
Jetez un coup d’œil à notre liste de plugins, de fonctionnalités et de thèmes déconseillés. Si vous constatez que votre site utilise l’un de ces thèmes, plugins ou configurations, le moyen le plus rapide d’éviter de devoir se plonger dans les détails des performances de votre site est de suivre les recommandations. Cela signifie généralement qu’il faut modifier la configuration ou désactiver/remplacer le plugin ou le thème incriminé.
2. Préchargement du cache
Si votre plugin de mise en cache statique pour WordPress a une fonction de préchargement, lorsqu’il s’exécute, il interroge toutes les pages non mises en cache en une seule fois. Il s’exécute lorsque vous l’activez pour la première fois, et chaque fois que vous videz le cache de votre site. Dès que le cache est vidé, l’araignée de préchargement entre en action et explore chaque page de votre site Web, générant une requête à chaque fois.
Chaque demande de page crée un processus dynamique sur le serveur pour générer le fichier de cache de cette page, de sorte que les visites suivantes de la page soient beaucoup plus rapides. Vous vous demandez probablement : “N’est-ce pas une bonne chose ? Parce qu’alors tous les caches sont prêts à être utilisés pour que les visiteurs voient le site super rapidement…”. Eh bien, vous avez raison ! Mais vous utilisez aussi inutilement les ressources du processeur (puisque les demandes de pages ne sont même pas destinées à un vrai visiteur). vous risquez également de sacrifier la vitesse de chargement des pages. pendant le temps où le moteur de mise en cache précharge vos fichiers de cache.
La solution : désactiver le préchargement. Oui, cela signifie que le *premier* visiteur à consulter ces pages mettra un peu plus de temps à se charger – pour contourner ce problème, vous pouvez charger vous-même vos pages à fort trafic manuellement avec un navigateur séparé pour générer le fichier de cache – mais cela signifie également que le préchargeur ne gaspille pas les ressources du processeur (parce que la demande qu’il fait n’est même pas pour un vrai visiteur) et ne ralentit pas le site pendant le préchargement.
Sur au moins certains de nos serveurs mutualisés, le préchargement en cache est détecté et bloqué en raison du gaspillage des ressources du processeur qui pourraient être utilisées pour les visiteurs réels du site. Si vous passez à votre propre VPS, ce blocage peut être supprimé sur demande, car vous pouvez choisir de gaspiller les ressources du processeur.
3. Sauvegardes et analyses de logiciels malveillants
Lorsque vous utilisez des plugins WordPress pour gérer les sauvegardes et les analyses de logiciels malveillants, vous choisissez également d’utiliser un ou plusieurs de vos précieux processus PHP disponibles pour gérer ces sauvegardes, ces analyses, ou les deux.
Désactiver les plugins de sauvegarde et les scanners de logiciels malveillants ou les configurer pour qu’ils soient exécutés beaucoup moins fréquemment (et surtout en dehors des heures de pointe) aidera à résoudre ce problème.
Nous avons longtemps considéré ces deux tâches comme des éléments qui devraient être gérées par le panneau de contrôle de l’hôte et non par un plugin. pour cette raison précise. Pourquoi devriez-vous potentiellement sacrifier les performances de votre site web simplement parce que vous voulez avoir des sauvegardes et un site sans malware ? Si vous êtes hébergé chez nous, nous incluons les services côté serveur suivants avec tous les plans d’hébergement :
Comme ils sont exécutés au niveau du serveur, aucun de ces processus n’affecte votre limite de processus PHP ! Configurez simplement votre sauvegarde pour qu’elle se connecte au service en nuage de votre choix et vous n’aurez plus besoin de plugins de sécurité ou de sauvegarde pour WordPress.
4. Désactiver les pages 404 personnalisées
En raison du mode de fonctionnement des réécritures de WordPress, chaque demande 404 doit être traitée par un processus PHP de manière dynamique. Vous pouvez utiliser Google Search Console pour identifier les 404, ou vous pouvez les identifier en utilisant les journaux de votre serveur.
Voici quelques solutions potentielles :
# BEGIN 404 Chargement fixe
<IfModule mod_rewrite.c> ;
RewriteEngine on
RewriteCond %{REQUEST_URI} .(jpe?g|png|gif|js|css|ttf|xml|map)$
RéécrireCond %{REQUEST_FILENAME} !-f
Règle de réécriture .* – [R=404,L]
</IfModule> ;
# END 404 Load fix
5. Panier global WooCommerce
La meilleure chose à faire dans ce cas est de désactiver l’affichage dynamique du panier, si votre thème dispose d’une telle option. Nous décrivons quelques thèmes et plugins qui le font dans le lien Fonctionnalité déconseillée ci-dessus, mais il y en a certainement d’autres que nous n’avons pas encore découverts.
6. Exécuter WP-CRON moins souvent
Pour résoudre ce problème, vous pouvez soit ajouter define(‘WP_CRON_LOCK_TIMEOUT’, 900) ; dans wp-config.php ou suivez notre guide pour vous aider à forcer votre WP Cron à s’exécuter moins fréquemment et de manière plus fiable. Le guide est préférable.
7. Interrogation lente de la base de données
Requêtes inefficaces: si un plugin ou votre thème est mal codé, il exécutera des requêtes inefficaces sur votre base de données.
Grande taille de la base de données / Taille de la table : Si une table de base de données est remplie de centaines de milliers ou de millions d’entrées, les requêtes qui utilisent cette table peuvent devenir plus lentes.
La façon la plus simple de détecter les problèmes de performance de la base de données est d’installer et d’activer le plugin Query Monitor, puis de charger la page lente. Le plugin Query Monitor s’ajoutera au bas de votre page et affichera une liste exhaustive de toutes les requêtes de la base de données, identifiant celles qui prennent le plus de temps.
Si le chargement des pages prend 5 secondes, mais que Query Monitor montre que toutes les requêtes de la base de données se terminent en moins d’une seconde, je crains que ce ne soit pas votre problème et que vous deviez suivre les étapes ci-dessous pour essayer d’identifier la véritable source. Cependant, si Query Monitor montre que les requêtes de la base de données correspondent à peu près aux temps de chargement des pages, vous pourrez l’utiliser pour identifier soit le plugin qui cause le problème, soit la table qui est trop grande.
Si la table qu’il interroge est trop grande (typiquement > ; 500k entrées ou plus de 50-100MB, mais cela varie en fonction de la configuration de la mémoire cache et des performances IO), vous pouvez utiliser le bouton phpMyAdmin dans Plesk pour afficher la table et passer en revue les entrées. Vous constaterez peut-être que beaucoup d’entre elles sont d’anciennes données dont vous n’avez plus besoin (et que vous pouvez supprimer à l’aide de phpMyAdmin), ou qu’un plugin crée des données en double en raison d’un bogue qui doit être signalé au développeur.
Exemples courants de tables de base de données massives
Exemple 1 : Table des actions programmées de WooCommerce : nous en avons récemment vu une avec plus de 2M de lignes, apparemment en raison de la journalisation de la synchronisation de Square. Il semble que WooCommerce ne réduise pas cette table au fil du temps et nous avons donc exécuté la requête suivante dans l’onglet SQL de phpMyAdmin afin d’effacer toutes les actions terminées :
DELETE FROM wp_actionscheduler_actions WHERE status = ‘complete’ ;
Exemple 2Un bogue dans la fonctionnalité Reduce Unused CSS (RUCSS) de WP Rocket entraîne l’enregistrement de données en double dans la base de données à chaque fois qu’un des fichiers CSS ou Javascript générés par un thème ou un plugin est modifié. En conséquence, la table wp_wpr_rucss_resources devient énorme : jusqu’à 5 Go dans le cas du site d’un de nos clients. La meilleure façon de résoudre ce problème est de tronquer le tableau dans phpMyAdmin (sous l’onglet Opérations) quotidiennement jusqu’à ce que WP Rocket soit en mesure de résoudre le bug.
Comment détecter le traitement dynamique
Si vous avez suivi les conseils ci-dessus et que vous pensez que le traitement dynamique affecte toujours les performances de votre site, je crains que le reste ne soit pas aussi simple à résoudre, mais vous pouvez utiliser les étapes suivantes pour vous aider à déterminer ce qui se passe.
Remarque : ce processus de dépannage peut être délicat. Il vous faudra analyser soigneusement les journaux de votre site Web et utiliser l’outil d’inspection de votre navigateur afin de trouver la cause de vos problèmes de traitement dynamique. Nous vous montrerons comment analyser vos logs dans notre guide sur l’affichage des logs avec Plesk, mais il n’y a pas de guide sur l’utilisation de l’outil d’inspection de votre navigateur (du moins pas encore), alors consultez la documentation en ligne de votre navigateur si vous avez besoin d’aide à ce sujet.
Surveillez les journaux d’accès de votre site Web lors du chargement d’une page lente ou lorsque la charge du site est importante pour voir si une page fréquemment consultée et demandée par les visiteurs est celle qui déclenche les processus PHP. Il se peut que vous deviez noter un certain nombre de pages et les essayer toutes vous-même pour voir lesquelles ne sont pas mises en cache. Cet article contient quelques astuces pratiques pour vous aider à réduire les résultats aux requêtes spécifiques qui nécessitent un traitement dynamique et sont susceptibles de générer une charge plus importante.
Ouvrez chaque URL de page que vous avez notée avec votre navigateur et examinez-la à l’aide de l’inspecteur Web de votre navigateur. Allez dans l’onglet Réseau pour voir toutes les requêtes et le temps qu’elles ont pris. Il se peut que vous deviez rafraîchir la page pour remplir cet onglet avec les demandes de la page. Vous verrez également une option en haut de l’onglet Réseau qui vous permet de filtrer par type de ressource. Voici les deux plus importantes pour l’analyse du traitement dynamique :
Filtre pour Document/Doc et sélectionnez la page elle-même (appelée / ou /nom-de-page/ si ce n’est pas la page d’accueil dans la liste des ressources). Certains hôtes – comme nous – indiquent dans les en-têtes (un des onglets ici) si la page a été servie à partir du cache ou non. Vous devriez également voir ici le temps qu’il a fallu pour charger la page principale elle-même (à l’exclusion de toutes les autres ressources que la page charge). Ce nombre est le temps au premier octet ou TTFB. Plus d’informations à ce sujet ci-dessous.
Filtre pour XHR (il s’agit de requêtes AJAX ou asynchrones) et vérifiez si l’une d’entre elles charge des données depuis votre domaine. Les requêtes XHR vers des domaines externes n’affecteront pas le traitement dynamique de votre serveur, elles peuvent donc être ignorées. Sélectionnez chacune d’entre elles et utilisez les onglets de données/requête/réponse sur la droite pour déterminer quelles données sont envoyées/reçues. Ce site devrait être identifier la fonction du plugin ou du thème qui est utilisée ici pour générer des données dynamiques.
Voici comment analyser ces résultats :
- Si vous constatez que la page ne se charge pas à partir du cache, vous avez trouvé votre problème : essayez d’identifier pourquoi la page ne se charge pas à partir du cache.
- Si vous constatez qu’il charge du contenu dynamique XHR à partir de votre domaine, alors c’est votre problème : trouvez comment empêcher cette requête dynamique de se produire.
- Si la page est mise en cachealors le temps de réponse que vous avez trouvé lors du chargement initial de la page est une indication de la vitesse à laquelle le moteur du serveur Web peut fournir ce fichier en cache (et aussi de la distance physique qui vous sépare du serveur). Si vous êtes sur le même continent (ou proche) du serveur, cette valeur devrait être d’environ 200 ms ou moins. Si vous êtes de l’autre côté de la planète, cette valeur devrait se situer entre 300 et 500 ms. Tout ce qui est supérieur à 500 ms pour les pages en cache signifie généralement que votre serveur n’arrive pas à suivre.
- Si la page n’est pas mise en cachealors le TTFB que vous avez trouvé est une indication de la vitesse à laquelle le serveur peut préparer le PHP de votre page (plus la distance entre vous et le serveur, comme décrit ci-dessus). Pour les pages non mises en cache, plus ce traitement est rapide, moins il est gourmand en ressources CPU et mieux votre site évoluera. Il est donc fortement recommandé de réduire ce délai à 500 ms ou 1 s en suivant les étapes ci-dessous pour alléger un processus PHP lourd.
Si vous pensez avoir *besoin* de cette demande dynamique pour la fonctionnalité dont vous avez besoin sur le site, alors j’ai bien peur que votre site ait besoin de plus de puissance, comme migrer vers un VPS, ou si vous avez déjà un VPS, acheter un cœur de CPU supplémentaire et/ou plus de mémoire.
Comment alléger un processus PHP lourd
Malheureusement, la seule façon de résoudre les problèmes liés à un processus lourd est de déterminer quel code est à l’origine de cette lourdeur et de le supprimer. Il s’agit d’un processus fastidieux qui consiste à désactiver des plugins, à changer de thème et à tester les résultats après chaque changement. Une fois que vous avez déterminé la source du problème, vous devez trouver une option de remplacement plus légère pour ce thème, ce plugin ou ce code personnalisé. Vous devrez probablement en essayer d’autres jusqu’à ce que vous en trouviez une qui n’alourdisse pas le temps de chargement de la page.
Conseil : si vous avez réussi à alléger le traitement PHP en trouvant le code responsable et en le supprimant ou en le remplaçant, et que ce code affectait les performances de l’ensemble du site, il est probable qu’il affectait également les performances de certaines fonctionnalités que nous vous avons recommandé de désactiver ci-dessus. Par exemple, les paniers WooCommerce globaux peuvent maintenant fonctionner plus efficacement et être réactivés sans effet négatif.
Vous voulez que nous fassions le gros du travail pour vous ?
Aucun problème ! La plupart des optimisations et réparations des performances sont couvertes par notre forfait de 149 $, mais certaines peuvent être un peu plus complexes. Contactez nous aujourd’hui et nous commencerons à accélérer votre site!GET OPTIMIZED