Warum Ihre WordPress-Site so langsam ist und eine praktische Anleitung, um die Dinge zu beschleunigen

Ich wollte diesen Beitrag damit beginnen, dass ich Sie wissen lassen möchte, dass dies NICHT nur ein weiterer allgemeiner Artikel zum Thema „Wie man WordPress beschleunigt“ ist.

Ich werde nichts wiedergeben, was bereits im Internet zu finden ist. Ich werde Ihnen nicht sagen, dass Sie ein Caching-Plugin installieren, die Komprimierung aktivieren, Ihr CSS / JS minimieren usw.

Schließlich sollten Sie bereits wissen, wie Sie diese Dinge tun. Und wenn nicht, finden Sie diese allgemeinen Informationen in Hunderten anderer Blogs.

Stattdessen enthält dieser Artikel alles Custom/Semi-Custom, das ich im letzten Monat oder so implementiert habe, um meinen eigenen WordPress-Blog zu beschleunigen und im Grunde zu verhindern, dass Rogue-Zugriffe meinen Server zum Absturz bringen.

Und der Grund, warum es „wenig bekannt“ ist, ist, dass die Techniken, die ich beschreiben werde, sehr spezifisch für Ihr eigenes Blog sind, abhängig von den Verkehrsmustern, die Sie sehen.

Hinweis: Wenn Sie einen langsamen Blog haben und sich wirklich nicht mit den technischen Aspekten der Beschleunigung einer Website befassen möchten, sollten Sie sich wahrscheinlich für einen Dienst wie WP Engine anmelden .

Diese Jungs sind auf WordPress-Hosting spezialisiert und sorgen dafür, dass Ihr Blog so schnell wie möglich läuft. Aber das hat natürlich seinen Preis. Sie sollten sie sich ansehen, wenn Ihnen dieser Beitrag über den Kopf geht :)

Wie auch immer, bevor ich Ihnen erklären kann, wie und warum ich das getan habe, was ich mit meinem Blog gemacht habe, müssen Sie einige grundlegende Konzepte zu WordPress und Caching verstehen, die ich im Folgenden beschreiben werde.

Einige interessante WordPress-Fakten

Angenommen, Sie haben bereits alle Richtlinien zur Beschleunigung von WordPress befolgt. Dein Blog fühlt sich flink an. Webpagetest.org sagt Ihnen, dass Ihr Blog verdammt schnell ist. Alles ist gut oder? Nicht unbedingt .

Früher ging es mir bei meinem Blog genauso. Schließlich folge ich den meisten Standard-Beschleunigungsprotokollen. Ich betreibe nur sehr wenige Plugins und mein Blog fühlt sich aus der Perspektive eines menschlichen Lesers bei normaler Nutzung ziemlich schnell an (Die Werbenetzwerke verlangsamen meinen Blog, sodass ich Anzeigen zuletzt lade).

Aber dann begann ich, meine CPU-Auslastungsdiagramme zu analysieren und bemerkte oft Zeiten hoher Serverlast trotz niedrigem bis mäßigem Datenverkehr. Gelegentlich wurde mein Server sogar für längere Zeit unbrauchbar oder reagierte nicht mehr.

Beachten Sie, der einzige Grund, warum ich angefangen habe, auf diese Statistiken zu achten, war, dass ich vor einiger Zeit meinen Online-Shop auf demselben Server wie mein Blog betrieben habe. Und regelmäßig beschweren sich Kunden darüber, dass der Laden extrem langsam ist. Als ich schließlich etwas nachforschte, stellte ich fest, dass mein optimierter, vollständig zwischengespeicherter WordPress-Blog meinen Server in die Knie zwang!

Moral der Geschichte? Nur weil ein Geschwindigkeitstest Ihnen sagt, dass Ihr Blog schnell ist, heißt das nicht unbedingt, dass alles gut ist.

Hier sind einige interessante Fakten über WordPress und Caching-Plugins wie WP Super Cache und W3 Total Cache, die Sie kennen sollten.

