Pingdom-Geschwindigkeitstest-Tool: Der ultimative Leitfaden

Heute wollen wir uns damit beschäftigen, wie man die Daten des beliebten Website-Geschwindigkeitstests Pingdom besser nutzen und verstehen kann. Du kannst damit eine Wasserfall-Analyse deiner WordPress-Website durchführen. Das kann dir helfen, Leistungsprobleme schnell zu diagnostizieren und Fehldiagnosen zu vermeiden.

Oft sehen wir, dass WordPress-Nutzer die Daten im Pingdom-Geschwindigkeitstest falsch interpretieren, was manchmal dazu führt, dass eine Website so konfiguriert wird, dass sie noch schlechter läuft als zuvor. Denk daran, dass alle Tools dieser Art nur als Orientierungshilfe dienen. Sie sind niemals zu 100 % genau. Wichtig ist, dass du konsequent bleibst und bei allen deinen Tests dasselbe Tool verwendest.

Was ist das Pingdom-Geschwindigkeitstest-Tool?

Pingdom ist ein Unternehmen mit Sitz in Schweden (das mittlerweile zu SolarWinds gehört), das verschiedene Dienste anbietet, wie z. B. Verfügbarkeitsüberwachung, Websites-Geschwindigkeitsüberwachung, Transaktionsüberwachung, Serverüberwachung und Besucheranalysen (RUM). Besonders bekannt ist das Unternehmen für sein kostenloses Tool zum Testen der Website-Geschwindigkeit. Es ist eines der beliebtesten Tools zur Leistungsmessung in der WordPress-Community.

Warum ist es so beliebt? Nun, zum einen ist es wahrscheinlich das am einfachsten zu bedienende Tool zur Geschwindigkeitsmessung! Nicht jeder ist ein Experte für Web-Performance, daher können einige der anderen verfügbaren Tools für den typischen WordPress-Nutzer ziemlich überwältigend sein. Manchmal ist weniger mehr, wie man so schön sagt. Schließlich interessiert dich nur, wie schnell deine Website ist und wie du sie schneller machen kannst.

Mit Pingdom kannst du derzeit die Geschwindigkeit jeder Website von 7 verschiedenen Standorten (5 Kontinente) aus testen, die strategisch rund um den Globus verteilt sind:

• Asien – Japan – Tokio
• Europa – Deutschland – Frankfurt
• Europa – Vereinigtes Königreich – London
• Nordamerika – USA – Washington, D.C.
• Nordamerika – USA – San Francisco
• Pazifik – Australien – Sydney
• Südamerika – Brasilien – São Paulo

Hinweis: Uns ist aufgefallen, dass gelegentlich nicht alle Teststandorte verfügbar sind. Das liegt höchstwahrscheinlich daran, dass der Standort wegen Wartungsarbeiten offline ist oder durch zu viele Nutzer, die dort Tests durchführen wollen, überlastet wurde. Wenn ein Teststandort, den du bisher genutzt hast, nicht mehr verfügbar ist, schau in ein oder zwei Stunden noch einmal nach. Höchstwahrscheinlich wird er wieder erscheinen.

Der von dir gewählte Teststandort ist entscheidend für den physischen Standort, an dem deine Website gehostet wird. Hier kommt ein kleiner Faktor namens Netzwerklatenz ins Spiel. Aber darauf gehen wir weiter unten noch genauer ein.

Wasserfallanalyse mit dem Pingdom-Geschwindigkeitstest-Tool

Eine Webseite besteht aus verschiedenen Elementen wie HTML, JavaScript, CSS, Bildern und Videos. Jedes dieser Elemente generiert Anfragen, um das darzustellen, was du auf deiner Website siehst. Normalerweise gilt: Je mehr Anfragen es gibt, desto langsamer lädt deine Website. Das ist nicht immer der Fall, trifft aber in den meisten Fällen zu.

Im Folgenden werden wir jeden Abschnitt von Pingdom einzeln betrachten und genauer erklären, was die Informationen im Hinblick auf die Gesamtleistung deiner Website bedeuten und wie man eine Wasserfallanalyse durchführt.

• Pingdom-Zusammenfassung
• Einblicke in die Leistung
• Antwortcodes
• Inhaltsgröße und Anfragen nach Inhaltstyp
• Inhaltsgröße und Anfragen nach Domain
• Wasserfall-Diagramm
• Fallstudie zur Domain-Konfiguration

Pingdom-Zusammenfassung

Wenn du deine WordPress-Website über Pingdom testest, werden eine Leistungsbewertung, die Gesamtladezeit, die Gesamtseitengröße und die Anzahl der Anfragen auf deiner Website ermittelt. In unserem Beispiel handelt es sich um eine E-Commerce-Website, auf der „Easy Digital Downloads“ läuft. Sie wird auf den blitzschnellen Servern von Kinsta gehostet.

