Eine schnellere WordPress-Website beginnt damit, die langsame Ebene zu finden
Eine langsame WordPress-Seite kann ihre Zeit an mehreren Stellen verbringen: beim Herunterladen von Bildern, beim Warten auf PHP, beim Abfragen der Datenbank oder beim Aufruf eines anderen Dienstes. Ein weiteres Cache-Plugin zu installieren, ohne die Verzögerung zu identifizieren, kann ein Problem verbergen und ein zweites schaffen. Beginnen Sie mit einem wiederholbaren Ablauf und einer kleinen Auswahl an Messungen.
Das Wichtigste in Kürze
Messen Sie den tatsächlich langsamen Ablauf, unterscheiden Sie zwischengespeicherte und personalisierte Antworten, ändern Sie jeweils nur eine Ebene und bestätigen Sie sowohl Geschwindigkeit als auch Korrektheit, bevor Sie eine Optimierung beibehalten.
Machen Sie aus „die Website ist langsam“ eine reproduzierbare Beobachtung
Wählen Sie eine Seite und beschreiben Sie den Besucherzustand genau. Ein Erstbesuch eines Artikels, ein wiederkehrender Kunde, der einen Warenkorb öffnet, und ein Administrator, der einen Beitrag speichert, beanspruchen unterschiedliche Teile von WordPress. Notieren Sie die URL, ob die Person angemeldet ist, die ungefähre Uhrzeit, das Gerät und das Zugangsnetzwerk. Wiederholen Sie denselben Ablauf, statt unzusammenhängende Seiten aus dem Gedächtnis zu vergleichen. Halten Sie private Kontodetails aus Screenshots und geteilten Diagnoseexporten heraus.
Trennen Sie die Wartezeit auf die erste Antwort von der danach ausgeführten Arbeit. Ein Browser kann HTML schnell empfangen und dennoch mehrere Sekunden mit dem Herunterladen überdimensionierter Bilder oder der Ausführung von Drittanbieter-Skripten verbringen. Umgekehrt kann eine optisch einfache Seite auf langsame serverseitige Arbeit warten. Notieren Sie Antwortdauer, übertragene Bytes und fehlgeschlagene Anfragen gemeinsam. Eine isolierte Bewertung ist weniger nützlich als zu wissen, welche Anfrage den Teil der Seite verzögert, den Besucher benötigen.
| Beobachtung | Erste zu untersuchende Ebene | Nützlicher Vergleich |
|---|---|---|
| HTML kommt verspätet an | PHP, Datenbank oder externe Aufrufe | Dieselbe URL mit demselben Anmeldestatus |
| HTML ist schnell, die Seite bleibt schwer | Bilder, Schriftarten und Browser-Skripte | Übertragungsgröße und der Anfrage-Wasserfall des Browsers |
| Nur angemeldete Besucher sind langsam | Personalisierte Anwendungsarbeit | Anonyme und angemeldete Abläufe getrennt |
| Eine Verzögerung tritt nach einem Update auf | Geänderte Komponente oder Konfiguration | Die erfasste Version und ein kontrolliertes Zurückrollen |
Wissen, was ein Cache tatsächlich wiederverwendet
Seiten-Caching kann eine erzeugte Antwort wiederverwenden, statt sie für jede Anfrage neu aufzubauen. Das ist nützlich für öffentliche Inhalte, die für viele Besucher gleich aussehen. Es erfordert bewusste Regeln für Anmeldeseiten, Warenkörbe, Checkout, Kontobildschirme und andere personalisierte Antworten. Eine schnelle Seite, die falsche Kundeninformationen zeigt, ist eine gescheiterte Optimierung. Testen Sie das Cache-Verhalten über getrennte Browsersitzungen und bestätigen Sie, dass private Seiten der vorgesehenen Behandlung durch die Anwendung folgen.
Objekt-Caching verwendet Anwendungsdaten wieder und ist eine andere Ebene als das Zwischenspeichern einer ganzen Seite. Browser-Caching bestimmt, was ein Besucher lokal wiederverwenden kann. Ein Content-Delivery-Cache kann an anderer Stelle im Anfragepfad liegen. Zeichnen Sie die Ebenen auf, die in Ihrer Installation tatsächlich existieren, einschließlich ihres Ablauf- und Löschverhaltens. Gehen Sie nicht davon aus, dass ein Control Panel, ein Plugin oder eine Hosting-Reihe einen bestimmten Cache-Dienst enthält, sofern die verfügbare Konfiguration dies nicht bestätigt.
Vergleichen Sie für einen öffentlichen Artikel die erste Anfrage nach einem Löschen mit späteren Anfragen. Ein großer Unterschied kann darauf hindeuten, dass Erzeugungsarbeit wiederverwendet wird; er beweist nicht, welche Ebene die Wiederverwendung durchgeführt hat. Prüfen Sie die relevanten Cache-Diagnosen oder Antwort-Header, sofern verfügbar. Testen Sie für einen Shop einen geänderten Produktpreis und einen aktualisierten Warenkorb getrennt. Eine korrekte Invalidierung ist ebenso wichtig wie ein Timing-Ergebnis bei warmem Cache.
Verfolgen Sie nicht zwischengespeicherte Arbeit, bevor Sie Ressourcen hinzufügen
Überprüfen Sie die am langsamen Ablauf beteiligten Komponenten. Ein Theme kann wiederholte Abfragen auslösen, ein Plugin einen entfernten Endpunkt aufrufen und eine geplante Aufgabe mit normalen Anfragen konkurrieren. Verwenden Sie für Ihre Umgebung geeignete Diagnosen und entfernen Sie temporäre Diagnosen nach der Untersuchung. Bevorzugen Sie eine Staging-Kopie zur Isolierung von Komponenten. Das Ändern mehrerer Plugins auf einer stark ausgelasteten Produktionsseite macht das Ergebnis schwerer interpretierbar und kann Inhalte oder Bestellungen stören.
Datenbankarbeit verdient eine eigene Untersuchung, wenn ungecachte Anfragen langsam bleiben. Erfassen Sie, welche Abfragen häufig oder teuer sind und ob die Anwendung dieselbe Suche unnötig wiederholt. Eine Indexänderung, ein kleineres Abfrageergebnis oder ein korrigiertes Plugin-Verhalten können mehr helfen als zusätzliche CPU. Wenn die Datenbank auf Sperren wartet, können zusätzliche PHP-Worker die Konkurrenz erhöhen statt den nutzbaren Durchsatz zu steigern. Interpretieren Sie Prozesszahlen zusammen mit Antwortdauer und erfolgreichen Anfragen.
Hosting-Ressourcen bleiben wichtig, wenn Messungen eine echte Einschränkung zeigen. Berücksichtigen Sie den Speicher der gesamten Anwendung, gleichzeitige PHP-Arbeit, Datenbankaktivität und Speicherwachstum. Die Webhosting-Karten von HM Bastion beschreiben Website-, Speicher- und Datenbanklimits; sie sind keine veröffentlichte Zahl garantiert gleichzeitiger Käufer. Wenn ein Projekt eigene Dienste oder Betriebssystemkontrolle benötigt, vergleichen Sie einen VPS anhand seiner tatsächlichen Ressourcen und der damit verbundenen Administrationsverantwortung.
Eine Änderung erst nach Prüfung des gesamten Ablaufs beibehalten
Notieren Sie die geplante Änderung und das erwartete Ergebnis, bevor Sie sie anwenden. Beispielsweise sollte die Größenanpassung überdimensionierter öffentlicher Bilder die übertragenen Bytes reduzieren, ohne den Artikelinhalt zu verändern. Der Ausschluss von Kontoseiten aus einem Seiten-Cache sollte die Privatsphäre wahren, auch wenn diese Seiten langsamer als öffentliche Inhalte bleiben. Bewahren Sie eine aktuelle Wiederherstellungskopie auf und wissen Sie, wie Konfigurationsänderungen rückgängig gemacht werden. Verwenden Sie nach der Änderung dieselben Messbedingungen, damit der Vergleich aussagekräftig bleibt.
- Prüfen Sie eine öffentliche Seite sowohl mit leerem als auch mit warmem Cache.
- Prüfen Sie Anmeldung, Abmeldung, Kontoseiten, Suche und einen etwaigen Warenkorb.
- Bestätigen Sie, dass Inhaltsänderungen innerhalb der vorgesehenen Zeit sichtbar werden.
- Vergleichen Sie Fehler und erfolgreiche Antworten ebenso wie die Seitengeschwindigkeit.
- Erfassen Sie die Einstellung, die Komponentenversion und das Rollback-Verfahren.
Führen Sie nach der unmittelbaren Verbesserung eine kurze Leistungsaufzeichnung. Notieren Sie die normale Seitengenerierungszeit, häufige aufwendige Abläufe und die bei gewöhnlichen Spitzen freie Kapazität. Sehen Sie diese Beobachtungen nach einem Theme-Wechsel, einem großen Import oder einer neuen Kampagne erneut an. Das nützliche Ergebnis ist eine Website, deren Verhalten Sie verstehen und pflegen können, statt einer Sammlung überlappender Plugins, deren scheinbare Geschwindigkeit verschwindet, sobald sich ein Besucher anmeldet.