• WordPress 404-Antworten sind langsam . Jedes Mal, wenn Ihr Blog Zugriff auf eine Seite erhält, die nicht existiert, muss Ihr schlechter Server WordPress laden, eine Menge PHP-Code ausführen, eine Reihe von MySQL-Abfragen durchführen und dann Ihre benutzerdefinierte WordPress 404-Seite ausspucken. Dies ist eine sehr ressourcenintensive Aufgabe und Caching wird nicht helfen.
• Ihr Caching-Plugin funktioniert nicht sehr gut, wenn die URL GET-Parameter enthält. Ich habe zum Beispiel bemerkt, dass mein Blog immer langsamer wird, wenn ich eine Explosion an meine E-Mail-Liste schicke. Theoretisch sollte mein Server mit statischem Datei-Caching nahezu unbesiegbar sein.

  Aber weil Aweber Tracking-Parameter in die URL einfügt, wird keine meiner Dateien super zwischengespeichert. Als Ergebnis muss WordPress jedes Mal eine brandneue Cache-Datei generieren (obwohl sie bereits existiert), sie zippen und jedes Mal versenden. Das Schlimmste ist, dass diese zwischengespeicherten Dateien nur einmal verwendet werden, was eine Verschwendung von Serverressourcen bedeutet

• Rogue-Zugriffe sind langsam. Da betrügerische Zugriffe erfordern, dass WordPress standardmäßig geladen wird, kann ein schlechter Bot oder Crawler, der beschließt, Ihre Website mit schlechten Anfragen zu spammen, Ihren Blog ziemlich einfach zerstören.
• Ihr Caching-Plug-in weist möglicherweise einen Fehler oder eine Inkompatibilität mit der Art und Weise auf, wie Sie Ihr Blog eingerichtet haben . Zum Beispiel dachte ich 3 Jahre lang, dass WP Super Cache das Richtige tut, bis ich anfing, meine Logs zu beobachten und einen Fehler im Code bemerkte. Aufgrund meiner Einrichtung hatte ich ein Problem, bei dem WP Super Cache meinen Cache viel zu oft geleert hat.

Der entscheidende Punkt, den ich mit den obigen Aufzählungspunkten ansprechen möchte, ist, dass jedes Mal , wenn ein nicht standardmäßiger Zugriff auf Ihr Blog stattfindet, viele Serverressourcen verbraucht werden, unabhängig davon, wie Sie Ihr WordPress-Blog eingerichtet haben. Und es sind diese Arten von Zugriffen, die Ihren Server in die Knie zwingen, nicht der normale Datenverkehr.

Erkennen von Rogue-Zugriffen

Der erste Schlüssel zur Optimierung Ihres WordPress-Blogs besteht darin, die Verkehrsmuster zu verstehen, die Ihr Blog empfängt. Ich wette, dass 99% der WordPress-Benutzer dies nicht tun. Stattdessen folgen und installieren sie blindlings verschiedenen Plugins und gehen davon aus, dass alles ordnungsgemäß funktioniert. Kein schlechtes Gewissen, mir ging es genauso.

Der erste Schritt ist also herauszufinden, was zum Teufel los ist. Es gibt viele Möglichkeiten, dies zu tun, aber der einfachste Weg ist, den Debug-Modus zu verwenden, den das Plugin WP SuperCache bietet. Was macht dieser Modus? Grundsätzlich wird jedes Mal, wenn ein Zugriff direkt von WordPress bearbeitet wird (ressourcenintensiv), im WP Super Cache-Protokoll angezeigt. So aktivieren Sie diesen Modus.

Klicken Sie auf der Registerkarte Debug Ihres WP Super Cache-Plugins einfach auf das Kontrollkästchen „Debugging Enabled“ und Sie können loslegen!

Sobald die Protokollierung aktiviert ist, können Sie auf den Link „Logfile“ klicken, der Sie zu einer Datei führt, die Ihren WordPress-Verkehr detailliert beschreibt. Es wird ähnlich wie im folgenden Text aussehen.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

Es ist wichtig zu beachten, dass jedes Mal, wenn Sie etwas in diesem Protokoll sehen, dies eine schlechte Sache ist, da es bedeutet, dass WordPress arbeiten muss. Und weil WordPress ein Ressourcenfresser ist, möchten Sie, dass es so wenig Arbeit wie möglich macht.

Worauf Sie in den Protokollen achten müssen

