280 Sites aus China heraus gemessen: Ein Drittel hat nie fertig geladen

Die Frage, nach der Menschen suchen, ist, ob eine Site in China gesperrt ist. Es ist die falsche Frage, und dies ist die Messung, die zeigt, warum.

Wir haben 280 Enterprise-Software- und -Infrastruktur-Sites von einer Sonde innerhalb Festlandchinas abgerufen, jeweils dreimal, mit einer 60-Sekunden-Obergrenze bei jedem Versuch. 840 Anfragen. Ein Lauf zählt nur dann als vollständig, wenn die Seite fertig geladen hat; ein Lauf, der nach 60 Sekunden noch läuft, wird als Fehlschlag erfasst statt verworfen.

Das Ergebnis

Ergebnis	Sites	Anteil
Jeden Versuch abgeschlossen	162	58 %
Keinen abgeschlossen	96	34 %
Einige Versuche abgeschlossen	22	8 %

Über jede Site, die überhaupt antwortete, lag die mediane Zeit bis zum ersten Byte bei 742 ms (90. Perzentil 1.093 ms). Unter den Sites, die fertig luden, lag das mediane Largest Contentful Paint bei 2,1 Sekunden (90. Perzentil 4,7 s).

Dann die Zahl, die mehr zählt als jede davon:

Von den 96 Sites, die nie fertig luden, antworteten 66. Ein erstes Byte kam an, in den meisten Fällen wurde ein Paint erfasst, und die Seite wurde dennoch nie fertig. Nur 30 erzeugten überhaupt keine Antwort.

Zwei verschiedene Fehler im selben Gewand

Beide Gruppen sehen für einen Nutzer identisch aus — die Seite funktioniert nicht — und sie sind völlig verschiedene Probleme.

Die 30, die nichts erzeugten, sind das, was Menschen mit „gesperrt“ meinen. Die Liste wird von zwei Unternehmen dominiert: zehn Google-Properties (Maps, Docs, reCAPTCHA, Tag Manager, Analytics, Cloud Functions, Hosted Libraries, die Fonts-Browsing-Site, YouTube und Support-Seiten) und vier von Meta und X (Facebook, Instagram, Twitter, X). Snapchat ist auch dabei. Das ist der gut verstandene Teil des Betriebs in China, und es ist kein Auslieferungsproblem — eine Anfrage an ein Ziel, das nicht antwortet, wird nicht zum Antworten gebracht, indem man ändert, woher sie kommt.

Ein nützlicher Kontrast sitzt im selben Datensatz: bing.com/maps lieferte das schnellste erste Byte aller 280 Sites, bei 66 ms. Maps als Kategorie ist nicht das Problem. Der konkrete Host ist es.

Die 66, die antworteten und nie fertig wurden, sind die, mit denen niemand plant, und sie sind doppelt so zahlreich. Eine Verbindungsprüfung besteht. Ein Geschwindigkeitstest meldet eine Zeit. Monitoring, das auf eine 200 pingt, bleibt grün. Und die Seite, die ein Besucher öffnet, wird nie nutzbar.

Einige Beispiele, wie weit sich diese Lücke dehnen kann:

Site	Erstes Byte	Paint	Abgeschlossen
Authentisign	108 ms	2,6 s	0 von 3
Framer	339 ms	2,6 s	0 von 3
AWS Route 53 Console	375 ms	4,0 s	0 von 3
Contentstack	1.104 ms	28,0 s	0 von 3
Freshdesk	718 ms	14,2 s	0 von 3

Authentisign antwortete schneller als jede andere Site im Zensus und schloss keinen seiner Läufe ab. Contentstack paintete nach achtundzwanzig Sekunden — eine Zahl, die nur existiert, weil ein Messtool weiter wartete, nicht weil es jemand täte.

Die Zeit bis zum ersten Byte sagt nicht, ob eine Seite funktioniert. Das ist das Nützlichste in diesem Datensatz, und es ist der Grund, warum ein Geschwindigkeitstest, der von außerhalb Chinas gemacht wird, oder eine Erstes-Byte-Zahl, die irgendwo gemacht wird, die Frage nicht beantworten kann, die ein Käufer tatsächlich stellt.

Was wir lernten, das keine einzelne Site zeigen konnte

