Was ist Ping? Latenz, RTT und Serverstandort erklärt

Was ist Ping und was misst der Befehl?

Ping ist ein Netzwerkbefehl, der prüft, ob Ihr Gerät einen anderen Rechner erreicht und wie lange die Antwort braucht. Er sendet eine ICMP Echo Anfrage, wartet auf die Echo Antwort und gibt die Umlaufzeit in Millisekunden aus. Kurz gesagt zeigt Ping, dass eine Verbindung besteht und wie schnell sie ist.

Zudem stammt der Name vom Ping Ton eines Sonars. Ein U Boot sendet einen Impuls und schätzt die Entfernung aus der Zeit, die das Echo braucht. Ping funktioniert also genauso, nur mit einem winzigen Netzwerkpaket statt mit Schall.

Für Website Betreiber ist Ping oft die erste Zahl bei der Hosting Auswahl. Allerdings erzählt sie nie die ganze Geschichte. In diesem Leitfaden erklären wir, was Ping misst, was es übersieht und wie es mit Serverstandort und CDN zusammenhängt.

Die kurze technische Antwort auf die Frage, was ist Ping, passt in eine Zeile. Die praktische Antwort hängt allerdings von der Person ab. Für Netzwerkadministratoren ist es ein Werkzeug zur Fehlersuche. Zum Beispiel nutzen Website Betreiber es als schnellen Entfernungscheck. Entwickler sehen darin dann den ersten Gesundheitstest nach einem Deployment.

Wie funktioniert der Ping Befehl im Hintergrund?

Ping nutzt ICMP, das Internet Control Message Protocol. RFC 792 definiert es. In diesem Dokument hat die Echo Nachricht den Typ 8 und die Echo Antwort den Typ 0. Der Absender schickt die Echo Nachricht, danach sendet der Empfänger dieselben Daten zurück.

RFC 792 legt fest, dass die Daten der Echo Nachricht in der Echo Antwort zurückkommen müssen. Dann vertauscht der Empfänger Quell und Zieladresse, setzt den Typ auf 0 und berechnet die Prüfsumme neu. Die Zeit misst der Absender danach mit seiner eigenen Uhr.

Dieses Detail ist wichtig, denn die gemessene Zeit umfasst den ganzen Weg hin und zurück. Außerdem ist es keine Zeit für eine einzelne Richtung. Daher ist ein Ping Ergebnis im Kern ein RTT Wert, also eine Round Trip Time.

Beachten Sie: Ping testet nicht die Software Ihres Webservers. Stattdessen testet es die Netzwerkschicht des Betriebssystems. Eine abgestürzte Website kann trotzdem auf Ping antworten, und eine gesunde Website kann Ping ignorieren.

Was ist Ping in einer Ausgabe, und wie lesen Sie sie?

Die folgende Ausgabe dient nur als Beispiel. Zudem sind die Werte erfunden, und die Adressen stammen aus dem reservierten Dokumentationsbereich. Echte Ausgaben unterscheiden sich je nach Betriebssystem leicht.

$ ping -c 4 example.com
PING example.com (192.0.2.10): 56 data bytes
64 bytes from 192.0.2.10: icmp_seq=0 ttl=57 time=28.4 ms
64 bytes from 192.0.2.10: icmp_seq=1 ttl=57 time=27.9 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=57 time=31.2 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=57 time=28.1 ms

--- example.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 27.9/28.9/31.2/1.3 ms

So lesen Sie die einzelnen Teile:

• icmp_seq: die laufende Nummer des Pakets. Eine übersprungene Nummer bedeutet ein verlorenes Paket.
• ttl: die Zahl der Router, die das Paket noch passieren darf. Sie sinkt bei jedem Sprung.
• time: die Umlaufzeit dieses Pakets in Millisekunden.
• packet loss: der Anteil der Pakete ohne Antwort.
• min/avg/max/stddev: niedrigste, durchschnittliche und höchste Zeit sowie die Streuung.

