Wie man seine WordPress-Seite beschleunigt (Ultimativer 2024 Guide)

Wir haben im Laufe der Jahre viele WordPress Geschwindigkeitsoptimierungs-Tutorials veröffentlicht, die dir zeigen, wie du WordPress optimieren und beschleunigen kannst. Aber manchmal kann es verwirren, wenn man versucht, alles, was man braucht, an einem Ort zu finden. Deshalb werden wir heute mit dir alles, was wir über die Beschleunigung von WordPress wissen – über 15 Jahre Erfahrung und viele Lektionen – teilen, alles in einem ultimativen Leitfaden! Egal, ob du gerade erst anfängst WordPress zu verwenden oder ein erfahrener Entwickler bist, wir versprechen dir, dass du in diesem Beitrag etwas Nützliches finden wirst!

Über 43.6% des Webs werden heute mit WordPress betrieben. Obwohl dies fantastisch ist, bedeutet es auch, dass es Tausende von verschiedenen Themen, Plugins und Technologien gibt, die alle nebeneinander existieren müssen. Für den alltäglichen WordPress-Benutzer kann dies schnell zu einem Alptraum werden, wenn seine Webseite zu einem Engpass wird und er nicht weiß, warum oder sogar wo er Fehler beginnen soll.

In unserem vorherigen Leitfaden zur Seitengeschwindigkeit haben wir viele Grundlagen von Performance erläutert und erfahren, wie sie einen großen Einfluss auf den Erfolg deines Unternehmens haben können. Aber heute werden wir in anwendbare Schritte eintauchen, die du im Moment umsetzen kannst, um Verbesserungen auf deinen eigenen WordPress-Seiten zu sehen. Wir werden auch einige Ressourcen teilen, die für uns von unschätzbarem Wert waren.

WordPress Seitentypen: statisch oder dynamisch

Bevor wir zu den WordPress Geschwindigkeitsoptimierungen loslegen, ist es wichtig, zuerst zu verstehen, dass nicht alle WordPress-Seiten gleich sind. Deshalb haben viele Benutzer Probleme, da man nicht jedes Problem auf die gleiche Weise lösen kann. Wir geben WordPress-Seiten immer eine Klassifizierung: statisch oder dynamisch. Lass uns also zunächst die Unterschiede zwischen diesen beiden Webseitenarten untersuchen.

Hauptsächlich statische Standorte

Statisch sind typischerweise Webseiten wie Blogs, Webseiten für kleine Unternehmen, Webseiten für Nachrichten mit geringerem Volumen, persönliche Webseiten, fotografische Webseiten, usw.. Unter statisch verstehen wir, dass sich die Daten auf diesen WordPress-Seiten nicht sehr oft (vielleicht ein paar Mal am Tag) ändern. Selbst die meisten unserer Kinsta-Seiten würden als statische Webseiten bezeichnet werden.

Dies wird unglaublich wichtig, da viele der Anfragen direkt aus dem Cache auf dem Server mit rasanter Geschwindigkeit bedient werden können! Keine Sorge, wir werden weiter unten auf das Thema Caching in breiter Länge eingehen. Das bedeutet, dass du weniger Datenbankaufrufe haben wirst und nicht so viele Ressourcen benötigt werden, um Google Performance zu erreichen.

Hochdynamische Webseiten

Auf der anderen Seite haben wir hochdynamische Seiten. Dazu gehören Webseiten wie eCommerce (WooCommerce oder Easy Digital Downloads), Community, Mitgliedschaft, Foren (bbPress oder BuddyPress) und Learning Management Systeme (LMS). Unter dynamisch verstehen wir, dass sich die Daten auf diesen WordPress-Seiten häufig ändern (Servertransaktionen finden alle paar Minuten oder sogar jede Sekunde statt). Das bedeutet, dass nicht alle Anfragen an den Server direkt aus dem Cache bedient werden können und zusätzliche Serverressourcen und Datenbankabfragen erforderlich sind.

Diese Webseiten haben in der Regel auch eine große Anzahl von gleichzeitigen Besuchern und Sitzungen. Auf einer Informations- oder Firmen-WordPress-Seite, die meist statisch ist, kann ein Besucher fünf oder zehn Minuten bleiben bis er gefunden hat, was er braucht (und das ist eine hohe Zahl, normalerweise sind die Bounce-Raten viel höher). Auf dynamischen Webseiten geschieht das Gegenteil. Besucher kommen in der Regel auf die Webseite, um sich mit etwas oder jemandem zu beschäftigen. Wenn sie einen Online-Kurs absolvieren, ist es nicht ungewöhnlich, dass sie stundenlang auf derselben Seite verweilen.

Du kannst sehen, wohin das führt. Die gleichzeitigen Besucher, die mit Deinem WordPress-Host verbunden sind, summieren sich schnell. Um es noch schlimmer zu machen, hast du dann eine große Anzahl gleichzeitiger Besucher zusätzlich zu dem Problem mit „nicht zwischenspeicherbaren Inhalten“.

Entscheide Dich für leistungsstarkes WordPress Hosting

Ein WordPress Host ist ein Unternehmen, das alle Daten deiner Webseite speichert. Man meldet sich für einen Plan an und alle Bilder, Inhalte, Videos usw. werden auf einem Server gespeichert, der sich im Rechenzentrum des Hosts befindet. Der WordPress Host bietet eine einfache Möglichkeit, auf die Daten zuzugreifen, sie zu verwalten und an deine Besucher weiterzuleiten. Ziemlich einfach, oder? Nun, nicht ganz.

Es gibt drei sehr unterschiedliche Arten von WordPress Hosts, die man im Internet antrifft. Tauchen wir ein in die Vor- und Nachteile jedes einzelnen. Es ist wichtig, dass man von Anfang an die richtige Wahl trifft, sonst verursacht das Ganze einfach nur Kopfschmerzen und man verschwendet seine Zeit.

1. Shared WordPress Hosting

Die erste und beliebteste Art von WordPress Hosting ist das, was wir „Shared Hosting“ nennen. Dazu gehören die größten Hosts der Branche wie EIG-Unternehmen wie Bluehost und HostGator sowie Anbieter wie Siteground, GoDaddy, Media Temple, OVH, GreenGeeks und InMotion Hosting. Sie nutzen typischerweise cPanel, und der Durchschnittskunde zahlt in der Regel zwischen 3 und 25 EUR pro Monat.

Jeder, der diese Art von Hosting nutzt, wird irgendwann die Nachteile erleben. Es ist nur eine Frage der Zeit. Warum? Weil Shared Hosts dazu neigen, ihre Server zu überlasten, was wiederum die Leistung deiner Webseite beeinträchtigen kann. Standortausfälle oder häufige Fehler vom Typ 500 sind alltägliche Umstände, die du erleben wirst, da diese Anbieter allem Limits setzen und Ressourcen bündeln müssen, um zu überleben. Oder noch schlimmer: Ausfallzeiten deiner Webseite. Auch wenn es einem nicht bewusst ist, befindet sich die eigene WordPress-Seite höchstwahrscheinlich auf demselben Server wie die 200+ anderer Kunden. Alle Probleme, die mit anderen Webseiten auftreten, können deine Seite beeinträchtigen.

Egal, wie man es dreht, abzüglich der Ausgaben, generiert kein Hosting Unternehmen mit $3 pro Monat Gewinne. Vor allem, wenn man noch die Supportleistungen miteinbezieht. Ein Supportfall und das Ganze rentiert sich nicht mehr. Die Art und Weise, wie diese und ähnliche Unternehmen ihr Geld verdienen, ist durch Upselling und versteckte Gebühren. Diese Upsells beinhalten Vorgänge wie Migrationen, Domainregistrierungen, SSL-Zertifikate, etc. Eine weitere gängige Methode ist es, satte Anmelde-Rabatte anzubieten. Aber sobald die Verlängerung ansteht, erhält man eine hohe Rechnung.

Die meisten dieser Hosts bieten etwas an, was sie ihren „unbegrenzten Ressourcen“-Plan nennen. Ihr habt das wahrscheinlich alle schon mal gesehen. Nun, es gibt in der realen Welt nichts dergleichen wie unbegrenzte Ressourcen. Was Hosts hinter den Kulissen tun, ist die Clients zu drosseln, die eine Menge Ressourcen verbrauchen. Dies wiederum führt dazu, dass diese wütenden Kunden gehen und Platz für mehr Kunden schaffen, die eben nicht so viele Ressourcen verbrauchen. Das führt schließlich zu einem Teufelskreis, angetrieben durch den Hosting Anbieter, der weiter billige Angebote durchdrückt und Kunden anmeldet, von denen er hofft, dass sie nicht so viele Ressourcen verbrauchen werden und denen er dann weitere Upsells verkaufen wird.

Kundenservice und Support mit Shared Hosting sind fast immer unterdurchschnittlich, da die Anzahl der Webseiten im Vergleich zu den Supportmitarbeitern schier unüberschaubar ist. Shared Hosts müssen sich sehr oft schlecht aufstellen, um überhaupt einen Gewinn zu erzielen, was in der Regel zu einem nicht zufriedenstellendem Erlebnis für den Kunden führt.

Achte darauf, einen ausführlichen Artikel unseres CFO über die schockierende Wahrheit hinter der Wirtschaft der Webhosting-Branche zu lesen.

2. DIY VPS WordPress Hosting

Die zweite Art von WordPress Hosting ist DIY VPS, oder „Do it yourself on a virtual private server“. Dieser Typus besteht üblicherweise aus Bootstrap-Startups und Benutzern mit etwas mehr Entwicklungs-, Servermanagement- und WordPress-Erfahrung. Sie sind die DIY-Fraktion. Diese Leute versuchen in der Regel immer noch, Geld zu sparen, aber sie sind auch in der Regel mit Leistung beschäftigt und erkennen ihre Bedeutung für den Erfolg ihres Unternehmens an. Gängige Methoden können beispielsweise die Verwendung eines VPS-Anbieters, eines Drittanbieters wie Digital Ocean, Linode oder Vultr sowie eines Tools wie ServerPilot zur einfacheren Verwaltung darstellen.

Ein kleines VPS von DigitalOcean beginnt bei 5 Dollar im Monat und der beliebteste Plan bei ServerPilot bei 10 Dollar im Monat. Abhängig von deinem Setup kannst du also mit Kosten zwischen 5 und 15 EUR oder mehr pro Monat rechnen. Der DIY-Ansatz kann Kosten senken, bedeutet aber auch, dass man verantwortlich ist, wenn etwas schiefläuft, und dass man selbst den Server auf Leistung optimieren muss.

Der DIY-Ansatz kann großartig sein, aber er kann auch nach hinten losgehen, wenn man nicht vorsichtig ist. Bediene dich dieser Variante nicht, wenn du nicht technisch versiert bist oder nur, weil du basteln möchtest! Deine Zeit ist Geld wert und du solltest dich auf das Wachstum deines Unternehmens konzentrieren.

3. Verwaltetes WordPress Hosting

Die dritte Form des Hostings ist das, was wir bei Kinsta anbieten, und das ist Managed WordPress Hosting. Ein Host dieser Art übernimmt für Dich alle Aufgaben im Zusammenhang mit dem Backend-Server und bietet Unterstützung, wenn du sie benötigst. Letzterer ist in der Regel auf die Arbeit mit WordPress abgestimmt und beinhaltet meist Funktionen wie Staging-Umgebungen mit einem Klick und automatische Backups. Dein Support-Team wird besser informiert sein, wenn es darum geht, sich im CMS zurechtzufinden, da sie sich täglich auf eine Plattform konzentrieren.

Wenn du Zeit sparen willst, ist das Managed WordPress Hosting der richtige Weg! 👍

Pläne für Managed WordPress Hosting reichen in der Regel zwischen 25 EUR und 150 EUR pro Monat oder mehr, je nach Größe deiner Webseite und der Art deiner Bedürfnisse. Große Unternehmen wie jQuery, Intuit, Plesk, Dyn, Ngnix und sogar das weiße Haus verwenden WordPress, um ihre Webseite zu hosten. Einige beliebte Managed WordPress Hosts, mit denen du wahrscheinlich vertraut bist oder die du vielleicht auch gerade verwendest, sind WP Engine, Flywheel, Pressable, Media Temple, Pressidium oder Pagely.

Kinsta verfolgt einen anderen Ansatz

Kinsta bringt jedoch das WordPress Hosting auf das nächste Level. Unsere Hosting-Plattform fällt in keine der traditionellen Hosting-Kategorien. Unsere gesamte Infrastruktur ist auf der Google Cloud Platform aufgebaut und unterscheidet sich von der traditionellen Shared-, VPS- oder dedizierten Infrastruktur, was sie zu einer der schnellsten WordPress-Hosting-Lösungen auf dem Markt macht.

Jede WordPress-Seite auf unserer Plattform läuft in einem isolierten Software-Container, der alle für den Betrieb der Seite erforderlichen Softwareressourcen (Linux, Ngnix, PHP, MySQL) enthält. Das bedeutet, dass die Software, die jede Webseite betreibt, völlig privat ist und nicht einmal zwischen deinen eigenen Webseiten geteilt wird.

Jeder Webseiten-Container läuft auf virtuellen Maschinen in einem von mehreren GC-Rechenzentren und nutzt das Premium-Tier-Netzwerk der Google Cloud Platform für einen optimierten Datentransfer mit geringer Latenzzeit. Jede Maschine hat bis zu 96 CPUs und hunderte von GB RAM. Hardwareressourcen (RAM/CPU) werden jedem Webseiten-Container von unseren virtuellen Maschinen automatisch nach Bedarf zugewiesen.

Im Gegensatz zu anderen Hosts, die die Allzweck-Virtual Machines der Google Cloud Platform verwenden, stellen wir allen unseren Kunden in den unterstützten Regionen rechenoptimierte C2-VMs zur Verfügung. Die C2-Maschinen von Google Cloud verfügen über die neueste Generation skalierbarer Intel Xeon-Prozessoren, die in der Lage sind, Turbo-Geschwindigkeiten von 3,8 GHz zu unterstützen. C2-Maschinen sind beliebt für CPU-lastige Anwendungsfälle wie wissenschaftliches Modellieren und maschinelles Lernen, aber sie eignen sich auch hervorragend für hochleistungsfähige WordPress-Hosts. Während unserer Tests stellten wir fest, dass die Migration einer WordPress Webseite von einer Allzweck-VM zu einer C2-VM zu einer zweifachen Leistungssteigerung führte!

Thank you @kinsta for handling today's traffic spike without issue. It's comforting to know your site can handle surges. #webperf #webhosting #wordpress pic.twitter.com/fplO87LIu0

— Adam Lundeen (@adam_lundeen_) January 29, 2019

Jedes Jahr veröffentlicht Review Signal seine WordPress Hosting-Leistungsbenchmarks, und wir sind stolz darauf, dass Kinsta sich fünf Jahre in Folge als das beste Unternehmen auf allen Ebenen erwiesen hat! Und das nicht nur für ein oder zwei unserer Pläne, sondern für jeden Plan, von Starter bis zu Enterprise.

Wir haben auch keine Level 1 oder Level 2 Support-Reps. Unser gesamtes Support-Team besteht aus WordPress-Entwicklern und Linux-Hosting-Technikern, von denen viele ihre eigenen Server verwalten, Themes und Plugins erstellen und auch Code für WordPress Core beigesteuert haben. Auf diese Weise erhältst du kompetente Beratung von jemandem, der mit WordPress aktiv arbeitet und entwickelt.

Du kannst mit den gleichen Support-Teammitgliedern chatten, die auch unsere Fortune-500- und Unternehmenskunden unterstützen. Wir sind so wählerisch in Bezug auf die Qualität unseres Support-Teams, dass wir nur weniger als 1% der Bewerber einstellen, die sich bewerben. Besseren Support gibt es nirgendwo sonst!

Um mehr darüber zu erfahren, warum du dich für Kinsta als Managed WordPress Host entscheiden solltest, lies, „warum wir – wie Kinsta sich unterscheidet“. Aber unabhängig davon, wen du als Deinen Hosting-Anbieter wählst, solltest du immer nach diesen folgenden Serverfunktionen suchen, um sicherzustellen, dass Deine Webseite so schnell wie möglich läuft.

PHP 7 oder höher für die beste Leistung

PHP ist eine Open-Source-, serverseitige Scripting- und Programmiersprache, die hauptsächlich für die Webentwicklung verwendet wird. Der Großteil der Kern-Software WordPress ist in PHP geschrieben, zusammen mit deinen Plugins und Themes, was PHP zu einer sehr wichtigen Programmiersprache für die WordPress-Community macht. Du solltest sicherstellen, dass dein WordPress Host mindestens PHP 7 oder höher anbietet.

Es gibt verschiedene Versionen von PHP, die Dir Dein Host auf Deinem Server zur Verfügung stellt, wobei das neuere PHP 7.3 enorme Leistungssteigerungen bietet.

In der Tat, in unseren aktuellen PHP-Vergleichstests, kann PHP 7.3 im Gegensatz zu PHP 5.6 dreimal so viele Anfragen (Transaktionen) pro Sekunde verarbeiten! PHP 7.3 ist auch im Durchschnitt 9% schneller als PHP 7.2. Das kann sich auch auf die Geschwindigkeit deines WordPress Admin-Dashboards auswirken.

Schnellere Geschwindigkeiten bei verbesserter Sicherheit, deshalb bietet Kinsta immer die neuesten Versionen von PHP an. Du kannst die PHP-Versionen mit einem einzigen Klick ändern.

Und halte Dich fern von WordPress Hosts, die HHVM als Alternative zu PHP anbieten. HHVM ist keine geeignete Lösung mehr für das WordPress Hosting.

Suche dir einen Hoster der Ngnix unterstützt

Hinter den Kulissen verwendet jeder WordPress Host einen Webserver, um Deine WordPress-Seiten zu betreiben. Die gängigsten Optionen sind Ngnix und Apache.

Wir empfehlen dringend, sich für einen Host zu entscheiden, der Ngnix verwendet, da Ngnix seine Wurzeln in der Performance-Optimierung und in der Skalierung hat. Ngnix übertrifft in Vergleichstests oft andere gängige Webserver, insbesondere in Situationen mit statischen Inhalten oder hohen gleichzeitigen Anforderungen, weshalb Kinsta Ngnix einsetzt.

Einige namhafte Unternehmen, die Ngnix einsetzen, sind Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple, Intel und viele mehr. (Quelle)

Laut W3Techs versorgt Apache 44,0% aller Webseiten und ist damit die am weitesten verbreitete Option. Aber wenn man sich den beliebtesten Webserver unter den hochfrequentierten Webseiten (Top 10.000) ansieht, werden 41,9% von ihnen von Ngnix gehostet, während der Apache nur 18,1% versorgt. Es wird von einigen der ressourcenintensivsten Webseiten verwendet, die es gibt, darunter Netflix, NASA und sogar WordPress.com.

Liest du mehr in unserem Webserver Showdown: Ngnix vs Apache

Das Netzwerk deines Hosts macht den Untershied

Wenn man sich für einen WordPress Host entscheidet, denkt man meistens nicht einmal daran zu fragen oder zu recherchieren, welches Netzwerk sie verwenden, aber das solltest du tun. Das Netzwerk kann einen großen Einfluss auf die Leistung deiner Webseite und sogar auf die Geschwindigkeit deines WordPress Dashboards haben. Viele Hosts werden das nicht in ihr Marketing einbeziehen, da sie sich für das günstigste Netzwerk entscheiden, um Kosten zu sparen.

Hier sind ein paar Fragen, die du stellen solltest:

• Über welche Netzwerke übertragen Sie Daten? Liegt der Großteil davon über öffentliche ISP-Netzwerke oder private Infrastrukturen wie Google oder Microsoft? Diese großen Anbieter verfügen über Netzwerke, die auf geringe Latenz und Geschwindigkeit ausgelegt und optimiert sind. Sie haben sogar ihre eigenen Internet-Kabel unter dem Meer!
• Sind die von ihnen verwendeten Netzwerke redundant? Was passiert, wenn ein Kabel versehentlich durchtrennt wird? Das passiert öfter, als man denkt.

Bereits 2017 kündigte Google sein Standard-Tier-Netzwerk an, das ein langsameres Netzwerk ist, aber zu einem günstigeren Preis zu haben ist. Bei Kinsta nutzen wir das Premium-Tier-Netzwerk für alle unsere Hosting-Angebote. Dies ist zwar für uns ein zusätzlicher Kostenfaktor, stellt aber sicher, dass du blitzschnelle Geschwindigkeiten erhältst.

Laut Google erreicht das Premium-Tier-Netzwerk eine verbesserte Netzwerkleistung, indem es die “Reisedauer” im öffentlichen Internet verkürzt; Pakete gelangen (und verlassen) das Netzwerk von Google um so nah wie möglich am Nutzer zu sein und reisen dann über das Backbone von Google, bevor sie zur VM gelangen. Die Standardebene liefert ausgehenden Datenverkehr von GCP ins Internet über öffentliche Verkehrsmittel (ISP-Netze) anstelle des Google-Netzwerks.

Um es anders auszudrücken, wäre es vielleicht leichter so zu verstehen:

• Premium-Tier-Pakete verbringen mehr Zeit im Netzwerk von Google, wobei sie weniger “herumhüpfen” und somit eine bessere Leistung erbringen (aber mehr kosten).
• Standard-Tier-Pakete verbringen weniger Zeit im Google-Netzwerk und mehr Zeit damit, in öffentlichen Netzwerken zu reisen, und liefern somit schlechtere Ergebnisse (aber weniger Kosten).

Wie stark wirkt sich das aus? Nun, für Daten, die über Kontinente transferiert werden, ist ihr Premium-Tier-Netzwerk im Durchschnitt etwa 41% schneller als das Standard-Tier-Netzwerk. Bei Daten, die in eine nahegelegene Region (denselben Kontinent) reisen, ist die Premium-Ebene etwa 8% schneller. Während die Vernetzung nur einen Bruchteil deiner gesamten Seitenladezeiten ausmacht, summiert sich jede Millisekunde!

Auch die Redundanz ist entscheidend, und deshalb verwendet Google mindestens drei unabhängige Pfade (N+2-Redundanz) zwischen zwei beliebigen Standorten im Google-Netzwerk, um sicherzustellen, dass der Datenverkehr auch im Falle einer Unterbrechung zwischen den Standorten weiterläuft.

Wie du wahrscheinlich schon jetzt feststellen kannst, geht hinter den Kulissen viel vor sich, wenn es um Netzwerke geht. Stelle sicher, dass Dein WordPress Host ein seriöses verwendet und sich nicht aus Kostengründen für ein langsames entscheidet.

HTTP/2 ist ein Must-Have

HTTP/2 ist ein im Jahr 2015 veröffentlichtes Webprotokoll, das entwickelt wurde, um die Bereitstellung von Webseiten zu beschleunigen. Aufgrund der Browserunterstützung ist HTTPS (SSL) erforderlich. Wenn dein WordPress Host HTTP/2 nicht unterstützt, solltest du nach einem neuen Provider suchen. Mit der Umstellung des gesamten Webs auf HTTPS ist das nicht mehr nur ein nettes Feature, sondern eine Notwendigkeit.

Die Verbesserung der Performance mit HTTP/2 ist auf eine Vielzahl von Gründen zurückzuführen, wie z.B. die Unterstützung von besserem Multiplexing, Parallelität, HPACK-Kompression mit Huffman-Kodierung, die ALPN-Erweiterung und Server-Push. Früher gab es beim Ausführen über HTTPS einen ziemlichen TLS-Overhead, aber dank HTTP/2 und TLS 1.3 ist dies nun nicht mehr so oft der Fall. Kinsta unterstützt HTTP/2 und TLS 1.3 auf allen unseren Servern und CDN. Kinsta unterstützt HTTP/2 und TLS 1.3 auf allen unseren Servern und CDN.

Ein weiteres großes Plus mit HTTP/2 ist, dass du dir bei den meisten WordPress-Seiten keine Sorgen mehr um die Konkatenation (Konkatenation von Dateien) oder das Domain-Sharding machen musst. Das sind nun veraltete Optimierungen.

Wähle einen Server, der deinen Besuchern am nächsten ist