Öffentliche Asset-CDNs: zwei von fünf funktionierten

Host	Ergebnis
cdnjs	3 von 3 abgeschlossen
Microsoft Ajax CDN	3 von 3 abgeschlossen
Google Hosted Libraries	überhaupt keine Antwort
BootstrapCDN	0 von 3 abgeschlossen
Font Awesome	0 von 3 abgeschlossen

Alle fünf werden normalerweise aus dem Dokumentkopf referenziert, wo der Browser erst paintet, wenn sie aufgelöst sind. Diese Position macht sie überproportional schädlich — eine Seite, die ein scheiterndes Skript-CDN referenziert, lädt nicht langsam, sie bleibt stehen.

Die Regel, nach der Menschen greifen — „öffentliche CDNs funktionieren in China nicht“ — ist nicht gestützt. Drei von fünf scheiterten und zwei waren in Ordnung. Der brauchbare Rat ist enger und nützlicher: Messen Sie den Host, von dem Sie tatsächlich abhängen, oder bündeln Sie die Bibliothek in Ihren eigenen Build und beseitigen Sie die Frage. Bündeln ist meist eine kleinere Änderung als jede Auslieferungsarbeit.

Eine gemeinsame Fehlersignatur bei einem Anbieter — aber nicht bei allem davon

Vier Adobe-Properties scheiterten mit ERR_HTTP2_PROTOCOL_ERROR statt einem Timeout: Adobe Commerce, Magento, Marketo und Adobe Dynamic Tag Management. Ein Fehler auf Protokollebene ist eine andere Diagnose als Überlastung — er weist darauf hin, dass die Verbindung während der Übertragung unterbrochen wird, und er wird nicht durch mehr Bandbreite oder Präsenzpunkte verbessert.

Adobe Fonts, im selben Lauf gemessen, schloss jeden Versuch ab. Verallgemeinerungen auf Anbieterebene überleben die Messung nicht, weshalb dieser Zensus Hosts statt Marken testet.

Dieselbe Produktkategorie, entgegengesetzte Ergebnisse

Von neun Podcast-Hosts erzeugten fünf keinen nutzbaren Ladevorgang und vier schlossen jeden Versuch ab. Von zwei Loyalty-Apps für dieselbe Storefront-Plattform schloss eine jeden Lauf ab und die andere keinen. Lernplattformen teilen sich genauso: Eine schloss alle drei Versuche bei einem 1,6-Sekunden-Paint ab, eine andere keinen.

Es gibt hier keine Antwort auf Kategorieebene. Das ist kein rhetorischer Punkt — es bedeutet, dass Rat der Form „nutze ein Headless-CMS“ oder „vermeide eingebettetes Video“ nicht umsetzbar ist, und das Einzige, was es auflöst, ist, den konkreten Host zu messen.

Selbst die eigenen Hosts eines Anbieters können uneins sein

Google Fonts ist das sauberste Beispiel. fonts.googleapis.com, der Stylesheet-Endpunkt, den eine Seite aufruft, antwortete 73 von 73 Mal in einem separaten 12-Stunden-Sampling-Lauf bei medianen 111 ms. fonts.google.com, die Site, die ein Designer zum Auswählen einer Schrift besucht, schloss keinen von drei Versuchen ab. Besucher erhalten die Schriften; die Designer können nicht einkaufen gehen.

Was wir ausschlossen und warum

Fünf Hosts sind nicht in den 280.

Drei davon — fauna.com, stepzen.com und thin.dev — lösen auch von außerhalb Chinas nicht auf. Diese Dienste existieren nicht mehr. Der vierte war eine Seite in unserer eigenen Wissensdatenbank mit einer falschen Anbieter-URL; die Domain, auf die sie zeigte, ist nirgends registriert.

Der fünfte ist der, bei dem es sich zu verweilen lohnt, denn er wäre beinahe veröffentlicht worden. edg.io scheiterte aus China heraus mit ERR_CERT_COMMON_NAME_INVALID — der einzige Zertifikatsfehler im Lauf und eine wirklich diagnostisch aussehende Signatur. Wir hatten ihn bereits als eigenständigen Befund aufgeschrieben, als eine Prüfung von außerhalb Chinas denselben Fehler zurückgab. Edgio, das Edgecast übernommen hatte, meldete im September 2024 Chapter 11 an, und sein Content Delivery Network ging am 15. Januar 2025 offline; Akamai kaufte die Kundenverträge, aber nicht das Netzwerk. Das Zertifikat auf diesem Host wird nicht gepflegt, weil es niemand pflegt, nirgends.