Schauen Sie zunächst auf den Durchschnitt und die Streuung. Ist der Durchschnitt niedrig, die Streuung aber hoch, dann ist die Verbindung instabil. Diese Instabilität heißt also Jitter. Eine einzelne schnelle Antwort beweist also noch keine schnelle Verbindung.

Was verraten Paketverlust und Jitter im Ping Ergebnis?

Ping zeigt neben der Geschwindigkeit auch die Stabilität. Paketverlust ist der Prozentsatz der Pakete ohne Antwort. Liegt er über null, verliert irgendwo auf dem Weg etwas Pakete. Konkret kann das die Leitung, ein Router oder der Zielrechner sein.

Jitter beschreibt, wie stark die Antwortzeiten von Paket zu Paket schwanken. Die Abweichung in der Ping Zusammenfassung gibt Ihnen einen groben Anhaltspunkt. Zum Beispiel kann eine Leitung mit 30 ms im Durchschnitt Pakete mal nach 25 ms und mal nach 90 ms zurückbringen. Dann ist der Jitter hoch.

Warum ist das für eine Website wichtig? Ein Seitenaufruf besteht aus Dutzenden kleinen Anfragen. Außerdem nutzt jede dieselbe Leitung. Deshalb macht eine instabile Leitung die Seite mal schnell und mal langsam. Besucher erleben das also als Seite, die manchmal träge ist.

Vertrauen Sie also nie einem einzelnen Ping Lauf. Nehmen Sie eine Serie von mindestens zehn Paketen und lesen Sie neben dem Durchschnitt auch Verlust und Streuung. Außerdem sollten Sie den Test zu verschiedenen Tageszeiten wiederholen, um Muster bei Überlastung zu erkennen.

Wie nutzen Sie Ping unter Windows, macOS und Linux?

Der Befehlsname ist auf allen drei Systemen gleich. Allerdings liegt der Unterschied im Schalter für die Paketzahl. Laut Microsoft Dokumentation sendet Windows standardmäßig 4 Anfragen, und Sie ändern das mit /n. Unter macOS und Linux läuft Ping bis zum Abbruch, und der Schalter -c begrenzt die Anzahl.

Raten Sie auf einem unbekannten System keine Schalternamen. Geben Sie im Terminal man ping ein, unter Windows ping /?. Somit nutzen Sie nur Optionen, die Ihre eigene Version unterstützt.

Was ist Latenz, und ist sie dasselbe wie Ping?

Latenz ist die Zeit, die Daten von einem Punkt zum anderen brauchen. Anders gesagt ist sie der allgemeine Begriff für Wartezeit im Netzwerk. Ping ist der einfachste Weg, sie zu messen. Dennoch sind beide nicht identisch.

Latenz kann eine einzelne Richtung oder die Umlaufzeit meinen. In der Praxis ist meist die Umlaufzeit gemeint. Ping liefert dagegen nur die Umlaufzeit eines kleinen ICMP Pakets.

Zum Beispiel nutzt ein Browser beim Laden einer Seite TCP, TLS und HTTP statt ICMP. Denn Netzwerke können diese Protokolle anders behandeln als ICMP. Daher ist Ping nur ein grober Hinweis auf die echte Seitenlatenz, kein exaktes Maß.

Konkret hat Latenz vier Hauptquellen. Erstens die Laufzeit des Signals über die Entfernung. Zweitens die Verarbeitungs und Wartezeit in Routern und Switches. Drittens die Schritte beim Verbindungsaufbau. Viertens die Zeit, die der Server für die Anfrage braucht. Ping erfasst die ersten beiden, während TTFB und Browser Werkzeuge die letzten beiden zeigen.

Was ist RTT, und worin unterscheidet sie sich von der Latenz?

RTT steht für Round Trip Time, auf Deutsch Umlaufzeit. Sie ist die gesamte Zeit, die ein Paket von Ihrem Gerät zum Ziel braucht, plus die Zeit, bis die Antwort zurück ist. Daher ist der Zeitwert in der Ping Ausgabe genau diese Zahl.