Die WP Super Cache-Protokolle sind großartig, weil sie Ihnen alles sagen, was vor sich geht. Aber die schiere Menge an Informationen kann überwältigend sein, wenn Sie nicht wissen, wonach Sie suchen müssen. Folgendes sollten Sie in diesen Protokollen beachten.

• 404-Fehler – Im Grunde sind dies Zugriffe auf Seiten, die in Ihrem Blog nicht existieren. Jeder 404-Zugriff, der von WordPress verarbeitet wird, beansprucht viele Serverressourcen, daher möchten Sie diese nach Möglichkeit im Keim ersticken
• Einmalige Zugriffe – Dies sind Anfragen, die Ihren Server veranlassen, Seiten zu cachen und zu komprimieren, die nur einmal verwendet werden (dazu später mehr).
• Seltsame Traffic-Bursts – Dies sind normalerweise Bots, die deinen Blog auf einmal hämmern
• Seltsames Caching-Verhalten – Werden Ihre Caches geleert, wenn sie sollten? Wird unter allen Umständen alles richtig zwischengespeichert?

Nachdem ich 2 Wochen lang meinen Blog-Traffic protokolliert hatte, entdeckte ich viele Ineffizienzen, die ich im Folgenden beschreiben werde.

Bots hämmerten mein Archiv

Als erstes habe ich mir meine Serverprotokolle für Zeiten hoher CPU-Last angesehen. Dann analysierte ich meine Super-Cache-Protokolle in genau denselben Zeiträumen, um zu sehen, ob es irgendwelche lustigen Geschäfte gab. Es stellte sich heraus, dass etwa jeden zweiten Tag eine Gruppe von Bots kam und alle Archivseiten meines Blogs gleichzeitig hämmerte!

Da diese Archivseiten standardmäßig nicht zwischengespeichert werden, reichten mehrere gleichzeitige Zugriffe aus, um meine Serverlast zu erhöhen und die Dinge extrem langsam zu machen. Und gelegentlich führte es sogar zum Absturz meines Servers.

Also habe ich mir meine HTML-Ausgabe genauer angesehen und festgestellt, dass ich eine Reihe von Archiv-Links als Teil meines WordPress-Headers hatte. Daher kamen Bots und andere Webcrawler vorbei und versuchten, die Archive zu durchsuchen.

Nach langem Googeln stellte ich fest, dass einige andere Webmaster ähnliche Probleme hatten.

Wenn wir häufig Ladeprobleme mit Ihrer Site sehen, gibt es eine große Anzahl von Treffern für Proxy-Server-IPs und die Theorie ist, dass diese Proxys Ihre Site zwischenspeichern und alle diese Archivlinks treffen. Viele der IPs, die wir sehen, wenn Ihre Website Ladeprobleme verursacht, sind Unternehmens-, Bildungs- und Regierungs-/Militär-Proxy-IPs, die anscheinend Inhalte vorab abrufen, wenn jemand auf eine Website zugreift.

Lösung: Überprüfen Sie, ob Sie die PHP-Anweisung „wp_get_archives“ im Header-Code Ihres Blogs haben und entfernen Sie sie. Nach dem Löschen dieses kleinen Snippets sind alle meine Archivzugriffe verschwunden.

Bots greifen auf nicht vorhandene Dateien zu

Die zweite wichtige Sache, die mir aufgefallen ist, war, dass es eine Reihe von Bots gab, die auf Dateien auf meinem Server zugegriffen haben, die nicht existierten. Das Problem ist, dass Ihr Server bei jedem Dateizugriff WordPress laden, eine Menge PHP-Code ausführen und dann eine 404-Seite ausgeben muss.

Die Lösung für dieses Problem besteht darin, die Datei .htaccess (Google this, wenn Sie nicht wissen, was es ist) zu bearbeiten und die folgenden Zeilen hinzuzufügen.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz)?)
RewriteCond %{REQUEST_FILENAME} \.(css|js|html|htm|rtf|rtx|svg
|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc
|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|
m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf
|png|pot|pps|ppt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma|wri|
xla|xls|xlsx|xlt|xlw|zip)$ [NC]
RewriteRule .* – [L]

Nachdem diese Zeilen in Ihre .htaccess-Datei eingefügt wurden, prüft Ihr Webserver zunächst, ob eine Datei existiert. Wenn nicht, wird eine 404-Antwort ausgegeben, OHNE WordPress zu laden.