Wie du sehen kannst, haben wir unseren ersten Test durchgeführt und bei Pingdom 88 von 100 Punkten erzielt; die Gesamtladezeit beträgt 541 ms. So erfahren wir die Gesamtgröße unserer kombinierten Assets und die Anzahl der Anfragen.

Wir haben dann einen weiteren Test durchgeführt, und jetzt beträgt unsere Gesamtladezeit 392 ms bei gleicher Seitengröße und gleicher Anzahl an Anfragen! Was hat das zu bedeuten? 🤔 Das fällt dir vielleicht auf, wenn du deine Website mehrmals mit dem Pingdom-Geschwindigkeitstest-Tool testest. Bei größeren Websites sind die Unterschiede sogar noch deutlicher.

Dafür gibt es drei Hauptgründe: DNS-Caching, CDN-Caching und WordPress-Caching . Deshalb solltest du Tests immer mehrmals durchführen. Natürlich können auch externe Aufrufe von Drittanbieter-Ressourcen und APIs einen Einfluss darauf haben. Warum das so ist, erfährst du weiter unten in unserer Wasserfall-Analyse.

Möchtest du einen besseren Pingdom-Score für deine WordPress-Website erzielen? Je nach deiner Website und Konfiguration ist es vielleicht nicht immer möglich, die perfekte Punktzahl von 100/100 zu erreichen, besonders wenn du E-Commerce-Websites betreibst oder Marketing-Pixel einsetzt. Aber schon allein die Zeit, die du in die Verbesserung deines Scores investierst, ist ein hervorragender Anfang. Die Gesamtgeschwindigkeit ist wirklich das Wichtigste.

Manchmal kann die Benutzererfahrung auch wichtiger sein als einige der Web-Performance-Tricks, über die du im Internet liest. Die Benutzererfahrung darfst du nicht vergessen! Aber keine Sorge, weiter unten verraten wir dir ein paar Tipps und Tricks, wie wir die oben genannte Website so schnell eingestellt haben – also lies einfach weiter.

WinningWP hat unabhängig Geschwindigkeitstests durchgeführt, bei denen Kinsta mit anderen führenden Hosting-Anbietern verglichen wurde, und festgestellt, dass Kinsta „viel schneller“ war – mit einer durchschnittlichen Ladezeit von nur 394 ms.

Websiteleistung verbessern

Der Bereich „Performance-Einblicke“, jetzt „Websiteleistung verbessern“, wurde 2018 aktualisiert; dabei wurden einige alte Punkte entfernt und neue hinzugefügt. Das liegt höchstwahrscheinlich daran, dass einige der dort aufgeführten Vorschläge nicht mehr so relevant sind wie früher. Wenn es um die Optimierung der Web-Performance geht, ändern sich die Dinge ständig. Und es kann manchmal problematisch sein, wenn man einfach nur versucht, dem perfekten Pingdom-Ergebnis hinterherzujagen.

Wir lassen diesen gesamten Abschnitt jedoch in unserem Beitrag stehen (sowohl alte als auch neue Inhalte), da es wichtig ist zu verstehen, wie diese Werte berechnet werden. Diese basieren im Wesentlichen alle auf den Regeln von Google PageSpeed Insights. Wenn du diese Aspekte auf deiner Website verbesserst, solltest du im Allgemeinen deine Ladezeiten insgesamt verkürzen können.

Hier sind ein paar der Kategorien aus dem Abschnitt „Websiteleistung verbessern“:

• Verwende ein Content Delivery Network (CDN)
• Vermeide HTTP-404-Fehler (Nicht gefunden)
• Minimiere Weiterleitungen
• Füge „Expires“-Header hinzu
• Entferne Abfragezeichenfolgen aus statischen Ressourcen
• Verwende Cookie-freie Domains
• Parallelisiere Downloads über Hostnamen hinweg
• Cache-Validator festlegen
• Einen „Vary: Accept-Encoding“-Header festlegen

Schauen wir uns nun einige davon genauer an und prüfen wir, welche davon heute noch relevant sind.

Nutze ein Content Delivery Network (CDN)

Einer der wichtigsten Dienste, die du heute auf deiner WordPress-Website implementieren solltest, ist ein Content Delivery Network (CDN). Dabei handelt es sich um ein Netzwerk von Servern (auch als POPs bezeichnet), die rund um den Globus verteilt sind. Sie dienen dazu, Kopien der statischen (und manchmal auch dynamischen) Inhalte deiner WordPress-Website – wie Bilder, CSS, JavaScript und Videostreams – zu hosten und bereitzustellen.

Wenn du Kinsta-Kunde bist, ist ein CDN in unseren Hosting-Paketen enthalten. Die Aktivierung ist mit wenigen Klicks erledigt. Zu den Vorteilen eines CDNs gehören eine Leistungssteigerung (niedrigerer TTFB und geringere Netzwerklatenz), geringere Bandbreiten- und Hosting-Kosten sowie sogar SEO-Vorteile.

Wichtig: Das kürzlich aktualisierte Pingdom-Tool weist derzeit einen Fehler auf, der CDN-Anbieter nicht korrekt erkennt.