Eines der ersten Dinge, die du tun solltest, wenn du deine WordPress-Seite hostest, ist festzustellen, woher die Mehrheit deiner Besucher oder Kunden kommt. Warum ist das wichtig? Der Standort, an dem du deine Webseite hostest, spielt eine wichtige Rolle bei der Bestimmung deiner gesamten Netzwerklatenz und TTFB. Es wirkt sich auch auf SFTP-Geschwindigkeiten und die Reaktionsfähigkeit des WordPress Admin Dashboards aus.

Netzwerklatenz: Das bezieht sich auf die Zeit und/oder Verzögerung, die bei der Übertragung von Daten über ein Netzwerk anfällt, mit anderen Worten, wie lange es dauert, bis ein Datenpaket von einem Punkt zum anderen geht. Heutzutage wird dies typischerweise in Millisekunden gemessen, je nach Netzwerk können es jedoch Sekunden sein. Je näher an der Null, desto besser.

Informiere Dich über unseren ausführlichen Beitrag zur Netzwerklatenz.

TTFB: Das steht für Zeit bis zum ersten Byte. Einfach ausgedrückt, ist das ein Maß dafür, wie lange der Browser warten muss, bis er sein erstes Byte an Daten vom Server erhält. Je länger es dauert, diese Daten zu erhalten, desto länger dauert es, deine Seite anzuzeigen. Auch hier gilt: Je näher an der Null, desto besser.

Schaue Dir unseren ausführlichen Beitrag über TTFB an.

Wir werden dich nicht mit allen technischen Details in diesem Beitrag langweilen, alles, was du wissen musst, ist, dass deine Netzwerklatenz und TTFB so niedrig wie möglich sein sollten. Eine der einfachsten Möglichkeiten, das zu erreichen, ist die Wahl eines Servers, der deinen Besuchern am nächsten ist. Du kannst den besten Standort bestimmen, indem du die folgenden Tipps befolgst.

Tipp 1 – Überprüfe vie Google Analytics woher deine Besucher kommen

Eines der ersten Dinge, die du tun kannst, ist die Geolokalisierung deiner Besucher in Google Analytics zu untersuchen. Du findest das unter „Publikum → Geo → Ort“.

In diesem Beispiel unten sieht man, dass über 90% des Traffics aus den Vereinigten Staaten kommt. In den meisten Fällen würdest du also deine WordPress-Seite auf einem Server in den Vereinigten Staaten platzieren wollen. Du kannst die Daten auch noch weiter nach Städten filtern. Das ist besonders wichtig, wenn du ein lokales Unternehmen bist. Aber typischerweise empfehlen wir einen zentralen Standort wie Iowa, USA.

Tipp 2 – Überprüfe die eCommerce Daten

Wenn du einen eCommerce-Shop betreibst, überprüfe auch, woher deine Kunden kommen. Diese Kategorie an Kunden generieren deine Einnahmen, weshalb sie auch am wichtigsten sind. Das sollte mit deinem Traffic oben übereinstimmen, ist aber nicht immer der Fall. Wenn du über eine eCommerce-Dateneinrichtung oder Ziele in Google Analytics verfügst, kann man diese Informationen leicht über die Geolokalisierungsdaten legen, um eine fundiertere Entscheidung zu treffen. Oder überprüfe die in der Datenbank deiner E-Commerce-Plattform gespeicherten Standortinformationen.

Tipp 3 – Mache einen schnellen Latenz Test

Es gibt viele praktische kostenlose Tools, um die Latenzzeit von deinem aktuellen Standort für verschiedene Cloud-Anbieter zu messen. Das kann dir helfen, schnell zu beurteilen, welche Region die beste Wahl für deine Webseite sein könnte.

• GCP Ping (Messung der Latenzzeit für Regionen der Google Cloud Platform, einschließlich Kinsta-Server)
• CloudPing.info (Messung der Latenzzeiten für Amazon Web Services Regionen)
• Azure Latency Test (Messung der Latenzzeit für Azure-Regionen)

In diesem Beispiel unten können wir sehen, dass Oregon, USA (us-west1) der schnellste von unseren Standorten ist. Wenn du jedoch Kunden in den gesamten Vereinigten Staaten bedienst, könnte es besser sein, Iowa, USA (us-central1) zu wählen, um eine geringe Latenzzeit für Besucher von der West- und Ostküste zu gewährleisten.

Hier bei Kinsta bieten wir 37 verschiedene Rechenzentren auf der ganzen Welt an. Man kann sich leicht für eine Webseite entscheiden, die sowohl eine geringe Latenz als auch eine niedrige TTFB hat! Dies trägt auch dazu bei, den Netzwerk-Hop zu reduzieren.

Weitere Möglichkeiten wie du deine Latenzzeit verringern kannst

Neben der Wahl eines nahegelegenen Serverstandortes gibt es hier noch einige andere Möglichkeiten, die Latenz zu reduzieren.

• Implementiere Caching auf Deiner WordPress-Seite. In unseren Tests reduzierte das Caching unser TTFB um satte 90%!
• Nutze ein Content Delivery Network (CDN), um zwischengespeicherte Assets von POPs auf der ganzen Welt bereitzustellen. Das hilft, die Netzwerklatenz für Besucher zu minimieren, die sich möglicherweise nicht in der Nähe Ihres Hostservers befinden.
• Profitiere vom HTTP/2-Protokoll, um die Anzahl der Rundreisen durch Parallelisierung zu minimieren. HTTP/2 ist auf allen Kinsta-Servern aktiviert.
• Reduziere die Anzahl der externen HTTP-Requests. Jeder von ihnen kann seine eigene zusätzliche Latenzzeit haben, basierend auf dem Standort seines Servers.
• Verwende Prefetch und Prerender, um Aufgaben hinter den Kulissen auszuführen, während die Seite geladen wird.

Keine Sorge, wir werden alle oben genannten Empfehlungen weiter unten in diesem Beitrag behandeln.

SFTP Geschwindigkeiten und das WordPress Admin Dashboard

Deine Besucher und Kunden sollten immer Deine Priorität sein. Aber ein weiterer Aspekt der Leistung, über den viele nicht sprechen, ist, wie sich einige dieser Entscheidungen auf Deine tägliche Arbeit auswirken. Der von Dir gewählte Standort des Rechenzentrums hat einen Einfluss darauf, wie schnell Deine SFTP-Download- und Upload-Geschwindigkeiten (Übertragung von Dateien mit einem FTP-Client) sind, sowie auf die Reaktionsfähigkeit Deines WordPress-Admin-Dashboards.

Während du also sicherstellen möchtest, dass du einen Ort wählst, der für deine Besucher am besten geeignet ist, denke auch daran, dass er die Seitenverwaltung beeinflussen kann. Aufgaben wie das Hochladen von Dateien in die WordPress-Medienbibliothek werden schneller erledigt, wenn Deine Webseite in einem Rechenzentrum in Deiner Nähe gehostet wird.

Wir hören immer wieder von Kunden bei Kinsta, dass sie überrascht sind, wie viel schneller ihr Admin-Dashboard bei uns ist. Es gibt eine Vielzahl von Faktoren, die das beeinflussen, aber 20 verschiedene Rechenzentren zu haben, ist ein großer! Wähle einen Ort, der sowohl für deine Besucher als auch für dich geeignet ist! Schließlich bist du derjenige, der wahrscheinlich Tausende von Stunden damit verbringen wird, an deiner Webseite zu arbeiten.

Ein premium DNS is besser als ein kostenloses DNS

DNS, kurz für Domain Name System, ist eine der häufigsten, aber meist missverstandenen Komponenten der Web-Landschaft. Vereinfacht ausgedrückt, hilft DNS bei der “Verkehrsleitung” im Internet, indem es Domainnamen mit echten Webservern verbindet. Im Wesentlichen nimmt es eine menschenfreundliche Anfrage – einen Domainnamen wie kinsta.com – und übersetzt sie in eine computerfreundliche Server-IP-Adresse – wie 216.58.217.206.

Es gibt sowohl kostenloses DNS als auch Premium-DNS. Alle Kinsta-Kunden erhalten über die Amazon Route 53 Zugang zu Premium-DNS. Und im Allgemeinen glauben wir, dass Premium-DNS in der heutigen Welt eine Notwendigkeit ist.

Ein wichtiger Grund für die Wahl von Premium-DNS sind Geschwindigkeit und Zuverlässigkeit. Das Nachschlagen von DNS-Einträgen und das Leiten von Datenverkehr braucht Zeit, auch wenn es nur eine Frage von Millisekunden ist.

Normalerweise ist das kostenlose DNS, das du von Deinem Domain-Namen-Registrator erhältst, vergleichsweise langsam, während Premium-DNS oft eine bessere Leistung bietet. In unseren Tests haben wir beispielsweise festgestellt, dass das kostenlose NameCheap DNS 33% langsamer ist als das Amazon Route 53 Premium DNS. Darüber hinaus kann Premium-DNS eine bessere Sicherheit und Verfügbarkeit bieten, insbesondere, wenn man unter einem DDoS-Angriff steht.

Du kannst ein Tool wie SolveDNS Speed Test verwenden, um Deine DNS-Lookup-Zeiten zu überprüfen. DNSPerf liefert auch hervorragende Leistungsdaten über alle führenden DNS-Anbieter.

Für einen guten Mittelweg zwischen dem kostenlosen DNS deines Domain-Anbieters und dem Premium-DNS ist Cloudflare DNS, ein kostenloser Dienst, der immer noch viele Vorteile des Premium-DNS bietet. Und sie sind rasend schnell, mit durchschnittlichen Reaktionszeiten von unter 20 ms rund um den Globus (siehe unten).

Die Cloudflare-Integration ist in allen Kinsta-Plänen enthalten. Wenn du hauptsächlich Besucher in den USA bedienst, ist DNS Made Easy ein weiterer großartiger Premium-DNS-Anbieter, den du vielleicht ausprobieren möchtest. Es hat den Ruf, einige der besten DNS-Verfügbarkeiten der letzten zehn Jahre angeboten zu haben.

In den letzten 30 Tagen zeigt DNSPerf die nachfolgende Betriebszeit dieser Anbieter an:

• DNS Made Easy: 99,99%, was 4min 23,0s monatlichen Ausfallzeiten entspricht
• Amazon Route 53: 99,88%, was 52min 35,7s monatlichen Ausfallzeiten entspricht
• Wolkenfeuer: 99,85%, was 1h 5min 44,6s monatlichen Ausfallzeiten entspricht

Sind Ausfallzeiten bei DNS-Anbietern so wichtig? Die Antwort darauf ist wirklich ja und nein. DNS wird typischerweise mit ISPs gecached, die den Time To Live Value (TTL) im DNS-Eintrag verwenden. Wenn also ein DNS-Provider für 10 Minuten ausfällt, wirst du höchstwahrscheinlich nichts bemerken. Ausfallzeiten spielen jedoch eine Rolle, wenn der Provider immer wieder längere und häufige Ausfälle hat, oder wenn Deine ISP- und DNS-Einträge beide wirklich niedrige TTL-Werte verwenden.

Dein WordPress-Theme ist entscheidend

Jeder liebt ein brandneues WordPress-Motiv, aber sei vorsichtig, bevor du rausgehst und dir das mit all den neuen, glänzenden Funktionen schnappst. Zuerst solltest du unseren Artikel über die Unterschiede zwischen kostenlosen und kostenpflichtigen Themes lesen. In Bezug auf die Leistung hat jedes Element, das du in einem Theme siehst, einen gewissen Einfluss auf die Gesamtgeschwindigkeit deiner Webseite. Und leider gibt es bei Tausenden von Themes dort draußen sowohl gute als auch schlechte.

Also, woher willst du wissen, welches du wählen sollst? Wir empfehlen, sich für eine der beiden folgenden Optionen zu entscheiden:

• Ein schnelles, leichtes WordPress-Theme, das nur mit den Funktionen erstellt wurde, die du benötigst, mehr nicht.
• Ein funktionsreicheres WordPress-Theme, aber du kannst Funktionen deaktivieren, die du nicht benötigst.

Dinge wie Google-Fonts, Font Awesome Symbole, Schieberegler, Galerien, Video- und Parallaxenskripte etc. das sind nur einige der vielen Dinge, die du abschalten können solltest, wenn du sie nicht verwendest. Du möchtest wirklich nicht versuchen, diese nachträglich manuell zu optimieren. Die 50 verschiedenen Möglichkeiten, diese zu entfernen, werden wir hier kaum aufgreifen können, aber stattdessen empfehlen wir, dass du mit einem WordPress-Theme startest oder zu einem anderen wechselst, das entweder von Anfang an leichtgewichtig ist oder dir diese Optionen bietet.

Unten sind ein paar WordPress-Themes, die wir empfehlen und mit denen du nichts falsch machen kannst! Vertrau uns, du wirst es uns später danken. 😉

Jedes der unten genannten Themes ist voll kompatibel mit WooCommerce und Easy Digital Downloads, WPML, BuddyPress und bbPress. Wir führen einige Geschwindigkeitstests mit jedem Theme unter Verwendung der folgenden Konfiguration durch:

• Gehostet auf Kinsta, mit WordPress 4.9.8
• PHP 7.3 and SSL (HTTPS)
• Kinsta CDN
• Imagify wurde verwendet, um Bilder automatisch zu komprimieren

GeneratePress

GeneratePress ist ein schnelles, leichtes (weniger als 1 MB gezippt), mobiles WordPress-Theme, das mit Blick auf Geschwindigkeit, SEO und Benutzerfreundlichkeit entwickelt wurde. Erbaut von Tom Usborne, einem Entwickler aus Kanada. Es wird aktiv aktualisiert und gut unterstützt. Selbst einige Kinsta-Teammitglieder nutzen GeneratePress für ihre Projekte.

Es gibt sowohl eine kostenlose als auch eine Premium-Version. Wenn du dir das WordPress Repository ansiehst, verfügt die kostenlose Version derzeit über mehr als 200.000 aktive Installationen, mehr als 2 Millionen Downloads und eine beeindruckende 5 von 5 Sternen Bewertung (über 850 Personen haben ihm 5 Sterne gegeben).

Eines der großartigsten Dinge an GeneratePress ist, dass alle Optionen den intuitiven WordPress Customizer verwenden, d.h. Du kannst jede Änderung, die Du vornimmst, sofort sehen, bevor Du auf die Schaltfläche Veröffentlichen klickst. Das bedeutet auch, dass Du kein neues Control Panel für das Theme lernen musst.

Wie schnell ist es? Wir haben GeneratePress neu installiert, fünf Geschwindigkeitstests in Pingdom durchgeführt und den Durchschnitt ermittelt. Die Gesamtladezeit betrug 305 ms bei einer Gesamtseitengröße von nur 16,8 KB. Es ist immer gut, einen Basistest durchzuführen, um zu sehen, wozu das Motiv in Bezug auf die Rohleistung fähig ist.

Anschließend führten wir eine weitere Reihe von Tests mit einem der vorgefertigten Designs aus der GeneratePress Bibliothek durch. Das beinhaltet Bilder, Hintergründe, neue Abschnitte etc. Ein Vorteil von GeneratePress ist, dass es viele vorgefertigte Designs hat, die kein Page Builder Plugin erfordern. Man sieht, dass es noch unter 400 ms getaktet hat.

Jetzt natürlich, in einer realen Umgebung, kannst du andere Dinge wie Google Analytics, Facebook Remarketing Pixel, Hotjar etc. ausführen lassen. Aber du solltest in der Lage sein, leicht unter der 1-Sekunden-Marke zu bleiben. Schaue Dir einen ausführlichen Bericht über GeneratePress auf Woorkup an.

Wir zeigen dir weitere Möglichkeiten, wie du WordPress optimieren und beschleunigen kannst.

OceanWP

Das OceanWP-Theme ist leicht und gut erweiterbar und ermöglicht es dir, fast jede Art von Webseite wie einen Blog, ein Portfolio, eine Business-Webseite und ein WooCommerce Storefront mit einem schönen und professionellen Design zu erstellen. Es wurde von Nicolas Lecocq entworfen und wird aktiv aktualisiert und gut unterstützt.

Genau wie bei GeneratePress gibt es sowohl eine kostenlose als auch eine Premium-Version. Wenn du dir den WordPress Repository ansiehst, hat die kostenlose Version derzeit über 400.000 aktive Installationen und weitere beeindruckende 5 von 5 Sterne Bewertungen (über 2.600 Nutzer haben 5 Sterne vergeben).

Wie schnell ist es? Wir haben OceanWP neu installiert, fünf Geschwindigkeitstests in Pingdom durchgeführt und den Durchschnitt ermittelt. Die Gesamtladezeit betrug 389 ms bei einer Gesamtseitengröße von nur 230,8 KB. Die Skripte in OceanWP sind etwas größer, aber nichts, worüber man nach Hause schreiben könnte.

Anschließend führten wir eine weitere Reihe von Tests mit einem der Demo-Themes aus der OceanWP-Bibliothek durch. Diese enthält Bilder, Hintergründe, neue Abschnitte und erfordert das Elementor Page Builder Plugin. Man sieht, dass es noch unter 600 ms läuft.

Du kannst eine detailliertere Rezension über OceanWP in unserem Blog nachlesen.

Astra

Astra ist ein schnelles, vollständig anpassbares und schönes Design, das sich für Blogs, persönliche Portfolios, Geschäftswebseiten und WooCommerce-Schaufenster eignet. Es ist sehr leicht (weniger als 50 KB am Frontend) und bietet eine beispiellose Geschwindigkeit. Es wurde vom Team von Brainstorm Force entwickelt und wird aktiv aktualisiert und gut unterstützt. Du erkennst sie möglicherweise als die Entwickler des beliebten All In One Schema Rich Snippets Plugins wieder, das es seit vielen Jahren gibt.

Genau wie bei GeneratePress und OceanWP gibt es sowohl eine kostenlose als auch eine Premium-Version. Wenn du dir den WordPress Repository ansiehst, hat die kostenlose Version derzeit über 400.000 aktive Installationen, 1,6+ Millionen Downloads und darüber hinaus eine beeindruckende 5 von 5 Sterne Bewertung (über 2500 Nutzer haben 5 Sterne vergeben).

Wie schnell ist es? Wir haben eine Neuinstallation von Astra durchgeführt, fünf Geschwindigkeitstests in Pingdom durchgeführt und den Durchschnitt ermittelt. Die Gesamtladezeit betrug 243 ms bei einer Gesamtseitengröße von nur 26,6 KB.

Wir führten dann einen weiteren Satz von Tests mit einem der Demo-Designs aus der Astra Starter Kit Bibliothek durch. Diese enthält Bilder, Hintergründe, neue Abschnitte und erfordert das Elementor Page Builder Plug-In. Man sieht, dass es noch unter 700 ms getaktet hat. Hinweis: Die Bilder in dieser Demo wurden vollständig komprimiert, aber sie wählten von Anfang an sehr hochauflösende Bilder.

Es ist wichtig, die Unterschiede zwischen den Geschwindigkeitstests mit diesen drei Themen mit Vorsicht zu genießen. Das Problem ist, dass es fast unmöglich ist, einen völlig genauen Seitenvergleich durchzuführen. Das Wichtigste, was wir Dir zeigen wollten, ist, dass all diese WordPress-Themen rasant schnell arbeiten, sowohl direkt „von der Stange“ als auch mit vollständigen Demos! 🚀

Eine Warnung wenn es um PageBuilder geht

Wie du wahrscheinlich bemerkt haben wirst, benötigten OceanWP und Astra beide Seitenersteller, um ihre jeweiligen Bibliotheksthemes zu verwenden. Hier sind ein paar Dinge, die du bei der Verwendung eines Page Builder Plugins beachten solltest:

• Einige Seitenersteller können die Ladezeit auf deiner Webseite verlängern. Das liegt daran, dass sie zusätzliche CSS und JS laden müssen, damit die Prozesse für dich ohne Code funktionieren. So funktioniert die Magie! Wir empfehlen immer, die Geschwindigkeit der WordPress-Seite vor und nach der Installation eines Page Builders zu testen.
• Du bindest dich mit diesem Seitenersteller an ein einziges Design. Achte darauf, dass du dich für einen entscheidest, der regelmäßig aktualisiert wird und alles hat, was du langfristig benötigst.

Allerdings sind wir immer noch große Fans von Pagebuildern wie Elementor und Beaver Builder. In den meisten Fällen werden sie unter dem Gesichtspunkt der Leistung entwickelt und fügen nur wenig Aufwand hinzu. Für die meisten lohnt sich die Funktionalität und Benutzerfreundlichkeit, denn mit diesen Plugins kannst du alles erstellen, was du dir vorstellst! Sie könnten auch in einigen Fällen schneller sein, da sie ein Ersatz für mehr als 5 andere Plugins sein könnten, die du sonst hättest verwenden müssen.

Wenn du jedoch kein Page Builder Plugin benötigst, installiere auf jeden Fall nicht einen nur für den Kick. Es wird auch interessant sein zu sehen, wie der neue Gutenberg-Editor in den nächsten Jahren eine Rolle im Webseite-Design spielen wird.

Der Überblick über WordPress Plugins

Nun zu den Informationen über WordPress-Plugins. Es wurde dir vielleicht gesagt, dass zu viele Plugins nicht das Gelbe vom Ei sind, da das deine WordPress-Seite verlangsamen würde. Obwohl das manchmal wahr ist, ist es nicht der kritischste Faktor. Die Anzahl der Plugins ist nicht so wichtig wie die Qualität derselben. So, jetzt haben wir es gesagt. 😜

Genau wie bei Themes spielt es eine Rolle, wie das Plugin entwickelt wird und ob es mit Blick auf die Performance entwickelt wurde. Wir haben viele Kunden bei Kinsta, die 30-40 Plugins betreiben und deren Seiten immer noch weit unter einer Sekunde laden.

Es macht zwar Spaß, Deiner Webseite Code hinzuzufügen, aber das ist aus den folgenden Gründen nicht immer praktisch:

1. Man muss den Code selbst pflegen und ihn bei Änderungen der Standards auf dem neuesten Stand halten. Warum dann nicht auf die fantastischen Entwickler vertrauen, die die Standards besser kennen als die meisten anderen?
2. Meistens wird ein gut programmiertes Plugin nicht viel mehr Overhead einbringen als der Code selbst.
3. Beachte, dass die Mehrheit der WordPress-Community nicht so technisch versiert ist wie die Entwickler. Plugins sind Lösungen, die helfen, Probleme zu lösen.
4. Es gibt natürlich auch nicht so tolle Plugins da draußen, von denen man sich fernhalten sollte. Vertraue uns, wir haben bei Kinsta das Schlimmste vom Schlimmsten gesehen. Viele, nicht alle, der Plugins, die wir bei Kinsta verbannen, verursachen Performance-Probleme aus erster Hand. Wir werden vertiefend weiter unten darüber reden.

Davon abgesehen es gibt natürlich auch nicht so tolle Plug-Ins da draußen, von denen man sich fernhalten möchte. Vertraue uns, wir haben bei Kinsta das Schlimmste vom Schlimmsten gesehen. Viele, nicht alle, der Plug-Ins, die wir bei Kinsta verbannen, verursachen Performance-Probleme aus erster Hand. Wir werden vertiefend weiter unten darüber reden.

Francesco hat einen interessanten Beitrag, in dem er in die Lasttests von WordPress-Plugins eintaucht, um zu sehen, wie sie sich auf das Backend einer WordPress-Seite auswirken, das in den meisten Fällen nicht im Cache gespeichert wird. Wir werden weiter unten erfahren, wie man schlechte Plugins auf deiner Seite findet.

Es steht jedoch fest, dass eines der Dinge, die Menschen an WordPress lieben, seine riesige Bibliothek von Drittanbieter-Plugins ist. Aber mit mehr als 56.000 kostenlosen Plugins, die allein auf WordPress.org aufgelistet sind, und Tausendeen weiteren, die anderswo aufgelistet sind, kann es schwierig sein, das eine Plugin zu finden, das man benötigt. Apropos Nadel im Heuhaufen! Schaue dir die Liste an, die wir nur aus den besten WordPress-Plugins auf dem Markt zusammengestellt haben.

Wir versuchen nur Dinge, die wir täglich benutzen, zu teilen. Und ja, wir verwenden WordPress-Plugins auf unserer Webseite, genau wie Ihr auch. Viele der Teammitglieder bei Kinsta entwickeln und verkaufen sogar Plugins.