Der Unterschied zwischen Latenz und RTT liegt in der Richtung. Latenz ist der allgemeine Begriff. RTT ist deren Messung für Hin und Rückweg. Auf einem symmetrischen Weg beträgt die Latenz für eine Richtung grob die Hälfte der RTT.

Im Internet sind Wege allerdings nicht immer symmetrisch. Denn Hin und Rückweg können über verschiedene Routen laufen. Die RTT zu halbieren ist deshalb nur eine grobe Schätzung. Für Hosting Entscheidungen zählt ohnehin die RTT, denn jeder Schritt eines neuen Verbindungsaufbaus braucht einen vollen Umlauf.

Worin unterscheiden sich Latenz, RTT und TTFB?

Diese Begriffe werden ständig verwechselt. Die Tabelle fasst zusammen, was jeder misst und wo Sie ihm begegnen.

Zusammengefasst misst Ping das Netzwerk. TTFB misst Netzwerk, Verbindungsaufbau und Arbeitszeit des Servers zusammen. Die Bandbreite ist ein eigenes Thema, das wir in einem separaten Leitfaden behandeln.

Was umfasst TTFB, und was gilt als guter Wert?

Laut web.dev ist TTFB die Zeit zwischen dem Start der Navigation zu einer Seite und dem Moment, in dem das erste Byte der Antwort eintrifft. Die Dokumentation nennt die Bestandteile: Weiterleitungszeit, Start des Service Workers, DNS Abfrage, Verbindungsaufbau samt TLS Aushandlung und die Anfragephase bis zum ersten Byte.

Außerdem nennt dieselbe Seite grobe Schwellen. Ein TTFB von 0,8 Sekunden oder weniger gilt als gut, zwischen 0,8 und 1,8 Sekunden als verbesserungswürdig und darüber als schlecht. Es sind Richtwerte, die das 75. Perzentil der Nutzer im guten Bereich halten sollen. Harte Grenzen sind es allerdings nicht.

Der entscheidende Punkt: Viele Teile des TTFB hängen direkt von der Umlaufzeit ab. Wächst die Entfernung, wächst die RTT, und jeder dieser Teile wird langsamer. Deshalb kommt hier der Serverstandort ins Spiel.

Warum erhöht Entfernung die Latenz, und wo liegt die Grenze der Lichtgeschwindigkeit?

Signale laufen mit Lichtgeschwindigkeit durch Kabel, aber nicht mit der Lichtgeschwindigkeit im Vakuum. Konkret verlangsamt sich Licht in Glasfaser auf etwa zwei Drittel seiner Geschwindigkeit im Vakuum. Das sind rund 200.000 Kilometer pro Sekunde, also ungefähr 5 Mikrosekunden pro Kilometer.

Eine Forschungsarbeit mit dem Titel Dissecting Latency in the Internet's Fiber Infrastructure untersucht, woher Latenz in Glasfasernetzen kommt. Den Link finden Sie am Ende des Beitrags. Die Kernaussage ist einfach: Keine Software Optimierung ändert die Physik.

Zudem verlaufen Kabel nicht auf geraden Linien. Sie führen unter dem Meer, durch Städte und über viele Knoten. Daher ist die reale Route oft länger als die Luftlinie. Jeder Router und Switch fügt außerdem eigene Wartezeit hinzu. Folglich ist die theoretische Zeit immer eine Untergrenze.

Rechenbeispiel: Wie viel Zeit fügt die Entfernung bis zum ersten Byte hinzu?

Die folgende Tabelle ist ein Rechenbeispiel. Die Entfernungen sind Luftlinie, die Geschwindigkeit beträgt 200.000 Kilometer pro Sekunde. Reale Zeiten sind länger, die Zahlen zeigen also nur die physikalische Untergrenze.