Zu den von uns empfohlenen CDN-Anbietern von Drittanbietern gehören:

• KeyCDN (damit läuft das Kinsta-CDN)
• Cloudflare
• CDN77

Bei unseren eigenen CDN-Geschwindigkeitstests haben wir festgestellt, dass ein CDN die Ladezeiten von Websites in manchen Fällen um über 50 % verkürzen kann!

Vermeide den HTTP-404-Fehler (Nicht gefunden)

Dieser Abschnitt hieß früher „Falsche Anfragen vermeiden“. Und das ist immer relevant! Diese Warnung ist genau das, wonach es klingt: Es handelt sich um eine Anfrage, die nicht erfolgreich abgeschlossen werden konnte. Das passiert typischerweise, wenn du manuell auf eine Datei oder ein Bild verlinkst, das inzwischen gelöscht wurde, was zu einem 404-Fehler führt. In Pingdom wird dies als orangefarbener Kreis angezeigt, zusammen mit einem 404 im Status des Antwort-Headers.

Stell immer sicher, dass jede Anfrage auf deiner Website mit einem Erfolgstatus zurückkehrt. So stellst du sicher, dass keine Abfragen an Assets generiert werden, die nicht mehr existieren.

Minimiere Weiterleitungen

Zu viele Weiterleitungen sind immer etwas, worauf du achten musst. Einfache Weiterleitungen wie eine einzelne 301-Weiterleitung, von HTTP zu HTTPS oder von www zu nicht-www (und umgekehrt) sind akzeptabel. Und oft sind diese in bestimmten Bereichen deiner Website notwendig. Allerdings beeinträchtigt jede einzelne davon die Leistung deiner Website. Und wenn du anfängst, Weiterleitungen übereinander zu stapeln, ist es wichtig zu erkennen, wie sich das auf die Leistung deiner Website auswirkt. Das gilt für Seiten- und Beitragsweiterleitungen, Bildweiterleitungen – für alles.

Wie stark wirken sich Weiterleitungen auf deine Website aus? Machen wir einen kleinen Test. Zunächst führen wir einen Geschwindigkeitstest auf unserer Kontaktseite durch. Wir erhalten eine Gesamtladezeit von 417 ms, wie du unten sehen kannst.

Anschließend ändern wir die URL leicht ab und führen einen weiteren Geschwindigkeitstest durch, um die Auswirkungen mehrerer Weiterleitungen zu sehen. Wie du sehen kannst, braucht dieselbe Seite jetzt 695 ms zum Laden. Das ist eine Steigerung um 66 %. Huch!

Schau dir unseren ausführlichen Beitrag zu WordPress-Weiterleitungen und den Best Practices für eine schnellere Leistung an.

„Expires“-Header hinzufügen

Dieser Vorschlag hieß früher „Browser-Caching nutzen“. Einfach ausgedrückt: Jedes Skript auf deiner WordPress-Seite muss mit einem HTTP-Cache-Header versehen sein (oder sollte es zumindest). Dieser legt fest, wann der Cache der Datei abläuft. Um das zu beheben, stelle sicher, dass dein WordPress-Host die richtigen cache-control-Header und expires-Header eingerichtet hat. Bei Kinsta sind diese Header auf allen unseren Servern bereits vorhanden.

Schau dir die Schritte zum manuellen Hinzufügen von Caching-Headern auf deinem Server an und lies unseren Leitfaden zum Hinzufügen von „Expires“-Headern.

Das andere Problem ist, dass du beim Laden von Skripten von Drittanbietern keinen Zugriff hast, um die Caching-Header hinzuzufügen, da du keine Kontrolle über deren Webserver hast. Häufige Verursacher sind das Google-Analytics-Skript und Marketing-Pixel wie die von Facebook und Twitter. Um das zu beheben, kannst du dein Google-Analytics-Skript lokal hosten (auch wenn das offiziell nicht unterstützt wird) – mit einem Plugin eines Drittanbieters. WP Rocket bietet jetzt auch eine Option, dein Facebook-Marketing-Pixel lokal zu hosten.

Die Auswirkungen der lokalen Verlagerung von Skripten auf die Leistung deiner Website können variieren. Der Vorteil ist, dass du die vollständige Kontrolle über die Datei hast und sie über dein CDN bereitstellen kannst. Dadurch entfällt zudem eine weitere DNS-Anfrage an Drittanbieter. Es ist jedoch auch wichtig zu bedenken, dass diese Dateien möglicherweise bereits im Browser der Besucher zwischengespeichert sind.

Lies unseren ausführlichen Beitrag dazu, wie du die Warnung „Leverage Browser Caching“ beheben kannst.

Entferne Abfragezeichenfolgen aus statischen Ressourcen