Ein großes Problem bei WordPress Plugins

Ein großes Problem bei WordPress-Plugins ist der Deinstallationsprozess. Wann immer du ein WordPress-Plugin oder -Theme installierst, speichert es die Daten in der Datenbank. Das Problem ist, dass, wenn du ein Plugin mit einer der Standardmethoden löschst, es normalerweise Tabellen und Zeilen in deiner Datenbank hinterlässt. Im Laufe der Zeit kann das zu einer Menge von Daten führen und sogar anfangen, deine Webseite zu verlangsamen. In unserem Beispiel haben wir das Wordfence Security Plugin deinstalliert und es hinterließ 24 Tabellen in unserer Datenbank (siehe unten). Es ist noch schlimmer, wenn sie hinter den Daten in der Tabelle wp_options liegen.

Und neben der Datenbank hinterlassen viele Plugins auch zusätzliche Ordner und Dateien. Nach unserer Erfahrung wird dass häufig bei Sicherheits- und Caching-Plugins beobachtet, die zusätzliche Verzeichnisse für die Protokollierung erstellen. Nachdem beispielsweise das Wordfence-Plugin gelöscht wurde, wurde uns ein Ordner „wflogs“ in unserem Verzeichnis wp-content zur Verfügung gestellt. Aber wir versuchen nicht, uns auf Wordfence zu konzentrieren da die meisten Plugins und Themes auf dem Markt auch so funktionieren.

Warum tun Entwickler das?

Du fragst dich also wahrscheinlich, warum haben Entwickler keine Selbstreinigungsoptionen, wenn sie ein Plugin deinstallieren und löschen? Nun, das tun sie. Aber, hier sind ein paar Gründe, warum sie wahrscheinlich nicht so offensichtlich sind.

1. Sie wollen die Einstellungen für den Benutzer beibehalten. Wenn du ein WordPress-Plugin löschst und dich entscheidest, es später noch einmal zu versuchen, sind alle deine Einstellungen und Daten noch vorhanden. Dies ist zwar sehr praktisch, aber nicht der effizienteste Weg.
2. Sie kümmern sich nicht um die Leistung. Einige Entwickler mögen argumentieren, dass das Hinterlassen von Tabellen keinen Einfluss auf die Performance hat. Aber stelle dir eine Webseite im Laufe von zehn Jahren vor, die Hunderte von Plugins verwendet hat, die möglicherweise Tausende von Zeilen oder Tabellen generiert haben. Datenbankabfragen haben einen erheblichen Einfluss auf die Leistung deiner WordPress-Seite, und Plugins können viele dieser Anfragen stellen, wenn der Entwickler nicht vorsichtig war. Im Allgemeinen sollte ein gut geschriebenes Plugin nur die Tabellen oder Zeilen abfragen, an die es gebunden ist, das ist jedoch nicht immer der Fall. Wir haben das bei Kinsta aus erster Hand gesehen, lange Datenbankabfragen, die eine Webseite zum Crawlen bringen, weil unnötige, automatisch geladene Daten in der Tabelle wp_options zurückgelassen wurden.
3. Sie haben einen Fehler gemacht. Im WordPress Plugin-Handbuch steht sogar, dass „weniger erfahrene Entwickler manchmal den Fehler machen, den Deaktivierungshaken zu diesem Zweck zu verwenden“.

Die guten Nachrichten? Es gibt Möglichkeiten, ein Plug-In zu bereinigen und richtig loszuwerden. 👏 Schau Dir unsere folgenden Tutorials an:

• So deinstallieren Sie ein WordPress-Plugin (auf die richtige Weise)
• Manuelle Bereinigung von Tabellen, die hinterlassen wurden

Die Optimalen WordPress Einstellungen

Nun zu den optimalen WordPress-Einstellungen. Hier sind ein paar Änderungen, die Du vornehmen kannst, um Deine WordPress-Seite zu beschleunigen. Viele davon sind sehr subtile Veränderungen, aber alles hilft!

Ändere Deine WordPress Login URL

Standardmäßig ist die Anmelde-URL deiner WordPress-Seite domain.com/wp-admin/. Eines der Probleme dabei ist, dass alle Bots, Hacker und Skripte da draußen das auch wissen. Durch das Ändern der URL kannst du dich weniger zu einem potentiellen Angriffsziel machen, dich besser vor Brute-Force-Angriffen schützen und die Bandbreite der Bots verringern, die diese URL wiederholt treffen.

Das Ändern der Anmelde-URL von WordPress kann auch dazu beitragen, häufige Fehler wie „429 Too Many Requests“ zu vermeiden. Das ist keine Lösung, es ist nur ein kleiner Trick, der helfen kann, dich zu schützen und die Belastung auf der Seite zu verringern.

Um deine WordPress Login-URL zu ändern, empfehlen wir dir, eines der folgenden Plugins zu verwenden:

• WPS Hide Login (kostenlos)
• Perfmatters (Premium, beinhaltet aber auch andere Einstellungen zur Leistungsoptimierung; entwickelt von einem Teammitglied bei Kinsta)

Plugin- und Theme Updates deaktivieren oder optimieren

Langsame WordPress Admin-Dashboards können vom Netzwerk, dem Standort des Rechenzentrums und sogar von PHP-Versionen beeinflusst werden. Aber ein weiterer Faktor, über den nicht viele Leute sprechen, ist der WordPress Update Checker, der im Hintergrund läuft. Das ist ein Fall, in dem viele WordPress Plugins und Themes dir schaden könnten. WeFoster hat einen großartigen Blog-Post zu diesem Thema, in dem sie den Begriff „Third Party Plugin Update Check Syndrome“ oder TPPUCS einführen.

Im Wesentlichen besteht das Problem darin, dass der eingebaute WordPress Update Checker hinter den Kulissen eine externe GET-Anfrage stellt (https://third-party-plugin/update-check.php). Manchmal kann das periodisch oder sehr häufig erfolgen. Wenn es häufiger vorkommt, könnte das dazu führen, dass dein Admin-Dashboard stark verlangsamt.

Das Problem hängt eher damit zusammen, wie der Update-Checker in WordPress aufgebaut ist. Wenn du unter langsamen Ladezeiten des WordPress-Administrations-Dashboards leidest, solltest du es vielleicht versuchen. Die Lösung besteht darin, automatische Updates zu deaktivieren. Warnung: Das ist nur dann der Fall, wenn du beabsichtigst, manuell nach Updates zu suchen. Viele Updates beinhalten Sicherheits- und Bugfixes.

Um Updates zu deaktivieren, empfehlen wir die Verwendung eines der folgenden Plug-Ins:

• Deactivate all WordPress Updates: völlig kostenlos und ohne Einstellungen; macht das, was es sagt, gut.
• Simple Update-Manager: bietet mehr Kontrolle über selektive Updates. Die Basisversion ist kostenlos.

Du könntest dir ganz einfach eine Kalendererinnerung einrichten, um das Plugin einmal pro Woche zu deaktivieren, nach Updates zu suchen und es dann wieder zu aktivieren.

Pingbacks deaktivieren

Ein Pingback ist ein automatisierter Kommentar, der erstellt wird, wenn ein anderer Blog auf dich verlinkt. Es kann auch Self-Pingbacks geben, die erstellt werden, wenn du auf einen Artikel in deinem eigenen Blog verlinkst.

Wir empfehlen, diese einfach zu deaktivieren, da sie wertlose Abfragen und zusätzlichen Spam auf deiner Webseite erzeugen. Denke daran, je weniger Aufrufe deine WordPress-Seite machen muss, desto besser, besonders auf stark frequentierten Seiten. Ganz zu schweigen von der Tatsache, dass ein Pingback auf der eigenen Webseite einfach geradezu ärgerlich ist. Führe die folgenden Schritte aus, um Pingbacks zu deaktivieren.

Schritt 1 – Pingbacks von anderen Blogs deaktivieren

Klicke in deinem WordPress Dashboard auf „Einstellungen → Diskussion“. Deaktiviere im Bereich Diskussionseinstellungen die Option „Link-Benachrichtigungen aus anderen Blogs (Pingbacks und Trackbacks) über neue Artikel zulassen“.

Schritt 2 – Deaktiviere Self-Pingbacks

Wenn es darum geht, Self-Pingbacks zu deaktivieren, hast du verschiedene Möglichkeiten. Du kannst das kostenlose No Self Pings Plugin verwenden. Oder du kannst ein Premium-Plugin wie Perfmatters verwenden.

Alternativ kannst Du auch Self-Pingbacks deaktivieren, indem du den folgenden Code zur Datei functions.php deines WordPress-Themes hinzufügst. Warnung: das Bearbeiten der Quelle eines WordPress-Themes könnte deine Seite beschädigen, wenn sie nicht korrekt ausgeführt wird. Tipp: Du kannst mit dem kostenlosen Code Snippets Plugin einfach solche PHP-Snippets hinzufügen. Das bedeutet, dass du dein Theme nicht bearbeiten musst.

function wpsites_disable_self_pingbacks( &$links ) {
  foreach ( $links as $l => $link )
        if ( 0 === strpos( $link, get_option( 'home' ) ) )
            unset($links[$l]);
}

add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );

Limitiere die Anzahl der Posts in deinem Blog-Feed

Egal, ob Dein Blog-Feed als Deine Homepage eingestellt ist oder eine andere Seite Deiner Webseite, Du brauchst keine 50 Miniaturansichten, die alle gleichzeitig geladen werden. Für diejenigen, die hochfrequentierte Blogs betreiben, ist die Homepage die wichtigste Seite einer Webseite, und Du willst, dass sie schnell geladen wird. Je weniger Anfragen und Medien, desto besser in Bezug auf die Leistung!

Auch genau deshalb wurde der Seitennummerierung erfunden (wie unten gezeigt). Es ist das, was du am Ende von Blog-Feeds siehst, mit denen du zur nächsten Seite navigieren kannst. Typischerweise sind das Zahlen, oder sie verwenden möglicherweise „nächste/vorherige“ Beiträge. Dein WordPress-Theme wird höchstwahrscheinlich bereits eine benutzerdefinierte Seitennummerierung eingebaut haben.

WordPress setzt standardmäßig die Grenze für neue WordPress-Installationen auf 10, aber wir haben gesehen, dass sich das so oft geändert hat, dass wir aufgehört haben mitzuzählen. Achte also darauf, dass du noch einmal überprüfst, welchen Wert du verwendest. Wir empfehlen einen Wert zwischen 8 und 12. Falls du neugierig bist, wir verwenden 12 auf unserer Kinsta-Blog-Homepage.

Du findest diese Option in Deinem WordPress Admin Dashboard unter „Einstellungen → Lesen“. Anschließend kannst Du den Wert für „Blogseiten maximal anzeigen“ ändern.

Warum ist Caching so wichtig

Caching ist bei weitem eine der wichtigsten und einfachsten Möglichkeiten, WordPress zu beschleunigen! Aber bevor wir Dir zeigen, wie man Caching verwendet, ist es wichtig, zuerst zu verstehen, wie es funktioniert und welche verschiedenen Arten von Caching es gibt.

Was ist Caching?

Kurz gesagt, jede Webseite, die auf Deiner WordPress-Seite besucht wird, erfordert eine Anfrage an den Server, die Verarbeitung durch diesen Server (einschließlich Datenbankabfragen) und dann ein Endergebnis, das vom Server an den Browser des Benutzers gesendet wird. Das Ergebnis ist Deine Webseite, komplett mit allen Dateien und Elementen, die sie so aussehen lassen, wie sie eben aussieht.

Zum Beispiel kannst du einen Header, Bilder, ein Menü und einen Blog haben. Da der Server alle diese Anfragen bearbeiten muss, dauert es einige Zeit, bis die gesamte Webseite dem Benutzer zugestellt wird – insbesondere bei klobigen oder größeren Webseiten.

Hier kommt ein WordPress Caching-Plugin ins Spiel! Caching weist den Server an, je nach Konfiguration einige Dateien auf der Festplatte oder im RAM zu speichern. Daher kann es sich an den gleichen Inhalt erinnern und ihn duplizieren, den es in der Vergangenheit bereitgestellt hat. Im Grunde genommen reduziert es den Arbeitsaufwand für die Generierung eines Seitenaufrufs. Dadurch werden deine Webseiten viel schneller geladen, direkt aus dem Cache.

Einige andere Vorteile des Caching sind:

• Dein Server verbraucht weniger Ressourcen – das bringt folglich Geschwindigkeit mit sich, da weniger Ressourcen für eine schnellere Webseite sorgen. Es belastet aber auch den Server weniger. Das ist sehr wichtig, wenn es um hochdynamische Webseiten geht, wie z.B. Mitgliederseiten und um festzustellen, was man aus dem Cache bedienen kann und was nicht.
• Du wirst sehen, dass die TTFB niedriger ist – Caching ist eine der einfachsten Möglichkeiten, deine TTFB zu senken. Tatsächlich reduziert das Caching in unseren Tests typischerweise TTFB um bis zu 90%!

Cachingarten

Wenn es um die Art des Caching geht, gibt es zwei verschiedene Ansätze, die häufig verwendet werden:

1. Caching auf Serverebene
2. Caching mit einem Plugin

1. Caching auf Serverebene

Das Caching auf Serverebene ist bei weitem einer der einfachsten Ansätze für den Endanwender. Das bedeutet, dass der WordPress Hosting-Provider das für dich übernimmt. Bei Kinsta verwenden wir die folgenden vier Arten von Cache, die alle automatisch auf Software- oder Serverebene ausgeführt werden:

• Bytecode caching
• Object caching
• Page caching
• CDN caching

Das bedeutet, dass du dir keine Sorgen machen musst, dich mit komplizierten und verwirrenden Caching-Plugins zu beschäftigen. Du kannst aufhören, nach den „besten Caching-Plugins von 2024“ zu suchen und dich auf produktivere Aufgaben konzentrieren. 👏

An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀

— WPColt (@WPColt) January 3, 2018

 

Der Seiten-Cache ist so konfiguriert, dass er mit Standard WordPress sofort nach dem Einrichten funktioniert. Du musst gar nichts tun! Starte einfach Deine WordPress-Seite und der Seiten-Cache beginnt.

Wir haben auch Caching-Regeln für E-Commerce-Seiten wie WooCommerce und Easy Digital Downloads. Standardmäßig werden bestimmte Seiten, die niemals zwischengespeichert werden sollten, wie z.B. Warenkorb, mein Konto und Auschecken, vom Caching ausgeschlossen. Benutzer umgehen automatisch den Cache, wenn das woocommerce_items_in_cart Cookie oder edd_items_in_cart erkannt wird, um einen reibungslosen und synchronen Checkout-Prozess zu gewährleisten.

Du kannst den Cache Deiner WordPress-Seite jederzeit über die Admin-Symbolleiste löschen.

Es ist auch in unserem MyKinsta Dashboard integriert. Klick einfach bei Werkzeuge auf „Cache löschen“.

2. Caching mit einem Plugin

Wenn Dein Hosting-Provider keinen Cache zur Verfügung stellt, kannst Du ein WordPress-Caching-Plugin von Drittanbietern verwenden. Aufgrund unserer Erfahrung empfehlen wir eine der folgenden Optionen:

1. WP Rocket (Premium)
2. Cache Enabler (kostenlos)
3. W3 Total Cache (kostenlos)

Du kannst auch einige weitere Optionen in unserem ausführlichen Beitrag über WordPress Caching-Plugins nachlesen.

Wir unterstützen auch WP Rocket in Kinsta! Wir erlauben in der Regel keine Caching-Plugins in unserer Umgebung, da sie im Konflikt mit unserer integrierten Caching-Lösung stehen. Ab WP Rocket 3.0 wird die Page-Caching-Funktionalität jedoch automatisch deaktiviert, wenn sie auf Kinsta-Servern ausgeführt wird.

Dies ermöglicht es Kinsta-Kunden, unser schnelles Caching auf Serverebene zu verwenden, aber dennoch die fantastischen Optimierungsfunktionen von WP Rocket zu nutzen.

Kein Caching vs Caching

Wie viel hilft das Caching? Der Beweis liegt im Probieren.

Wir haben einige Geschwindigkeitstests mit dem Caching auf Serverebene von Kinsta durchgeführt, damit Du sehen kannst, welchen Unterschied es macht, sowohl in Bezug auf die Gesamtgeschwindigkeit als auch auf TTFB.

Kein Caching

Wir haben zuerst fünf Tests auf Pingdom ohne aktiviertes Caching durchgeführt und den Durchschnitt genommen.

Kein Caching TTFB

Es ist auch wichtig, den Unterschied in TTFB mit und ohne Caching zu beachten. TTFB in Pingdom wird durch die gelbe „wartende“ Leiste dargestellt. Wie man sieht, beträgt der TTFB ohne Caching 192 ms. Wie du sehen kannst, wird die Seite nicht aus dem Cache geladen, da der x-kinsta-cache Header ein MISS anzeigt.

Mit aktiviertem Caching

Dann haben wir fünf Tests mit Caching auf Server-Ebene aktiviert auf Pingdom durchgeführt und den Durchschnitt genommen.

Das Caching auf Server-Ebene hat unsere Seitenladezeit um 33,77% verkürzt! Und das ohne zusätzlichen Arbeitsaufwand. Diese von uns getestete Webseite ist schon ziemlich optimiert, so dass größere weniger optimierte Webseiten noch größere Unterschiede aufweisen werden.

TTFB mit aktiviertem Caching

Wenn wir uns nun die TTFB mit aktiviertem Caching ansehen, können wir sehen, dass sie unter 35 ms liegt. Man erkennt, dass es aus dem Cache bedient wird, da der x-kinsta-cache Header einen HIT anzeigt.

Der CDN-Cache ist ebenso wichtig wie der Cache von Deinem WordPress-Host. Wir werden weiter unten mehr über CDNs erfahren.

Probleme mit dem Caching und Mitgliederseiten

Mitgliederseiten enthalten viele nicht cachebare Inhalte und Seiten, die sich ständig ändern. Dinge wie die Login-Seite für Community-Mitglieder (die je nach Größe der Webseite ständig angegriffen werden können), Checkout-Seiten für digitale Waren oder Kurse und Diskussionsforen sind häufige Ursachen und Schwachstellen, da diese in der Regel nicht zwischengespeichert werden können.

Doch damit ist es noch nicht zu Ende. Auf Standard WordPress Seiten wird das WordPress Dashboard auch nicht für „angemeldete“ Benutzer zwischengespeichert. Das ist in Ordnung, wenn du nur ein paar Autoren und Administratoren hast, aber wenn plötzlich Tausende von Mitglieder das Dashboard benutzen, verursacht das sofort Performance-Probleme, da nichts davon aus dem Cache auf dem Server laufen kann. Das bedeutet, dass du die Kraft und Architektur hinter den Kulissen brauchst, um sie zu unterstützen. Shared Hosting Provider werden unter diesen Umständen in der Regel lahmgelegt.

Objekt Caching für hoch dynamische Webseiten

Wenn es um WordPress-Mitgliederseiten geht, sind deine üblichen Caching-Setups in der Regel nicht ausreichend, da sie nicht immer alle Vorteile nutzen. Hier kommt das Objekt-Caching ins Spiel.

Der Objekt-Cache speichert die Ergebnisse von Datenbankabfragen, so dass beim nächsten Mal, wenn ein bestimmtes Bit an Daten benötigt wird, diese aus dem Cache geliefert werden können, ohne die Datenbank abzufragen. Dies beschleunigt die PHP-Ausführungszeiten und entlastet deine Datenbank. Das wird bei Mitgliederseiten extrem wichtig! Mit WordPress kannst du das Objekt-Caching auf verschiedene Arten implementieren:

1. Eine Caching-Lösung eines Drittanbieters wie beispielsweise W3 Total Cache
2. Redis (empfohlen)
3. Memcached

Wir bieten Redis als Add-on bei Kinsta an, damit du den vollen Nutzen aus dem persistenten Objekt-Caching für deine Mitgliedsseiten ziehen kannst.

Cache analysieren

Erinnerst du dich an den x-kinsta-cache Header, den wir oben erwähnt haben? Abhängig von deinem Hosting-Provider oder deiner Caching-Lösung kann der Header etwas anders heißen. Jedes Mal, wenn eine Anfrage von deiner WordPress-Seite gestellt wird, hat dieser Header einen Wert, wie beispielsweise HIT, BYPASS, MISS und EXPIRED. Auf diese Weise kannst du sehen, wie der Cache funktioniert.

Die Erhöhung der Cache-Trefferrate Deiner WordPress-Seite ist wichtig, da Du möchtest, dass so viel von Deiner Seite aus dem Cache bedient wird wie möglich. Bei Kinsta kannst Du die Daten in unserem MyKinsta Analysetool und den Kinsta-Cache-Protokollen analysieren, um festzustellen, ob es Cache BYPASSing GET-Anfragen gibt, die zwischengespeichert oder POST-Anforderungen, die eliminiert werden könnten.

Der Cache component stack (wie unten gezeigt) zeigt den Status jeder Anforderung an, unabhängig davon, ob es sich um einen HIT, BYPASS, MISS oder EXPIRED handelt. Du kannst die Daten nach den letzten 24 Stunden, 7 Tagen oder 30 Tagen filtern.

Das Cache Component Chart gibt dir einen Überblick über dein Caching-Verhältnis. Je mehr Anfragen du aus dem Cache stellst, desto besser. Wie du im folgenden Beispiel sehen kannst, liegt diese WordPress-Seite bei einem HIT-Cache-Verhältnis von 96,2%, was sehr gut ist!

Im Abschnitt Bypasses des oberen Cache kannst du sehen, welche Requests nicht vom Cache bedient werden. Typischerweise können das CRON-Jobs, Admin-Ajax-Anfragen, E-Commerce-Checkout-Seiten, Query-Strings und UTM-Parameter sein etc.

Bildoptimierung ist ein Muss

Die Bildoptimierung ist eine weitere einfache Sache, die man unternehmen kann, um einen erheblichen Einfluss auf die Ladezeiten der gesamten Seite zu haben. Das ist nicht optional; jede Seite sollte das tun!

Große Bilder verlangsamen deine Webseiten, was zu einem nicht optimalen Benutzererlebnis führt. Die Optimierung von Bildern ist der Prozess der Verringerung der Dateigröße, entweder mit einem Plugin oder einem Skript, was wiederum die Ladezeit der Seite beschleunigt. Verlorene und verlustfreie Kompression sind zwei gängige Methoden.

Laut HTTP Archive machen Bilder ab August 2019 durchschnittlich 34% der Gesamtgröße einer Webseite aus. Nach Videos, die viel schwieriger zu optimieren sind, sind Bilder bei weitem der erste Anlaufpunkt! Es ist wichtiger als JavaScript, CSS und Fonts. Und ironischerweise ist ein guter Bildoptimierungs-Workflow eines der am einfachsten zu implementierenden Dinge, aber viele Webseitenbetreiber übersehen das.

Bereits im Dezember 2017 machten Bilder durchschnittlich 54% der Gesamtgröße einer Seite aus. Es scheint also, dass das Web als Ganzes bei der Bildoptimierung immer besser wird! Aber 34% ist immer noch eine Zahl, die nicht ignoriert werden darf. Wenn du keinen Videoinhalt auf deiner Webseite hast, sind Bilder wahrscheinlich immer noch dein größtes Laster in Bezug auf die Größe deiner Seite.

Finde die Balance (Dateigröße und Qualität)

Das Hauptziel der Formatierung deiner Bilder ist es, die Balance zwischen der niedrigsten Dateigröße und der akzeptablen Qualität zu finden. Es gibt mehr als eine Möglichkeit, fast alle dieser Optimierungen durchzuführen. Eine der grundlegendsten Möglichkeiten ist es, sie vor dem Hochladen auf WordPress zu komprimieren. Normalerweise kann das mit einem Tool wie Adobe Photoshop oder Affinity Photo erfolgen. Oder mit der neuen Squoosh-App von Google. Diese Aufgaben können aber auch automatisch über Plugins durchgeführt werden, auf die wir im Folgenden näher eingehen.