Bots griffen auf URLs zu, die nicht existierten

Das Bedauerliche an der Schreibweise von WordPress ist, dass Ihr Server WordPress laden, eine Menge PHP-Code ausführen und eine Reihe von MySQL-Suchvorgängen durchführen muss, bevor er eine Datei ausgibt, wenn Sie auf einen Artikel zugreifen, der nicht in Ihrer Datenbank vorhanden ist 404-Antwort.

Wenn Sie sich Ihre Logs genau ansehen, werden Sie wahrscheinlich bestimmte Zugriffsmuster bemerken, die Sie ausschließen können, bevor sie WordPress erreichen.

Ich habe zum Beispiel bemerkt, dass eine Reihe von Bots mit der URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… auf meine Website zugegriffen haben . Und jedes Mal lud mein Server WordPress und gab eine 404-Antwort aus.

Anstatt diese Anfragen von WordPress bearbeiten zu lassen, habe ich die folgenden Zeilen zu meiner .htaccess-Datei hinzugefügt

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} www\.facebook\.com/plugins [NC]
RewriteRule .* 404.html [L,R=404]

In den obigen Zeilen lasse ich meinen Webserver in der URL nach „www.facebook.com/plugins“ suchen und gebe sofort eine 404-Antwort aus, ohne WordPress zu laden. Wenn Sie Ihre Protokolle durchsehen, werden Sie viele betrügerische Zugriffe wie den oben beschriebenen finden. Schreiben Sie für jede eine .htaccess-Regel und diese Zugriffe werden Ihren Server nicht mehr belasten.

Bots hämmerten meine Kommentar-Links

Erinnern Sie sich, als ich Ihnen sagte, dass URLs mit GET-Parametern von Ihrem Caching-Plugin anders behandelt werden? Ich habe festgestellt, dass eine Menge Bots mit dem Parametersatz "Antwort auf Kommentar" auf meine Artikel hämmern.

Wenn dies passiert (abhängig von Ihren Caching-Einstellungen), wird WordPress geladen und eine zwischengespeicherte / ZIP-Datei bereitgestellt, obwohl wahrscheinlich nie wieder darauf zugegriffen wird. Das ist Ressourcenverschwendung.

Beispiel aus meinem Logbuch
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

Die Lösung besteht darin, alle Bots und Crawler mit diesen GET-Parametern auf die Hauptartikelseite umzuleiten. Hier ist der Code, den ich meiner .htaccess-Datei hinzugefügt habe.

RewriteCond %{QUERY_STRING} responsetocom
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|crawl|spinne|slurp) [NC]
RewriteRule .* https://mywifequitherjob.com%{REQUEST_URI}? [L]

Dieser Code sucht nach dem GET-Parameter „replytocom“ und entfernt diesen Parameter dann aus der endgültigen URL, bevor der Zugriff auf WordPress angezeigt wird.

Crawler griffen ohne abschließenden Schrägstrich auf Posts zu

Ich bin mir nicht sicher, warum dies der Fall ist, aber ich habe eine Reihe von Webcrawlern bemerkt, die anscheinend rechtmäßig versuchten, auf die Artikel in meinem Blog zuzugreifen, ohne einen nachgestellten Schrägstrich in der URL.

Wie Sie vielleicht oder vielleicht nicht bewusst, eine URL, die wie http://yourblog.com/article/ geschrieben wird , ist anders als eine URL wie http://yourblog.com/article geschrieben.

Wenn eine URL ohne nachgestellten Schrägstrich gefunden wird, muss WordPress daher eingreifen, eine Reihe von PHP-Code ausführen und dann eine 301-Weiterleitung zum Artikel mit dem nachgestellten Schrägstrich ausgeben. Um WordPress das Bild herauszunehmen, kannst du einfach die folgende Regel in deine .htaccess-Datei einfügen.

# Nachgestellten Schrägstrich hinzufügen
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{QUERY_STRING} !.*=.*
RewriteRule ^(.*)$ $1/ [L,R=301]

Indem Sie einen nachgestellten Schrägstrich hinzufügen, geben Sie die 301-Weiterleitung an die richtige URL aus, bevor sie zu WordPress gelangt, was CPU-Ressourcen spart.