Ein weiteres häufiges Problem sind Query-Strings. Deine CSS- und JavaScript-Dateien haben normalerweise die Dateiversion am Ende ihrer URLs, zum Beispiel https://domain.com/file.min.css?ver=4.5.3. Manche Server und Proxy-Server können Query-Strings nicht zwischenspeichern. Indem du sie entfernst, kannst du daher manchmal die Zwischenspeicherung verbessern.

Oder du kannst den folgenden Code manuell in die Datei functions.php deines Themes einfügen. Eine bessere Alternative wäre es, ein kostenloses Plugin wie „Code Snippets“ zu verwenden, um den Code hinzuzufügen. Auf diese Weise musst du dein Theme nicht direkt bearbeiten.

function remove_query_strings() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);
   }
}

function remove_query_strings_split($src){
   $output = preg_split("/(&ver|\?ver)/", $src);
   return $output[0];
}
add_action('init', 'remove_query_strings');

Bevor du jedoch sofort alle Abfragezeichenfolgen auf deiner Website entfernst, ist es wichtig zu wissen, wozu sie dienen. WordPress-Entwickler nutzen in der Regel die Versionsverwaltung bei Dateien, um Caching-Probleme zu umgehen.

Wenn sie beispielsweise ein Update veröffentlichen und style.css von ?ver=4.6 in ?ver=4.7 ändern, wird dies als völlig neue URL behandelt und nicht zwischengespeichert. Wenn du die Abfragezeichenfolgen entfernst und ein Plugin aktualisierst, könnte dies dazu führen, dass weiterhin die zwischengespeicherte Version ausgeliefert wird. In manchen Fällen könnte dies das Erscheinungsbild deiner Website beeinträchtigen, bis die zwischengespeicherte Ressource abläuft oder der Cache vollständig geleert wird.

Außerdem können manche CDNs Abfragezeichenfolgen zwischenspeichern. Das Kinsta-CDN kann dies und tut es standardmäßig. Wenn du also ein Kinsta-Kunde bist, werden Abfragezeichenfolgen bei deinen Assets bereits zwischengespeichert.

Lies unser ausführliches Tutorial dazu, wie du Abfragezeichenfolgen aus statischen Ressourcen entfernst.

Verwende cookie-freie Domains

Wir haben einen ausführlichen Beitrag zum Umgang mit der Warnung „Statische Inhalte von einer cookielosen Domain bereitstellen“. Oft kannst du diese Warnung ignorieren, da neue Protokolle wie HTTP/2 dies mittlerweile weniger wichtig machen. Eine neue Verbindung ist in der Regel aufwendiger, als alles über dieselbe Verbindung zu streamen. Es gibt jedoch zwei Möglichkeiten, dies zu lösen: Entweder nutzt du einen CDN-Anbieter, der die Cookies entfernt, oder du richtest eine separate Domain oder Subdomain ein.

Weitere Informationen findest du in unserem Beitrag zur Verwendung von cookielosen Domains.

Komponenten mit GZIP komprimieren

Die Warnung „Komponenten mit GZIP komprimieren“ erscheint, wenn Pingdom ein Asset erkennt, das nicht mit GZIP komprimiert wurde. GZIP ist ein Komprimierungsverfahren, mit dem die Größe von textbasierten Dateien wie HTML-Dokumenten und CSS-/JS-Dateien reduziert wird. Die GZIP-Komprimierung ist auf dem Server aktiviert und komprimiert Webseiten und Assets, bevor sie an Besucher gesendet werden. Unsere Tests haben gezeigt, dass die Aktivierung der GZIP-Komprimierung die Dateigröße einer Anfrage um über 78 % reduziert hat.

Bei Kinsta musst du dir keine Gedanken über die Aktivierung von GZIP machen, da jede Kinsta-Website bereits von der Brotli-Komprimierung profitiert – einer schnelleren Alternative zur GZIP-Komprimierung. Das liegt an unserer einzigartigen Cloudflare-Integration. Das bedeutet, dass deine bei Kinsta gehostete Website schneller ist als die der Konkurrenz, die GZIP nutzt, und auch auf kleineren Geräten blitzschnell geladen wird.

Wenn du nach der Aktivierung von GZIP auf deinem Server immer noch die Meldung „Komponenten mit GZIP komprimieren“ siehst, ist es möglich, dass auf einem Server, der ein von deiner Website benötigtes externes Asset hostet, weder GZIP- noch Brotli-Komprimierung aktiviert ist. In diesem Fall kannst du von deiner Seite aus nichts tun, um das Verhalten des Servers zu ändern.

Downloads über Hostnamen hinweg parallelisieren

Die Warnung „Downloads über Hostnamen hinweg parallelisieren“ resultiert aus einer Einschränkung von HTTP/1.1 und der Tatsache, dass Webbrowser in der Anzahl der gleichzeitigen Verbindungen zu einem Host begrenzt sind; in der Regel sind das sechs Verbindungen. Diese Warnung tritt typischerweise auf Websites mit einer großen Anzahl von Anfragen auf. Früher war die einzige Möglichkeit, diese Einschränkung zu umgehen, die Implementierung des sogenannten Domain-Shardings.