Die beiden wichtigsten Dinge, die zu berücksichtigen sind, sind das Dateiformat und die Art der Kompression, die du verwendest. Durch die Wahl der richtigen Kombination aus Dateiformat und Kompressionstyp kannst du deine Bildgröße um bis zu dem fünffachen reduzieren. Du musst mit jedem Bild oder Dateiformat experimentieren, um zu sehen, was am besten funktioniert.

Bevor Du anfängst, Deine Bilder zu bearbeiten, stelle sicher, dass Du den besten Dateityp ausgewählt hast. Es gibt mehrere Arten von Dateien, die man verwenden kann:

• PNG – erzeugt Bilder in höherer Qualität, hat aber auch eine größere Dateigröße; wurde als verlustfreies Bildformat erstellt, kann aber auch verlustbehaftet sein.
• JPEG – verwendet verlustbehaftete und verlustfreie Optimierung. Du kannst die Qualitätsstufe für ein ausgewogenes Verhältnis von Qualität und Dateigröße anpassen.

Im Idealfall solltest du JPEG (oder JPG) für Bilder mit viel Farbe und PNG für einfache Bilder verwenden.

Du solltest auch die Verwendung von WEBP-Bildern auf deiner Webseite in Betracht ziehen.

Was ist mit GIFs? Animierte GIFs machen immer Spaß, aber sie beeinträchtigen die Webleistung. Viele GIFs sind über 1 MB groß. Wir empfehlen, diese für Social Media und Slack aufzubewahren. Wenn es einen gibt, ohne den du in deinem Blog-Post nicht leben lassen kannst, solltest du animierte GIFs immer komprimieren.

Kompressionsqualität vs. Größe

Hier ist ein Beispiel dafür, was passieren kann, wenn man ein Bild zu stark komprimiert. Das erste ist die Verwendung einer sehr niedrigen Kompressionsrate, was zu höchster Qualität (aber größerer Dateigröße) führt. Das zweite ist die Verwendung einer sehr hohen Kompressionsrate, was zu einer sehr geringen Bildqualität (aber einer geringeren Dateigröße) führt. Hinweis: Das unveränderte Originalbild beträgt 2,06 MB.

Wie du sehen kannst, ist das erste Bild oben 590 KB groß. Das ist ziemlich groß für ein Foto! Es ist im Allgemeinen am besten, wenn du das Gesamtgewicht einer Webseite unter 1 oder 2 MB halten kannst. 590 KB wären schon ein Viertel davon. Das zweite Bild sieht schrecklich aus, aber dann sind es nur noch 68 KB. Was du tun solltest, ist ein geeignetes Mittelmaß zwischen der Kompressionsrate (Qualität) und der Dateigröße zu finden.

Also haben wir das Bild wieder mit einer mittleren Kompressionsrate aufgenommen, und wie Du unten sehen kannst, sieht die Qualität jetzt gut aus, und die Dateigröße beträgt 151 KB, was für ein hochauflösendes Foto akzeptabel ist. Dies ist fast 4x kleiner als das Originalfoto bei geringer Kompression. Wir versuchen, die meisten unserer Bilder unter der 100 KB-Marke zu halten, um die beste Leistung zu erzielen.

Verlustbehaftete vs. verlustfreie Optimierung

Bei der Komprimierung ist es wichtig sich ins Gedächtnis zu rufen, dass es zwei Arten von Kompression gibt, die man verwenden kann: verlustbehaftet und verlustfrei.

Bei der verlustbehafteten Komprimierung werden einige der Daten in deinem Bild entfernt. Folglich bedeutet das, dass du eine Verschlechterung (Qualitätsminderung oder was man auch als “verpixelt” bezeichnen würde) sehen könntest. Du musst also vorsichtig dabei sein, wie sehr du dein Bild reduzierst. Nicht nur wegen der Qualität, sondern auch, weil man den Vorgang nicht rückgängig machen kann. Tatsache ist aber, dass einer der großen Vorteile und Gründe der Popularität der verlustbehafteten Komprimierung ist, dass man die Dateigröße um einen beträchtlichen Betrag reduzieren kann.

Die verlustfreie Kompression verringert im Gegensatz zur verlustbehafteten Kompression nicht die Bildqualität. Wie ist das möglich? Das geschieht in der Regel durch das Entfernen unnötiger Metadaten (automatisch generierte Daten, die von dem Gerät erzeugt werden, das das Bild erfasst). Der größte Nachteil dieser Methode ist jedoch, dass es keine signifikante Verringerung der Dateigröße bewirken wird. Mit anderen Worten, es wird im Laufe der Zeit viel Speicherplatz einnehmen.

Du wirst mit dem experimentieren wollen, was am besten für Dich funktioniert. Aber für die Mehrheit der Benutzer empfehlen wir die verlustbehaftete Komprimierung, da man ein Bild leicht weit über 70% (manchmal sogar über 90%!) ohne großen Qualitätsverlust komprimieren kann. Multipliziere das mit 15 Bildern auf einer Seite, und es wird eine wichtige Rolle bei der Reduzierung der Ladezeit Deiner Webseite spielen.

Plugins für die Bildkomprimierung

Die großartige Nachricht ist, dass es einige erstaunliche WordPress Bildkompressionsplugins gibt, mit denen Du den gesamten Prozess automatisieren kannst. Hier sind einige Plugins, die wir empfehlen:

• Imagify (verlustbehaftet und verlustfrei – optimiert Bilder extern)
• WP Smush (verlustbehaftet und verlustfrei – optimiert Bilder extern)
• Optimole (lossy and lossless – optimizes images externally)
• ShortPixel (verlustbehaftet und verlustfrei – optimiert Bilder extern)

Das Wichtigste bei der Auswahl eines Plugins zur Bildoptimierung ist, eines zu verwenden, das Bilder extern auf deren Servern komprimiert und optimiert. Das wiederum reduziert die Belastung deiner Webseite. Alle der oben genannten Plugins gehen diesen Weg.

Falls du neugierig bist, bei Kinsta verwenden wir das Imagify-Plugin. Es komprimiert Bilder automatisch, wenn wir sie in die WordPress-Medienbibliothek hochladen. Also müssen wir uns um nichts Sorgen machen. Im Laufe der Zeit kannst du ein Gefühl dafür bekommen, welche Bildkompressionsstufe du verwenden möchtest. Es bietet Normal, Aggressiv und Ultra an.

Wir verwenden den aggressiven Modus bei Kinsta und sehen typischerweise 60-70% Einsparungen je nach Bild. Hinweis: Wir verwenden viel mehr PNGs als JPEGs, da die meisten unserer Bilder Symbole und Illustrationen sind und keine Fotos.

Wie viel schneller wird Deine WordPress-Seite sein, wenn Du die Bildkompression verwendest? Es hängt alles von den Größen der Originalbilder ab und wie stark sie nach der Komprimierung reduziert werden. Wir haben jedoch einige Geschwindigkeitstests durchgeführt und festgestellt, dass eine qualitativ hochwertige Bildkompressionslösung die Seitenladezeiten um über 80% verkürzen kann!

Lazy Loading

Wenn du viele Bilder hast, kannst du sie langsam laden lassen. Das ist eine Optimierungstechnik, die sichtbare Inhalte lädt, aber das Herunterladen und Rendern von Inhalten, die unter dem Seitenumbruch erscheinen, verzögert.

Werfe einen Blick in unseren Leitfaden zur Implementierung von Lazy Loading in WordPress. Dies kann besonders wichtig sein bei Blog-Posts mit vielen Gravatarsymbolen aus Kommentaren. Google veröffentlichte auch gerade ihre Empfehlungen für Lazy Loading.

Zusätzliche Tipps zur Bildoptimierung

Hier sind ein paar letzte Tipps zur Bildoptimierung, mit denen Du durchstarten kannst:

• Die Tage des Hochladens von Bildern, die nur auf die Breite der Spalte oder des DIV zugeschnitten sind, sind vorbei. Responsive Bilder funktionieren in WordPress (seit Version 4.4) sofort und zeigen mobilen Benutzern automatisch kleinere Bildgrößen an.
• SVGs können eine weitere großartige Alternative zur Verwendung von Bildern sein. Alle handgezeichneten Illustrationen, die Du auf der Kinsta Webseite siehst, sind SVGs (Vektoren). SVGs sind in der Regel viel kleiner in der Dateigröße, wenn auch nicht immer. Schaue Dir unser Tutorial an, wie Du SVGs auf deiner WordPress-Seite verwenden kannst.
• Benutze Symbolfonts, anstatt Text in Bildern zu platzieren – sie sehen besser aus, wenn sie skaliert werden und nehmen weniger Platz ein. Und wenn du einen Schriftgenerator verwendest, kannst du ihn noch weiter optimieren. Sieh dir an, wie wir die Größe unserer Icon-Fonts-Datei mit Hilfe eines Schriftgenerators um satte 97,59% reduziert haben.

Die Datenbank optimieren

Als nächstes folgen einige Tipps, wie man seine WordPress-Datenbank verfeinern kann. Genau wie ein Auto muss deine Datenbank gepflegt werden, da sie mit der Zeit aufgebläht wird.

Mitgliederseiten machen es besonders schwierig, da sie in der Regel komplexere Abfragen erzeugen, was wiederum zusätzliche Latenzzeiten beim Abrufen der Informationen aus der MySQL-Datenbank mit sich bringt. Das ist häufig auf die vielen unterschiedlichen Prozesse und die großen Mengen an Daten zurückzuführen, die bei diesem Seitentyp üblich sind. Das kann auch durch Webseiten verursacht werden, die stark auf Suchanfragen zur Navigation angewiesen sind oder WP_Query verwenden.

Nicht zu vergessen, sie haben auch eine große Anzahl gleichzeitiger Benutzer, die ständige die Datenbankabfragen erzeugen.

Verwende den InnoDB MySQL Storage Engine

Viele ältere Webseiten verwenden noch immer die MyISAM-Speichermaschine in ihrer Datenbank. In den letzten Jahren hat sich InnoDB als leistungsfähiger und zuverlässiger erwiesen.

Hier sind einige Vorteile von InnoDB gegenüber MyISAM:

• InnoDB hat eine Sperre auf Zeilenebene. MyISAM hat nur eine vollständige Sperre auf Tabellenebene. Dies ermöglicht eine schnellere Bearbeitung der Anfragen.
• InnoDB hat die so genannte referentielle Integrität, die die Unterstützung von Fremdschlüsseln (RDBMS) und Beziehungsbeschränkungen beinhaltet, MyISAM nicht (DMBS).
• InnoDB unterstützt Transaktionen, d.h. man kann Commit und Rollback durchführen. MyISAM nicht.
• InnoDB ist zuverlässiger, da es Transaktionsprotokolle für die automatische Wiederherstellung verwendet. MyISAM nicht.

Jetzt fragst Du Dich vielleicht, ob Du InnoDB oder MyISAM verwendest? Wenn Du auf einer ziemlich neuen WordPress-Seite arbeitest, besteht die Chance, dass Du bereits den InnoDB MySQL Storage Engine verwendest. Aber mit älteren WordPress-Seiten solltest Du vielleicht einen kurzen Check machen. Einige Seiten haben vielleicht sogar MyISAM- und InnoDB-Tabellen gemischt und abgeglichen, in denen Du Verbesserungen erzielen kannst, indem Du einfach alles konvertierst.

Befolge diese einfachen Schritte unten, um zu überprüfen.

Schritt 1

Schritt 2

Führe einen Schnellscan oder eine Sortierung der Spalte „Typ“ durch, und du kannst sehen, welche Speicher-Engine Typen deine Tabellen verwenden. In diesem Beispiel unten ist ersichtlich, dass zwei der Tabellen noch MyISAM verwenden.

MyISAM Datenbank TabellenWenn Du welche gefunden hast, dann ist es wahrscheinlich an der Zeit, sie nach InnoDB zu verschieben. Wir empfehlen immer, sich an den eigenen Host zu wenden und ihn zu fragen, ob er dies für einen tun kann. Bei Kinsta werden die Datenbanktabellen jedes Kunden von unserem Migrationsteam automatisch in InnoDB umgewandelt.

Du kannst aber jederzeit diese Tutorials unten befolgen, um Deine MyISAM-Tabellen manuell in InnoDB zu konvertieren:

Konvertiere MyISAM in InnoDB mit phpMyAdmin.

Konvertiere MyISAM nach InnoDB mit WP-CLI

Entferne und limitiere Seiten und Post Revisionen

Wann immer du eine Seite oder einen Beitrag in WordPress speicherst, erstellt es eine sogenannte Revision. Das geschieht sowohl bei Entwürfen als auch bei bereits veröffentlichten Beiträgen, die aktualisiert werden. WordPress Revisionen können hilfreich sein, wenn du zu einer früheren Version deines Inhalts zurückkehren musst.

WordPress revision

Änderungen können jedoch auch die Leistung deiner WordPress-Seite beeinträchtigen. Auf großen Webseiten kann das sehr schnell zu Tausenden von Zeilen in deiner Datenbank führen, die nicht unbedingt benötigt werden. Und je mehr Zeilen du hast, desto größer ist deine Datenbank, was Speicherplatz in Anspruch nimmt. Obwohl Indizes gerade für diesen Zweck erstellt wurden, können sie WordPress-Seiten trotzdem lähmen. Es gibt jedoch ein paar Dinge, die du tun kannst.

1. Entferne alte Revisionen

Wenn Du eine ältere WordPress-Seite mit vielen Seiten und Beiträgen hast, könnte es an der Zeit sein, eine schnelle Bereinigung durchzuführen und diese alten Revisionen zu löschen. Du kannst dies mit MySQL tun, aber mit all den schlechten Codeausschnitten, die im Web herumfliegen, empfehlen wir ein Backup Deiner Webseite und die Verwendung eines kostenlosen Plugins wie WP-Sweep.

Ein weiteres unserer Lieblings-Plugins, WP Rocket, verfügt ebenfalls über eine Datenbankoptimierungsfunktion, um Revisionen zu entfernen.

WP Rocket DatenbankoptimierungFalls Du mit WP-CLI vertraut bist, gibt es ein paar Befehle, die Du dafür verwenden kannst.

Melde Dich über SSH bei Deinem Server an und führe den folgenden Befehl aus, um die Anzahl der Revisionen, die sich derzeit in der Datenbank befinden, abzurufen und zu sehen.

wp revisions list

WP CLI ReviosionslisteWenn Du einen Fehler erhältst, musst Du möglicherweise zuerst das Paket wp-revisions-cli Paket mit dem folgenden Befehl installieren:

wp package install trepmal/wp-revisions-cli

Du kannst dann den folgenden Befehl ausführen, um die Revisionen zu bereinigen:

wp revisions clean

2. Revisionen limitieren

Eine weitere gute Strategie, die wir bei Kinsta verfolgen, ist die Begrenzung der Anzahl der Revisionen, die pro Beitrag oder Seite gespeichert werden können. Selbst wenn man diese etwa auf zehn setzt, werden Revisionen nicht außer Kontrolle geraten, besonders, wenn man viele Updates durchführt.

Um Revisionen zu begrenzen, kannst du den folgenden Code zu deiner wp-config.php-Datei hinzufügen. Der untenstehende Code muss über dem ‚ABSPATH‘ eingefügt werden, sonst funktioniert er nicht. Du kannst die Nummer auf beliebig viele Revisionen ändern, die Du in Deiner Datenbank speichern möchtest.

define('WP_POST_REVISIONS', 10);

Beschränkung von Beitragsrevisionen in wp-config.phpOder du benutzt ein Plugin wie Perfmatters um das Limit einzustellen.

Begrenzung der Beitragsrevisionen mit dem Perfmatters Plug-In

3. Revisionen deaktivieren

Und zu guter Letzt kannst du auch Revisionen auf deiner Seite komplett deaktivieren. In diesem Fall empfehlen wir dir dringend, der ersten Option oben zu folgen, um Revisionen zu löschen und sie anschließend zu deaktivieren. Auf diese Weise ist deine Datenbank völlig frei von allen alten Revisionen und es werden in Zukunft keine neuen mehr hinzugefügt.

Um Revisionen zu deaktivieren, kannst Du den folgenden Code zu Deiner wp-config.php-Datei hinzufügen. Der untenstehende Code muss über dem ‚ABSPATH‘ eingefügt werden, sonst funktioniert er nicht.

define('WP_POST_REVISIONS', false);

Deaktivierung der Beitragsrevisionen in wp-config.phpOder du benutzt ein Plugin wie Perfmatters um Revisionen komplett zu deaktivieren.

Deaktivierung von Beitragsrevisionen mit dem Perfmatters Plug-In

Bereinige deinee wp_options Tabelle und automatisch geladene Daten

Die Tabelle wp_options wird oft übersehen, wenn es um die allgemeine WordPress- und Datenbankleistung geht. Besonders auf älteren und großen Webseiten kann das leicht der Grund für langsame Suchanfragen auf deiner Webseite sein aufgrund von automatisch geladenen Daten, die von Plugins und Themes von Drittanbietern zurückgelassen werden. Vertraue uns, wir sehen das jeden Tag!

Die Tabelle wp_options enthält alle möglichen Daten für deine WordPress-Seite, wie z.B.:

• Site-URL, Home-URL, Admin-E-Mail, Standardkategorie, Beiträge pro Seite, Zeitformat, etc.
• Einstellungen für Plugins, Themes, Widgets etc.
• Temporär zwischengespeicherte Daten

wp_options Tabelle in der WordPress DatenbankDiese Tabelle enthält folgende Felder (columns):

• option_id
• option_name
• option_wert
• Autoload (das ist das, was uns wichtig ist, wenn es um die Leistung geht)

Autoload DatenEines der wichtigsten Dinge, die man über die Tabelle wp_options wissen sollte, ist das Feld autoload. Dieses enthält einen Ja- oder Nein-Wert (Flag). Das steuert im Wesentlichen, ob es von der Funktion wp_load_alloptions() geladen wird oder nicht. Automatisch geladene Daten sind Daten, die auf jeder Seite deiner WordPress-Seiten abgerufen werden. Genauso wie wir dir gezeigt haben, wie du bestimmte Skripte vom standortübergreifenden Laden ausschließen kannst, gilt hier derselbe Ansatz. Das autoload-Attribut ist für Entwickler standardmäßig auf „yes“ gesetzt, aber nicht jedes Plugin sollte theoretisch seine Daten auf jeder Seite laden.

Das Problem, auf das WordPress-Seiten stoßen können, ist, wenn sich eine große Menge an automatisch geladenen Daten in der Tabelle wp_options befindet. Das ist in der Regel eine Konsequenz aus dem Folgenden:

• Die Daten werden von einem Plugin automatisch geladen, auch wenn sie eigentlich auf „nein“ gesetzt werden könnten. Ein gutes Beispiel dafür ist ein Kontaktformular-Plugin. Muss es diese Daten auf jeder Seite laden oder würde die Kontaktseite reichen?
• Plugins oder Themes wurden von der WordPress-Seite entfernt, aber ihre Optionen bleiben in der Tabelle wp_options zurück. Das kann dazu führen, dass bei jeder Anforderung unnötige, automatisch geladene Daten abgefragt werden.
• Plugin- und Theme-Entwickler laden Daten in die Tabelle wp_options anstatt ihre eigenen Tabellen zu verwenden. Es gibt Argumente dafür und dagegen, da einige Entwickler Plugins bevorzugen, die keine zusätzlichen Tabellen erstellen. Die Tabelle wp_options ist jedoch auch nicht für Tausende von Zeilen ausgelegt.

Wie viel sind zu viele Daten? Das kann natürlich variieren, aber idealerweise möchtest du, dass diese zwischen 300 KB und 1 MB liegt. Sobald sie anfangen, sich dem Bereich von 3-5 MB oder mehr zu nähern, gibt es höchstwahrscheinlich Dinge, die optimiert oder entfernt werden können, wenn sie automatisch geladen werden. Und alles, was über 10 MB hinausgeht, sollte sofort in Angriff genommen werden. Das bedeutet nicht immer, dass es ein Problem verursachen wird, aber die Möglichkeit besteht.

Da dies ein beträchtliches Problem darstellt, haben wir ein komplettes separates Tutorial, das Du lesen solltest, wie man am besten Probleme mit autoloadeten Daten löst und wie man sie bereinigt.

Bereinigung von Transienten

Sofern du keinen Objekt-Cache verwendest, speichert WordPress transiente Datensätze in der Tabelle wp_options. Typischerweise erhalten diese eine Verfallszeit und sollten mit der Zeit verschwinden. Das ist jedoch nicht immer der Fall. Wir haben einige Datenbanken gesehen, in denen es Tausende von alten transienten Datensätzen gibt. Tatsächlich haben wir uns an einem Standort mit einigen korrupten transienten Datensätzen beschäftigt, bei denen über 695.000 Zeilen in der Tabelle wp_options erzeugt wurden.

Beschädigte Transienten in der Tabelle wp_optionsEs ist auch wichtig zu beachten, dass Transienten standardmäßig nicht automatisch geladen werden. Du könntest eine Abfrage wie die folgende verwenden, um zu sehen, ob es automatisch geladene transiente Daten gibt.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

Eine bessere und sicherere Option wäre die Verwendung eines kostenlosen Plugins wie Transient Cleaner oder Delete Expired Transients, das nur die abgelaufenen Transienten aus der Tabelle wp_options bereinigen kann. Es scheint jedoch, dass es jetzt eine Funktion in WordPress gibt, die in 4.9 hinzugefügt wurde, dass sich um abgelaufene Transienten kümmert. Somit wird das hoffentlich zukünfitg automatisch auf deiner Seite geschehen.

WP Rocket bietet auch die Möglichkeit, Transienten in ihren Datenbankoptimierungsoptionen zu bereinigen.

Bereinige Transienten mit WP Rocket

WordPress Sitzungen bereinigen

Ein weiteres häufiges Problem, das wir gesehen haben ist, dass Cronjobs manchmal nicht synchronisiert oder nicht richtig ausgelöst werden, und Sitzungen daher nicht bereinigt werden. Es kann passieren, dass du Tonnen von _wp_session_ Zeilen in deiner Datenbank ansammelst. In diesem Beispiel unten wurde die betreffende Webseite mit über 3 Millionen Zeilen in der Tabelle wp_options abgeschlossen. Und die Tabelle war auf über 600 MB angewachsen.

wp_options Tabelle mit Millionen an ZeilenDu könntest eine Abfrage wie die untenstehende verwenden, um zu sehen, ob du auf dieses Problem gestoßen bist:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

wp-session ZeilenIn den meisten Fällen kannst du diese dann mit dem folgenden Befehl sicher löschen (wie es ein Cron-Job getan haben sollte):

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Nach der Bereinigung aller übrig gebliebenen _wp_session_ rows Zeilen hatte die Tabelle weniger als 1.000 Zeilen und wurde auf 11 MB reduziert.

WP Sitzungen, nachdem sie bereinigt wurdenEs wurden auch die Spikes behoben, die die Seite in MySQL erhielt.

MySQL web transactions

Füge einen Autoload zum Index hinzu

Wenn das Bereinigen deiner wp_options -Tabelle nicht ausreicht, kannst du versuchen, dem Feld Autoload einen „Index“ hinzuzufügen. Das kann im Wesentlichen dazu beitragen, dass die Suche effizienter wird. Das großartige Team von 10up führte einige Tets an einer wp_options-Tabelle mit einer typischen Anzahl von autloload Datensätzen durch, um zu zeigen, wie das Hinzufügen eines Autoload-Index zu wp_options-Abfragen die Leistung steigern kann.

wp_options Anfragenzeit (Bildquelle: 10up)Wir empfehlen auch, diese beiden zusätzlichen Ressourcen von WP Bullet zu überprüfen:

• So fügst du den MySQL-Index zur Tabelle wp_options hinzu
• Bereinigung der Tabelle wp_options mit WP-CLI

Nutze Redis als einen Persistenten Objekt Cache für WordPress

Redis ist ein Open-Source-Speicher für Datenstrukturen im Speicher. Im Rahmen von WordPress kann Redis verwendet werden, um die vom nativen Objekt-Cache von WordPress erzeugten Werte dauerhaft zu speichern, so dass zwischengespeicherte Objekte zwischen den Seitenladevorgängen wiederverwendet werden können.