Ich habe einen Fehler im WP Super Cache gefunden

Im Gegensatz zu den meisten Leuten habe ich mein WordPress-Blog nicht im Stammverzeichnis meines Verzeichnisses public_html installiert. Außerdem ist die Titelseite meines Blogs auch nicht meine „Posts“-Seite. Wenn Sie Ihr Blog auf die gleiche Weise wie ich konfiguriert haben, gibt es einen Fehler in WP Super Cache, bei dem alle Ihre Cache-Dateien vorzeitig gelöscht werden könnten, selbst wenn Sie Ihren Cache vorab laden.

Ich bin mir nicht sicher, ob der Autor des Plugins sich dieses Problems bewusst ist, aber im Grunde habe ich festgestellt, dass jedes Mal, wenn ein Spam-Kommentar zu meinem Blog gesendet wurde, mein gesamter Cache fälschlicherweise geleert wurde. Da ich ständig Kommentar- und Trackback-Spam bekomme, wurde mein Cache ständig geleert, was das Caching viel weniger effizient machte.

Also verbrachte ich ein Wochenende damit, dieses Problem zu debuggen und schließlich einen Workaround zu entwickeln. Wenn einer von Ihnen die gleichen Probleme hat, lassen Sie es mich wissen und ich zeige Ihnen meine Lösung. Die Moral der Geschichte hier ist, niemals davon auszugehen, dass Ihr Caching-Plugin einfach funktioniert. Sie müssen sich die Protokolle ansehen!

CPU-intensive Plugins deaktivieren

Selbst wenn Sie alle meine Schritte oben befolgt haben, ist es unmöglich, alle betrügerischen Zugriffe herauszufiltern, bevor sie Ihren WordPress-Blog erreichen.

Daher werden Sie immer Zugriffe auf Ihre Website erhalten, die nicht effizient verarbeitet werden. Es führt kein Weg daran vorbei.

Aber das Wichtigste ist, dass Sie höchstwahrscheinlich kein Bandbreitenproblem haben werden, sondern ein CPU-Problem.

Infolgedessen (und dies ist möglicherweise nicht intuitiv) möchten Sie eigentlich keine CPU-intensiven Vorgänge wie das „Verkleinern“ oder „Komprimieren“ Ihrer Seiten im Handumdrehen durchführen. Minimieren und Komprimieren hilft bei der Bandbreite auf Kosten der CPU-Auslastung.

Das Letzte, was Sie tun möchten, ist das Minimieren und Zwischenspeichern von Rogue-Zugriffen. Tatsächlich sollten Sie wahrscheinlich auch erwägen, URLs nicht mit GET-Parametern zu verkleinern oder zu komprimieren.

Am wichtigsten ist, dass Sie auf Ihrer Site keine CPU-intensiven Plugins ausführen. WP-Engine hat eine großartige Liste von CPU-intensiven Plugins, die Sie wahrscheinlich vermeiden sollten.

Als ich meine Plugin-Liste durchsah, bemerkte ich, dass ich ein "Ähnliches Posts"-Plugin verwende. Und als ich mir den Quellcode ansah, stellte ich entsetzt fest, dass das Plugin Volltextvergleiche durchführte, um ähnliche Artikel zu finden, was eine große CPU-Belastung und nicht skalierbar ist.

Sobald ich einen passenden Ersatz finde, landet dieses Plugin definitiv im Müll.

Moral der Geschichte

Nur weil ein Online-Geschwindigkeitstest Ihnen sagt, dass Ihr Blog schnell ist, bedeutet dies im Großen und Ganzen nicht viel.

Versteh mich nicht falsch. Die Seitenladegeschwindigkeit ist wichtig für die Suchmaschinen und für Ihre Stammkunden, aber Sie müssen auch unbefugte Zugriffe berücksichtigen, die Ihren Cache umgehen und Ihren Server in die Knie zwingen können.

Installieren Sie Ihr Caching und andere Speedup-Plugins also nicht blindlings. Nehmen Sie sich etwas Zeit, um Ihren Datenverkehr zu analysieren und so viele .htaccess-Regeln wie möglich zu schreiben, um den Arbeitsaufwand von WordPress zu minimieren. Viel Glück!