Angenommen, du nutzt jedoch einen Webhost oder CDN-Anbieter, der HTTP/2 unterstützt. In diesem Fall kannst du diese Warnung jetzt getrost ignorieren, da mehrere Ressourcen nun parallel über eine einzige Verbindung geladen werden können. Du kannst dir aber auch unser Tutorial ansehen, in dem erklärt wird, wie du die Warnung „Parallelisierte Downloads über Hostnamen hinweg“  durch die Implementierung von Domain-Sharding beheben kannst.

Cache-Validator angeben

Diese Warnung bezieht sich auf fehlende HTTP-Caching-Header, die in jeder Antwort des Ursprungsservers enthalten sein sollten, da sie sowohl die Gültigkeit des Caches überprüfen als auch dessen Dauer festlegen. Wenn die Header nicht gefunden werden, wird jedes Mal eine neue Anfrage für die Ressource generiert, was die Auslastung deines Servers erhöht. Zu diesen Headern gehören last-modified, ETag, Cache-Control und Expires. Wie bei der Warnung „Browser-Caching nutzen“ sollte dein WordPress-Host diese Header automatisch hinzufügen. Wenn du diese Warnung bei Anfragen von Drittanbietern siehst, kannst du nichts dagegen tun, da du keine Kontrolle über deren Webserver hast.

Lies unseren ausführlichen Beitrag darüber, wie du die Warnung „Cache-Validator angeben“ beheben kannst.

„Gib einen Vary: Accept-Encoding-Header an“

Wir haben einen ausführlichen Beitrag zur Behebung der Warnung „Gib einen Vary: Accept-Encoding-Header an“ veröffentlicht. Dabei handelt es sich um einen HTTP-Header, der in jeder Antwort des Ursprungsservers enthalten sein sollte, da er dem Browser mitteilt, ob der Client komprimierte Versionen des Inhalts verarbeiten kann oder nicht. Dieser wird automatisch auf allen Servern von Kinsta hinzugefügt.

Pingdom-Antwortcodes

Der folgende Abschnitt im Pingdom-Geschwindigkeitstest-Tool befasst sich mit den Antwortcodes. Antwortcodes, auch als HTTP-Statuscodes bezeichnet, sind wie eine kurze Notiz vom Webserver, die ganz oben auf einer Webseite angehängt wird. Es handelt sich um eine Nachricht des Webservers, die dir mitteilt, wie der Vorgang abgelaufen ist, als die Anfrage zum Aufrufen der Seite eingegangen ist. Einige gängige Beispiele sind:

• 200: „Alles ist in Ordnung.“ Dieser Code wird zurückgegeben, wenn eine Webseite oder Ressource genau so funktioniert, wie es erwartet wird.

  

• 301: „Die angeforderte Ressource wurde dauerhaft verschoben.“ Dieser Code wird zurückgegeben, wenn eine Webseite oder Ressource dauerhaft durch eine andere Ressource ersetzt wurde. Er wird für dauerhafte URL-Weiterleitungen verwendet.

  

• 404: „Die angeforderte Ressource wurde nicht gefunden.“ Die häufigste Fehlermeldung überhaupt. Dieser Code bedeutet, dass die angeforderte Ressource nicht existiert und der Server nicht weiß, ob sie existiert.

  

Mehr über die verschiedenen Antwortcodes erfährst du in unserem ausführlichen Beitrag zu HTTP-Statuscodes.

Inhaltsgröße und Anfragen nach Inhaltstyp

In den folgenden Abschnitten geht es um die Inhaltsgröße nach Inhaltstyp und die Anfragen nach Inhaltstyp. Beides ist nützlich, um schnell zu erkennen, was auf deiner Webseite die meisten Ressourcen beansprucht. Laut HTTP Archive machen Bilder im Durchschnitt 43 % der Gesamtgröße einer typischen Webseite aus. Das beobachten wir in der Regel auch so. Wie du jedoch unten auf dieser Seite sehen kannst, ist das nicht immer der Fall.

Zur Optimierung eurer Bilder empfehlen wir euch dringend, unseren ausführlichen Beitrag darüber zu lesen, wie man Bilder für das Web optimiert und was es mit WebP auf sich hat. Es gibt viele tolle Tools und Plugins, mit denen ihr eure Bilder weiter komprimieren könnt, um sicherzustellen, dass sie nicht den Großteil der Ladezeit eurer Website ausmachen. Und in unserem obigen Beispiel nutzt die Website große Font Awesome-Icons anstelle von Bildern. Das kann eine großartige Strategie sein, die einen riesigen Unterschied macht. Und natürlich haben wir in unserem Leitfaden zur Seitengeschwindigkeit noch einige zusätzliche Tipps, wie du die Größe deiner Inhalte weiter reduzieren kannst.

Inhaltsgröße und Anfragen pro Domain