Die Verwendung eines persistenten Objekt-Cache wie Redis ermöglicht die Wiederverwendung von zwischengespeicherten Objekten, anstatt dass die MySQL-Datenbank ein zweites Mal für dasselbe Objekt abgefragt werden muss. Das Ergebnis ist, dass Redis die Last auf die MySQL-Datenbank einer Webseite reduzieren, gleichzeitig die Antwortzeit der Webseite verkürzen und die Fähigkeit der Seite erhöhen kann, zu skalieren und zusätzlichen Traffic zu verarbeiten.

Hochdynamische Webseiten (WooCommerce, Mitgliederseiten, Foren, Diskussionsforen, Blogs mit extrem aktiven Kommentarsystemen), die das Page Caching nicht sinnvoll nutzen können, sind potenzielle Kandidaten für eine persistente Objekt-Caching Option wie Redis.

Wenn Du Kinsta-Kunde bist, bieten wir ein Redis-Add-on an. Erfahre, wie du Redis zu deinem Hosting-Angebot hinzufügen kannst.

Nutze Elasticsearch um die WordPress Suchfunktion zu beschleunigen

Elasticsearch ist eine Open-Source-Volltextsuchmaschine. Es wird verwendet, um Daten zu indizieren und diese unglaublich schnell zu durchsuchen.

Im Rahmen von WordPress kann mit Elasticsearch die Abfrage der WordPress-Datenbank beschleunigt werden. Das geschieht, indem man einen Index des Inhalts der Datenbank deiner Webseite erstellt und dann Elasticsearch verwendet, um diesen Index viel schneller zu durchsuchen, als eine MySQL-Abfrage in der Lage ist, die gleiche Suche durchzuführen.

Wenn Du die Zeit und die Fähigkeit hast, kann Elasticsearch von einem sehr erfahrenen WordPress- und Elasticsearch-Entwickler in eine WordPress-Seite integriert werden. Wenn Deine Webseite relativ standardmäßig WP_Query verwendet, kann Elasticsearch auch durch die Installation von ElasticPress integriert werden, einem kostenlosen WordPress-Plugin von 10up, das auf WordPress.org verfügbar ist und automatisch in das WP_Query-Objekt integriert wird, um Abfrageergebnisse mit Elasticsearch und nicht mit MySQL zu generieren.

Jede Webseite, die WP_Query intensiv nutzt, kann von Elasticsearch profitieren. Beispiele für Webseiten, die von Elasticsearch profitieren können:

• Seiten, bei denen die Suche das primäre Navigationsmittel ist
• WooCommerce-Seiten mit einer großen Anzahl von Bestellungen, bei denen die Administratoren der Webseite in der Lage sein müssen, die Liste der Bestellungen regelmäßig zu durchsuchen.
• Jede Webseite mit einer großen Anzahl von Beiträgen, bei der MySQL-Abfragen zu inakzeptabel langsamen Ergebnissen führen.

Deaktiviere nicht essentielle Merkmale, die Datenbankintensiv sind

Das mag ein wenig offensichtlich erscheinen, aber es kann einen großen Unterschied machen, wenn du weniger wichtige Plugins und Themenfunktionen deaktivierst, die datenbankintensiv sind.

• Beliebte und/oder verwandte Post-Widgets und Plugins sind schrecklich. Sie haben typischerweise umfangreiche, seitenweiten Abfragen.
• Bildoptimierungs-Plugins, die Bilder mit Deinem Server komprimieren; Du solltest immer ein Bildoptimierungs-Plugin verwenden, das Bilder extern optimiert.

Wenn du den Kinsta-Blog besuchst und bis zum Ende eines Beitrags scrollst, wirst du feststellen, dass wir sogenannte „handverlesene“ Artikel haben. Diese werden von uns manuell ausgewählt und dem Beitrag zugeordnet. Das reduziert die Abfrage auf fast nichts und beeinträchtigt nicht die Leistung deiner gesamten Webseite. Nimmt es mehr Arbeit in Anspruch? Ja, aber es ist hilfreich, da du wählen kannst, was die Leser sehen sollen.

WordPress bezogene ArtikelWie haben wir das geschafft? Wir haben das erstaunliche Advanced Custom Fields Plugin verwendet und diese Felder dann unserem Blog-Post-Typ zugeordnet. Das ermöglicht es uns, jeden unserer Blog-Posts (wie unten gezeigt) zu durchsuchen und mit verwandten Inhalten zu versehen.

Zugeordnete Beiträge zuweisenWir empfehlen auch, sich von Plugins fernzuhalten, die einen View/Post-Counter deiner Webseite hinzufügen, es sei denn, du benötigst ihn unbedingt. Vermeide beispielsweise Dinge wie „792 Beiträge“ neben dem Avatar eines Benutzers in Forumsbeiträgen oder „5.243 Ansichten“, wenn du Forumsbeiträge auflistest. Wenn du eine lange Diskussion hast, werden diese Zähler eine enorme Belastung für deine Datenbank darstellen. Im Allgemeinen solltest du den Einsatz von Zählern minimieren und sie nur bei Bedarf verwenden.

Das gilt auch für viele Social Counters. Zum Beispiel, auf dieser Seite unten kannst du sehen, dass die Antwortzeit von dem beliebten Social Warfare Plugin 30x länger ist als das nächste Plugin darunter. Das Caching ist aktiviert, aber offensichtlich birgt dieses Plugin einen erheblichen Performanceverlust. Nachdem das Plugin auf der Webseite deaktiviert wurde, verbesserten sich die Ladezeiten sofort und die Reaktionsfähigkeit des WordPress Admin Dashboards wurde verbessert.

Social Warfare Ladezeiten

Verwenden eines Content Delivery Network (CDN)

CDN ist die Abkürzung für Content Delivery Network. Das ist ein Netzwerk von Servern (auch bekannt als POPs), die sich auf der ganzen Welt befinden. Sie wurden entwickelt, um Kopien der statischen (und manchmal auch dynamischen) Inhalte deiner WordPress-Seite wie Bilder, CSS, JavaScript und Videostreams bereitzustellen.

Erstens sind ein CDN und ein WordPress Host nicht zu verwechseln. Es handelt sich dabei um völlig getrennte Dienstleistungen. Ein CDN ist kein Ersatz für Deinen Hosting-Provider, sondern eine zusätzliche Möglichkeit, die Geschwindigkeit Deiner Webseite zu erhöhen. Während unser Hosting hier in Kinsta rasant schnell ist, kann ein CDN Deine Webseite noch schneller machen.

Wie funktioniert ein CDN

Wie funktioniert ein CDN genau? Nun, wenn Du zum Beispiel Deine Webseite bei Kinsta hosten möchtest, musst Du einen physischen Rechenzentrumsstandort wählen, wie z.B. die USA, Europa, Asien-Pazifik oder Südamerika.

Angenommen, Du entscheidest dich für Zentralamerika. Das bedeutet, dass sich Deine Webseite physisch auf einem „Host-Server“ in Council Bluffs, Iowa, befindet. Wenn Menschen in Europa Deine Webseite besuchen, wird es länger dauern, bis sie geladen ist, als wenn jemand sie von Dallas, TX, besucht.

Warum? Weil die Daten eine weitere Strecke zurücklegen müssen. Das ist die sogenannte Latenzzeit. Latenzzeit bezieht sich auf die Zeit und/oder Verzögerung, die bei der Übertragung von Daten über ein Netzwerk anfällt. Je weiter der Abstand, desto größer die Latenzzeit.

Verschiedene CDN Arten

Es gibt zwei verschiedene Arten von Content Delivery Networks:

• Traditionelles Pull CDN
• Reverse Proxy CDN

Traditionelle Pull-CDNs speichern eine Kopie all Deiner Inhalte und Medien im Cache, aber eine Anfrage des Kunden wird immer noch direkt an Deinen Hosting-Provider gerichtet. KeyCDN und CDN77 sind Beispiele für traditionelle CDNs.

Ein Reverse-Proxy-CDN ist etwas anders. Während es sich immer noch wie ein CDN verhält, fängt es alle eingehenden Anfragen ab und fungiert als Zwischenserver zwischen dem Client und dem Host. Cloudflare und Sucuri sind Beispiele für Reverse-Proxy-CDNs. Dies ist ein Grund, warum Du Dein DNS direkt auf diese Anbieter und nicht auf Deinen Host verweisen musst.

Der Vorteil hier ist, dass sie als Zwischenserver fungieren und somit auch als Firewall dienen können, und etwa unerwünschten Traffic blockieren können, sodass dieser Deinen Host und somit Deine WordPress-Seite gar nicht erst erreicht. Ein Nachteil hingegen ist, dass sie im Vergleich zu einem herkömmlichen Pull-CDN mit zusätzlichem Leistungsaufwand verbunden sind. Aber mit zusätzlichen Leistungs- und Sicherheitsfunktionen kann das als vernachlässigbar angesehen werden.

Nachfolgend wird anhand eines Beispiels gezeigt, was nach der Aktivierung von Sucuri auf der Webseite eines Kunden passiert. Wie Du sehen kannst, hat es einen enormen Einfluss auf die Menge an schlechtem Traffic gehabt, der durchkommt. Letztendlich können diese Arten von Diensten dazu beitragen, dass Du Hostingkosten einsparst.

Ressourcen nach Sucuri WAF

CDN Speed Tests

Vorhin haben wir über die großen Vorteile des WordPress-Caching gesprochen. Nun, CDN-Caching ist auch super mächtig. Das liegt daran, dass CDNs in der Regel viel mehr Serverstandorte haben als Hosting-Provider. Das bedeutet, dass sie alle deine Assets (Bilder, JS, CSS) näher bei deinen Besuchern zwischenspeichern und mit rasanter Geschwindigkeit bereitstellen können.

Lass uns ein paar Kurztests durchführen, um zu sehen, wie viel schneller deine Seite mit einem CDN sein könnte.

Ohne CDN

Unsere Test-Webseite wird bei Kinsta gehostet und befindet sich physisch im Rechenzentrum in Iowa, USA. Wir haben zuerst fünf Geschwindigkeitstests in Pingdom durchgeführt (ohne aktiviertes CDN) und den Durchschnitt genommen. Wichtig: Wir nutzen den Standort Europa – Großbritannien – London in Pingdom, um die wahre Leistungsfähigkeit eines CDNs zu demonstrieren. Die Gesamtladezeit betrug 1,03 s.

Geschwindigkeitstest ohne CDN

Mit CDN

Wir aktivierten dann unser CDN und führten fünf weitere Geschwindigkeitstests in Pingdom durch. Unsere Gesamtladezeit beträgt nun 585 ms vom Testort Europa – Großbritannien – London Pingdom. Durch die Verwendung des CDN konnten wir also unsere Seitenladezeiten um 43,2% verringern! Das ist ein Wahnsinn.

Geschwindigkeitstest mit CDNDer Grund für diesen drastischen Unterschied ist, dass das CDN über ein Rechenzentrum in London verfügt. Das bedeutet, dass alle Assets an diesem Ort zwischengespeichert werden und mit minimaler Latenz bedient werden können.

TTFB ohne CDN

Denk daran, dass der gelbe Balken in Pingdom für Wartezeit steht, also Zeit bis zum ersten Byte (TTFB). Bei unseren Geschwindigkeitstests ohne das laufende CDN lag der durchschnittliche TTFB auf Assets bei etwa 98 ms.

TTFB ohne CDN

TTFB mit CDN

Sobald wir das CDN aktiviert haben, sank der durchschnittliche TTFB auf durchschnittlich 15 ms. Durch die Verwendung eines CDN sank unser durchschnittlicher TTFB also um 84,69%. Dies liegt vor allem daran, dass die Assets direkt aus dem Cache des CDN bedient wurden.

TTFB mit CDN

Wie man ein CDN aktiviert

Das Aktivieren eines CDN auf Deiner WordPress-Seite muss nicht schwer sein, es ist ganz einfach! Folge einfach diesen Schritten.

Schritt 1

Das Aktivieren eines CDN auf Deiner WordPress-Seite muss nicht schwer sein, es ist ganz einfach! Folge einfach diesen Schritten.

Wenn Du Dich mit der Bereitstellung von KeyCDN selbst beschäftigst, empfehlen wir Dir, diesen Artikel über CDN für Dummies zu lesen. Jeder CDN-Anbieter sollte auch eine Dokumentation haben, die den Einstieg erleichtert.

Wir haben ausführliche Tutorials zur Installation von Cloudflare und zur Installation von Sucuri.

Schritt 2

Wenn Du ein traditionelles Pull-CDN verwendest, kannst Du kostenlose Plugins wie CDN Enabler, WP Rocket oder Perfmatters verwenden, um es in Deine WordPress-Seite zu integrieren. Diese Plugins verknüpfen Deine Assets automatisch mit dem CDN. Es ist keine zusätzliche Arbeit Deinerseits erforderlich, um Deine Inhalte auf das CDN zu bringen; das funktioniert alles von selbst! Reverse Proxy-CDNs benötigen in der Regel keine Plugins, obwohl sie manchmal über sie verfügen, um zusätzliche Funktionen zu aktivieren.

Aktivierung von CDN in WordPress mit Perfmatters

Wie man das CDN bei Kinsta aktiviert

Hat dir die CDN-Geschwindigkeitsprüfung oben gefallen? Wir haben KeyCDN in diesen Tests verwendet. Die tolle Nachricht ist, dass unser Kinsta CDN auf KeyCDN basiert. Es handelt sich um ein HTTP/2- und IPv6-fähiges Content-Delivery-Netzwerk mit 34 Standorten, das deine Assets und Medien rund um den Globus auf Hochtouren befördert. Zu den derzeit bedienten Regionen gehören Amerika, Südamerika, Europa, Afrika, Asien und Australien.

Kinsta CDN NetzwerkWenn du ein Kinsta-Kunde bist, integrieren wir kostenlose CDN-Bandbreite in alle unsere Hosting-Angebote. Du kannst das Kinsta CDN in zwei einfachen Schritten aktivieren.

Schritt 1

Melde dich zunächst in deinem MyKinsta Dashboard an. Klicke dann auf deine Webseite und dann auf die Registerkarte CDN.

Schritt 2

Klicke dann auf „Kinsta CDN aktivieren“. Nach einigen Minuten wird das CDN automatisch bereitgestellt, und Deine Assets werden aus dem Cache rund um den Globus bereitgestellt. Das war’s dann auch schon. 😄

Zusätzliche CDN Optimierungen

Hier sind ein paar zusätzliche CDN-Optimierungen, die Du vielleicht ausprobieren oder in Betracht ziehen möchtest.

• Wenn man viele Kommentare hat, können Gravatare viele Anfragen generieren. Sie werden vom secure.gravatar.com geladen. In diesem Tutorial erfährst du, wie du stattdessen Gravatare aus deinem CDN laden kannst. Das tun wir auch auf der Kinsta-Webseite.
• Du kannst deine benutzerdefinierten Webfonts von deinem CDN oder sogar von Google-Fonts auf Deinem CDN hosten. Schaue dir unser ausführliches Tutorial über lokale Schriften an.

Achte darauf, dass du dein Favicon von deinem CDN lädst. Auch wenn es klein ist, jede Anfrage zählt!

Medien und Emails auslagern falls nötig

Alles, was eine Anfrage generiert, hat auf die eine oder andere Weise Auswirkungen auf die Leistung deiner Webseite. Für Webseiten mit Hunderttausenden von Dateien oder großen Medien kann es sinnvoll sein, das vollständig auszulagern. Das Auslagern unterscheidet sich von der Bereitstellung über ein CDN. Bei einem CDN befinden sich die Originaldaten noch auf deinem Host, das CDN hat einfach mehrere Kopien davon.

Wenn das Caching für deine CDN-Assets abläuft, fragt es deinen Host nach den neuesten Kopien der Dateien. Aber da sie auf so viele POPs setzen, müssen Dateien häufig erneut in den Cache geladen werden, weil dieser in verschiedenen Regionen ausläuft. Das könnte eine Menge zusätzlicher Abfragen bedeuten.

Wenn du Medien oder Dateien auslagerst, bedeutet das, dass du den ursprünglichen physischen Speicherort von ihnen tatsächlich von deinem Hosting-Provider verlagerst. Während es also den Anschein haben mag, dass die Dateien von deiner Webseite aus bereitgestellt werden, befinden sie sich in Wirklichkeit an einem anderen Ort. Neben der Reduzierung zusätzlicher Anfragen an den Host ist der wichtigste Grund natürlich, auch Speicherplatz zu sparen.

Medien zu Amazon S3 auslagern

Eine der beliebtesten Auslagerungslösungen ist Amazon S3. Amazon S3 ist eine Speicherlösung und eines vieler Amazon Web Services Produkte. Typischerweise wird das für große Webseiten verwendet, die entweder zusätzliche Backups benötigen oder große Dateien bereitstellen (Downloads, Software, Videos, Spiele, Audiodateien, PDFs, etc.). Amazon hat sich als sehr zuverlässig erwiesen und kann aufgrund seiner massiven Infrastruktur sehr niedrige Speicherkosten anbieten. Zu den Kunden von S3 gehören unter anderem Netflix, Airbnb, SmugMug, Nasdaq etc.

Da sie sich ausschließlich mit Massenspeicher befassen, können sie fast garantieren, dass die Preise billiger sind als bei deinem WordPress Host. Das Offloading von Medien auf AWS kann eine sehr gute Möglichkeit sein, Geld zu sparen und ist für das erste Jahr kostenlos (bis zu 5 GB Speicherplatz). Da die Anfragen für deine Medien direkt von Amazon bedient werden, wird deine WordPress-Seite weniger belastet, was zu schnelleren Ladezeiten führt.

In unserem ausführlichen Tutorial erfährst du, wie du WordPress-Medien auf Amazon S3 abladen kannst.

Medien auf Google Cloud Storage auslagern

Eine weitere beliebte Offloading-Lösung ist Google Cloud Storage. Da Kinsta von der Google Cloud Plattform betrieben wird, sind wir große Fans der Technologie und Infrastruktur. Aufgrund der massiven Infrastruktur von Google und der Tatsache, dass sie sich mit Massenspeichern befassen, können sie sehr niedrige Speicherkosten anbieten. Zu den Kunden gehören unter anderem Spotify, Vimeo, Coca-Cola, Philips, Evernote und Motorola.

In unserem ausführlichen Tutorial erfährst Du, wie Du WordPress-Medien in Google Cloud Storage auslagern kannst.

Transaktions- und Marketingemails auslagern

Ganz gleich, ob du davon überzeugt bist oder nicht, E-Mails haben Auswirkungen auf deine Server- und Serverressourcen. Bei einigen Hosts, insbesondere bei Shared Hosts, könnte ein Missbrauch sogar zur Suspendierung führen. Das wird insbesondere bei denen, die versuchen, Massen-E-Mails zu versenden, zu einem Problem. Das ist der Grund, warum es Drittanbieter für transaktionale E-Mail-Provider gibt und warum viele Hosting-Provider die E-Mail-Zustellung auf Standardports insgesamt blockieren. Wir raten davon ab, deinen Hosting-Provider für E-Mails zu verwenden.

Wenn du Newsletter oder Massen-E-Mails versendest, empfehlen wir immer die folgenden Alternativen, um die besten Ergebnisse zu erzielen:

• Verwende eine professionelle E-Mail-Marketing-Software von Drittanbietern, die nicht Teil von WordPress ist.
• Verwende einen transaktionalen E-Mail-Dienstleister (HTTP-API oder SMTP) zusammen mit WordPress.

Weitere Vorteile der Nutzung eines Drittanbieter-Service sind:

• Bessere Zustellbarkeit von E-Mails. Lass die E-Mail-Anbieter das tun, was sie am besten können!
• Bessere Chancen, schwarze Listen zu vermeiden.
• Es ist möglicherweise nicht immer möglich, DMARC-Einträge mit deinem Hosting-Provider einzurichten.

Email Marketing Tools

Einige Beispiele für Marketing-E-Mails sind Newsletter, Produkt- und Feature-Ankündigungen, Verkäufe, Event-Einladungen, Onboard-Erinnerungen etc. Hier sind ein paar E-Mail-Marketing-Tools, die wir empfehlen:

• MailChimp – Wir verwenden MailChimp bei Kinsta.
• MailerLite
• Drip

Transaktionale E-Mail-Dienste

Einige Beispiele für transaktionale E-Mails sind Kaufbelege von WooCommerce oder EDD, Benachrichtigungen zur Kontoerstellung, Versandbenachrichtigungen, App-Fehlermeldungen, Passwort-Rücksetzungen usw. Wenn du ein Kinsta-Kunde bist, verlassen wir uns auf einen externen SMTP-Anbieter, um eine hohe Lieferfähigkeit zu gewährleisten. Aber abhängig von deinem Volumen empfehlen wir immer, dieses außerhalb zu verschieben. Hier sind ein paar Transaktions-E-Mail-Dienste, die wir empfehlen:

• SendGrid – Wir verwenden SendGrid bei Kinsta.
• Mailgun – Sieh wie du Mailgun in WordPress konfigurierst.
• SparkPost

Wie man Engpässe und langsame Plugins findet

Nun werden wir dir einige Tipps offenbaren, wie man Engpässe auf deiner WordPress-Seite findet und was du dagegen tun kannst.

Verwende New Relic um langsame Plugins und Datenbankanfragen zu identifzieren

Es gibt einige großartige Tools auf dem Markt, die dir helfen können, langsame Datenbankabfragen und Plugins zu lokalisieren und zu identifizieren, die viel Zeit in Anspruch nehmen. Wir sind große Fans von New Relic bei Kinsta und nutzen es täglich. New Relic ist ein PHP-Monitoring-Tool, mit dem du detaillierte Leistungsstatistiken auf deiner Webseite erhalten kannst.

Wenn Du ein Kinsta-Kunde bist, kannst Du sogar Deinen eigenen New Relic-Lizenzschlüssel in unserem MyKinsta-Dashboard hinzufügen.

 

Verwende New Relic jedoch mit Vorsicht, da es die Leistung der Webseite beeinträchtigt. Es fügt außerdem JavaScript zu Deiner Webseite hinzu. Wir empfehlen, es zu aktivieren, wenn Du Probleme bei der Performance beheben musst, und es danach zu deaktivieren.

Langsame Plugins finden

Wenn ein WordPress-Plugin eine allgemeine Verlangsamung verursacht, variieren die Symptome je nach Aktivität, die das Plugin ausführt. In vielen Fällen wirst du jedoch feststellen, dass ein langsames Plugin jede Seite einer WordPress-Webseite beeinflusst. Im Falle der Webseite, deren Daten du im Bild unten siehst, wurde allgemeine Langsamkeit auf jeder Frontend-Seite der Webseite festgestellt. Hier sieht man, was New Relic über die Leistung der Plugins auf der Webseite zu sagen hat.

Man erkennt sofort, dass das Adinjektor-Plugin mehr als 15-mal so viel Zeit verbraucht wie das nächstlangsamere Plugin.

Beim Anblick solcher Daten kann es verlockend sein, das Plugin sofort als schlecht kodiert oder irgendwie unwirksam zu erachten. Obwohl das manchmal der Fall ist, muss das nicht zwingend sein. Fehlkonfiguration des Plugins, Langsamkeit der Datenbank oder externe Ressourcen, die nur langsam reagieren, können dazu führen, dass ein Plugin viel Zeit in Anspruch nimmt.

Wenn Du also ein Plugin siehst, das langsam reagiert, ist es eine gute Idee, mehrere andere Screens in New Relic zu überprüfen, um zusätzliche Informationen zu sammeln. Die Transaktionen, Datenbanken und externen Ressourcen sollten alle überprüft werden, bevor entschieden wird, dass die Deaktivierung des Plugins der beste oder einzige Weg ist.

Allgemeine Verzögerungen durch überforderte Datenbanken

Eine schlecht optimierte Datenbank kann zu einer allgemeinen Langsamkeit auf einer WordPress-Seite führen. Weiter oben haben wir schon über zahlreiche Dinge berichtet, die man tun kann, um das Problem zu lösen. In New Relic wird diese datenbankbezogene Langsamkeit höchstwahrscheinlich an zwei Stellen auftreten:

• Zunächst siehst Du in der Übersicht eine überdimensionale Menge an MySQL-Aktivität.
• Als nächstes werden eine oder mehrere Datenbanktabellen angezeigt, die viel Zeit in der Registerkarte Datenbanken verbrauchen.

