▷ Warum Ihre WordPress-Site so langsam ist und ein praktischer Leitfaden zur Beschleunigung

Der folgende Artikel hilft Ihnen dabei: Warum Ihre WordPress-Site so langsam ist und ein praktischer Leitfaden zur Beschleunigung

Ich wollte diesen Beitrag damit beginnen, Sie darüber zu informieren, dass dies der Fall ist NICHT nur ein weiterer allgemeiner Artikel „Wie man WordPress beschleunigt“.

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. sollten.

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

Stattdessen enthält dieser Artikel alles, was ich im letzten Monat oder so benutzerdefiniert/semi-benutzerdefiniert implementiert habe, um meinen eigenen WordPress-Blog zu beschleunigen und grundsätzlich zu verhindern, dass betrügerische Zugriffe meinen Server zum Absturz bringen.

Und der Grund dafür, dass es „wenig bekannt“ ist, liegt darin, dass die Techniken, die ich gleich beschreiben werde, je nach den beobachteten Verkehrsmustern sehr spezifisch für Ihr eigenes Blog sind.

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

Diese Leute 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 ein paar grundlegende Konzepte über WordPress und Caching verstehen, die ich im Folgenden beschreibe.

Einige interessante WordPress-Fakten

Nehmen wir an, Sie haben bereits alle Richtlinien zur Beschleunigung von WordPress befolgt. Dein Blog fühlt sich flott an. Webpagetest.org sagt Ihnen, dass Ihr Blog höllisch schnell ist. Alles ist gut, oder? Nicht unbedingt.

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

Doch dann begann ich mit der Analyse meiner CPU-Auslastungsdiagramme und stellte oft fest, dass die Server trotz geringer bis mäßiger Datenmengen zeitweise stark ausgelastet waren. Gelegentlich war mein Server sogar für längere Zeit unbrauchbar oder reagierte nicht mehr.

NoteDer einzige Grund, warum ich angefangen habe, auf diese Statistiken zu achten, war, dass ich vor einiger Zeit meinen Online-Shop auf demselben Server wie meinen Blog betrieben habe. Und von Zeit zu Zeit beschwerten sich Kunden darüber, dass der Laden extrem langsam sei. Als ich schließlich etwas recherchierte, 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 in Ordnung 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 armer Server WordPress laden, eine Menge PHP-Code ausführen, eine Menge 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. Mir fiel zum Beispiel auf, dass mein Blog immer langsamer wurde, wenn ich eine E-Mail an meine E-Mail-Liste verschickte. Theoretisch sollte mein Server mit statischem Datei-Caching nahezu unbesiegbar sein.
Da Aweber jedoch Tracking-Parameter in die URL einfügt, werden meine Dateien nicht im Super-Cache gespeichert. Daher muss WordPress jedes Mal eine brandneue Cache-Datei generieren (auch wenn diese bereits vorhanden ist), sie komprimieren und versenden. Das Schlimmste daran ist, dass diese zwischengespeicherten Dateien nur einmal verwendet werden, was zu einer Verschwendung von Serverressourcen führt
Schurkenzugriffe sind langsam. Da bei betrügerischen Zugriffen WordPress standardmäßig geladen werden muss, kann ein bösartiger Bot oder Crawler, der beschließt, Ihre Website mit böswilligen Anfragen zu spammen, Ihr Blog ziemlich leicht lahmlegen.
Ihr Caching-Plugin weist möglicherweise einen Fehler auf oder ist mit der Art und Weise, wie Sie Ihr Blog eingerichtet haben, nicht kompatibel. Ich dachte zum Beispiel drei Jahre lang, dass WP Super Cache das Richtige tut, bis ich anfing, meine Protokolle zu überwachen und einen Fehler im Code bemerkte. Aufgrund der Art und Weise, wie ich die Dinge eingerichtet habe, hatte ich das Problem, dass WP Super Cache meinen Cache viel zu oft geleert hat.