Der Abschnitt „Inhaltsgröße und Anfragen nach Domain“ ist eine hervorragende Möglichkeit, schnell zu erkennen, welche externen Dienste und Skripte auf deiner Website vorhanden sind. In unserem Beispiel siehst du, dass alle unsere Assets über unser CDN geladen werden. Dann gibt es noch das anfängliche Laden des HTML-Dokuments für die Website vom Webserver sowie einen externen Aufruf an die Google-Analytics-Domain. Abhängig von deiner Website hast du vielleicht noch weitere externe Dienste wie Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg usw.

Generell gilt: Je weniger externe Anfragen du stellen musst, desto besser, denn jeder externe Dienst verursacht Latenz, Verzögerungen beim TLS-Handshake, DNS-Lookups usw. Lies dir unbedingt unseren ausführlichen Beitrag zum Erkennen und Analysieren externer Dienste auf deiner WordPress-Website durch.

Generell ist es am besten, die Anzahl der Anfragen so weit wie möglich zu reduzieren und die Assets an einem Ort zu hosten, z. B. indem du sie auf deinen Webserver oder ein CDN verschiebst. Ein Beispiel wäre Font Awesome. Anstatt auf das externe Skript für Font Awesome zu verlinken, lade es herunter und stelle es direkt bereit.

Pingdom-Wasserfall-Diagramm

Und zu guter Letzt gibt es den Abschnitt „Anfragen“ im Pingdom-Geschwindigkeitstest-Tool, der ein Wasserfall-Diagramm aller einzelnen Anfragen auf deiner Webseite erstellt (wie unten gezeigt). Du kannst dann jede einzelne Anfrage analysieren, um festzustellen, was Verzögerungen und Leistungsprobleme auf deiner Website verursacht. Das meinen wir, wenn wir von einer Wasserfall-Analyse sprechen. Im Folgenden findest du eine ausführlichere Zusammenfassung bzw. Definition der Bedeutung der einzelnen Statusfarben.

DNS (Rosa)

Was ist also DNS? Stell es dir einfach wie ein Telefonbuch vor. Es gibt Server, sogenannte Domain Name Server, die die Informationen über deine Website speichern und wissen, an welche IP-Adresse sie weitergeleitet werden soll. Wenn du deine Website zum ersten Mal über Pingdom laufen lässt, führt das Tool eine neue Abfrage durch und muss die DNS-Einträge abfragen, um die IP-Informationen zu erhalten. Das führt zu einer gewissen zusätzlichen Abfragezeit. Auch der Standort des DNS-Servers spielt eine Rolle.

Wenn du deine Website mehr als einmal über Pingdom laufen lässt, speichert Pingdom die DNS-Daten im Cache, da es die IP-Informationen bereits kennt und die Abfrage nicht erneut durchführen muss. Deshalb erscheint deine Website schneller, nachdem du sie mehrmals über Pingdom geprüft hast.

Wie du auf dem Bild unten sehen kannst, betrug beim zweiten Test, den wir durchgeführt haben, die DNS-Lookup-Zeit beim ersten Laden des DOC 3,6 ms. Normalerweise sinkt sie dann wie erwartet auf 0 ms, da die Anfrage bereits zwischengespeichert ist. Das ist ein Punkt, den viele Leute falsch interpretieren!

Außerdem kannst du das Ganze noch weiter optimieren, indem du einen Premium-DNS-Dienst nutzt – der bringt zudem viele zusätzliche Vorteile mit sich. Auch der kostenlose DNS-Dienst von Cloudflare ist schnell! Schau dir mal die automatische Plattformoptimierung von Cloudflare an.

Weitere Gründe, warum deine Website nach mehreren Tests schneller erscheinen könnte. Einer davon ist, wenn du ein Content Delivery Network (CDN) nutzt. Für alle, die mit einem CDN nicht vertraut sind: Es handelt sich um ein Netzwerk globaler Server, die deine Inhalte (JS, CSS, Bilder usw.) an Standorten zwischenspeichern, die näher am Besucher liegen. Wenn du deine Website zum ersten Mal über Pingdom testest, musst du die Dateien möglicherweise erst frisch vom CDN abrufen. Ein CDN-Cache funktioniert ähnlich wie DNS. Sobald die Inhalte zwischengespeichert sind, werden sie bei nachfolgenden Ladevorgängen deutlich schneller bereitgestellt.

Ein weiterer Tipp zur Beschleunigung des DNS ist die Verwendung von DNS-Prefetching. Dadurch kann der Browser DNS-Lookups für eine Seite im Hintergrund durchführen. Das kannst du erreichen, indem du ein paar Zeilen Code in den Header deiner WordPress-Website einfügst. Unten findest du einige Beispiele.

<!-- Prefetch DNS for external assets -->
 <link rel="dns-prefetch" href="//fonts.googleapis.com">
 <link rel="dns-prefetch" href="//www.google-analytics.com"> 
 <link rel="dns-prefetch" href="//cdn.domain.com">