Ausgehend vom Übersichtsscreen könnte eine Webseite mit einer belasteten Datenbank etwa so aussehen:

Um einen besseren Überblick darüber zu erhalten, welche Datenbanktabelle oder Abfrage das Problem verursacht, gehe zur Registerkarte Datenbanken.

Die Registerkarte Datenbanken zeigt die Tabelle und die Art der Abfrage an, die am meisten Zeit in Anspruch nimmt. Wenn Du einen der Einträge in der Liste auswählst, kannst Du mehr Details sehen, einschließlich einiger Beispielabfragen.

In diesem Fall weisen die Aufnahmen auf automatisch geladene Daten in der Tabelle wp_options hin. Vielleicht erinnerst du dich, wir haben das vorhin besprochen! Eine schnelle Analyse der Tabelle wp_options bestätigt, dass fast 250 MB Daten aus dieser Tabelle automatisch geladen werden, was diese Webseite zu einem offensichtlichen Kandidaten für die Wartung und Optimierung von Datenbanken macht.

Schau dir unser ausführliches Tutorial an, wie du mit New Relic, Performance-Probleme auf deiner WordPress-Seite beheben kannst.

Nutze das kostenlose Query Monitor Plugin

Du kannst auch das kostenlose Query Monitor WordPress Plugin verwenden. Mithilfe dieses Programms kann man langsame Datenbankabfragen, AJAX-Aufrufe, REST-API-Anfragen und vieles mehr identifizieren und prüfen. Darüber hinaus meldet das Plugin Webseite-Details wie Script Dependencies und Dependents, WordPress-Hooks, die während der Seitengenerierung ausgelöst wurden, Details zur Hosting-Umgebung, bedingte Abfrage-Tags, die von der aktuellen Seite erfüllt werden, und vieles mehr.

Das Plugin wurde von John Blackbourn entwickelt, einem WordPress Core Committer, der derzeit Entwickler bei Human Made ist und zuvor bei WordPress VIP beschäftigt war – mit anderen Worten, jemand, der WordPress tiefgreifend kennt. Query Monitor wurde 2013 in das WordPress Plugin-Verzeichnis aufgenommen und verfügt derzeit über mehr als 10.000 aktive Installationen – eine beeindruckende Zahl für ein Entwicklungs-Plugin. Die Benutzerbewertung des Plugins mit fünf von fünf Sternen bestätigt seine Beliebtheit bei Entwicklern.

Schau Dir unser komplettes Tutorial an, wie man Query Monitor benutzt.

Nutze Staging-Umgebungen ohne die Produktions-Umgebung zu berühren

Wir wissen nicht, was wir ohne Staging-Umgebungen tun würden. Diese können von unschätzbarem Wert sein, wenn es um die Behebung von Performance-Problemen geht. Glücklicherweise stellt Kinsta Staging-Umgebungen mit nur einem Klick bereit. Wenn Dein WordPress Host keine Staging-Umgebungen anbietet, kannst Du auch ein Plugin wie WP Staging verwenden, obwohl das nicht so einfach ist.

Nachdem du eine Staging-Seite eingerichtet hast, kannst du als erstes alle deine Plugins deaktivieren. Da es sich hierbei um eine Kopie deiner Live-Seite handelt, musst du dir keine Sorgen machen, dass du etwas kaputt machst. Es ist bei weitem eine der einfachsten Möglichkeiten, Probleme einzugrenzen. Gehe einfach zu Plugins, wähle alle aus und klicke in den Bulk Actions auf „Deaktivieren“.

Anschließend kannst du die Antwortzeiten im New Relic oder Query Monitor überwachen und sehen, was passiert. In diesem Beispiel unten fielen die Antwortzeiten sofort wieder auf den Normalzustand auf der Webseite zurück, so dass wir wussten, dass eines der Plugins die Ursache des Problems war. Du kannst sie dann nacheinander wieder aktivieren und den gleichen Prozess wiederholen, bis du den Übeltäter gefunden hast.

Hier ist ein Beispiel dafür, was passiert ist, als wir das Plugin aktiviert haben, das das Problem verursacht hat. Die Ladezeiten (Web-Transaktionszeiten) stiegen sofort wieder an.

Was ist zu tun, nachdem du das Plugin gefunden hast, das die Verzögerung verursacht? Hier ist, was wir Dir raten:

1. Aktualisiere deine Plugins und Themes auf die neueste Version, wenn du es nicht schon getan hast.
2. Wende dich an den Entwickler des Plugins oder Theme und bitte ihn um Hilfe.
3. Finde ein alternatives Plugin, das die gleiche Funktion bietet.
4. Vielleicht verursacht deine PHP-Version ein Problem. Ändere dein PHP-Engine auf eine niedrigere Version und sieh nach, ob das Plugin oder das Theme dann funktioniert.

Du kannst auch einen WordPress-Entwickler beauftragen, um das Problem zu beheben. Wenn es um Geschwindigkeitsfragen geht, müssen wir Mike Andreason von WP Bullet an dieser Stelle kurz loben. Er ist ein hauptberuflicher Codeable Entwickler, der sich auf Performance-Optimierung spezialisiert hat und vielen Kunden hier bei Kinsta mit komplizierten Installationen geholfen hat, ihre Seite deutlich zu verbessern.

Überprüfe deine Fehlerprotokolle

Das Überprüfen von Fehlerprotokollen macht nie Spaß, kann aber viel über Performance-Probleme mit WordPress-Plugins aussagen. Als Kinsta-Kunde kannst du deine Fehlerprotokolle, Cache-Protokolle und Zugriffsprotokolle direkt im MyKinsta-Dashboard einsehen.

Du kannst Fehlerprotokolle auch aktivieren, indem du einen Code zu deiner wp-config.php-Datei hinzufügst. Zuerst wirst du dich mit deiner Webseite über SFTP verbinden wollen. Lade dann deine wp-config.php herunter, damit du sie bearbeiten kannst. Hinweis: Mach immer zuerst ein Backup dieser Datei!

Finde die Zeile /* That's all, stop editing! Happy blogging. */ und füge unmittelbar davor folgendes hinzu (wie unten gezeigt):

define( 'WP_DEBUG', true );

Wenn der obige Code bereits in deiner wp-config.php-Datei existiert, aber auf „false“ gesetzt ist, ändere ihn einfach auf „true“. Dadurch wird der Debug-Modus aktiviert. Hinweis: Du wirst auch Warnungen oder Fehler in deinem WordPress-Administrator sehen, falls diese existieren.

Du kannst dann das Debug-Protokoll aktivieren, um alle Fehler in eine Datei zu senden, indem du den folgenden Code direkt nach der Zeile WP_DEBUG hinzufügst (wie unten gezeigt):

define( 'WP_DEBUG_LOG', true );

Speichere deine Änderungen und lade sie erneut auf deinen Server hoch. Die Fehler werden dann in der Datei debug.log in deinem Ordner /wp-content/ protokolliert. Wenn du diese Datei aus irgendeinem Grund nicht siehst, kannst du jederzeit eine erstellen.

Die MyKinsta Analytics verwenden

Als Kinsta-Kunde kannst Du die Performance-Einblicke nutzen, die wir in unser MyKinsta Analytics-Tool integriert haben.

Im Abschnitt zur Leistungsüberwachung kannst Du Deine durchschnittliche PHP + MySQL-Antwortzeit, den PHP-Durchsatz, die AJAX-Nutzung, die höchste durchschnittliche Upstream-Zeit und die höchste maximale Upstream-Zeit anzeigen.

Durchschnittliche PHP + MySQL Antwortzeit

Wann immer du deine WordPress-Seite besuchst, werden PHP und MySQL verwendet, um die Daten, die du auf der Seite siehst, zu kompilieren und abzufragen. Dieses Diagramm zeigt dir die durchschnittliche Antwortzeit der PHP-Engine und der MySQL-Engine für jede nicht zwischengespeicherte dynamische Anforderung. Die Resultate dieser Reaktionszeiten können dir helfen, Fehler zu beheben.

PHP Throughput

Der Throughput gibt die Anzahl der Transaktionen pro Sekunde an, die eine Anwendung verarbeiten kann, und in diesem Bericht bezieht er sich auf den PHP-Durchsatz von deiner WordPress-Seite. Mit anderen Worten, es zeigt dir, wie oft ein PHP-Asset angefordert wurde.

AJAX-Verwendung

AJAX ist ein kundenseitiges Skript, das mit und von einem Server/Datenbank kommuniziert, ohne dass ein Postback oder eine komplette Seitenaktualisierung erforderlich ist. Wenn es um WordPress geht, haben viele von Euch das wahrscheinlich in ihren Geschwindigkeitstests gesehen. Zu den beiden wichtigsten Problemen mit AJAX gehören Plugins, die dazu führen, dass es zu Spike- und CPU-Problemen im Backend kommt.

Schau Dir unseren ausführlichen Beitrag zu Diagnose einer hohen Admin-AJAX-Nutzung auf Deiner WordPress-Seite an.

Der AJAX-Nutzungsbericht in MyKinsta Analytics kann eine sehr gute Möglichkeit sein, dir bei der Behebung dieser Art von Problemen zu helfen, da du sehen kannst, ob du bestimmte AJAX-Spitzen in bestimmten Zeiträumen siehst. Dieses Diagramm zeigt die Anzahl der admin-ajax Anfragen. Du kannst dann einige der Tipps in dem Beitrag, den wir oben erwähnt haben, verwenden, um einzugrenzen, woher sie kommen könnten.

Top Durchschnittliche PHP + MySQL Reaktionszeit

Diese Liste zeigt die durchschnittlich besten Antwortzeiten von PHP und MySQL. Diese Zahlen können einmalige Spitzenwerte sein, daher wird empfohlen, diese Liste mit „Top Maximum Upstream Time“ zu vergleichen.

Höchste maximale Upstream Zeit

Die Upstream-Zeit ist die Gesamtzeit, die Ngnix (und die Upstream-Server) benötigen, um eine Anfrage zu bearbeiten und eine Antwort zu senden. Die Zeit wird in Sekunden gemessen, mit einer Auflösung von Millisekunden. Erfahre mehr über die Ngnix-Kennzahlen.

Deine Seite könnte gehackt werden

Wenn Du Probleme hast, ein Performance-Problem aufzuspüren, kann es sehr gut sein, dass Deine Webseite gehackt, mit Malware infiziert oder einem DDoS-Angriff unterzogen wird. Dies kann die Geschwindigkeit Deiner Webseite und sogar die Reaktionsfähigkeit Deines WordPress Admin Dashboards beeinträchtigen. In diesen Fällen empfehlen wir folgendes:

1. Implementiere einen Proxy-Server und WAF wie Cloudflare oder Sucuri.
2. Blockiere schlechte IP-Adressen über die oben genannten Dienste oder wenn du ein Kunde von Kinsta bist, kannst du auch IP-Adressen über unser MyKinsta-Dashboard blockieren.
3. Du kannst auch Geo-Blocking implementieren. Einige Länder schneiden sehr schlecht ab, wenn es um die Qualität des von ihnen erzeugten Traffic geht. Wenn du angegriffen wirst, musst du möglicherweise das ganze Land blockieren, entweder vorübergehend oder dauerhaft.

Fehlerbehebung mit Fehlercodes (HTTP Status Codes)

HTTP-Statuscodes sind wie eine kurze Notiz vom Webserver, die oben auf einer Webseite angehängt wird. Sie sind nicht Teil der Webseite. Stattdessen handelt es sich um eine Nachricht des Servers, der Dich darüber informiert, wie es gelaufen ist, als die Anforderung, die Seite anzuzeigen, vom Server empfangen wurde. Diese können bei der Fehlersuche von unschätzbarem Wert sein!

Während es über 40 verschiedene Statuscodes gibt, führen wir unten die häufigsten an, mit denen WordPress-Nutzer zu kämpfen haben.

429: „Too Many Requests“ wird vom Server generiert, wenn der Benutzer zu viele Anfragen in einer bestimmten Zeitspanne gesendet hat (Ratenbegrenzung). Dies kann manchmal bei Bots oder Skripten auftreten, die versuchen, auf deine Webseite zuzugreifen. In diesem Fall solltest du vielleicht versuchen, deine WordPress-Login-URL zu ändern.

500: „Es gab einen Fehler auf dem Server und die Anfrage konnte nicht abgeschlossen werden.“  Ein generischer Code, der einfach „interner Serverfehler“ bedeutet. Auf dem Server ist etwas schief gelaufen, und die angeforderte Ressource wurde nicht geliefert. Dieser Code wird typischerweise von Drittanbieter-Plugins, fehlerhaftem PHP oder sogar der Verbindung zur Datenbank erzeugt. In unseren Tutorials erfährst du, wie du den Fehler beim Herstellen einer Datenbankverbindung beheben kannst und wie du einen internen 500-Serverfehler beheben kannst.

502: „Bad Gateway.“ Dieser Fehlercode bedeutet in der Regel, dass ein Server eine ungültige Antwort von einem anderen empfangen hat. Manchmal dauert eine Abfrage oder Anforderung zu lange, und so wird sie vom Server abgebrochen oder beendet und die Verbindung zu den Datenbanken bricht ab. In unserem ausführlichen Tutorial erfährst Du, wie Du den Fehler 502 Bad Gateway beheben kannst.

503: „Der Server ist im Moment nicht in der Lage, diese Anfrage zu bearbeiten.“ Die Anfrage kann zurzeit nicht bearbeitet werden. Dieser Code kann von einem überlasteten Server zurückgegeben werden, der keine zusätzlichen Anfragen bearbeiten kann.

504: „Der Server, der als Gateway fungiert, hat ein Timeout und wartet darauf, dass ein anderer Server antwortet.“  Der Code wird zurückgegeben, wenn zwei Server an der Verarbeitung einer Anforderung beteiligt sind, und der erste Server weiterhin auf die Antwort des zweiten wartet. Erfahre mehr darüber, wie Du 504-Fehler beheben kannst.

Du kannst Dich auch in diese HTTP-Antwortcodes in unserem MyKinsta Analytics-Tool einarbeiten. Unser Antwortcode-Dashboard gibt Dir einen Überblick über die Verteilung der HTTP-Statuscodes, die für die angeforderten Ressourcen bereitgestellt werden.

Im Bericht über die Antwortstatistiken siehst du die Gesamtzahl der Redirects, Fehler, Erfolgsrate und Fehlerquote. Jede WordPress-Seite hat typischerweise eine kleine Fehlerquote; das ist völlig normal.

Es gibt dann Ausfallberichte für jede Art von Fehlercode, wie z.B. 500 Fehler, 400 Fehler, Redirects etc.

Empfehlungen zur Backend optimierung

Nun werden wir auf einige Möglichkeiten eingehen, wie Du WordPress beschleunigen kannst, indem Du das Backend optimierst. Backend beinhaltet typischerweise alles, was vollständig vom Server verwaltet wird, wie z.B. PHP, HTTP-Cache Header, GZIP-Kompression etc.

Erstelle eine einfache 404 Seite

Wir haben aus erster Hand gesehen, dass hochdynamische Webseiten typischerweise viele 404 Fehler erzeugen. Deine Webseite generiert eventuell mehr, als du denkst! Unser Analyticstool in MyKinsta kann dir helfen, den genauen Betrag zu ermitteln (siehe unten).

Der Grund für diese Fehler ist, dass viele 404 Seiten sehr ressourcenintensiv sind. Für eine hochdynamische WordPress-Webseite solltest du eine übermäßige 404-Seite vermeiden. Erstelle eine einfache 404-Vorlage, die eine weitere Abfrage der Datenbank nach Möglichkeit vermeidet. Und natürlich solltest du einige Zeit damit verbringen, die 404-Fehler zu beheben, da das nicht nur ressourcenintensiv ist, sondern auch einfach schlecht für die Benutzerfreundlichkeit.

Neben der Verwendung einer leichten 404-Seite empfehlen wir auch die Implementierung einer speziellen Seitencache-Regel für 404-Seiten. Bei Kinsta werden 404 Seiten automatisch für 15 Minuten zwischengespeichert. Wenn unser Webserver feststellt, dass eine neue Seite mit der gleichen URL wie eine gecachte 404-Seite erstellt wurde, leeren wir den Cache automatisch. Wenn deine WordPress Webseite keine 404 Seiten im Cache hat, empfehlen wir, dass du mit deinem Host zusammenarbeitest, um diese Fähigkeit zu deinem Webserver hinzuzufügen.

Erhöhe die Anzahl der PHP Worker

PHP-Worker sind vielleicht ein Begriff, von dem du noch nie gehört hast, aber damit bearbeiten viele Hosts, einschließlich Kinsta, Begrenzungsanfragen (anstatt dich durch CPU oder RAM einzuschränken, was normalerweise bei Shared Hosting-Providern der Fall ist).

PHP-Worker bestimmen, wie viele gleichzeitige Anfragen deine Webseite zu einem bestimmten Zeitpunkt bearbeiten kann. Einfach ausgedrückt, wird jede nicht gecachte Anfrage an deine Webseite von einem PHP-Worker bearbeitet. Wenn man zum Beispiel 4 Anfragen hat, die genau zur gleichen Zeit auf seine Webseite kommen und die Webseite 2 PHP-Worker hat, werden zwei dieser Anfragen bearbeitet, während die anderen beiden in der Warteschlange warten müssen, bis die ersten beiden verarbeitet wurden.

Erinnern wir uns, dass eines der größten Probleme mit WordPress-Mitgliederseiten all diese nicht gecachten Anfragen sind. Aus diesem Grund werden PHP-Worker sehr wichtig, da sie für jede dieser PHP-Requests zuständig sind. Daher werden diese Webseiten in der Regel zusätzliche PHP-Worker benötigen, um sicherzustellen, dass jede Anfrage ohne Verzögerung bearbeitet und erfolgreich abgeschlossen wird.

Was passiert, wenn du deine PHP-Worker kontinuierlich ausreizt? Im Grunde genommen beginnt die Warteschlange, ältere Anfragen zu entfernen, was zu 500 Fehlern auf deiner Webseite führen kann. Jedes der Hosting-Angebote von Kinsta beinhaltet eine vordefinierte Anzahl von PHP-Workern. Wenn du Schwierigkeiten hast, einzuschätzen, was deine Seite braucht, kannst du jederzeit mit unserem Verkaufs- oder Support-Team chatten.

Verwende die GZIP Komprimierung

GZIP ist ein Dateiformat und eine Softwareanwendung zur Komprimierung und Dekomprimierung von Dateien. Die GZIP-Komprimierung ist serverseitig aktiviert und ermöglicht eine weitere Reduzierung der Größe Deiner HTML-, Stylesheets und JavaScript-Dateien.

Wenn ein Webbrowser eine Webseite besucht, wird überprüft, ob auf dem Webserver GZIP aktiviert ist, indem er prüft, ob die content-encoding: gzip HTTP- Header existieren. Wenn der Header erkannt wird, dient er zur Ausgabe der komprimierten und kleineren Dateien. Wenn nicht, werden die unkomprimierten Dateien bereitgestellt. Wenn du GZIP nicht aktiviert hast, wirst du höchstwahrscheinlich Warnungen und Fehler in Geschwindigkeitstest-Tools wie Google PageSpeed Insights und GTmetrix sehen.

Die Aktivierung der GZIP-Komprimierung kann dazu beitragen, die Größe deiner Webseite zu reduzieren, was die Zeit für das Herunterladen der Ressource erheblich verkürzt, den Datenverbrauch für den Besucher reduziert und die Zeit bis zur ersten Darstellung deiner Seiten verringert. Das ist heute bei den meisten Hosting-Providern ziemlich üblich, aber an dieser Stelle überrascht uns nichts mehr.

Den Hotlink Schutz aktivieren

Das Konzept des Hotlinking ist ziemlich einfach. Du findest irgendwo im Internet ein Bild und verwendest die URL des Bildes direkt auf deiner Seite. Dieses Bild wird auf deiner Webseite angezeigt, aber es wird von dem ursprünglichen Standort aus bedient. Dies ist sehr praktisch für den Hotlinker, aber es ist eigentlich Diebstahl, da er die Ressourcen der gehotlinkeden Seite nutzt. Es ist, als würden wir in unser Auto steigen und mit Benzin wegfahren, das wir aus dem Auto unseres Nachbarn abgezapft haben.

Hotlinking kann eine enorme Belastung für die Ressourcen des Zielservers darstellen. Man stelle sich vor, Du befindest dich auf einem freigegebenen WordPress Host und Spiegel Online verlinkt plötzlich auf deine Bilder. Du könntest von ein paar hundert Anfragen pro Stunde auf deiner Seite zu ein paar hunderttausend übergehen. Dies kann sogar zu einer Sperrung deines Hosting-Accounts führen. Das ist ein Grund, nicht nur einen leistungsstarken Host zu verwenden (der mit solchen Problemen umgehen kann), sondern auch den Hotlink-Schutz zu aktivieren, damit
solch ein Problem vermieden werden kann.

In unserem Tutorial erfährst Du, wie du Hotlinking verhindern kannst.

Minimiere Weiterleitungen und füge sie auf Serverebene hinzu

Zu viele Weiterleitungen sind immer etwas, auf das man achten muss. Einfache Weiterleitungen wie eine einzelne 301 Weiterleitung, HTTP zu HTTPS oder www zu non-www (oder umgekehrt) sind in Ordnung und oft werden diese in bestimmten Bereichen deiner Webseite benötigt. Allerdings beeinflusst jede davon die Geschwindigkeit Deiner Webseite. Und wenn du anfängst, Weiterleitungen übereinander zu stapeln, ist es wichtig zu erkennen, wie sie sich auf deine Webseite auswirken. Das gilt für Seiten- und Postverlinkungen, Bildverlinkungen, einfach alles.

Eine Weiterleitung erzeugt ein 301 oder 302 auf dem Status des Antwortheaders.

Wie stark wirken sich Weiterleitungen auf Deine Webseite aus? Lass uns einen kleinen Test durchführen. Zuerst führen wir einen Geschwindigkeitstest auf unserer Kontaktseite durch: https://perfmatters.io/contact/. Wie Du unten sehen kannst, erhalten wir eine Gesamtladezeit von 417 ms.

Wir ändern dann die URL leicht und führen einen weiteren Geschwindigkeitstest durch, um die Auswirkungen mehrerer Weiterleitungen zu sehen. http://www.perfmatters.io/contact. Wie Du sehen kannst, benötigt die gleiche Seite nun 695 ms zum Laden. Das ist eine Steigerung von 66%. Huch!

Die Verwendung kostenloser WordPress-Plugins zur Implementierung von Weiterleitungen kann manchmal zu Performance-Problemen führen, da die meisten von ihnen die wp_redirect-Funktion verwenden, die zusätzliche Codeausführung und Ressourcen erfordert. Einige von ihnen fügen auch automatisch geladene Daten zu deiner wp_options-Tabelle hinzu, was deine Datenbankgröße nur weiter aufbläst. Stattdessen sollten sie auf Serverebene hinzugefügt werden. Wir ermöglichen es dir, das bei MyKinsta mit unserem Redirect Rules Tool zu tun.

Du kannst auch eine vollständige Aufschlüsselung der Anzahl der Weiterleitungen auf Deinen Seiten in unserem MyKinsta Analysetool sehen. Schau Dir die Gesamtzahl der 301er, 302er und 304er an.

Informiere Dich in unserem ausführlichen Beitrag über WordPress Weiterleitungen und die bewährtesten Praktiken für eine schnellere Leistung.

Lasse nicht zu, dass Cronjobs außer Kontrolle geraten

CRON-Jobs (WP-Cron) werden genutzt, um wiederholende Aufgaben deiner WordPress-Seite zeitlich zu planen. Im Laufe der Zeit können diese jedoch außer Kontrolle geraten und Performance-Probleme verursachen. Du kannst das kostenlose WP Control Plugin verwenden, um einen Überblick über alle Cron Jobs zu erhalten, die auf deiner Seite stattfinden.

Wir haben auch Performance-Probleme mit WP Cron, dem in WordPress integrierten Cron Programm festgestellt. Wenn eine Webseite nicht genügend PHP-Worker hat und eine Anfrage beginnt, startet WordPress Cron, aber der Cron muss nun auf den Worker warten und dreht daher solange Däumchen. Ein besserer Ansatz ist es, WP-Cron zu deaktivieren und stattdessen den System Cron zu verwenden. Dies wird sogar im offiziellen Plugin-Handbuch empfohlen.