Der wichtigste Punkt, den ich mit den obigen Aufzählungspunkten ansprechen möchte, ist Folgendes Immer wenn ein nicht standardmäßiger Zugriff auf Ihr Blog erfolgt, werden viele Serverressourcen beansprucht Ganz gleich, wie Sie Ihr WordPress-Blog eingerichtet haben. Und es sind diese Zugriffsarten, die Ihren Server in die Knie zwingen, nicht der reguläre Datenverkehr.

Erkennen unerwünschter Zugriffe

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 blind verschiedene Plugins und gehen davon aus, dass alles ordnungsgemäß funktioniert. Fühl dich nicht schlecht, mir ging es genauso.

Der erste Schritt besteht also darin, herauszufinden, was zum Teufel los ist. Dafür gibt es viele Möglichkeiten, am einfachsten ist es jedoch, den Debug-Modus zu verwenden, den das Plugin WP SuperCache bereitstellt. Was macht dieser Modus? Grundsätzlich wird jedes Mal, wenn ein Zugriff direkt von WordPress verarbeitet wird (ressourcenintensiv), im WP Super Cache-Protokoll angezeigt. So aktivieren Sie diesen Modus.

Klicken Sie auf der Registerkarte „Debuggen“ Ihres WP Super Cache Plugins einfach auf das Kontrollkästchen „Debugging aktiviert“ und schon kann es losgehen!

Sobald die Protokollierung aktiviert ist, können Sie auf den Link „Protokolldatei“ klicken, der Sie zu einer Datei mit detaillierten Informationen zu Ihrem WordPress-Verkehr führt. Es wird ähnlich wie der Text unten aussehen.

