Website-Geschwindigkeit aus verschiedenen Ländern testen

Eine Website, die in Ihrem Büro in einer Sekunde lädt, kann für einen Besucher am anderen Ende der Welt vier Sekunden brauchen. Entfernung, der antwortende CDN-Edge, lokales DNS und regionsspezifische Skripte verändern, was jeder Markt erlebt, und ein einzelner Geschwindigkeitstest von Ihrem Schreibtisch aus zeigt nichts davon. Wenn Sie in mehreren Ländern verkaufen oder ranken, gehört das Testen aus diesen Ländern zum SEO Monitoring und ist kein optionales Extra.

Dieser Leitfaden zeigt, wie Sie die Website-Geschwindigkeit von verschiedenen Standorten aus testen: welche Tools was messen, warum PageSpeed Insights allein nicht ausreicht, wie Sie prüfen, ob sich Ihr CDN in jedem Markt gleich verhält, und einen einfachen Workflow, den Sie jede Woche wiederholen können.

Warum die Geschwindigkeit je nach Land variiert

Dieselbe URL ist nicht überall dieselbe Seite. Fünf Faktoren unterscheiden sich zwischen Märkten:

• Entfernung. Jeder Roundtrip zwischen Besucher und Server kostet Zeit, und eine Seite braucht mehrere davon (DNS, TCP, TLS, dann die Anfrage). Weit entfernte Besucher zahlen diesen Preis bei jedem einzelnen.
• Der CDN-Edge. Ein CDN antwortet vom Point of Presence, der dem Besucher am nächsten liegt, sofern es in dieser Region einen gibt. Ein Markt, der von einem Edge zwei Länder weiter bedient wird, verhält sich ganz anders als einer mit lokalem Edge.
• Cache-Status. Jeder Edge hat seinen eigenen Cache. In Ihrem Heimatmarkt bleiben Seiten warm; ein kleinerer Markt bekommt womöglich einen Cache-Miss und wartet auf Ihren Origin.
• DNS-Routing. Geo-DNS kann ein Land an einen anderen Origin oder sogar an ein ganz anderes CDN leiten.
• Regionsspezifische Inhalte. Consent-Banner in Europa, lokale Zahlungs-Widgets, übersetzte Seiten und länderspezifische Drittanbieter-Tags bringen zusätzliches Gewicht mit, das Ihre Heimatversion nie lädt.

Googles Core Web Vitals werden anhand echter Besuche gemessen. Langsame Märkte ziehen Ihre Felddaten also nach unten, selbst wenn Ihre eigenen Tests perfekt aussehen.

Labdaten und Felddaten

Es gibt zwei Arten von Geschwindigkeitsdaten, und Sie brauchen beide.

Felddaten stammen von echten Chrome-Nutzern. PageSpeed Insights und Search Console zeigen sie aus dem Chrome UX Report (CrUX), allerdings nur als einen globalen Wert für Ihre Seite oder Ihren Origin. CrUX veröffentlicht Daten auf Länderebene jedoch in seinem öffentlichen BigQuery-Datensatz, und das ist die ehrlichste Antwort auf die Frage “Wie schnell sind wir in Brasilien?”. Die Daten erscheinen monatlich und nur, wenn aus dem jeweiligen Land genug Traffic kommt.

Labdaten stammen aus einem kontrollierten Test, der bei Bedarf ausgeführt wird. Der Lighthouse-Test in PageSpeed Insights läuft in einem Google-Rechenzentrum, nicht in den Ländern Ihrer Besucher. Sein Labwert sagt daher nichts über die Erfahrung in einem bestimmten Markt aus. Nutzen Sie ihn, um Probleme in der Seite selbst zu finden, nicht um Regionen zu vergleichen.

Für Labtests nach Standort brauchen Sie ein Tool mit echten Test-Agents an vielen Orten, etwa WebPageTest, bei dem Sie für jeden Durchlauf Standort, Browser und Verbindungsgeschwindigkeit wählen. Kommerzielle Dienste für synthetisches Monitoring erledigen dasselbe nach Zeitplan.

Prüfen, was jedes Land ausgeliefert bekommt

Geschwindigkeitstools zeigen Ihnen, wie lange eine Seite gebraucht hat. Sie zeigen nicht immer, warum ein Land langsamer ist. Dafür müssen Sie die Antwort sehen, die ein Besucher in diesem Land tatsächlich erhält: welcher Edge geantwortet hat, ob es ein Cache-Hit war, ob eine zusätzliche Weiterleitung stattfand und wie schwer die Seite war.

Anfragen über Residential Proxies im Zielland zeigen genau das, weil die Anfrage von einem privaten Internetanschluss in diesem Markt kommt, genau wie bei einem echten Besucher. CDNs und Geo-DNS leiten sie so, wie sie auch Ihre Kunden leiten würden.

Eine einfache Prüfung mit curl gibt die Aufschlüsselung der Zeiten und die relevanten Header aus:

curl -s -o /dev/null -D - \
  -x http://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 \
  -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} size:%{size_download}\n" \
  https://www.example.com/

Ändern Sie country-de auf jeden Markt, der für Sie relevant ist, zum Beispiel country-br oder country-jp, und vergleichen Sie. Achten Sie auf:

• Cache-Status-Header wie cf-cache-status, x-cache oder x-vercel-cache. HIT in Ihrem Heimatmarkt und MISS anderswo bedeutet, dass dieser Edge kalte Seiten ausliefert.
• Edge-Kennungen. Die cf-ray von Cloudflare endet mit dem Flughafencode des antwortenden Rechenzentrums; CloudFront sendet x-amz-cf-pop; Fastly sendet x-served-by. Wenn deutsche Besucher von einem anderen Kontinent aus bedient werden, haben Sie Ihr Problem gefunden.
• Age, das anzeigt, wie lange die gecachte Kopie bereits auf diesem Edge liegt.
• Weiterleitungen und Größe. Eine länderspezifische Weiterleitung oder eine schwerere lokalisierte Seite zeigt sich als zusätzliche Hops und mehr Bytes.

Ein Hinweis zur Vorsicht: Eine Anfrage über einen Proxy läuft zusätzlich durch das Proxy-Netzwerk, daher sind ihre absoluten Zeiten höher als bei einem lokalen Besucher. Nutzen Sie Proxy-Tests, um Länder miteinander zu vergleichen und zu sehen, was ausgeliefert wird, und entnehmen Sie absolute Ladezeiten aus WebPageTest oder den Felddaten. Für einen schnellen visuellen Blick auf eine Seite aus einem anderen Land ohne jede Einrichtung genügt ein kostenloser Web-Proxy.

CDN-Performance und Edge-Caching testen

Die meisten regionalen Verlangsamungen erweisen sich als CDN-Problem und nicht als Serverproblem. Führen Sie diese Prüfungen pro Markt durch:

Edge-Abdeckung. Stellen Sie fest, welcher Edge in jedem Land antwortet. Anbieter veröffentlichen ihre Listen der Points of Presence, aber den einzigen Beweis liefert der Edge-Header einer Anfrage aus dem jeweiligen Land, zum Beispiel aus Deutschland oder Japan.

Cache-Hit-Rate nach Region. Rufen Sie dieselbe URL aus jedem Land zwei- oder dreimal ab. Die erste Anfrage kann ein Miss sein; die zweite sollte ein Hit sein. Bleibt es beim Miss, ist die Antwort dort vermutlich nicht cachebar.

Fragmentierung des Cache-Keys. Ein Vary-Header auf Cookies oder User Agent oder ein Geo-Cookie, das beim ersten Besuch gesetzt wird, kann eine Seite in viele Cache-Einträge aufspalten. Kleine Märkte treffen dann fast nie auf eine warme Kopie.

Verbreitung von Purges. Prüfen Sie nach einem Deployment oder Purge aus mehreren Ländern, ob die neue Version überall ausgeliefert wird und nicht nur am Edge, der Ihnen am nächsten liegt.

Origin Shield. Wenn Misses in entfernten Märkten langsam sind, sorgt ein Origin Shield oder regionales Tiered Caching dafür, dass Edges von einem nahegelegenen Cache statt von Ihrem Origin abrufen.

Ein wiederholbarer Workflow

1. Wählen Sie Ihre Märkte anhand von Search Console und Analytics: die Länder, die Traffic oder Umsatz bringen, plus die, in denen Sie wachsen wollen.
2. Prüfen Sie die Felddaten pro Land einmal im Monat im CrUX-Datensatz in BigQuery.
3. Führen Sie Labtests durch für Ihre wichtigsten Templates aus jedem Markt in WebPageTest, jedes Mal mit demselben Browser und derselben Verbindung.
4. Prüfen Sie, was ausgeliefert wird, mit Proxy-Anfragen pro Land: Edge, Cache-Status, Weiterleitungen und Größe.
5. Beheben und erneut testen in den Märkten, in denen die Zahlen oder die Header auffällig sind.

Derselbe länderspezifische Ansatz gilt für Rankings und Inhalte. Unsere Leitfäden zu Geo-Grid-Rank-Tracking und Lokalisierungs-QA im großen Maßstab behandeln diese Prüfungen.

FAQ

Wie teste ich die Geschwindigkeit meiner Website aus einem anderen Land?

Nutzen Sie für Ladezeiten ein Labtool mit Test-Agents in diesem Land, etwa WebPageTest. Um zu sehen, was dieses Land ausgeliefert bekommt (CDN-Edge, Cache-Status, Weiterleitungen), senden Sie Anfragen über einen Residential Proxy mit Standort in diesem Land.

Testet PageSpeed Insights vom Standort meiner Besucher aus?

Nein. Der Labtest läuft in einem Google-Rechenzentrum, und die Felddaten sind ein einziger globaler Wert. Felddaten auf Länderebene finden Sie im CrUX-Datensatz in BigQuery.

Warum ist meine Website in manchen Ländern langsamer?

Meist, weil es keinen nahegelegenen CDN-Edge gibt, der Edge einen kalten Cache hat, Geo-DNS das Land an einen weit entfernten Origin leitet oder die lokalisierte Seite zusätzliche Skripte lädt.

Wie oft sollte ich die Geschwindigkeit pro Land testen?

Wöchentliche synthetische Prüfungen Ihrer wichtigsten Templates, ein monatlicher Blick auf die Felddaten und eine zusätzliche Prüfung nach jedem größeren Deployment oder jeder CDN-Änderung.

Das Fazit

Geschwindigkeit ist lokal. Nutzen Sie Felddaten für die Wahrheit pro Land, ein Labtool mit mehreren Standorten für vergleichbare Ladezeiten und Anfragen aus dem jeweiligen Land, um zu sehen, welcher Edge antwortet und ob er einen warmen Cache ausliefert. Die meisten regionalen Verlangsamungen gehen auf das CDN zurück, und sie lassen sich leicht beheben, sobald Sie sie von dort aus sehen, wo Ihre Besucher sind.