Um WP-Cron zu deaktivieren, füge die folgende Zeile zu deiner Datei wp-config.php hinzu, sorge nur dafür, dass dies vor der Zeile „That’s all, step editing! Happy blogging.“ geschieht. Hinweis: Dadurch wird verhindert, dass es beim Laden der Seite läuft, nicht aber, wenn du es direkt über wp-cron.php aufrufst.

define('DISABLE_WP_CRON', true);

Dann musst du wp-cron.php von deinem Server aus koordinieren. Wenn Du ein Kinsta-Kunde bist, sind die System-Crons bereits aktiviert und werden standardmäßig alle 15 Minuten ausgeführt. Du kannst die Frequenz auch erhöhen lassen, indem Du Dich an unser Support-Team wendest. Wenn Du mit SSH vertraut bist, kannst Du Server-Crons von der Befehlszeile aus verwalten.

Füge Cache-Control und Expires Headers hinzu (lege die Zeit fest wie lange etwas gecached wird)

Jedes Skript auf deiner WordPress-Seite muss mit einem HTTP-Cache-Header versehen sein (oder sollte es). Das bestimmt, wann der Cache der Datei abläuft. Um das zu beheben, stelle sicher, dass dein WordPress Host über die richtigen cache-control headers und expires für Header verfügt. Wenn du es nicht tust, wirst du höchstwahrscheinlich Warnungen in Geschwindigkeitstests sehen, die darauf hindeuten, dass du expires Header hinzufügen musst oder das Browser-Caching nutzen solltest.

Während der cache-control Header das clientseitige Caching aktiviert und das maximale Zeitlimit einer Ressource festlegt, wird die expires Header verwendet, um einen bestimmten Zeitpunkt anzugeben, an dem die Ressource nicht mehr gültig ist. Obwohl beide Header zusammen verwendet werden können, muss man nicht unbedingt beide hinzufügen. Cache-Control ist neuer und normalerweise die empfohlene Methode.

Kinsta fügt automatisch HTTP-Cache-Header auf allen Serveranfragen hinzu, und wenn Du ein CDN verwendest, wird Kinsta höchstwahrscheinlich auch diese Header für Dich hinzufügen.

Wenn deinem Server diese Header fehlen, kannst du sie manuell hinzufügen.

Einen Cache-Control Header in Nginx hinzufügen

Du kannst cache-control Headers in Nginx hinzufügen, indem du folgendes zum Serverstandort oder Block deiner Serverkonfiguration hinzufügst.

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Einen Expires Header in Nginx hinzufügen

In Nginx kannst Du expires hinzufügen, indem Du Folgendes zu Deinem Serverblock hinzufügst. In diesem Beispiel wird erläutert, wie man je nach Dateityp unterschiedliche Ablaufzeiten angibt.

 location ~* \.(jpg|jpeg|gif|png|svg)$ {
 expires 365d;
 }
 location ~* \.(pdf|css|html|js|swf)$ {
 expires 2d;
 }

Einen Cache-Control Header in Apache hinzufügen