15:03:46 /?utm_source=fwisp.com Supercache-Verzeichnis:
15:03:46 /?utm_source=fwisp.com Keine wp-cache-Datei vorhanden. Muss ein neues generieren.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Einrichten von WordPress-Aktionen
15:03:46 /?utm_source=fwisp.com Supercache-Caching deaktiviert. Benutze nur wp-cache. Nicht leere GET-Anfrage.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (kompatibel; YandexBot/3.0; +http://yandex.com/bots)) abgelehnt. Kein 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 funktionieren 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 sollten

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

404 Fehler – Im Grunde handelt es sich hierbei um Zugriffe auf Seiten, die in Ihrem Blog nicht vorhanden sind. Jeder von WordPress verarbeitete 404-Zugriff beansprucht viele Serverressourcen, daher sollten Sie diese möglichst im Keim ersticken
Einmalige Zugriffe – Hierbei handelt es sich um Anfragen, die dazu führen, dass Ihr Server Seiten zwischenspeichert und komprimiert, die nur einmal verwendet werden (mehr dazu später).
Seltsame Verkehrsstöße – Dies sind normalerweise Bots, die Ihr Blog auf einmal zerstören
Seltsames Caching-Verhalten – Werden Ihre Caches geleert, wenn sie sollten? Wird unter allen Umständen alles ordnungsgemäß zwischengespeichert?

Nachdem ich zwei Wochen lang ein Protokoll meines Blog-Verkehrs geführt hatte, entdeckte ich viele Ineffizienzen, die ich im Folgenden beschreibe.

Bots bombardierten meine Archive

Als Erstes habe ich in meinen Serverprotokollen nach Zeiten hoher CPU-Auslastung gesucht. Dann habe ich meine Super-Cache-Protokolle genau in diesen Zeiträumen analysiert, um zu sehen, ob dort irgendetwas Lustiges vor sich ging. Es stellte sich heraus, dass etwa alle zwei Tage eine Gruppe von Bots kam und alle Archivseiten meines Blogs gleichzeitig bombardierte!

Da diese Archivseiten standardmäßig nicht zwischengespeichert werden, reichten mehrere gleichzeitige Zugriffe aus, um meine Serverlast in die Höhe zu treiben und die Arbeit extrem zu verlangsamen. Und gelegentlich kam es sogar zum Absturz meines Servers.

Also schaute ich mir meine HTML-Ausgabe genauer an und bemerkte, dass mein WordPress-Header eine Reihe von Archiv-Links enthielt. Daher würden Bots und andere Webcrawler vorbeikommen und versuchen, die Archive zu durchsuchen.

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

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

Bots griffen auf nicht vorhandene Dateien zu

Das zweite große Problem, das mir auffiel, war, dass eine Reihe von Bots auf Dateien auf meinem Server zugegriffen haben, die nicht existierten. Das Problem besteht darin, 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 .htaccess-Datei (Google dies, 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]

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

Bots griffen auf URLs zu, die nicht existierten

Das Unglückliche an der Art und Weise, wie WordPress geschrieben ist, ist, dass Ihr Server beim Zugriff auf einen Artikel, der nicht in Ihrer Datenbank vorhanden ist, WordPress laden, eine Menge PHP-Code ausführen und eine Reihe von MySQL-Suchvorgängen durchführen muss, bevor er einen Artikel ausgibt 404-Antwort.

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

Beispielsweise ist mir aufgefallen, dass eine Reihe von Bots über die URL auf meine Website zugegriffen hat www.mywifequitherjob.com/some-article/www.facebook.com/like.php/…. Und jedes Mal startete mein Server WordPress und gab eine 404-Antwort aus.

Anstatt also WordPress diese Anfragen verarbeiten 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 nach „www.facebook.com/plugins“ in der URL suchen und sofort eine 404-Antwort ausgeben, ohne WordPress zu laden. Wenn Sie Ihre Protokolle durchsehen, werden Sie viele betrügerische Zugriffe finden, wie den, den ich oben beschrieben habe. Schreiben Sie für jeden eine .htaccess-Regel und diese Zugriffe belasten Ihren Server nicht mehr.

Bots bombardierten meine Kommentarlinks

Erinnern Sie sich, als ich Ihnen sagte, dass URLs mit GET-Parametern von Ihrem Caching-Plugin unterschiedlich gehandhabt werden? Ich habe festgestellt, dass eine Menge Bots mit dem Parametersatz „Auf Kommentar antworten“ auf meine Artikel einhämmern.

Wenn dies geschieht (abhängig von Ihren Caching-Einstellungen), wird WordPress geladen und eine zwischengespeicherte/zip-Datei bereitgestellt, auch wenn wahrscheinlich nie wieder darauf zugegriffen wird. Das ist eine Verschwendung von Ressourcen.

Beispiel aus meinem Protokoll
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Keine wp-cache-Datei vorhanden. Muss ein neues generieren.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping-Puffer.

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} antwortet aufcom
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|crawl|spider|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 auf Beiträge ohne abschließenden Schrägstrich zu

Ich bin mir nicht sicher, warum das so ist, aber mir ist eine Reihe von Webcrawlern aufgefallen, die scheinbar legitim versucht haben, auf die Artikel in meinem Blog zuzugreifen, ohne einen abschließenden Schrägstrich in der URL.

Wie Sie vielleicht wissen, ist eine URL, die wie folgt geschrieben ist http://yourblog.com/article/ unterscheidet sich von einer URL, die so geschrieben ist http://yourblog.com/article.

Wenn also eine URL ohne abschließenden Schrägstrich gefunden wird, muss WordPress eingreifen, eine Menge PHP-Code ausführen und dann eine 301-Weiterleitung zum Artikel mit dem abschließenden Schrägstrich durchführen. Um WordPress aus dem Weg zu räumen, können Sie einfach die folgende Regel in Ihre .htaccess-Datei einfügen.

# Fügen Sie einen abschließenden Schrägstrich hinzu
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{QUERY_STRING} !.*=.*
RewriteRule ^(.*)$ $1/ [L,R=301]

Durch das Hinzufügen eines abschließenden Schrägstrichs leiten Sie die 301-Weiterleitung an die richtige URL weiter, bevor diese zu WordPress gelangt, wodurch CPU-Ressourcen gespart werden.

Ich habe einen Fehler im WP Super Cache gefunden

