Un site WordPress lent peut avoir de nombreuses causes. De grandes images, trop de plugins ou des plugins mal programmés, des requêtes de base de données lentes, des services externes, un manque de mise en cache, WP-Cron, des processus PHP ou des ressources d'hébergement surchargées peuvent influencer le temps de chargement individuellement ou collectivement.
C'est pourquoi il n'existe pas de solution universelle sérieuse du type „ Installez ce seul plugin de performance et WordPress sera rapide “. Avant d'optimiser, vous devez découvrir, quelle partie du site Web est réellement lente.
Une bonne analyse des performances distingue par exemple une réponse lente du serveur, un traitement WordPress complexe et un frontal qui est ralenti dans le navigateur par des images, du JavaScript, du CSS, des polices web ou des services externes.
En bref : Mesure d'abord, avant d'optimiser. Si la première réponse du serveur est déjà lente, tu dois examiner PHP, la base de données, les extensions, les processus WordPress et les ressources d'hébergement. Si la page HTML arrive rapidement, mais que le navigateur met ensuite du temps à l'afficher, les causes se situent plutôt du côté des images, du CSS, du JavaScript, des polices ou des ressources externes.
Que signifie réellement „ WordPress est lent “ ? #
Cette déclaration peut décrire des problèmes très différents.
Il se peut que le site public mette plusieurs secondes avant qu'il ne se passe quoi que ce soit. Il se peut que la page s'affiche rapidement, mais que les images et autres éléments mettent du temps à charger. Dans d'autres cas, seul l'espace d'administration WordPress est lent ou seul le module de paiement WooCommerce réagit avec du retard.
Ces situations n'ont pas nécessairement la même cause.
C'est pourquoi une optimisation des performances devrait toujours commencer par une description aussi précise que possible du problème.
Considérer le Front-end et l'espace d'administration WordPress séparément #
Un site web peut être rapide sur le front-end tout en ayant une zone d'administration lente.
C'est tout à fait possible d'un point de vue technique. Les pages publiques peuvent par exemple être servies à partir d'un cache de pages, tandis que les requêtes au sein de :
/wp-admin/
doivent être traités dynamiquement par WordPress et PHP.
Si seule la zone d'administration est lente, vous ne devez par conséquent pas automatiquement optimiser les images de la page d'accueil. Inversement, une image principale lente n'explique pas nécessairement un éditeur WordPress poussif.
Le temps de chargement se compose de plusieurs sections. #
Lors du chargement d'une page WordPress, plusieurs choses se produisent, pour faire simple.
Le navigateur doit atteindre le domaine et établir une connexion. Le serveur web traite la requête. Si la page ne peut pas déjà être fournie par un cache, PHP lance l'application WordPress. WordPress charge entre autres les extensions et le thème, exécute des requêtes de base de données et génère le document HTML.
Ce n'est qu'ensuite qu'une autre partie importante commence dans le navigateur : le HTML est traité et les ressources supplémentaires telles que les feuilles de style, le JavaScript, les images et les polices sont chargées.
Une indication globale telle que „ la page se charge en quatre secondes “ ne dit donc pas encore à quel endroit ce temps est perdu.
Qu'est-ce que le TTFB ? #
TTFB signifie Temps jusqu'au premier octet. En termes simplifiés, cette mesure indique le temps nécessaire pour que le premier octet de la réponse du serveur arrive chez le client après une requête.
Un TTFB élevé peut être le signe de problèmes côté serveur. Cependant, il ne prouve pas automatiquement que le serveur d'hébergement est trop lent.
Plusieurs facteurs peuvent influencer le temps mesuré, notamment le réseau, l'établissement de la connexion, le traitement par le serveur et, dans le cas d'un site WordPress dynamique, le traitement nécessaire par PHP et la base de données.
Important : Un TTFB élevé et un rendu visuel lent ne sont pas la même chose. Un site WordPress peut répondre rapidement côté serveur et sembler néanmoins lent par la suite en raison de ressources front-end volumineuses.
Le cache de pages transforme fondamentalement les performances de WordPress #
Sans cache de page, WordPress doit généralement exécuter PHP pour un affichage de page normal, charger WordPress, prendre en compte les plugins et le thème, effectuer des requêtes dans la base de données et générer du HTML à partir de cela.
Un cache de pages peut stocker du HTML déjà généré et le servir à nouveau lors de requêtes appropriées.
Cela évite à WordPress de devoir répéter l'intégralité du processus dynamique à chaque affichage de page anonyme.
Cela peut faire une différence de performance considérable, en particulier sur les pages de contenu normales.
Toutes les pages ne doivent pas être mises en cache de la même manière #
Sur les sites web dynamiques, la mise en cache doit être utilisée de manière ciblée.
Un panier d'achat WooCommerce, une page de validation de commande ou un espace membre personnalisé ne peuvent par exemple pas être traités simplement comme un article de blog public.
Même les utilisateurs connectés ont besoin de contenus individuels selon l'application.
Une mauvaise configuration du cache peut donc être rapide, mais causer simultanément des erreurs fonctionnelles ou des contenus incorrects.
Le cache n'est pas une réparation pour du code lent #
La mise en cache des pages peut accélérer considérablement de nombreuses pages publiques. Elle ne doit cependant pas être utilisée pour masquer complètement des problèmes fondamentaux.
Lorsqu'une requête WordPress non mise en cache prend énormément de temps, cela peut être dû, par exemple, à des extensions inefficaces, à des problèmes de base de données ou à des appels d'API externes.
Ces causes peuvent également se produire dans la zone d'administration, pour les utilisateurs connectés, lors du paiement ou pour les requêtes non mises en cache.
Conseil pratique : Lors d'une analyse de performance, vérifiez si possible à la fois un chargement de page normal en cache et les zones traitées dynamiquement. Une page d'accueil rapide ne prouve pas que l'ensemble de l'application WordPress est rapide.
Les extensions peuvent ralentir considérablement WordPress #
Le nombre pur de plugins installés n'est pas un indicateur de performance fiable.
Un site web doté de 30 extensions légères peut fonctionner plus rapidement qu'un site web doté de cinq extensions très complexes.
Ce qui est décisif, c'est, ce qu'un plugin fait réellement lors d'une requête.
Par exemple, un plugin peut générer de nombreuses requêtes de base de données, contacter des services externes, charger de grandes quantités de JavaScript ou effectuer des opérations gourmandes en calcul à chaque chargement de page.
„ Trop de plugins “ est un diagnostic trop imprécis #
La recommandation de se contenter de supprimer le plus de plugins possible est donc insuffisante.
Si WordPress est lent, vous devez identifier les extensions qui posent réellement problème.
Les extensions dont les performances ont nettement changé après leur installation ou leur mise à jour sont particulièrement intéressantes.
Vous devriez également vérifier les extensions qui se chevauchent sur le plan fonctionnel. Plusieurs plugins pour la même tâche peuvent non seulement générer une complexité inutile, mais aussi s'influencer mutuellement.
Nous vous expliquons comment tester de manière contrôlée des extensions les unes contre les autres sous Détecter et résoudre les conflits de plugins ou de thèmes dans WordPress.
Le thème influence également le temps de chargement #
Le thème actif détermine une partie essentielle de l'affichage du frontend. Il peut charger des feuilles de style, du JavaScript, des polices, des images et des fonctionnalités supplémentaires.
Un thème très volumineux peut par conséquent nécessiter plus de ressources qu'un thème léger.
Cependant, cela ne signifie pas qu'un thème minimaliste rend automatiquement chaque site WordPress rapide. Les page builders, les extensions, les images et les fonctionnalités personnalisées peuvent toujours représenter la majeure partie de la charge.
Le thème et le reste du site web doivent donc être examinés ensemble.
Évaluer les Page Builders de manière nuancée #
Les constructeurs de pages permettent des mises en page complexes, mais ils peuvent générer du HTML, du CSS et du JavaScript supplémentaires.
Que cela pose problème en pratique dépend fortement de la manière dont le site web a été conçu.
De nombreux conteneurs imbriqués, animations, curseurs, vidéos, grandes images d'arrière-plan et de nombreux widgets peuvent rendre une page nettement plus lourde.
Au lieu de rejeter la faute globalement sur le Page Builder, tu devrais analyser quelles ressources et quels éléments sont réellement chargés sur la page en question.
Les images comptent parmi les freins les plus fréquents du frontend #
Une photo haute résolution provenant directement d'un appareil photo ou d'un smartphone peut peser plusieurs mégaoctets. Si une telle image est utilisée telle quelle sur un site web, le visiteur doit transférer ces données, bien que l'image ne soit peut-être affichée qu'avec une largeur de quelques centaines de pixels.
C'est pourquoi les images doivent être correctement dimensionnées et compressées de manière judicieuse.
Les formats d'image modernes peuvent réduire davantage la quantité de données transférées, à condition qu'ils correspondent au site Web respectif et à la prise en charge du navigateur.
Les dimensions de l'image et la taille du fichier ne sont pas la même chose #
Une image peut par exemple avoir des dimensions de :
5000 × 3333 pixels
posséder, bien que sur le site Web ce soit seulement avec :
800 × 533 pixels
s'affiche.
La simple réduction visuelle par CSS ne réduit pas automatiquement le fichier image d'origine qui doit être transféré.
C'est pourquoi les dimensions des images doivent déjà correspondre à leur utilisation réelle.
Utiliser le chargement différé à bon escient #
Les images et autres ressources situées bien en dessous de la zone initialement visible ne doivent pas toujours être chargées immédiatement.
Le chargement différé (Lazy Loading) permet de charger ces ressources au moment où elles sont nécessaires.
Cela réduit le volume de données initial.
Cependant, une image importante située dans la zone directement visible ne doit pas être artificiellement retardée sans réflexion. L'optimisation des performances ne signifie pas qu'il faille systématiquement charger chaque ressource le plus tard possible.
JavaScript peut ralentir l'affichage #
Les sites Web WordPress modernes utilisent souvent JavaScript pour la navigation, les diaporamas, les formulaires, le suivi, les systèmes de consentement, les constructeurs de pages et bien d'autres fonctionnalités.
Un JavaScript trop important ou mal chargé peut retarder le traitement dans le navigateur.
En particulier sur les appareils mobiles plus lents, ce n'est pas seulement la taille des fichiers qui importe. Le JavaScript doit être téléchargé, analysé et exécuté.
C'est pourquoi un fichier plus petit peut tout de même coûter cher s'il génère beaucoup de travail de calcul.
Retarder le JavaScript – mais de manière contrôlée #
Les extensions de performance proposent souvent des fonctionnalités telles que le chargement différé ou différé du JavaScript.
Cela peut améliorer l'affichage initial, mais ne doit pas être activé aveuglément.
Si les scripts dépendants sont chargés dans le mauvais ordre, des menus, des formulaires, des curseurs ou d'autres éléments interactifs peuvent par exemple tomber en panne.
Après de telles optimisations, vous devriez donc toujours tester les fonctionnalités principales du site Web.
Le CSS peut également devenir un goulot d'étranglement #
Les grandes feuilles de style ou les nombreux fichiers CSS différents augmentent la charge de travail du navigateur.
Le CSS nécessaire au rendu initial, mais disponible tardivement, peut s'avérer particulièrement problématique.
Cependant, même ici, le nombre de fichiers le plus faible possible n'est pas automatiquement le seul objectif. Les protocoles de transfert modernes et les mécanismes de cache modifient l'évaluation par rapport aux anciennes règles d'optimisation.
Ce qui est déterminant, c'est le comportement de chargement réel du site Web.
Les polices Web coûtent des requêtes supplémentaires #
Les polices Web personnalisées peuvent améliorer le design, mais elles génèrent des ressources supplémentaires.
Un nombre particulièrement élevé de familles de polices, de graisses de polices et de services de polices externes peut augmenter le temps de chargement.
Vérifiez par conséquent quelles variantes de police sont réellement utilisées.
Si des services de polices externes sont utilisés, il faut tenir compte non seulement des performances, mais aussi des exigences en matière de protection des données.
Les services externes peuvent ralentir un site web rapide #
Toutes les ressources d'un site WordPress ne sont pas chargées depuis son propre serveur.
Les composants externes typiques sont, par exemple, les services d'analyse et de suivi, les cartes, les vidéos, les widgets de réseaux sociaux, les réseaux publicitaires, les systèmes de chat ou les polices externes.
Les performances de ces services échappent en partie au contrôle du propre serveur WordPress.
Si une page répond rapidement côté serveur mais met du temps à se charger dans le navigateur, vous devriez par conséquent également analyser les requêtes tierces.
Ne pas sous-estimer les vidéos intégrées #
Une vidéo intégrée peut charger des fichiers JavaScript supplémentaires, des images de aperçu, des connexions et d'autres ressources d'un fournisseur tiers.
Cet effet peut se multiplier avec plusieurs vidéos.
Selon le site web, il peut être judicieux de ne charger complètement les médias externes qu'après une interaction de l'utilisateur.
La base de données WordPress comme facteur de performance #
WordPress stocke les contenus, les paramètres et de nombreuses données de plugins dans une base de données relationnelle.
Lors d'un chargement de page, WordPress, le thème et les plugins exécutent des requêtes sur cette base de données.
La seule taille de la base de données n'est pas automatiquement décisive. Une grande base de données judicieusement structurée peut fonctionner sans problème, tandis qu'une base de données plus petite peut poser des problèmes de performance en raison de requêtes inefficaces.
Identifier les requêtes de base de données lentes #
Lorsqu'une requête WordPress dynamique est lente, des requêtes de base de données individuelles peuvent y contribuer de manière significative.
Les extensions, en particulier celles dotées de fonctions complexes de recherche, de filtrage, de statistiques ou de rapports, peuvent générer des requêtes exigeantes.
Une analyse professionnelle ne devrait donc pas seulement se demander quelle est la taille de la base de données, mais quelles requêtes prennent réellement du temps et à quelle fréquence elles sont exécutées.
wp_options et le chargement automatique #
La table des options WordPress contient les données de configuration de WordPress et des extensions. Certaines options sont chargées automatiquement lors de nombreuses requêtes WordPress.
Si des plugins y laissent des données de chargement automatique très volumineuses ou inutiles, cela peut nuire aux performances.
Cependant, de telles entrées ne devraient pas être supprimées de manière aléatoire de la base de données sur la base de leur nom.
Attention : Les „ nettoyages “ de base de données peuvent supprimer définitivement des paramètres ou des données de plugins. Créez une sauvegarde avant toute intervention manuelle et ne supprimez que les données dont la fonction et l'origine ont été clairement identifiées.
Transitoires et données temporaires #
WordPress et ses extensions peuvent utiliser des "transients" pour stocker temporairement des données en cache.
Les transients ne constituent fondamentalement pas une erreur et font partie du mécanisme normal de WordPress.
Les implémentations erronées ou les quantités inhabituellement grandes de données temporaires peuvent s'avérer problématiques.
Cependant, la suppression globale de tous les transients n'est pas une stratégie de performance durable. S'ils réapparaissent immédiatement en quantité problématique, la cause doit être étudiée.
Les révisions ne sont pas automatiquement le problème #
WordPress peut enregistrer les versions antérieures des articles et des pages sous forme de révisions.
Sur les sites web exploités de longue date, cela peut générer un grand nombre d'enregistrements.
Cela ne signifie pas pour autant que quelques centaines ou milliers de révisions sont automatiquement la cause de la lenteur d'un site web.
Une base de données doit être optimisée sur la base de mesures réelles et non sur des hypothèses générales.
Différencier le cache d'objets et le cache de pages #
Le cache de pages et le cache d'objets résolvent des tâches différentes.
Un cache de page stocke, pour faire simple, des affichages de pages déjà générés. En revanche, un cache d'objets persistant permet de stocker temporairement des résultats et des données dont WordPress a besoin lors de son traitement, au-delà de requêtes individuelles.
Des technologies telles que Redis peuvent être utilisées comme backend pour un cache d'objets persistant.
Cela peut s'avérer particulièrement utile pour les applications WordPress dynamiques avec des accès répétés à la base de données.
Cependant, un cache d'objets ne remplace pas un cache de page et ne supprime pas non plus un code mal programmé.
WooCommerce a des exigences différentes de celles d'un blog #
Un blog simple se compose principalement de contenus accessibles publiquement. De nombreuses pages peuvent par conséquent être mises en cache très efficacement.
En revanche, une boutique WooCommerce comporte de nombreuses opérations dynamiques. Le panier, la commande, le compte client, les stocks, les prix et d'autres fonctionnalités peuvent dépendre de l'utilisateur ou de l'état.
C'est pourquoi la performance sous WooCommerce doit être examinée de manière plus nuancée.
Par exemple, une page d'accueil de boutique extrêmement bien mise en cache dit peu de choses sur la rapidité avec laquelle le tunnel d'achat ou une recherche de produits complexe est traitée.
wp-admin lent : vérifier les extensions et les processus en arrière-plan #
Si seul l'espace d'administration de WordPress est lent, vous devriez examiner quels processus s'y déroulent.
Les extensions peuvent charger des widgets de tableau de bord, contacter des serveurs de licence externes, calculer des statistiques ou traiter des données en arrière-plan.
Un grand nombre de requêtes AJAX ou REST administratives peut également s'avérer pertinent.
Puisque la zone d'administration ne peut généralement pas être entièrement mise en cache comme une page publique, les processus inefficaces y sont particulièrement visibles.
classer correctement admin-ajax.php #
WordPress et les plugins peuvent modifier le fichier :
wp-admin/admin-ajax.php
für AJAX-Anfragen verwenden.
Viele Zugriffe darauf sind nicht automatisch problematisch. Wenn jedoch sehr häufige oder besonders langsame AJAX-Anfragen auftreten, sollte geprüft werden, welche Funktion beziehungsweise welches Plugin sie auslöst.
Das bloße Blockieren von admin-ajax.php ist keine sinnvolle allgemeine Performance-Lösung und kann Funktionen der Website beschädigen.
WordPress REST API nicht pauschal deaktivieren #
WordPress und moderne Plugins verwenden die REST API für zahlreiche Funktionen.
Sie aus Performance-Gründen vollständig zu deaktivieren, kann den Block-Editor oder Erweiterungen beeinträchtigen.
Wenn REST-Anfragen auffällig viel Last erzeugen, sollte die verursachende Anwendung beziehungsweise Route identifiziert werden.
WP-Cron kann die Performance beeinflussen #
WordPress verwendet standardmäßig WP-Cron, um geplante Aufgaben auszuführen.
Dazu gehören je nach Website beispielsweise geplante Beiträge, Wartungsaufgaben und von Plugins registrierte Hintergrundjobs.
Bei jedem Seitenaufruf kann WordPress prüfen, ob geplante Aufgaben fällig sind.
Wenn sehr viele oder besonders aufwendige Cron-Aufgaben anstehen, kann dies die Website belasten.
Entscheidend ist deshalb nicht nur, dass WP-Cron existiert, sondern welche Aufgaben darüber ausgeführt werden und wie lange diese benötigen.
WP-Cron durch einen echten Cronjob ersetzen #
Auf geeigneten Hosting-Umgebungen kann es sinnvoll sein, den WordPress-internen Cron-Aufruf nicht bei normalen Seitenaufrufen anzustoßen, sondern kontrolliert über einen serverseitigen Cronjob auszuführen.
Dafür kann WordPress beispielsweise mit:
DISABLE_WP_CRON
entsprechend konfiguriert werden.
Das sollte jedoch nur geschehen, wenn anschließend tatsächlich ein zuverlässiger externer Cronjob eingerichtet wird.
Attention : WP-Cron einfach zu deaktivieren, ohne einen Ersatz einzurichten, kann geplante WordPress- und Plugin-Aufgaben verhindern.
PHP-Version beeinflusst WordPress-Performance #
WordPress wird serverseitig überwiegend mit PHP ausgeführt. Die verwendete PHP-Version beeinflusst deshalb Kompatibilität, Sicherheit und Performance.
Eine aktuelle, von WordPress und den eingesetzten Erweiterungen unterstützte PHP-Version ist grundsätzlich sinnvoll.
Du solltest eine PHP-Version aber nicht ausschließlich deshalb wechseln, weil eine höhere Versionsnummer vermeintlich automatisch jede Website schneller macht.
Vor einem Wechsel müssen Plugins, Theme und individueller Code kompatibel sein.
Nous vous expliquons comment procéder sous Modifier la version PHP pour WordPress et vérifier la compatibilité.
PHP Memory Limit und Performance unterscheiden #
Das PHP Memory Limit bestimmt, wie viel Arbeitsspeicher ein einzelner PHP-Prozess beziehungsweise eine PHP-Ausführung innerhalb der jeweiligen Konfiguration verwenden darf.
Erreicht WordPress dieses Limit, kann ein Fehler wie:
Taille de mémoire autorisée ... épuisée
survenir.
Ein höheres Memory Limit macht eine normal funktionierende WordPress-Seite jedoch nicht automatisch schneller.
Wenn ein Plugin ungewöhnlich viel Speicher verbraucht, kann eine Erhöhung des Limits außerdem lediglich das Symptom verschieben.
Die Unterschiede erklären wir ausführlich unter Limite de mémoire PHP dans WordPress : identifier et corriger l'erreur.
PHP OPcache #
PHP-Code muss für die Ausführung verarbeitet werden. OPcache kann bereits kompilierten PHP-Bytecode im Arbeitsspeicher zwischenspeichern, sodass PHP-Dateien nicht bei jeder Anfrage vollständig neu kompiliert werden müssen.
Auf modernen PHP-Hosting-Umgebungen ist OPcache deshalb ein wichtiger Bestandteil der serverseitigen Performance.
Als WordPress-Benutzer musst du daran normalerweise nicht ständig Änderungen vornehmen. Bei einer technischen Performance-Analyse gehört die PHP-Laufzeitumgebung jedoch zum Gesamtbild.
Hosting-Ressourcen können zum Flaschenhals werden #
Auch eine technisch gut optimierte WordPress-Website benötigt Rechenleistung, Arbeitsspeicher, Datenbankleistung und I/O-Ressourcen.
Wenn eine Website dauerhaft mehr Ressourcen benötigt, als ihre Umgebung bereitstellen kann, können Anfragen langsamer verarbeitet werden.
Das betrifft beispielsweise stark frequentierte Websites, umfangreiche WooCommerce-Shops oder Websites mit ressourcenintensiven Plugins.
Bei CURIAWEB verwenden unsere WordPress-Hosting-Angebote eine für WordPress ausgelegte Hosting-Umgebung. Trotzdem sollte bei einem konkreten Performance-Problem immer zuerst geprüft werden, welche Ressource tatsächlich limitiert, statt pauschal mehr Serverleistung als Lösung anzunehmen.
CloudLinux-Ressourcen richtig interpretieren #
In einer CloudLinux-Hosting-Umgebung können Ressourcen eines Hosting-Accounts kontrolliert begrenzt werden. Dadurch kann ein einzelner Account nicht unbegrenzt Ressourcen des gesamten Servers beanspruchen.
Wenn eine WordPress-Website wiederholt an solche Limits stößt, ist das eine wichtige Diagnoseinformation.
Entscheidend ist jedoch, quel Limit erreicht wird und warum.
Ein plötzlich stark erhöhter Ressourcenverbrauch kann beispielsweise durch ein problematisches Plugin, Bots, Cronjobs oder ungewöhnlich viele dynamische Anfragen verursacht werden. Ein größeres Hosting-Paket würde in einem solchen Fall möglicherweise nur mehr Spielraum schaffen, ohne die Ursache zu beseitigen.
CPU-Auslastung #
PHP-Code, Datenbankoperationen und andere Prozesse benötigen CPU-Zeit.
Wenn eine Website dauerhaft rechenintensive Aufgaben ausführt, kann die CPU zum Engpass werden.
Besonders interessant ist dabei, ob die hohe Last permanent oder nur zu bestimmten Zeiten auftritt.
Wiederkehrende Lastspitzen können beispielsweise auf Cronjobs, Backups, Imports, Scans oder Bots hindeuten.
I/O und Festplattenzugriffe #
WordPress liest und schreibt Dateien und Daten. Auch Plugins können große Mengen an Dateioperationen verursachen.
Backups, Bildverarbeitung, Sicherheits-Scans, Imports und umfangreiche Logdateien sind Beispiele für Prozesse, die I/O-Ressourcen beanspruchen können.
Schneller NVMe-Speicher ist hilfreich, kann aber ineffiziente oder unnötig häufige Dateioperationen nicht vollständig kompensieren.
PHP-Prozesse und gleichzeitige Anfragen #
Bei dynamischen Seitenaufrufen muss PHP Anfragen verarbeiten. Erreichen sehr viele nicht gecachte Anfragen gleichzeitig die Website, können verfügbare Prozesse beziehungsweise Worker zum Engpass werden.
Das ist einer der Gründe, warum effizientes Page Caching bei öffentlich cachebaren Inhalten so wirkungsvoll sein kann: Nicht jeder Besucher benötigt dann eine vollständige neue WordPress-Ausführung.
Bots können WordPress belasten #
Nicht jeder Website-Aufruf stammt von einem echten Besucher.
Suchmaschinen, SEO-Tools, Monitoring-Dienste, KI-Crawler, Sicherheits-Scanner und unerwünschte Bots können ebenfalls Anfragen erzeugen.
Besonders aggressive Bots können dynamische URLs in hoher Frequenz aufrufen und dadurch PHP sowie Datenbank belasten.
Bei unerklärlichen Lastspitzen lohnt sich deshalb auch ein Blick auf Access Logs und die angeforderten URLs.
wp-login.php und automatisierte Login-Versuche #
Öffentlich erreichbare WordPress-Websites erhalten häufig automatisierte Anfragen auf:
wp-login.php
Eine große Zahl solcher Anfragen kann zusätzliche Ressourcen beanspruchen.
Geeignete Sicherheitsmechanismen können unerwünschte Login-Versuche begrenzen. Die Login-Datei einfach zu löschen oder WordPress-Core-Dateien zu verändern, ist dagegen keine Lösung.
XML-RPC als mögliche Quelle von Requests #
Je nach Konfiguration und verwendeten Funktionen kann:
xmlrpc.php
Anfragen erhalten.
Ob XML-RPC benötigt wird, hängt von der konkreten Website und eingesetzten Diensten ab.
Statt die Funktion pauschal aufgrund allgemeiner Performance-Empfehlungen zu deaktivieren, solltest du zunächst prüfen, ob dort tatsächlich relevante Last entsteht und ob abhängige Funktionen existieren.
Backups können temporär Ressourcen benötigen #
Ein vollständiges WordPress-Backup muss möglicherweise viele Dateien lesen, Archive erstellen und Datenbankinhalte exportieren.
Bei großen Websites kann das spürbare Ressourcenlast verursachen.
Wenn WordPress beispielsweise jeden Tag zu einer bestimmten Uhrzeit langsam wird, solltest du deshalb prüfen, ob zu diesem Zeitpunkt Backups oder andere geplante Wartungsaufgaben laufen.
Sicherheits-Scans benötigen ebenfalls Leistung #
Ein Security-Plugin, das tausende Dateien untersucht, benötigt zwangsläufig Ressourcen.
Das bedeutet nicht, dass Sicherheits-Scans grundsätzlich schlecht sind. Ihre Häufigkeit und Ausführung sollten jedoch zur Website und Hosting-Umgebung passen.
Wenn Performance-Probleme immer während eines Scans auftreten, ist der zeitliche Zusammenhang ein wichtiger Hinweis.
Logdateien können unbemerkt sehr groß werden #
Fehlerhafte Plugins oder dauerhaft aktiviertes Debugging können große Logdateien erzeugen.
Eine bekannte WordPress-Debugdatei ist beispielsweise:
wp-content/debug.log
Wenn ein Fehler bei jedem Seitenaufruf mehrfach protokolliert wird, kann diese Datei schnell wachsen.
Debugging sollte deshalb zur Diagnose kontrolliert verwendet und anschließend wieder passend konfiguriert werden.
Nous expliquons cela plus en détail sous Activer le débogage WordPress et utiliser les journaux d'erreurs.
Eine langsame externe API kann WordPress blockieren #
Plugins kommunizieren teilweise während einer Anfrage mit externen Diensten.
Wenn WordPress auf die Antwort eines langsamen oder nicht erreichbaren externen Servers wartet, kann die eigene Website verzögert reagieren.
Das ist besonders tückisch, weil der eigene Server technisch einwandfrei funktionieren kann.
Wenn Performance-Probleme sporadisch auftreten, können externe HTTP-Anfragen deshalb ebenfalls untersucht werden.
DNS und Netzwerk nicht mit WordPress verwechseln #
Bevor der Browser WordPress überhaupt erreicht, muss die Domain aufgelöst und eine Verbindung zum Server hergestellt werden.
Probleme auf dieser Ebene sind keine WordPress-Performance-Probleme im engeren Sinn.
Eine vollständige Analyse betrachtet deshalb auch, ob die Verzögerung bereits vor der eigentlichen Serververarbeitung entsteht.
CDN: sinnvoll, aber nicht automatisch notwendig #
Ein Content Delivery Network kann statische Ressourcen über geografisch verteilte Systeme bereitstellen und je nach Konfiguration weitere Optimierungen übernehmen.
Das kann insbesondere bei einem international verteilten Publikum sinnvoll sein.
Ein CDN repariert jedoch keine langsame PHP-Funktion, keine ineffiziente Datenbankabfrage und kein fehlerhaftes Plugin.
Bei einer hauptsächlich regionalen Zielgruppe sollte deshalb geprüft werden, welches konkrete Problem durch ein CDN gelöst werden soll.
Viele HTTP-Requests sind nicht automatisch schlecht #
Ältere Performance-Anleitungen konzentrieren sich häufig stark darauf, die Anzahl einzelner Dateien möglichst drastisch zu reduzieren.
Die Zahl der Requests bleibt relevant, sollte aber nicht isoliert betrachtet werden.
Dateigröße, Priorisierung, Cachebarkeit, Übertragungsprotokoll und Verarbeitungsaufwand im Browser spielen ebenfalls eine Rolle.
Eine einzelne riesige JavaScript-Datei ist nicht automatisch besser als mehrere sinnvoll strukturierte kleinere Ressourcen.
Core Web Vitals richtig einordnen #
Bei der wahrgenommenen Nutzererfahrung sind nicht nur Sekunden bis zum vollständigen Laden relevant.
Moderne Performance-Messungen betrachten unter anderem, wann der wichtigste sichtbare Inhalt erscheint, wie schnell eine Seite auf Interaktionen reagiert und ob sich das Layout während des Ladens unerwartet verschiebt.
Deshalb kann eine Website trotz akzeptabler Gesamt-Ladezeit eine schlechte Nutzererfahrung bieten.
LCP – Largest Contentful Paint #
Der Largest Contentful Paint betrachtet vereinfacht, wann ein großes beziehungsweise wichtiges Inhaltselement im sichtbaren Bereich dargestellt wird.
Häufig handelt es sich dabei um ein großes Bild, eine Überschrift oder einen anderen prominenten Inhalt.
Ist beispielsweise das Hero-Bild sehr groß oder wird unnötig verzögert geladen, kann dies den LCP verschlechtern.
INP – Interaction to Next Paint #
Interaction to Next Paint betrachtet die Reaktionsfähigkeit einer Seite auf Benutzerinteraktionen über den Besuch hinweg.
Aufwendiges JavaScript kann beispielsweise dazu führen, dass der Browser nach einem Klick oder einer anderen Interaktion nicht schnell genug reagieren kann.
Eine schnelle Serverantwort allein garantiert deshalb noch keine gute Interaktionsperformance.
CLS – Cumulative Layout Shift #
Cumulative Layout Shift bewertet unerwartete Layoutverschiebungen.
Wenn beispielsweise ein Bild zunächst ohne reservierten Platz geladen wird und anschließend den restlichen Inhalt nach unten verschiebt, kann das die visuelle Stabilität beeinträchtigen.
Auch nachträglich geladene Banner, Fonts oder andere Elemente können dazu beitragen.
Labordaten und echte Nutzerdaten unterscheiden #
Performance-Tools können Tests unter kontrollierten Bedingungen durchführen. Diese sogenannten Labordaten sind hervorragend für reproduzierbare Analysen geeignet.
Echte Besucher verwenden jedoch unterschiedliche Geräte, Browser und Netzwerkverbindungen.
Felddaten beziehungsweise reale Nutzerdaten können deshalb ein anderes Bild zeigen.
Beide Perspektiven sind nützlich und sollten nicht miteinander verwechselt werden.
Ein einzelner Speed-Test reicht nicht #
Performance-Messungen können schwanken.
Cache-Zustand, Netzwerk, externe Dienste und Hintergrundprozesse beeinflussen das Ergebnis.
Deshalb solltest du nicht aufgrund eines einzigen Tests umfangreiche Änderungen an einer Website vornehmen.
Mehrere Messungen unter vergleichbaren Bedingungen liefern eine bessere Grundlage.
Conseil pratique : Dokumentiere vor größeren Optimierungen einen Ausgangswert. Ändere anschließend möglichst nur einen relevanten Bereich und miss erneut. So kannst du feststellen, ob eine Maßnahme tatsächlich geholfen hat.
Startseite allein ist kein ausreichender Test #
Eine WordPress-Website besteht häufig aus sehr unterschiedlichen Seitentypen.
Für eine aussagekräftige Analyse solltest du beispielsweise auch einen normalen Beitrag, eine wichtige Landingpage und bei WooCommerce eine Produktseite betrachten.
Wenn ausschließlich eine einzelne Seite langsam ist, liegt die Ursache möglicherweise im Aufbau genau dieser Seite und nicht in der gesamten WordPress-Installation.
Mobile Performance besonders beachten #
Eine Website, die auf einem leistungsstarken Desktop mit schneller Internetverbindung problemlos wirkt, kann auf einem durchschnittlichen Smartphone deutlich langsamer reagieren.
Große JavaScript-Mengen und aufwendige visuelle Effekte fallen auf schwächeren Geräten stärker ins Gewicht.
Performance sollte deshalb nicht ausschließlich vom eigenen Bürocomputer aus beurteilt werden.
Warum ein Performance-Score nicht das alleinige Ziel ist #
Tools verdichten komplexe Messwerte häufig zu einer Punktzahl.
Solche Scores sind hilfreich, sollten aber nicht zum Selbstzweck werden.
Eine Website sollte schnell, stabil und für reale Benutzer gut bedienbar sein. Eine technische Änderung, die lediglich einen Score verbessert, dafür aber eine wichtige Funktion beschädigt, ist keine erfolgreiche Optimierung.
WordPress regelmäßig aufräumen – aber gezielt #
Im Laufe der Zeit sammeln sich auf vielen Installationen nicht mehr verwendete Plugins, Themes, Medien, Testfunktionen und alte Konfigurationen an.
Nicht alles davon macht die Website unmittelbar langsam. Unnötige Komponenten erhöhen aber die Komplexität und können Wartung sowie Fehlersuche erschweren.
Nicht mehr benötigte Erweiterungen sollten deshalb nach vorheriger Prüfung sauber entfernt werden.
Updates können Performance-Probleme lösen #
Aktuelle WordPress-, Plugin- und Theme-Versionen enthalten nicht nur neue Funktionen und Sicherheitskorrekturen. Entwickler verbessern teilweise auch Performance und Kompatibilität.
Eine dauerhaft veraltete Installation ist deshalb keine sinnvolle Performance-Strategie.
Updates sollten bei wichtigen Websites kontrolliert und mit einer funktionierenden Backup- beziehungsweise Wiederherstellungsstrategie durchgeführt werden.
Wann ein Plugin ersetzt werden sollte #
Wenn eine Erweiterung dauerhaft unverhältnismäßig viele Ressourcen benötigt und keine Konfigurations- oder Update-Lösung existiert, kann ein Ersatz sinnvoll sein.
Entscheidend ist dabei nicht, welches Plugin in irgendeiner Bestenliste als „schnellstes“ bezeichnet wird, sondern welche Funktionen deine Website tatsächlich benötigt und wie die Alternative in deiner konkreten Umgebung arbeitet.
Wann mehr Hosting-Ressourcen sinnvoll sind #
Optimierung bedeutet nicht, dass jede Website mit minimalen Ressourcen betrieben werden muss.
Wenn eine technisch sauber aufgebaute Website aufgrund echten Traffics oder legitimer dynamischer Prozesse dauerhaft hohe Ressourcen benötigt, kann mehr Rechenleistung die richtige Lösung sein.
Vorher sollte jedoch ausgeschlossen werden, dass die Last hauptsächlich durch einen Fehler, Bots, einen außer Kontrolle geratenen Cronjob oder eine ineffiziente Erweiterung entsteht.
Performance-Probleme systematisch eingrenzen #
Beginne mit dem konkreten Symptom. Ist die gesamte Website langsam oder nur eine Seite? Betrifft es das Frontend, wp-admin oder beides? Ist bereits die Serverantwort langsam oder entstehen die Verzögerungen erst beim Laden und Verarbeiten der Frontend-Ressourcen?
Prüfe danach, ob das Problem dauerhaft oder nur zu bestimmten Zeiten auftritt. Ein wiederkehrendes Zeitmuster kann auf Backups, Cronjobs, Scans oder andere geplante Prozesse hindeuten.
Betrachte anschließend die letzten Änderungen. Wenn die Website direkt nach Installation eines Plugins, einem Update oder einer PHP-Änderung langsam geworden ist, besitzt du bereits einen wichtigen Anhaltspunkt.
Erst danach solltest du gezielt Plugins, Datenbankabfragen, externe Requests, Cache, PHP und Hosting-Ressourcen untersuchen.
Was du bei einer langsamen WordPress-Website besser nicht tun solltest #
Installiere nicht fünf Performance-Plugins gleichzeitig. Mehrere Systeme, die gleichzeitig Cache, CSS, JavaScript und Datenbank optimieren wollen, können neue Konflikte erzeugen und die Diagnose erschweren.
Lösche nicht wahllos Datenbanktabellen oder Optionen, nur weil ein Optimierungstool sie als groß markiert. Größe allein beweist kein Performance-Problem.
Wechsle außerdem nicht gleichzeitig Theme, PHP-Version, Cache-System und mehrere Plugins. Wenn die Website danach schneller ist, weißt du nicht, welche Maßnahme tatsächlich geholfen hat.
Und erhöhe Serverressourcen nicht automatisch, bevor du geprüft hast, warum die vorhandenen Ressourcen ausgeschöpft werden.
Règle de base : Erst messen, dann Ursache eingrenzen, anschließend gezielt optimieren und danach erneut messen. Performance-Optimierung ohne Vergleichswerte ist häufig nur Vermutung.
Quelles informations aident le support de CURIAWEB ? #
Wenn eine WordPress-Website bei CURIAWEB ungewöhnlich langsam ist, hilft eine möglichst genaue Beschreibung des Problems wesentlich mehr als die allgemeine Aussage „WordPress ist langsam“.
Teile beispielsweise mit, welche URL betroffen ist, ob das Problem auch im Adminbereich auftritt und seit wann du die Veränderung bemerkst. Wenn die Performance nur zu bestimmten Zeiten schlecht ist, ist auch der ungefähre Zeitpunkt wichtig.
Hilfreich ist außerdem zu wissen, ob unmittelbar zuvor Plugins, Themes, WordPress, PHP oder andere Einstellungen verändert wurden.
Bei auffälligen Ressourcenwerten oder Fehlermeldungen können wir anschließend gezielt prüfen, ob beispielsweise PHP, Datenbank, Prozesse oder Account-Ressourcen beteiligt sind.
N'envoyez pas de mots de passe non sollicités.
Résumé #
Eine langsame WordPress-Website hat selten nur eine mögliche Ursache. Serverantwort, PHP, Datenbank, Plugins, Theme, Cache, Bilder, JavaScript, CSS, externe Dienste und Hosting-Ressourcen beeinflussen unterschiedliche Teile der Ladezeit.
Deshalb sollte die Optimierung nicht mit dem Installieren eines beliebigen Performance-Plugins beginnen, sondern mit einer Messung und Eingrenzung des Problems.
Ist bereits die dynamische Serverantwort langsam, solltest du insbesondere PHP-Verarbeitung, Datenbankabfragen, Plugins, externe API-Aufrufe, Cronjobs und Hosting-Ressourcen untersuchen. Antwortet der Server schnell, während die Seite im Browser langsam aufgebaut wird, rücken Bilder, JavaScript, CSS, Fonts und Drittanbieter-Ressourcen stärker in den Fokus.
Page Cache und persistenter Object Cache können WordPress erheblich entlasten, lösen aber unterschiedliche Aufgaben und ersetzen keine saubere Anwendung. Auch mehr Serverleistung ist nur dann die richtige Lösung, wenn tatsächlich Ressourcen fehlen und nicht lediglich ein fehlerhafter Prozess unnötig Last erzeugt.
Eine nachhaltige WordPress-Optimierung folgt deshalb immer demselben Prinzip: messen, Ursache bestimmen, gezielt verändern und erneut messen.