Du kannst cache-control-Header in Apache hinzufügen, indem Du Folgendes zu Deiner .htaccess-Datei hinzufügst. Codeausschnitte können oben oder unten in der Datei hinzugefügt werden (vor # BEGIN WordPress oder nach # END WordPress).

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"

Einen Expires Header in Apache hinzufügen

Du kannst expires Header in Apache hinzufügen, indem Du Folgendes zu Deiner .htaccess-Datei hinzufügst.

## EXPIRES HEADER CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"

## EXPIRES HEADER CACHING ##

Es ist auch wichtig zu beachten, dass Du nur HTTP-Cache-Header zu Ressourcen auf Deinem Server hinzufügen kannst. Wenn Du eine Warnung darüber erhältst, dass Du vielleicht das Browser-Caching bei einer Anfrage eines Drittanbieters nutzen musst, gibt es nichts, was Du tun kannst, da Du keine Anfrage über dessen Server stellen kannst. Zu den häufigsten Verursachern gehören das Google Analytics-Skript und Marketing-Pixel wie Facebook und Twitter.

Wenn du versuchst, das mit dem Google Analytics-Skript zu beheben, kannst du es lokal oder auf deinem CDN (obwohl das nicht offiziell unterstützt wird) mit einem Plugin wie Perfmatters oder WP Rocket hosten.

Die Last-Modified und ETag Header hinzufügen (Cache validieren)

Als nächstes haben wir noch zwei weitere Header, last-modified und etag.

Während cache-control und expires Headers helfen dem Browser festzustellen, ob sich die Datei seit der letzten Anforderung geändert hat (oder besser gesagt, sie validieren den Cache) die last-modified und etag-Header validieren und setzen die Länge des Caches und sollten bei jeder Serverantwort enthalten sein. Wenn diese nicht richtig eingestellt sind, wird möglicherweise eine Warnung angezeigt, dass Du“einen Cache-Validierer angeben“ musst.

Diese Header sollten in jeder Serverantwort enthalten sein, da sie die Länge des Cache validieren und festlegen. Wenn die Header nicht gefunden werden, wird jedes Mal eine neue Anforderung für die Ressource generiert, was die Belastung des Servers erhöht. Die Verwendung von Cache-Header stellt sicher, dass nachfolgende Anfragen nicht vom Server geladen werden müssen, was Bandbreite spart und die Performance für den Benutzer verbessert.

Kinsta fügt die obigen Header automatisch allen Serveranfragen hinzu, und wenn Du ein CDN verwendest, wird Kinsta höchstwahrscheinlich auch diese Header für Dich hinzufügen. Genau wie bei cache-control und expires kann man diese HTTP-Header nicht manuell auf externe Ressourcen verlegen.

„Last modified“ Header

Der „last modified“ Header wird in der Regel automatisch vom Server gesendet. Das ist ein Header, den du normalerweise nicht manuell hinzufügen musst. Er wird gesendet, um zu sehen, ob die Datei im Cache des Browsers seit der letzten Anforderung geändert wurde. Man kann sich die Header-Anfrage in Pingdom ansehen oder Chrome DevTools verwenden, um den Wert der „last modified“ Kopfzeile zu sehen.

ETag Header

Der „ETag„-Header ist dem „last modified“ Header sehr ähnlich. Er wird auch verwendet, um den Cache einer Datei zu validieren. Wenn Du Apache 2.4 oder höher verwendest, wird der „ETag“-Header bereits automatisch über die FileETag-Direktive hinzugefügt. Und was Ngnix betrifft, so ist der „ETag“-Header seit 2016 standardmäßig aktiviert.

Du kannst den ETag header manuell in Nginx mit dem folgenden Code aktivieren.

etag on

Einen Vary: Accept-Encoding Header hinzufügen

Der vary: Accept-Encoding Header sollte bei jeder Serverantwort enthalten sein, da er dem Browser sagt, ob der Client mit komprimierten Versionen des Inhalts umgehen kann oder nicht. Wenn das nicht richtig eingestellt ist, wird möglicherweise eine Warnung angezeigt, dass du einen „Vary: Accept-Encoding Header spezifizieren“ sollst.

Angenommen, Du hast einen alten Browser ohne gzip-Komprimierung und einen modernen Browser mit gzip-Komprimierung. Wenn Du den vary: Accept-Encoding Header nicht verwendest, könnte Dein Webserver oder CDN die unkomprimierte Version versehentlich an den modernen Browser liefern, was wiederum die Performance Deiner WordPress-Seite beeinträchtigt. Durch die Verwendung des Headers kannst Du sicherstellen, dass Dein Webserver und/oder CDN die entsprechende Version liefert.

Kinsta fügt die obigen Header automatisch auf allen Serveranfragen hinzu, und wenn Du ein CDN verwendest, wird Kinsta höchstwahrscheinlich auch diese Header für Dich hinzufügen. Genau wie bei den anderen Cache-Headern, die wir oben besprochen haben, kannst Du diesen Header nicht manuell auf externe Ressourcen verlegen.

Einen Vary: Accept-Encoding Header in Apache hinzufügen

Du kannst den Vary: Accept-Encoding Header in Apache hinzufügen, indem Du das Folgende zu Deiner .htaccess-Datei hinzufügst.

<IfModule mod_headers.c>
  <FilesMatch ".(js|css|xml|gz|html)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

Einen Vary: Accept-Encoding Header in Nginx hinzufügen

Du kannst Vary: Accept-Encoding Header in Nginx hinzufügen, indem Du den folgenden Code zu Deiner Konfigurationsdatei hinzufügst. Alle Nginx-Konfigurationsdateien befinden sich im Verzeichnis /etc/nginx/. Die primäre Konfigurationsdatei ist /etc/nginx/nginx.conf.

gzip_vary on

Das WordPress Memory Limit in der wp-config.php Datei ändern

Wie im WordPress Codex angegeben, erlaubt Dir die Option WP_MEMORY_LIMIT mit WordPress Version 2.5 die maximale Speichermenge anzugeben, die von PHP verbraucht werden kann. Diese Einstellung kann erforderlich sein, wenn Du eine Meldung wie „Zulässige Speichergröße von xxxxxxxx Bytes erschöpft“ erhältst.

Standardmäßig wird WordPress versuchen den für PHP zugewiesenen Speicherplatz auf 40 MB für eine einzelne Seite und 64 MB für mehrere Seiten zu erhöhen. Du definierst die Speichergrenzen in der Datei ./wp-includes/default-constants.php, auf den Zeilen 32 – 44 (Quelle).

Du hast dann auch PHP memory_limit auf dem Server von Deinem Hosting-Provider. Das sind zwei verschiedene Dinge. Bei Kinsta haben wir das Standard memory_limit auf 256M gesetzt. Wenn Du auf den Fehler Speichergröße erschöpft stößt, kannst Du versuchen, die PHP-Speichergrenze in WordPress zu erhöhen.

Füge das Folgende zu Deiner wp-config.php-Datei, hinzu, kurz vor der Zeile „That’s all, stop editing! Happy blogging.“

define( 'WP_MEMORY_LIMIT', '256M' );

Jan Reilink hat auch einen sehr guten Blog-Post verfasst, der das Problem der WordPress-Speicherbegrenzung genauer beschreibt. Er gibt auch eine Alternative zu dem Code, den du verwenden kannst. Anstatt den Betrag manuell einzustellen, kannst du ihn auf den PHP memory_limit-Wert setzen.

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

Tipps für die Front-End Optimierung und für externe Services

Nun werden wir auf einige Möglichkeiten eingehen, wie du WordPress beschleunigen kannst, indem du das Frontend optimierst. Frontend beinhaltet typischerweise alles, was vollständig vom client-seitigen Browser verarbeitet wird, wie CSS, JavasScript, Bilder, etc. Dazu gehört auch die Analyse externer Dienste, die du auf deiner Webseite laden kannst und wie sie sich auf deine Gesamtladezeit auswirken.

Zwei der wichtigsten Ziele, die du verfolgen solltest, wenn es um die Frontendoptimierung geht, sind:

• Reduziere die Größe deiner gesamten Webseite. Die Größe deines CSS, JavaScript, Bilder ist entscheidend. Eine 4 MB Webseite wird typischerweise viel langsamer geladen als eine 1 MB Webseite. Paul Calvano hat einen interessanten Artikel über die Auswirkungen der Größe einer Seite auf die Ladezeit verfasst und wie wichtig es ist sicherzustellen, dass es nicht das Einzige ist, was du verfolgst, da es manchmal irreführend sein kann.
• Reduzierung von HTTP-Anfragen und externen Diensten. Mit HTTP/2 können nun mehrere Anfragen und Antworten gleichzeitig über eine einzige TCP-Verbindung gesendet werden. Obwohl das für die Leistung fantastisch ist, kann die Reduzierung von HTTP-Anfragen dennoch helfen, deine WordPress-Seite zu beschleunigen. Dazu gehört auch die Reduzierung der Gesamtzahl der externen Anfragen und Dienstleistungen. Denn diese fügen zusätzliche Verzögerungen wie DNS-Lookups, TLS-Verbindungen und Netzwerklatenz hinzu.

Teste die Ladezeit deiner WordPress Seite um einen Basiswert zu erhalten

Wenn es darum geht, das Frontend deiner Webseite zu optimieren, ist es immer gut, mit einem Basiswert zu beginnen. Das bedeutet in der Regel, dass du einen Geschwindigkeitstest durchführen musst. Es gibt eine Vielzahl von Möglichkeiten, wie du das tun kannst, schau dir unsere Liste von 15 sehr guten Webseiten-Geschwindigkeitstest-Tools an.

Schau Dir unsere ausführlichen Anleitungen zur Verwendung von Pingdom und GTmetrix an. Hier sind ein paar Dinge, die man bei der Geschwindigkeitsprüfung beachten sollte:

1. Wähle ein Tool und bleibe dann dabei

Wir sind große Fans von Pingdom, GTmetrix, WebPageTest, PageSpeed Insights und Chrome DevTools. Es spielt jedoch keine Rolle, welches Tool du verwendest, es kommt darauf an, dass Du konsequent mit einem fährst. Sie alle haben verschiedene Möglichkeiten, die Geschwindigkeit zu messen und zu quantifizieren, also wähle ein Tool und führe damit alle deine Tests und Optimierungen durch. Sogar Google setzt darauf.

2. Fahre dich nicht fest nur weil du einen perfekten Score haben möchtest

Viele der Tools wie Google PageSpeed Insights haben alle eine Art Geschwindigkeits- oder Performancebewertung. Es ist wichtig, sich daran zu erinnern, dass das Ergebnis nicht immer so wichtig ist wie die Geschwindigkeit und die wahrgenommene Performance Deiner Webseite durch den Benutzer. Das Ergebnis ist da, um Dir eine Einschätzung zu liefern. Aber besessen perfekte 100 von 100 Punkten erreichen zu wollen, kann in manchen Fällen eine Zeitverschwendung sein. Und größere Webseiten mit vielen externen Skripten und Anzeigen werden nie eine perfekte Bewertung erhalten, was in Ordnung ist.

3. Der Standort spielt eine Rolle

Der Ort, den du wählst, ist nicht irrelevant bei der Geschwindigkeitsprüfung. Wie wir bereits in einem früheren Abschnitt besprochen haben, liegt der Grund darin, dass das alles mit dem von dir gewählten Serverstandort zusammenhängt. TTFB, Netzwerklatenz, all das spielt eine Rolle. Teste deine Webseite also sowohl von einem Standort, der sich in der Nähe deines Rechenzentrums befindet, als auch von einem Standort, der weit entfernt ist. Das wird dir auch helfen einzuschätzen, wie stark sich ein CDN auf deine WordPress-Seite auswirken kann.

4. Mache mehrere Tests wegen dem Caching

Wie wir bereits im Abschnitt über das Caching erläutert haben, wird der Cache, wenn er kürzlich gelöscht wurde oder auf Deinem WordPress Host oder CDN abgelaufen ist, ein „MISS“ im HTTP-Header anzeigen. Das bedeutet, dass Deine Webseite oder Dein Asset nicht aus dem Cache bedient wird.

Um die Geschwindigkeit deiner gesamten Webseite richtig wahrnehmen zu können, musst du alles aus dem Cache laden, deine Startseite und alle Assets, alles muss auf „HIT“ eingestellt sein. Das erfordert manchmal, dass du deinen Geschwindigkeitstest mehrmals durchführst. Dann kannst du den Durchschnitt nehmen.

Kommen wir nun zu einigen Front-End-Optimierungen, die Du auf Deiner WordPress-Seite vornehmen kannst.

Eliminiere das Render-Blocking JavaScript und CSS

Eine Warnung vor Rendering-Blocking von JavaScript und CSS kann angezeigt werden, wenn du Dateien hast, die das schnellstmögliche Laden der Seite verhindern. Spezifische JS und CSS sind manchmal bedingt, d.h. sie sind nicht erforderlich, um Inhalte above the fold anzuzeigen. Du kannst verhindern, dass sie zum Rendering-Blocking werden, indem du async und defer Attribute verwendest.

Schau dir dieses Video an, um mehr darüber zu erfahren, wie du Rendering-blockierende Ressourcen eliminieren kannst:

Um Rendering-Blocking von JavaScript und CSS zu vermeiden, muss man folgendes tun:

JavaScript aus dem kritischen Rendering-Pfad löschen

Das Verschieben von JavaScript aus dem kritischen Rendering-Pfad erfolgt in der Regel durch Hinzufügen des defer oder async-Attributs zu den HTML-Elementen des Skripts, die JavaScript-Ressourcen aufrufen.

• Das async-Attribut weist den Browser an, sofort mit dem Herunterladen der Ressource zu beginnen, ohne das HTML-Parsing zu verlangsamen. Sobald die Ressource verfügbar ist, wird das HTML-Parsing angehalten, damit die Ressource geladen werden kann.
• Das defer-Attribut weist den Browser an, den Download der Ressource zu stoppen, bis das HTML-Parsing abgeschlossen ist. Sobald der Browser mit dem HTML fertig ist, lädt er alle verzögerten Skripte herunter und rendert sie in der Reihenfolge, in der sie im Dokument erscheinen.

Optimiere die CSS Ressourcen Auslieferung

Die Optimierung der Bereitstellung von CSS bedeutet im Wesentlichen, dass man herausfinden muss, wie man es ohne Render Blocking einstellt.

• Identifiziere die styles, die erforderlich sind, um Inhalte übersichtlich darzustellen, und stelle diese styles in Einklang mit dem HTML ein.
• Verwende CSS auf Geräten nur bei Bedarf.
• Verbleibendes CSS asynchron laden.

Das kann manchmal definitiv ein kniffliger Prozess sein und erfordert hin und wieder einiges an Optimierung, je nachdem wie du Skripte auf deiner Seite lädst. Hier sind ein paar WordPress-Plugins, die dabei helfen können:

• Autoptimize
• Async JavaScript
• Hummingbird

Für eine detaillierte Erklärung und einen Leitfaden empfehlen wir dir, unseren Beitrag über die Beseitigung von Render-Blocking von JavaScript und CSS zu lesen.

Kombiniere externes CSS und JavaScript in WordPress

Die kombinierte externe CSS-Warnung wird typischerweise bei der Verwendung eines CDNs angezeigt, da du deine CSS-Dateien auf einer externen Domain, wie z.B. cdn.domain.com, hostest. In der Vergangenheit war eine einfache Lösung, die CSS-Dateien schlicht zu komprimieren oder zu kombinieren, sodass sie in einer einzigen Anfrage geladen werden.

Wenn du jedoch einen Provider, der HTTP/2 unterstützt über HTTPS nutzt, ist diese Warnung nicht mehr so relevant wie früher. Mit HTTP/2 können nun mehrere CSS-Dateien parallel über eine einzige Verbindung geladen werden. Und über 86% der Browser unterstützen HTTP/2 bereits.

Das bedeutet aber nicht unbedingt, dass diese Optimierung völlig hinfällig ist. In einigen Fällen haben wir gesehen, dass das die WordPress-Seiten noch schneller macht. Es hängt von der Größe der Dateien ab und wie viele es von ihnen gibt. Daher ist das ein Optimierungsweg, den wir dir weiterhin empfehlen können.

Eine der einfachsten Möglichkeiten, deine externen CSS- und JavaScript-Dateien zu kombinieren, ist das kostenlose Autoptimize-Plugin. Nach der Kombination siehst du eine Datei „autoptimize_xxxxxxx.css“ oder „autoptimize_xxxxx.js“. Es unterstützt auch das Laden aus dem CDN. Das WP Rocket Plugin bietet ähnliche Funktionen.

Schaue Dir unseren ausführlichen Beitrag an, wie Du externes CSS und JavaScript in WordPress kombinieren kannst.

Nutze die Komprimierung von HTML, CSS, und JavaScript

Wir können die Datenmenge, die der Browser herunterladen muss, reduzieren, indem wir HTML-, CSS- und JavaScript-Ressourcen anpassen. Minifizierung ist der Prozess der Entfernung unnötiger Zeichen wie Kommentare und Leerzeichen aus dem Quellcode. Diese Zeichen sind in der Entwicklung äußerst nützlich, aber sie sind für den Browser unwichtig, um die Seite darzustellen.

Nicht-komprimiertes HTML

Hier ist ein Beispiel für einen nicht-komprimierten HTML-Code.

Komprimierter HTML Code

Hier ist ein Beispiel für einen komprimierten HTML-Code.

Du kannst die kostenlosen Plugins Autoptimize oder WP-Rocket verwenden, um deine Dateien so auf einfache Weise zu verkleinern.

Wenn du ein Kinsta-Kunde bist, hast du Zugriff auf die Funktion zur Code-Minifizierung, die direkt in das MyKinsta-Dashboard integriert ist. Damit kannst du die automatische CSS- und JavaScript-Minifizierung schnell und einfach per Mausklick aktivieren und deine Seite ohne manuellen Aufwand effektiv beschleunigen.

Nutze Cookie-freie Domains

Wenn man Inhalte wie Bilder, JavaScript oder CSS bereitstellt, gibt es in der Regel keinen Grund, einen HTTP-Cookie mitzusenden, da dies zusätzlichen Aufwand verursacht. Sobald der Server ein Cookie für eine bestimmte Domain setzt, müssen alle nachfolgenden HTTP-Anfragen für diese Domain das Cookie auch enthalten. Diese Warnung wird typischerweise auf Webseiten mit einer großen Anzahl von Anfragen angezeigt.

Wir haben einen ausführlichen Beitrag darüber, wie man mit dem statischen Inhalt des Servers aus einer Cookieless Domain Warnung umgeht. Oftmals kann man diese Warnung ignorieren, da das bei neuen Protokollen wie HTTP/2 an Bedeutung verliert. Die Kosten für eine neue Verbindung sind in der Regel teurer als das Streamen aller Daten über dieselbe Verbindung.

Eine einfache Möglichkeit, diese Warnung zu beheben, besteht darin, einen CDN-Anbieter zu verwenden, der Cookies sowohl ignorieren als auch entfernen kann, was den Kunden vollständig davor bewahrt, den Set-Cookie-Response-Header zu empfangen. KeyCDN ist ein CDN-Anbieter, der diese Funktion anbietet. Standardmäßig siehst du, dass die folgenden beiden Optionen aktiviert sind. Das ist eine einfache Alternative, ohne sich mit dem Verschieben und Konfigurieren deiner Webseite herumschlagen zu müssen, um statische Assets aus einer separaten Subdomain bereitzustellen.

Wenn du Cloudflare verwendest, kannst du Cookies für Ressourcen, die über ihr Netzwerk bereitgestellt werden, nicht deaktivieren. CloudFlare fügt ein eigenes Sicherheits-Cookie in den Header ein. Auch diese Cookies sind sehr klein und die Auswirkungen auf die Performance sind äußerst gering. Aber wenn du CloudFlare benutzt, gibt es keine Möglichkeit, diese Warnung zu verhindern.

Eine zweite Möglichkeit, diese Warnung zu umgehen, besteht darin, die WordPress-Seite neu zu konfigurieren, um die statischen Elemente von einer neuen Domain oder Subdomain bereitzustellen.

Deaktiviere Einbettungen in WordPress

Mit der Veröffentlichung von WordPress 4.4, wurde die oEmbed-Funktion in Core integriert. Das ermöglicht es YouTube-Videos, Tweets und viele andere Ressourcen auf Webseiten einzubetten, indem eine einfache URL eingefügt wird, die WordPress dann automatisch in Embedded Code umwandelt, um eine Live-Vorschau im visuellen Editor anzuzeigen. Mit dem Update wurde WordPress selbst zum oEmbed-Anbieter.

Diese Funktion ist für viele Menschen nützlich, und du solltest sie vielleicht aktiviert lassen. Das bedeutet jedoch, dass es auch einen zusätzlichen HTTP-Request auf deiner WordPress-Seite erzeugt, um die Datei wp-embed.min.js zu laden. Und das lädt seitenübergreifend. Während diese Datei nur 1,7 KB groß ist, summieren sich solche Dinge mit der Zeit. Die Anfrage selbst ist manchmal ein größeres Problem als die Größe des Content-Downloads.

Du kannst diese Datei leicht vom Laden abhalten. Hier sind drei verschiedene Optionen:

• Option 1 – Einbettungen mit Plugin deaktivieren
• Option 2 – Einbettungen mit Code deaktivieren
• Option 3 – Bringe das JavaScript in Einklang

Emojis in WordPress deaktivieren

Neben Embeds wurde in WordPress 4.2 die Unterstützung für Emojis in älteren Browsern geliefert. Das große Problem dabei ist, dass es eine zusätzliche HTTP-Anfrage auf deiner WordPress-Seite erzeugt, um die Datei wp-emoji-release.min.js zu laden. Und das lädt seitenübergreifend. Während diese Datei nur 10,5 KB groß ist, ist sie nutzlos, wenn du keine Emojis auf deiner Webseite verwendest.

Es gibt verschiedene Möglichkeiten, Emojis in WordPress zu deaktivieren. Du kannst es mit einem kostenlosen Plugin oder mit Code tun.

• Emojis mit einem Plugin deaktivieren
• Emojis mit Code deaktivieren

So beschleunigt man WordPress Kommentare oder deaktiviert das Theme

Ein belebter Kommentarbereich auf einer Webseite kann viele Performance-Probleme verursachen. Denke nur an die Ressourcen, mit denen Kommentare funktionieren:

• Eine Datenbank wird abgefragt, um vorhandene Kommentare aufzurufen.
• Für jeden neuen Kommentar werden Datenbankeinträge angelegt.
• Kommentare und Kommentarmetadaten werden vom Browser eines Besuchers empfangen und verarbeitet.
• Externe Ressourcen, wie z.B. Gravatare, werden angefordert, heruntergeladen und geladen (erfordert ein separates DNS-Lookup).
• In vielen Fällen müssen große JavaScript- und jQuery-Ressourcen heruntergeladen und verarbeitet werden, damit das kommentierende System so funktioniert, wie es soll.

Hier sind vier verschiedene Optionen, wie du WordPress-Kommentare beschleunigen kannst:

Möglichkeit 1 – Kommentare deaktivieren

Wenn deine Seite nicht sehr viele Kommentare erhält und du nicht denkst, dass sie einen Mehrwert bringen, könnte es besser sein, Kommentare ganz zu deaktivieren. Denk daran, dass Kommentare Auswirkungen auf dein SEO haben können, da Google diese in der Regel als zusätzlichen Inhalt auf der Seite durchsucht, so dass du nur qualitativ hochwertige Kommentare genehmigen solltest. Schaue dir diese drei einfachen Möglichkeiten an, um Kommentare zu deaktivieren:

• Kommentare in den WordPress Optionen deaktivieren
• Kommentare mit Plugin deaktivieren
• Kommentare mit Code deaktivieren

Möglichkeit 2 – Optimiere die Native WordPress Kommentare

Deine zweite Option wäre, das native WordPress-Kommentarsystem zu optimieren. Eine Möglichkeit ist hier die Anzahl der Kommentare zu reduzieren, die beim Aufrufen der ersten Seite geladen werden.

1. Gehe zu Einstellungen → Diskussion im WordPress-Administrationsbereich.
2. Suche den Abschnitt Andere Kommentareinstellungen.
3. Wähle das Kontrollkästchen neben “Breche Kommentare in Seiten” und füge einen Wert für die Anzahl der Kommentare hinzu, die du beim Laden der ersten Seite anzeigen möchtest.

Eine weitere Möglichkeit, die du hast, ist die Verwendung von Host-Gravataren in deinem CDN. Das ist der Ansatz, den wir bei Kinsta verfolgen.

Standardmäßig, wenn WordPress-Kommentare geladen werden, benötigt jeder einzelne eindeutige Gravatar eine HTTP-Anfrage. Wenn also eine Seite mit Kommentaren von 50 verschiedenen Kommentatoren geladen wird, sind 50 HTTP-Anfragen erforderlich, um alle diese Gravatars herunterzuladen. Wie du dir vorstellen kannst, kann das die Seitengeschwindigkeit beeinflussen. Ganz zu schweigen von der Tatsache, dass wir gesehen haben, wie das externe DNS-Lookup zu gravatar.com manchmal langsam wird und in einigen Fällen sogar Zeitüberschreitungen hervorruft.

Wenn Du Dir Gravatars im Kinsta-Blog ansiehst, kannst Du sehen, dass sie von Kinsta.com (einschließlich unseres CDN) geladen werden. Erfahre, wie Du Gravatare aus deinem CDN laden kannst.

Möglichkeit 3 – Nutze ein WordPress Kommentarsystem eines Drittanbieters

Die dritte Möglichkeit ist die Verwendung eines Kommentarsystems eines Drittanbieters. Wenn deine Webseite auf einem billigen, ressourcenarmen Shared Server gehostet wird, kann die Verwendung eines Kommentarsystems von Drittanbietern Seiten mit vielen Kommentaren beschleunigen. Es ist die gleiche Idee wie bei der Bildoptimierung, die Arbeit wird entlastet. Wenn du jedoch bei Kinsta oder einem anderen Premium Webhoster hostest, wird der Wechsel zu einem Drittanbieter nicht viel dazu beitragen, die Ladegeschwindigkeit deiner Webseite zu erhöhen und kann sie sogar verlangsamen.

Achte immer darauf, dass du das Kommentarsystem eines Drittanbieters, das du gerade ausprobierst, kurz testest. Wirf einen Blick auf alle separaten Anforderungen, die beispielsweise Disqus generiert (wie oben gezeigt). Während die meisten dieser Anfragen asynchron geladen werden, wird dir bei der Verwendung von Disqus noch etwas zusätzliche Ladezeit auffallen.

Möglichkeit 4 – Kommentare mit der Lazy Load funktion ausstatten

Deine vierte Option besteht darin, Lazy Loading für Kommentare zu aktivieren, damit sie das anfängliche Darstellen der Seite nicht verlangsamen. Hier sind ein paar Plugins, die du vielleicht ausprobieren möchtest:

• Lazy Load for Comments: Dieses Plugin ermöglicht es dir, das Lazy Loading für native WordPress-Kommentare zu aktivieren
• Disqus Conditional Load: Wenn Du das Disqus-Kommentarsystem verwenden möchtest, ist dies ein Must-Plugin, um Kommentaren die Lazy Load funktion hinzuzufügen.

Deaktivieren des WordPress RSS Feeds

Wenn du den Blogging-Teil von WordPress auf deiner Webseite nicht verwendest, kannst du die WordPress-RSS-Feeds deaktivieren. Das hat zwar keinen großen Einfluss auf die Leistung, aber auch die kleinen Details helfen. Es ist auch eine Sache weniger, um die du dir Sorgen machen musst.

Sieh dir diese beiden verschiedenen Möglichkeiten an, um RSS-Feeds in WordPress zu deaktivieren:

• RSS-Feed mit Plugin deaktivieren
• RSS-Feed mit Code deaktivieren

Verwende Prefetch und Preconnect

Ressourcenhinweise und Anweisungen wie prefetch und preconnect können eine gute Möglichkeit sein, WordPress hinter den Kulissen zu beschleunigen. KeyCDN hat einen ausgezeichneten Artikel und eine Übersicht der Ressourcenhinweise.

Prefetch

Mit dem DNS-prefetch kannst du Domainnamen auflösen (DNS-Lookup im Hintergrund durchführen), bevor ein Benutzer auf einen Link klickt, was wiederum zur Verbesserung der Leistung beitragen kann. Dazu wird ein rel=“dns-prefetch“-Tag im Header deiner WordPress-Seite hinzugefügt.

<link rel="dns-prefetch" href="//domain.com">

Einige gängige Aspekte, für die man DNS-Prefetching verwenden sollte, sind die CDN-URL, Google-Fonts, Google Analytics, etc.

 <link rel="dns-prefetch" href="//cdn.domain.com/">
 <link rel="dns-prefetch" href="//fonts.googleapis.com/">
 <link rel="dns-prefetch" href="//www.google-analytics.com">

Prefetch wird auch von den meisten modernen Browsern unterstützt. Schaue Dir unser Tutorial an, wie du Code zu deinem WordPress-Header hinzufügen kannst.

Oder Du kannst einfach DNS-Prefetch mit einem Plugin wie Perfmatters implementieren. Klicke einfach auf die Registerkarte „Extras“ im Perfmatters-Plugin und füge Domains hinzu. Formatieren: //domain.tld (eine pro Zeile)

Preconnect

Preconnect ermöglicht es dem Browser, frühe Verbindungen vor einer HTTP-Anfrage einzurichten.

Preconnect ist ein wichtiges Werkzeug in deiner Optimierungs-Toolbox… es kann viele teure Roundtrips von deinem Anforderungspfad eliminieren – in einigen Fällen reduziert es die Anforderungslatenz um Hunderte und sogar Tausende von Millisekunden. – lya Grigorik (Quelle)

Das geschieht durch das Hinzufügen eines rel=“preconnect“-Tags im Header deiner WordPress-Seite.

 <link rel="dns-prefetch" href="//cdn.domain.com/">

Einige Beispiele für Dinge, für die du es verwenden könntest, sind deine CDN-URL oder Google-Fonts.

<link rel="preconnect" href="https://cdn.domain.com">
 <link rel="preconnect" href="https://fonts.gstatic.com">

Preconnect wird von den meisten modernen Browsern unterstützt, mit Ausnahme von Internet Explorer, Safari, IOS Safari und Opera Mini. Schaue Dir unser Tutorial an, wie Du Code zu deinem WordPress-Header hinzufügen kannst.

Oder Du kannst einfach Preconnect mit einem Plugin wie Perfmatters implementieren. Klicke einfach auf die Registerkarte „Extras“ im Perfmatters-Plugin und füge Domains hinzu. Format: scheme://domain.tld (eine pro Zeile).

Scripts auf Post- und Seitenebene deaktivieren

Eine weitere sehr effektive Möglichkeit, WordPress zu beschleunigen, besteht darin, jede Anfrage zu durchsuchen, die auf deinen Seiten und Beiträgen geladen wird. Du wirst höchstwahrscheinlich Skripte finden, die seitenübergreifend laden, was nicht sein sollte.
Du kannst ein Premium-Plugin wie Perfmatters verwenden, das über eine integrierte „Script Manager“-Funktion verfügt. So kannst du Skripte (CSS und JavaScript) auf Seiten-/Postbasis oder sogar seitenübergreifend mit einem einzigen Klick deaktivieren. Auch dieses Plugin wird von einem Teammitglied bei Kinsta entwickelt.
Einige Beispiele dafür, wofür dies genutzt werden kann:

• Das beliebte Contact Form 7 Plugin lädt sich auf jeder Seite und jedem Beitrag. Du kannst es einfach überall mit einem Klick deaktivieren und nur auf Deiner Kontaktseite aktivieren.
• Social Media Sharing Plugins sollten nur in Deinen Beiträgen geladen werden. Du kannst es einfach überall deaktivieren und nur auf Posttypen oder sogar auf benutzerdefinierte Posttypen laden.
• Das Inhaltsverzeichnis Plugin (TOC) lädt auf jeder Seite und jedem Beitrag. Mit dem Skript-Manager kannst Du ganz einfach steuern, wo er geladen werden soll.

Warum sind manche Plugins so geschrieben?

Du fragst dich vielleicht, warum alle Plugin-Entwickler ihre Skripte nicht einfach nur dann laden, wenn das Plugin auf der Seite erkannt wird? Nun, es ist etwas komplizierter als das. Wenn du zum Beispiel ein Plugin wie das Contact Form 7 hast, hat es auch Shortcodes, mit denen du es überall platzieren kannst. Dazu gehört auch das Ablegen in einem Widget. Mit WordPress ist es viel schwieriger, Daten von ihnen abzufragen, wenn man Skripte aus der Warteschlange entfernt, als Daten aus den Post- oder Seitenmetadaten abzufragen.

Daher ist dies oft auf Usability-Probleme zurückzuführen. Je kleiner die Chancen, dass ein Plugin aufhört zu funktionieren, desto weniger Supporttickets landen beim Entwickler. Allerdings zeigen viele Plugins heutzutage, dass es schon möglich wäre Plugins so zu schreiben, dass sie von grundauf für Performance optimiert sind. Leider macht manchmal die schiere Anzahl von Downloads und Benutzern die Programmierung für die Benutzerfreundlichkeit zu einer Priorität.

Eine Tour durch den Script Manager

Wir geben dir einen kleinen Einblick in den Script Manager. Nachdem du es in deiner Symbolleiste angeklickt hast, werden dir alle Skripte angezeigt, die auf dieser aktuellen URL geladen werden, sowohl JavaScript- als auch CSS-Dateien. Du hast dann die folgenden Möglichkeiten:

1. Status Ein (Standardeinstellung)
2. Status Aus: Überall deaktivieren (Du kannst dann wählen, für welche Beitragsarten Du sie aktivieren möchtest, zusammen mit der aktuellen URL).
3. Status Aus: Deaktiviere nur die aktuelle URL (dies ist sehr nützlich für die Verwendung auf Deiner Homepage).
4. Status Aus: Ausnahmen (aktuelle URL, Posttyp oder Archiv)

Alles ist nach dem Plugin- oder Theme-Namen gruppiert. Das macht es super einfach, ein ganzes Plugin auf einmal zu deaktivieren. Normalerweise hat ein WordPress-Plugin sowohl eine JavaScript- als auch eine CSS-Datei. Ein WordPress-Theme kann mehr als 10 Dateien enthalten.

Nachdem Du die Einstellungen ausgewählt und geändert hast, musst Du unten auf „Speichern“ klicken. Du kannst dann mit einem Geschwindigkeitstool testen, ob die Skripte nicht mehr auf die Seite oder den Beitrag geladen werden. Stelle sicher, dass Du zuerst Deinen Cache leerst! Und wenn auf Deiner Webseite visuell etwas schief geht, kannst Du es in den Einstellungen jederzeit wieder aktivieren, um alles wieder herzustellen.

In einem Geschwindigkeitstest von woorkup konnten sie die Gesamtladezeiten um 20,2% reduzieren. Allein auf ihrer Homepage konnten sie die Anzahl der HTTP-Requests von 46 auf 30 reduzieren. Auch die Seitengröße schrumpfte von 506,3 KB auf 451,6 KB.

Für andere Möglichkeiten, Skripte zu deaktivieren, lies unseren Blogbeitrag, wie du WordPress-Plugins vom Laden ausschließen kannst.

Analyse der Performance von Drittanbietern

Grundsätzlich hat alles, was du von deiner Webseite aus extern aufrufst, Konsequenzen für die Ladezeit. Was dieses Problem noch verschlimmert, ist, dass einige Abfragen nur sporadisch langsam sind, was die Identifizierung des Problems noch schwieriger macht.
Ein externer Dienst eines Drittanbieters könnte als alles angesehen werden, was mit Deiner WordPress-Seite von außerhalb Deines eigenen Servers kommuniziert. Hier sind einige häufige Beispiele, die uns regelmäßig begegnen:

• Social Media Plattformen wie Twitter, Facebook und Instagram (Widgets oder Konvertierungspixel)
• Drittwerbenetzwerke wie Google Adsense, Media.net, BuySellAds, Amazon Associates, etc.
• Seitenanalyse und Tracking-Skripte wie Google Analytics, Crazy Egg, Hotjar, AdRoll etc.
• A/B-Testtools wie Optimizely, VWO, Unbounce, etc.
• WordPress Kommentarsysteme wie Disqus, Jetpack, Facebook Kommentare
• Backup- und Sicherheitstools wie VaultPress, Sucuri, CodeGuard etc.
• Tools für den sozialen Austausch wie SumoMe und HelloBar
• CDN-Netzwerke wie KeyCDN, Amazon CloudFront, CDN77 und StackPath
• Extern gehostetes Javascript

Wie stark beeinflussen einige dieser Tracker von Drittanbietern die Leistung? In unserer eigenen Fallstudie haben wir festgestellt, dass Skripte von Drittanbietern die Seitenladezeiten um 86,08% erhöht haben.
Ghostery maß auch die Top 500 US-Domains in Alexa, und die Ergebnisse waren erstaunlich, wenn auch für uns nicht überraschend. Webseiten waren 2x langsamer, wenn überhaupt keine Tracker blockiert wurden. Das bedeutet, dass diese Tracking-Skripte von Drittanbietern einer der Hauptfaktoren für langsame Seitenladegeschwindigkeiten im Web sind.

Du musst sehr vorsichtig auf deiner WordPress-Seite sein. Nur ein einziger fehlerhafter API-Aufruf eines Drittanbieters könnte die gesamte Webseite ausfallen lassen! Ja, so sollte es nicht funktionieren, aber in vielen Fällen passiert das leider. Wir haben das öfter miterlebt, als wir zählen können.

New Relic bietet eine ausgezeichnete und einfache Möglichkeit, die externen Dienste im Laufe der Zeit zu überwachen. In diesem Beispiel unten sehen wir externe Anrufe an twitcount.com, graph.facebook.com und widgets.pinterest.com.

Es ist wichtig, dass, wann immer du eine neue Funktion oder ein Plugin zu deiner Webseite hinzufügst, du die externen Ressourcen untersuchst, die von ihr geladen werden. Je weniger, desto besser!

Optimiere alles mit der Prämisse “Mobile First” im Hinterkopf

Google begann am 26. März 2018 mit der Einführung des Mobile-First-Index. Bisher haben die Crawler-, Indexierer- und Rankingsysteme von Google die Desktop-Version von Webseiten verwendet. Mobile-first indexing bedeutet, dass Googlebot nun die mobile Version deiner WordPress-Seite für die Indexierung und das Ranking verwendet. Dies trägt dazu bei, das Sucherlebnis für mobile Nutzer zu verbessern.

Wenn es darum geht, deine Webseite für mobile-first zu optimieren, ist Geschwindigkeit einer der wichtigsten Faktoren, auf die du dich konzentrieren solltest. Geschwindigkeit spielt eine große Rolle in allem, von der Benutzerfreundlichkeit bis hin zu Bounce-Raten und der Entscheidung, ob potenzielle Käufer auf deine Webseite zurückkehren werden oder nicht. Tatsächlich ist die Geschwindigkeit heute ein Schlüsselfaktor von Google Search und Anzeigen für die mobile Suche.

Schlechte mobile Erfahrungen werden die Mehrheit der Nutzer dazu bringen, nie wieder zurückzukehren. Laut dem neuesten Google Page Speed Report betrug die durchschnittliche Ladezeit einer mobilen Webseite im Jahr 2018 15 Sekunden. Kannst Du Dir vorstellen, so lange zu warten, um eine einzelne Seite zu laden? Erstaunlich.

Die Nutzer fordern (und verdienen) mehr. Laut dem gleichen Bericht über die Seitengeschwindigkeit verlassen 53% der Besucher mobiler Webseiten, diejenigen Seiten, die länger als drei Sekunden zum Laden benötigen.

Langsame mobile Erlebnisse verhindern nicht nur die Konvertierung. Sie hindern dich daran, überhaupt eine Chance zu bekommen, potenzielle Kunden zu konvertieren. Wenn die Ladezeiten der Seiten um nur wenige Sekunden zunehmen, steigt die Wahrscheinlichkeit, dass jemand bounct, exponentiell an. Hier sind einige Dinge, die bei der Optimierung für das Handy zu beachten sind.

Überprüfe Deinen mobilen Traffic

Es ist immer wichtig, einen Blick darauf zu werfen, wieviel mobilen Traffic Du bekommst, da sich dadurch Deine Prioritäten ein wenig verschieben können. Wie viele mobile Geräte Deine Seite in Google Analytics besuchen, kannst Du unter „Audience → Mobile → Overview“ sehen. Wie Du auf dieser Seite sehen kannst, sind über 67% des gesamten Datenverkehrs vom Handy aus möglich. Das ist eine Menge!

Wenn du ein Kinsta-Kunde bist, kannst du auch deinen mobilen vs. Desktop-Traffic im MyKinsta Analytics-Tool überprüfen. Wie du auf dieser Seite sehen kannst, stammen über 88% des Datenverkehrs vom Desktop. Es ist immer wichtig zu überprüfen und nicht nur anzunehmen. Nur weil jeder sagt, dass die Dinge mobil werden, bedeutet das nicht immer, dass das für deine Seite gilt. Sieh dir unbedingt immer die Daten an.

Stelle sicher, dass deine Seite responsive ist

Im Jahr 2019 sollte deine Webseite responsive sein! Das bedeutet, dass es Medienabfragen nutzt, um die Dinge auf mobilen Geräten automatisch zu reduzieren. Wenn du das immer noch nicht getan hast, liegst du höchstwahrscheinlich schon hinter deiner Konkurrenz zurück. Alle WordPress-Themes, die wir bereits in diesem Beitrag erwähnt haben, sind voll responsive und sehen auf allen Geräten fantastisch aus.

Verwende das Mobile-Friendly-Tool von Google, um zu testen und sicherzustellen, dass Deine Webseite alle Anforderungen erfüllt.

Überprüfe doppelt ob srcset funktioniert

Bisher war es sehr wichtig, dass man Bilder hochlädt, um sie zu skalieren und sie nicht von CSS skalieren zu lassen. Das ist jedoch nicht länger von Bedeutung, da WordPress 4.4 nun responsive Bilder unterstützt (nicht durch CSS verkleinert). WordPress erstellt automatisch mehrere Größen von jedem Bild, das in die Medienbibliothek hochgeladen wird. Durch das Einfügen aller verfügbaren Größen eines Bildes in ein srcset-Attribut können Browser nun die am besten geeignete Größe herunterladen und die anderen ignorieren. Sieh dir unten ein Beispiel an, wie dein Code aussehen könnte.

Aufgrund all der Bild-Plugins und Anpassungen von Drittanbietern gab es häufig Fälle, in denen wir gesehen haben, dass das nicht richtig funktioniert. Daher ist es wichtig, noch einmal zu überprüfen, ob die Bilder stimmig sind und das Attribut srcset mit verschiedenen Versionen für die unterschiedlichen Bildschirmgrößen hinzugefügt wird. Die Bildoptimierung ist nun stets von Bedeutung.

Google AMP ist eventuell eine Lösung für dich

Google AMP (Accelerated Mobile Pages Project) wurde ursprünglich bereits im Oktober 2015 eingeführt. Das Projekt basiert auf AMP HTML, einem neuen offenen Framework, das vollständig aus bestehenden Web-Technologien besteht und es Webseiten ermöglicht, leichte Seiten zu erstellen. Um es einfach auszudrücken, bietet es die Möglichkeit, eine abgespeckte Version deiner aktuellen Webseite bereitzustellen.

Wir haben eine Art Hassliebe zu Google AMP, und so geht es auch einem Großteil der Community. Wir haben die Technik selbst getestet und keine guten Ergebnisse erzielt. Das bedeutet jedoch nicht, dass es für dich keine Vorteile bringen könnte. Jede Webseite ist anders, und Google AMP wird ständig verbessert.

Du kannst mit einem der folgenden Plugins schnell mit Google AMP auf Deiner WordPress-Seite beginnen:

• AMP für WordPress
• AMP für WP

In unserem ausführlichen Tutorial erfährst Du, wie Du Google AMP einrichten kannst. Und wenn Du es brauchst, wie du Google AMP deaktivieren kannst. Es nur zu deaktivieren führt leider nicht zum gewünschten Ergebnis.

Zusammenfassung

Wie du wahrscheinlich bemerkt hast, lieben wir es, alle Methoden der WordPress Optimierung genauer zu untersuchen und auszuprobieren. Eine schnelle Webseite hilft, deine Rankings zu verbessern, die Crawlability für Suchmaschinen zu erhöhen, die Konversionsraten zu steigern, die Zeit, die Benutzer auf einer Webseite verbringen zu erhöhen und deine Bounce-Rate zu reduzieren. Ganz zu schweigen von der Tatsache, dass jeder gerne eine schnelle Webseite besucht!

Wir hoffen, dass dieser Guide hilfreich war und dass du ein paar Dinge mitnehmen und auf deine WordPress-Seite anwenden kannst.

Haben wir etwas Wichtiges vergessen? Wenn ja, würden wir gerne davon hören. Lass uns Deine WordPress-Tipps unten in den Kommentaren wissen.