Warum 3 RTT in der letzten Spalte? Eine neue TCP Verbindung braucht für den Handshake einen Umlauf. Dann fügt der Handshake von TLS 1.3 einen weiteren hinzu. Dann beanspruchen die HTTP Anfrage und die erste Antwort den dritten. Die DNS Abfrage und die Verarbeitungszeit des Servers sind in dieser Rechnung nicht enthalten.

Das heißt: Ein Besucher in 10.000 Kilometern Entfernung wartet mindestens rund 300 Millisekunden auf das erste Byte, selbst wenn der Server in einer einzigen Millisekunde antwortet. Das Beispiel zeigt also, warum Entfernung zählt. Wird dieselbe Verbindung von einem nahen Standort bedient, sinkt die Wartezeit auf ein Zehntel.

Was ist eine gute Ping Zeit in Millisekunden?

Einen offiziellen Schwellenwert für Ping gibt es nicht. Die folgenden Bereiche sind gängige Faustregeln. Verstehen Sie sie als Startbereich, nicht als offizielle Grenze oder Garantie.

• Gleiche Stadt oder Region: meist etwa eine bis zwanzig Millisekunden.
• Gleicher Kontinent, anderes Land: meist zwanzig bis achtzig Millisekunden.
• Anderer Kontinent: hundert Millisekunden und mehr sind üblich.
• Satelliten und Mobilfunk: können deutlich über kabelgebundenen Verbindungen liegen.

Nutzen Sie diese Zahlen zur Orientierung, nicht als Ziele. Surft die Mehrheit Ihrer Besucher mobil, zählt auch deren eigene Leitung. Außerdem prägt bei einer schweren Seite die Seitenstruktur mehr als der Ping.

Was ist eine Ping Zeit ohne Kontext wert? Sehr wenig. Vergleichen Sie Ihre Seite stattdessen mit ihrer eigenen Vergangenheit. Wurden aus 30 ms gestern heute 120 ms, hat sich etwas verändert, unabhängig vom absoluten Wert. Daher hilft es weit mehr, diese Veränderung Ihrem Hosting Anbieter zu melden als ein vages Urteil von gut oder schlecht abzugeben.

Warum kann eine Website trotz niedrigem Ping langsam sein?

Ping misst allerdings nur den Netzwerkweg. Die Langsamkeit einer Seite liegt meist woanders. Eine langsame Datenbankabfrage, ein schweres Plugin oder ein fehlender Cache verzögern das erste Byte auf dem Server. Außerdem bremsen im Browser große Bilder und zu viel JavaScript die Seite aus.

Deshalb diagnostizieren Sie Schicht für Schicht:

1. Prüfen Sie mit Ping, ob der Netzwerkweg plausibel aussieht.
2. Betrachten Sie dann den TTFB, um Server und Verbindungsaufbau zu beurteilen.
3. Untersuchen Sie dann Seitengewicht, Bildgrößen und Skripte.
4. Vergleichen Sie das Ergebnis schließlich mit echten Nutzerdaten.

Um die Kette zu schließen, helfen unsere Leitfäden zu Ladezeit und SEO, zum Lighthouse Performance Test und zu Caching Ansätzen.

Heißt ein ausbleibender Ping, dass der Server ausgefallen ist?

Nein, nicht immer. Viele Server und Firewalls blockieren ICMP oder begrenzen es absichtlich. Dann läuft Ping in die Zeitüberschreitung, obwohl die Website problemlos öffnet. Laut Microsoft Dokumentation zeigt Windows bei fehlender Antwort eine Meldung zur Zeitüberschreitung, im englischen Original Request timed out. Das Standard Zeitlimit beträgt 4 Sekunden.

Der richtige Weg ist, über mehrere Kanäle zu prüfen. Zunächst öffnen Sie die Seite im Browser. Kontrollieren Sie dann die DNS Einträge und die IP Angaben der Domain. Dabei helfen unsere DNS Abfrage und unsere IP Abfrage.