Ein totes Produkt ist kein China-Befund. Jeder Fehlschlag mit einer ungewöhnlich sauberen Signatur — ein Name, der nicht auflöst, eine sofort geschlossene Verbindung, ein Zertifikat, das nicht passt — ist es wert, von außerhalb des Landes verifiziert zu werden, bevor er aufgeschrieben wird. Wir haben fünf auf diese Weise erwischt, darunter einen, der uns hätte veröffentlichen lassen, dass Google Fonts in China nicht funktioniert, während unsere eigenen Sampling-Daten das Gegenteil sagten.

Grenzen

• Eine Sonde, eine Stadt. Eine kommerzielle Cloud-Leitung in cn-zhangjiakou. Internationaler Transit aus einem Rechenzentrum ist materiell besser als aus einer Firmen-Breitbandverbindung, daher ist jede Zahl hier eher eine Untergrenze als ein Worst Case. Ein echtes Büro würde Schlimmeres sehen.
• Drei Versuche pro Site. Genug, um „kommt an“ von „kommt nicht an“ zuverlässig zu trennen; nicht genug, um eine präzise Latenzzahl zu sein. Wo wir über einen ganzen Tag sampelten — zwölf Stunden Drittanbieter-Anfragen — schwankte die Zeit bis zum ersten Byte eines Hosts von einem Median von 493 ms in seiner ruhigsten Stunde auf 1.086 ms im Abend-Peak, eine Spanne, die ein Drei-Lauf-Median nicht sehen kann.
• Anbieter-Sites, keine Kunden-Deployments. Wie sich die eigene Site eines Anbieters verhält, ist nicht, wie sich eine darauf gebaute Site verhält. Es ist ein Signal über den Host, kein Urteil über das Produkt.
• Eine 60-Sekunden-Obergrenze ist eine Wahl. Einige dieser Seiten könnten bei neunzig Sekunden abschließen. Kein Besucher wartet so lange, also taten wir es auch nicht.

Warum die Antwort nicht nur um Auslieferung geht

Es wäre bequem, hier zu enden, denn alles oben ist ein Erreichbarkeitsproblem, und Erreichbarkeit ist der Teil, den wir beheben können, indem wir ändern, von wo Bytes bedient werden. Aber die Auslieferung nach Festlandchina zu verlagern, ist nicht nur eine Engineering-Entscheidung. Aus dem Festland heraus zu bedienen, ist genau das, was die ICP-Registrierungspflicht auslöst — die Registrierung wird einer Festland-Rechtseinheit erteilt, sie bindet an Ihr Hosting und Ihre Zugangsvereinbarung, und Zugangsanbietern ist es untersagt, eine nicht registrierte Site zu führen.

So kommen die zwei Fragen zusammen, und sie werden einmal entschieden, zur Architekturzeit: Kann die Seite ankommen, und dürfen Sie sie von dort bedienen, von wo sie ankäme. Wir haben gemessen, was jede der verfügbaren Vereinbarungen bei der ersten Frage tatsächlich bringt, in vier Wege, eine Website nach China auszuliefern — gemessen — einschließlich der Vereinbarung, die innerhalb Chinas liegt, korrekt registriert ist und dennoch nicht fertig lud.

Was wir als Nächstes messen

Denselben Zensus von einer chinesischen Büro-Breitbandverbindung statt einer Rechenzentrumsleitung, von der wir erwarten, dass sie jede Zahl hier verschlechtert und den Vergleich weniger schmeichelhaft zum Veröffentlichen macht. Wir veröffentlichen ihn trotzdem. Die Methode, einschließlich der acht Wege, auf die wir es zuerst falsch machten, ist separat aufgeschrieben.

Die Messungen wurden vom China-Engineering-Team von 21YunBox am 28.–29. August 2026 von einer Sonde innerhalb Festlandchinas durchgeführt. Das Ergebnis jeder Site — Abschlussrate, mediane Zeit bis zum ersten Byte, medianer Paint und Fehlertyp — ist pro Host erfasst.