Oder, wenn du WordPress Version 4.6 oder neuer verwendest, kannst du „Resource Hints“ nutzen. Entwickler können den Filter wp_resource_hints verwenden, um benutzerdefinierte Domains und URLs für dns-prefetch, preconnect, prefetch oder prerender hinzuzufügen.

SSL (Lila)

Die violette Statusfarbe steht für die Zeit, die dein Browser benötigt, um einen SSL/TLS-Handshake durchzuführen. Immer wenn du eine Website über HTTPS aufrufst, ist ein SSL-Zertifikat erforderlich, und durch den Verschlüsselungsprozess (SSL/TLS-Handshake) entsteht ein zusätzlicher Zeitaufwand. Bei unserer Beispieldomain haben wir sowohl auf unserem Webserver bei Kinsta als auch auf unserem CDN, KeyCDN, ein Zertifikat. Daher entsteht eine SSL-Verhandlungszeit sowohl beim ersten Laden des HTML-Dokuments vom Webserver als auch bei unseren Assets.

Zwar entsteht durch den Betrieb von HTTPS ein leichter Mehraufwand, doch dank HTTP/2 – einem neuen Protokoll, das das Web beschleunigt – ist das mittlerweile kein entscheidender Faktor mehr! Aufgrund der Browserunterstützung ist HTTPS erforderlich, um HTTP/2 nutzen zu können. Schau dir unseren ultimativen Leitfaden zu HTTP/2 an.

Es ist außerdem wichtig zu beachten, dass selbst im Jahr 2018 noch nicht alle Anbieter HTTP/2 unterstützen. Das gilt sowohl für Webhosting-Anbieter als auch für CDNs. Wenn du also nach einem Hosting-Anbieter und einem CDN suchst, achte darauf, dass beide das Protokoll unterstützen! Kinsta ist stolz darauf, HTTP/2 für alle seine WordPress-Kunden zu unterstützen.

Mitte 2018 hat Pingdom sein Tool endlich auf Chrome 60 und höher aktualisiert. Im Request-Header kannst du sehen, dass user-agent verwendet wird. Zuvor wurde Chrome 39 verwendet, und Chrome unterstützte HTTP/2 erst ab Version 49. Wir freuen uns daher, dass das Pingdom-Tool bei der Durchführung von Tests nun alle Vorteile von HTTP/2 anzeigt! 👏

Verbindung (Teal)

Die Verbindungszeit bei Pingdom bezieht sich auf die TCP-Verbindung, also die Gesamtzeit, die zum Aufbau einer TCP-Verbindung benötigt wird. Du musst nicht verstehen, wie das funktioniert – es handelt sich einfach um einen Kommunikationsvorgang zwischen Host/Client und Server, der stattfinden muss.

Wartezeit (Gelb)

Die Wartezeit bei Pingdom bezieht sich auf die Zeit bis zum ersten Byte, in manchen Tools auch als TTFB bezeichnet. TTFB ist ein Messwert, der die Reaktionsgeschwindigkeit eines Webservers oder einer anderen Netzwerkressource angibt. Im Allgemeinen gilt alles unter 100 ms als akzeptabel und als guter TTFB-Wert. Wenn du dich dem Bereich von 300–400 ms näherst, ist möglicherweise etwas auf deinem Server falsch konfiguriert, oder es ist an der Zeit, auf einen besseren Web-Stack umzusteigen.

Der einfachste Weg, deine TTFB zu senken? Die beiden besten Methoden sind effektives WordPress-Caching und ein CDN. Also lass uns ein paar Tests durchführen.

TTFB ohne WordPress-Host-Cache

Wir haben zunächst einen Test durchgeführt, nachdem wir den Cache auf unserer WordPress-Website geleert hatten. Das bedeutet, dass der Cache erst wieder vorladen muss. Unsere Gesamtladezeit betrug 541 ms, und die TTFB (Wartezeit) bei unserer ersten Anfrage lag bei 185,2 ms.

TTFB mit WordPress-Host-Cache

Anschließend haben wir den Test erneut durchgeführt. Die Seite wird nun direkt aus dem Cache bereitgestellt. Wie du sehen kannst, ist unsere Gesamtladezeit auf 392 ms gesunken, und die TTFB bei der ersten Anfrage beträgt nun 52,8 ms! Das ist der Unterschied, den das Caching ausmacht.

Wenn du eine Website hast, die Besucher in verschiedenen Teilen des Landes oder weltweit bedient, ist die Nutzung eines CDNs eine weitere einfache Möglichkeit, deine TTFB drastisch zu senken. Wir haben erneut ein paar Tests durchgeführt, um den Unterschied zu zeigen.

TTFB ohne CDN

Zuerst haben wir einen Test mit deaktiviertem CDN durchgeführt, und wie du sehen kannst, betrug unsere Gesamtladezeit 1,93 s, und unsere durchschnittliche TTFB pro Asset lag bei etwa 176 ms.

TTFB mit CDN