Es gibt allerdings auch den umgekehrten Fall. Antwortet Ping, doch die Seite öffnet nicht, liegt das Problem im Webserver oder in der Anwendungsschicht. Somit können Sie Ihrem Hosting Anbieter genaue Informationen geben.

ICMP besteht außerdem nicht nur aus Echo. RFC 792 definiert auch Destination Unreachable (Typ 3) und Time Exceeded (Typ 11). Router melden damit also Netzwerkprobleme. Werkzeuge, die die Stationen eines Weges zeigen, nutzen diese Nachrichten, und diesen Befehl behandeln wir in einem eigenen Leitfaden.

Was ist Ping im Zusammenhang mit dem Serverstandort?

Wer fragt, was ist Ping, steht oft kurz vor einer Hosting Entscheidung. Ping ist der einfachste Weg zu sehen, wie nah ein Server am Besucher steht. Ein näherer Server bedeutet eine niedrigere RTT, und eine niedrigere RTT bedeutet einen kürzeren Verbindungsaufbau.

Allerdings endet die Antwort auf die Frage, was ist Ping, hier nicht. Ping zeigt also nur die Netzwerkentfernung. Die echte Geschwindigkeit der Seite ergibt sich erst aus TTFB, Seitengewicht und echten Nutzerdaten zusammen.

Eine praktische Methode: Bitten Sie infrage kommende Anbieter um eine Testadresse oder senden Sie Ping an den aktuellen Server Ihrer Domain. Vergleichen Sie danach ähnliche Messungen aus den Städten, in denen Ihre Zielgruppe lebt. So beruht die Standortentscheidung auf Zahlen statt auf Vermutungen.

Kurz gesagt wirkt Ping bei der Standortwahl wie ein Kompass. Es ist allerdings nicht die ganze Karte. Ergänzen Sie vor der Entscheidung eine TTFB Messung und Ihren CDN Bedarf.

Worauf achten Sie bei der Wahl des Serverstandorts?

Zunächst zählt, wo Ihre Besucher sitzen. Lebt Ihre Zielgruppe überwiegend in einem Land, ist ein Standort sinnvoll, der dieses Land oder eine nahe Region bedient. Verteilen sich Ihre Besucher über die Welt, reicht ein einzelner Standort allein nicht aus.

Die Entscheidungsliste sieht so aus:

• Verteilung der Besucher: prüfen Sie die Aufteilung nach Land und Stadt in Ihrem Analytics Bericht.
• Art der Inhalte: überwiegend statische Seiten oder personalisierte und dynamische?
• Rechtliche Vorgaben: der Speicherort von Daten ist eine eigene Rechtsfrage, fragen Sie dazu Ihre Rechtsberatung.
• Netzqualität des Anbieters: zwei Anbieter in derselben Stadt können unterschiedliche Netzwege haben.
• Offenheit für Tests: bitten Sie den Anbieter um eine Test IP oder eine Probezeit.

Allgemeine Auswahlkriterien erklären wir in unserem Leitfaden zur Webhosting Auswahl. Daher behandeln wir hier nur die Seite von Standort und Latenz.

Wie senkt ein CDN die Latenz, und wann reicht es nicht?

Ein CDN, also ein Content Delivery Network, ist ein verteiltes Netz, das Kopien Ihrer Inhalte auf Servern an vielen Orten speichert. web.dev beschreibt es so: CDNs lösen das Problem der Nutzernähe, indem sie Ressourcen auf Servern zwischenspeichern, die den Nutzern physisch näher stehen.

Dasselbe Dokument weist darauf hin, dass CDN Anbieter meist schnelle DNS Auflösung und moderne TLS Versionen bieten. Außerdem spielen Protokolle wie HTTP/3 hier eine Rolle. Dadurch sinkt die Zahl der Umläufe beim Verbindungsaufbau.

Trotzdem löst ein CDN nicht alles. Anfragen, die sich nicht zwischenspeichern lassen, gehen weiterhin an Ihren Ursprungsserver. Ein Warenkorb, eine Kontoseite für angemeldete Nutzer und ein Bezahlschritt sind Beispiele. Für diese Anfragen behält der Standort des Ursprungsservers seine Bedeutung.