Im Gegensatz zu den meisten Menschen habe ich mein WordPress-Blog nicht im Stammverzeichnis meines public_html-Verzeichnisses installiert. Außerdem ist die Startseite meines Blogs auch nicht meine „Beiträge“-Seite. Wenn Sie Ihren 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 dem Autor des Plugins dieses Problem bekannt ist, aber im Grunde habe ich festgestellt, dass bei jedem Spam-Kommentar in meinem Blog fälschlicherweise mein gesamter Cache geleert wurde. Da ich ständig Kommentar- und Trackback-Spam bekomme, wurde mein Cache ständig geleert, was das Caching deutlich weniger effizient machte.

Also habe ich ein Wochenende damit verbracht, dieses Problem zu beheben und schließlich eine Problemumgehung entwickelt. Wenn einer von Ihnen die gleichen Probleme hat, lassen Sie es mich wissen und ich zeige Ihnen meine Lösung. Die Moral der Geschichte lautet hier: Gehen Sie niemals davon aus, dass Ihr Caching-Plugin einfach funktioniert. Sie müssen sich die Protokolle ansehen!

Deaktivieren Sie CPU-intensive Plugins

Selbst wenn Sie alle oben genannten Schritte befolgt haben, ist es unmöglich, alle unerwünschten Zugriffe herauszufiltern, bevor sie Ihr WordPress-Blog erreichen.

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

Wichtig ist jedoch, dass Sie höchstwahrscheinlich kein Bandbreitenproblem haben, sondern ein CPU-Problem.

Aus diesem Grund (und das ist möglicherweise nicht intuitiv) möchten Sie eigentlich nichts CPU-intensives wie das „Minimieren“ oder „Komprimieren“ Ihrer Seiten im laufenden Betrieb tun. Durch die Minimierung und Komprimierung wird die Bandbreite auf Kosten der CPU-Auslastung verbessert.

Das Letzte, was Sie tun möchten, ist die Minimierung und Zwischenspeicherung unerwünschter Zugriffe. Tatsächlich sollten Sie wahrscheinlich auch darüber nachdenken, URLs nicht mit GET-Parametern zu minimieren oder zu komprimieren.

Am wichtigsten ist, dass Sie auf Ihrer Website keine CPU-intensiven Plugins ausführen. WP-Engine verfügt über eine großartige Liste CPU-intensiver Plugins, die Sie wahrscheinlich vermeiden sollten.

Als ich meine Plugin-Liste durchgesehen habe, ist mir aufgefallen, dass ich ein „Ähnliche Beiträge“-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 darstellt und nicht skalierbar ist.

Sobald ich einen passenden Ersatz finde, wandert dieses Plugin definitiv in den Papierkorb.

Moral der Geschichte

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

Versteh mich nicht falsch. Die Seitenladegeschwindigkeit ist für Suchmaschinen und Ihre Stammkunden wichtig, aber Sie müssen auch mit unerwünschten Zugriffen rechnen, die Ihren Cache umgehen und Ihren Server in die Knie zwingen können.

Installieren Sie Ihre Caching- und anderen Beschleunigungs-Plugins also nicht einfach blind. Nehmen Sie sich etwas Zeit, um Ihren Datenverkehr zu analysieren und so viele .htaccess-Regeln wie möglich zu schreiben, um den Arbeitsaufwand für WordPress zu minimieren. Viel Glück!

Sind Sie bereit, ernsthaft mit der Gründung eines Online-Geschäfts zu beginnen?

Wenn Sie wirklich darüber nachdenken, Ihr eigenes Online-Geschäft zu gründen, dann sollten Sie sich unbedingt meinen kostenlosen Minikurs anschauen So erstellen Sie in 5 einfachen Schritten einen Nischen-Onlineshop.

In diesem 6-tägigen Minikurs zeige ich die Schritte, die meine Frau und ich unternommen haben, um Geld zu verdienen 100.000 Dollar innerhalb von nur einem Jahr. Das Beste daran ist, dass es kostenlos ist und Sie wöchentlich E-Commerce-Tipps und -Strategien erhalten!

Warum Ihre WordPress-Site so langsam ist und ein praktischer Leitfaden zur Beschleunigung