Anschließend haben wir unser CDN aktiviert und den Test erneut durchgeführt. Unsere Gesamtladezeit sank auf 1,21 s, und unsere durchschnittliche TTFB für ein CDN-Element liegt nun bei 4,6 ms! Was für einen Unterschied ein CDN doch machen kann.

Ein weiterer wichtiger Punkt ist, dass wir für diesen Test den Standort „Pacific – Australia – Sydney“ gewählt haben. Warum? Weil wir euch die tatsächliche Verbesserung zeigen wollten, die sich erzielen lässt. Unsere WordPress-Seite in diesem Beispiel wird von Kinsta an einem zentralen Standort in den USA gehostet. Indem wir den Test mit Australien durchführen, können wir zeigen, wie das Kinsta-CDN-Caching die Geschwindigkeit erhöht und die TTFB verkürzt.

Und natürlich ist auch ein guter WordPress-Host mit einer durchdachten Architektur entscheidend, um deine TTFB zu senken.

Senden (orange) und Empfangen (grün)

Die Statusangaben für „Senden“ und „Empfangen“ in Pingdom bedürfen keiner großen Erklärung. Die Sendezeit ist einfach die Zeit, die der Webbrowser benötigt, um Daten an den Server zu senden. Und die Empfangszeit ist die Zeit, die der Webbrowser benötigt, um Daten vom Server zu empfangen. Beide Werte sind in deinen Tests normalerweise sehr niedrig oder gar nicht vorhanden.

HTTP-Antwort-Header

Du kannst während deiner Wasserfall-Analyse auch auf eine einzelne Anfrage klicken und dir die HTTP-Antwort-Header ansehen. Das liefert wertvolle Informationen. Auf dem Bildschirm unten sehen wir auf einen Blick, dass beispielsweise gzip auf dem Webserver aktiviert ist und dass die Daten aus dem Cache bereitgestellt werden (HIT – andernfalls würde dort MISS stehen), sowie die Cache-Control-Header, Expires-Header, den Browser-User-Agent und vieles mehr.

Konfiguration der Fallstudien-Domain

Wenn du es bis hierher in unserem Beitrag zur Wasserfallanalyse geschafft hast, erwartet dich eine kleine Überraschung. Es ist immer ärgerlich, wenn Leute Tipps und Fallstudien teilen, aber nicht verraten, wie sie dorthin gekommen sind. Deshalb findest du unten unsere genaue Konfiguration für die oben verwendete Fallstudien-Domain! Du kannst sie gerne nachbauen.

Architektur

• Die Fallstudien-Domain wird bei Kinsta in den USA gehostet. Kinsta bietet derzeit 30 verschiedene Rechenzentren zur Auswahl an.
• Kinsta nutzt HTTP/2, Nginx und MariaDB, was zu den schnellen Ladezeiten beiträgt.
• Die Seite nutzt KeyCDN, das das Kinsta-CDN betreibt. Kostenlose CDN-Bandbreite ist in allen Hosting-Paketen enthalten.
• Die Website nutzt kein Caching-Plugin. Kinsta speichert alles auf Serverebene im Cache, was die Sache erheblich vereinfacht!
• Die Seite läuft unter PHP 7.3. Neuere PHP-Versionen haben schon immer große Leistungssteigerungen gezeigt. Schau dir diese PHP-Benchmarks an. Bei Kinsta kannst du mit einem Klick zwischen den beiden Versionen wechseln.

WordPress-Plugins und Theme

Hier ist eine Liste der Plugins, die die Leistung der WordPress-E-Commerce-Website beeinflussen.

• Das Premium-Plugin „Imagify“ wird zur Komprimierung von Bildern verwendet.
• Das kostenlose „Safe SVG“-Plugin wird verwendet, um SVG-Bilder auf die WordPress-Website hochzuladen.
• Das Premium-WordPress-Theme „GeneratePress“ wurde zum Erstellen der EDD-Seite verwendet.

Empfohlene Tutorials zum Weiterlesen:

• So beseitigst du Render-blockierendes JavaScript und CSS
• So deaktivierst du Emojis in WordPress
• So deaktivierst du Einbettungen in WordPress
• So erreichst du mit WordPress 100/100 bei Google PageSpeed Insights
• So diagnostizierst du eine hohe Admin-Ajax-Auslastung auf deiner WordPress-Website

Zusammenfassung

Wie du siehst, kann es dir helfen, fundiertere Entscheidungen in Sachen Leistung zu treffen, wenn du ein bisschen besser verstehst, wie das Pingdom-Geschwindigkeitstest-Tool funktioniert und was all die Diagramme bedeuten.

Eine Wasserfallanalyse ist entscheidend, um zu verstehen, wie deine Assets geladen werden und wie sie durch deinen WordPress-Host, den physischen Standort, ein CDN usw. beeinflusst werden. Wir hoffen, dieser Beitrag hat dir geholfen, die Geschwindigkeit und Leistung deiner Website besser zu optimieren.

Hast du noch weitere tolle Pingdom-Tipps? Lass es uns unten in den Kommentaren wissen!