Serverstandort oder CDN: Wie entscheiden Sie?

Die Antwort hängt von der Struktur Ihrer Seite ab. Die Tabelle bietet einen groben Entscheidungsrahmen. Sie enthält keine Zahlen, weil sich die richtige Wahl nur in Messungen Ihrer eigenen Seite zeigt.

Der Einfluss der Ladezeit auf den Umsatz ist ein eigenes Thema. Wir haben ihn in Ladezeit im Onlineshop und Umsatz behandelt.

Denken Sie an ein Szenario. Eine lokale Klinik in Istanbul hat Besucher fast nur in der Türkei. Dann genügt meist ein Standort nahe der Türkei. Andererseits gewinnt ein Shop, der nach Europa und Nordamerika verkauft, viel, wenn er statische Bilder über ein CDN ausliefert. Es ist also ein Beispielszenario, und die echte Entscheidung entsteht durch Messung.

Welche Fehler passieren beim Messen von Ping am häufigsten?

Ping wirkt einfach, deshalb lässt es sich leicht falsch lesen. Das sind häufige Grenzen, auf die auch die offiziellen Dokumente hinweisen:

• Entscheidung nach einer Messung: ein einzelnes Paket kann zufällig gut oder schlecht sein.
• WLAN vergessen: ein schwaches Signal zu Hause sieht aus wie Serverlatenz.
• Messen mit aktivem VPN: der Verkehr läuft zuerst in ein anderes Land, die Zeit wächst.
• Ping mit Seitengeschwindigkeit verwechseln: Ping misst nur den Netzwerkweg.
• Blockiertes ICMP als Ausfall deuten: eine Firewall kann die Antwort absichtlich verwerfen.

Bereinigen Sie also vor dem Messen die Umgebung. Nutzen Sie eine Kabelverbindung, schalten Sie das VPN aus und wiederholen Sie den Test mehrmals. Dann sagt der gemessene Wert wirklich etwas über Server und Weg aus.

Wie messen Sie die Latenz selbst?

Außerdem genügt eine Messung von einem einzigen Punkt nicht. Schauen Sie zu verschiedenen Zeiten und, wenn möglich, von verschiedenen Orten. Sie können diese Schritte befolgen:

1. Führen Sie im Terminal ping -c 10 example.com mit Ihrer eigenen Domain aus und notieren Sie den Durchschnitt.
2. Danach wiederholen Sie dieselbe Messung zu verschiedenen Tageszeiten.
3. Öffnen Sie die Entwicklerwerkzeuge des Browsers, wechseln Sie in den Netzwerk Tab und prüfen Sie die Wartezeit der Hauptdokument Anfrage.
4. Lesen Sie den Befund zur Antwortzeit des Servers in Ihren PageSpeed Insights und Lighthouse Berichten.
5. Bitten Sie nach Möglichkeit eine Bekannte im Ausland oder ein Online Messwerkzeug, denselben Test auszuführen.

Legen Sie die Ergebnisse nebeneinander, dann zeigt sich ein Muster. Bleiben die Werte zum Beispiel jeden Abend hoch, kann Überlast zur Hauptzeit die Ursache sein. Die Seite der Core Web Vitals verfolgen Sie außerdem in unserem Leitfaden zu Core Web Vitals.

Wie melden Sie ein Ping Ergebnis Ihrem Hosting Anbieter?

Schreiben Sie nicht nur, dass Ihre Seite langsam ist, sondern hängen Sie die Messung an. Der Anbieter erkennt dann schneller, ob das Problem in seinem Netz oder bei Ihnen liegt. Ein gutes Support Ticket enthält Folgendes:

• Die getestete Domain oder IP Adresse.
• Datum, Uhrzeit und das Netz, in dem Sie waren.
• Die vollständige Ping Ausgabe samt Zusammenfassung.
• Ob das Problem dauerhaft besteht oder nur zu bestimmten Zeiten auftritt.

Außerdem sollten Sie das Ziel nicht überfluten. Hunderte Pakete in kurzen Abständen erzeugen Last statt einer Messung. Deshalb werten manche Anbieter das als Missbrauch.

Erhöht eine sichere Verbindung die Latenz?

HTTPS fügt dem Verbindungsaufbau einen TLS Handshake hinzu. Daher dauert die erste Verbindung etwas länger. TLS 1.3 ist allerdings darauf ausgelegt, den Handshake auf einen Umlauf zu verkürzen. Somit ist der Aufwand auf modernen Servern gering.

Verzichten Sie deshalb nicht auf Sicherheit. HTTPS ist heute der Standard, den Browser erwarten und dem Nutzer vertrauen. Wie Zertifikate funktionieren, erklären wir in unserem Leitfaden zum SSL Zertifikat.

Weiterleitungsketten sind dagegen eine echte Quelle für Verzögerung. Laut web.dev fügt schon eine Weiterleitung unerwünschte Latenz hinzu, und es wird schlimmer, wenn sie auf eine weitere zeigt. Der HSTS Header weist den Browser an, bei späteren Besuchen direkt HTTPS zu nutzen, und verringert solche Weiterleitungen.

Wann sollten Sie das nicht selbst tun und Ihrem Hosting Anbieter überlassen?

Seien wir ehrlich: Wir sind ein Team für digitales Marketing und Web, kein Hosting Unternehmen. Netzwerk Routing, Serverhardware und Anbindungen im Rechenzentrum sind Sache des Anbieters. Daher messen Sie in diesen Bereichen, greifen aber nicht ein.

Wenden Sie sich in diesen Fällen direkt an Ihren Anbieter:

• Der Ping bleibt hoch, und die Ursache liegt nicht bei Ihnen.
• Zu bestimmten Zeiten tritt Paketverlust auf.
• Die IP Adresse des Servers muss sich ändern oder der Standort muss umziehen.
• Eine Firewall Regel für ICMP muss geändert werden, und Ihnen fehlt die Berechtigung.

Entscheiden Sie sich für einen Umzug, erstellen Sie zuerst eine Sicherung. Unser Leitfaden zur Website Backup Strategie hilft bei diesem Schritt.

Wie unterstützen wir Sie bei Entscheidungen zu Ladezeit und Infrastruktur?

Allerdings bietet unser Team kein Hosting an. Wir betrachten aber, wie eine Hosting Entscheidung Ladezeit, SEO und Conversions gemeinsam beeinflusst. Bauen oder erneuern wir eine Website, planen wir Standort, CDN und Caching zusammen mit Design und Inhaltsplan.

Möchten Sie Unterstützung, werfen Sie einen Blick auf unseren Webdesign Service und unsere SEO Beratung. Zunächst messen wir Ihre aktuelle Lage, danach entscheiden wir gemeinsam, welcher Schritt wirklich einen Unterschied macht.

Zusammengefasst zeigt Ping das Netzwerk, TTFB zeigt Verbindung und Server, und Nutzerdaten zeigen das echte Erlebnis. Lesen Sie alle drei zusammen, dann beruht Ihre Entscheidung über Serverstandort und CDN auf Messung statt auf Vermutung.

Jetzt wissen Sie, was ist Ping und wie Sie es lesen. Der nächste Schritt ist also, Ihre eigene Seite zu messen. Zunächst starten Sie mit einem Ping über zehn Pakete. Prüfen Sie dann Ihren TTFB Wert. Danach sehen Sie sich die Verteilung Ihrer Besucher in Analytics an. Mit diesen drei Daten wird die Entscheidung über Hosting und CDN deutlich klarer.

Quellen: web.dev: Time to First Byte, web.dev: TTFB optimieren, Microsoft Learn: Ping Befehl, RFC 792: Internet Control Message Protocol, Dissecting Latency in the Internet's Fiber Infrastructure.