Die meisten veröffentlichten Zahlen über Drittanbieter-Ressourcen in China sind Einzelstichproben. Wir haben zuvor argumentiert, dass eine einzelne Stichprobe keine Messung ist – grenzüberschreitendes Verhalten variiert dort über einen Tag hinweg um mehr als zwei Größenordnungen, und eine Zahl, die um 14 Uhr genommen wird, sagt Ihnen sehr wenig über 21 Uhr.
Also haben wir es ordentlich durchgeführt: fünf Drittanbieter-Ressourcenkategorien, alle zehn Minuten gesampelt, von einer Probe innerhalb Festlandchinas, jede zweimal angefordert – einmal direkt, einmal durch unser eigenes Auslieferungsnetzwerk. 720 Messungen über zwölf Stunden, die den Abend-Peak abdecken, um den Betreiber herumplanen.
Dann taten wir das, was mehr zählte, und es kostete uns eine Empfehlung.
Update, 30. August 2026. Die zwölfstündige Studie unten wurde von einer kommerziellen Cloud-Leitung innerhalb Chinas durchgeführt – so wie fast jede veröffentlichte China-Messung genommen wird, auch unsere. Wir sagten damals, dass wir sie von einer Verbraucherverbindung wiederholen und das Ergebnis veröffentlichen würden, selbst wenn es wenig schmeichelhaft wäre. Wir haben das nun getan, und das Problem ist größer als eine falsche Empfehlung: Für eine ganze Kategorie von Hosts melden eine Festland-Cloud-Probe und eine Festland-Verbraucherleitung nicht dasselbe Land. Hosts, die aus der Cloud zu 100 % antworteten, antworteten von einer Pekinger Heimleitung zu 0 %. Die ursprünglichen Daten bleiben bestehen – sie beschreiben diese Vantage treu. Was sie nicht beschreiben, ist einen Besucher. Siehe was passierte, als wir die Probe verschoben.
Was gemessen wurde
| Ressource | Kategorie | Warum sie auf der Liste steht |
|---|---|---|
fonts.googleapis.com | Web-Font-Stylesheet | Auf einem großen Anteil von Enterprise-Seiten |
fonts.gstatic.com | Web-Font-Datei | Die eigentlichen Font-Bytes |
cdn.jsdelivr.net | Öffentliches JS-CDN | Häufiger Skript-Host |
www.googletagmanager.com | Tag Manager | Analytics- und Marketing-Tags |
www.google.com/recaptcha | Formular-Verifizierung | Entscheidet, ob ein Formular abgeschickt werden kann |
Die Liste ist nicht willkürlich. Sie stammt daraus, echte Vendor-Websites von innerhalb Chinas zu messen und aufzuzeichnen, welche Drittanbieter-Hosts tatsächlich aufhörten zu antworten – diese fünf Kategorien sind, was auftauchte.
Methode: Probe innerhalb Festlandchinas (Alibaba Cloud cn-zhangjiakou); jede Ressource direkt und durch unser Netzwerk in derselben Runde angefordert; Durchsatz nur über den Body-Transfer berechnet, ohne Time-to-First-Byte, sodass kleine Dateien nicht vom Verbindungsaufbau dominiert werden; 30-Sekunden-Timeout; Timeouts als Ergebnisse gezählt statt verworfen. 72 Stichproben pro Zelle, 28. August 2026. Die Zeiten unten sind chinesische Ortszeit.
Ergebnisse über zwölf Stunden
| Ressource | Route | Erfolg | TTFB Median | TTFB p95 | Durchsatz Median |
|---|---|---|---|---|---|
| Font-Stylesheet | direkt | 100 % | 111 ms | 137 ms | 2,4 MB/s |
| unser Netzwerk | 100 % | 278 ms | 303 ms | 5,0 MB/s | |
| Font-Datei | direkt | 100 % | 102 ms | 121 ms | 4,9 MB/s |
| unser Netzwerk | 100 % | 195 ms | 208 ms | 0,8 MB/s | |
| Öffentliches JS-CDN | direkt | 100 % | 660 ms | 1.757 ms | 4,0 MB/s |
| unser Netzwerk | 100 % | 103 ms | 114 ms | 16,1 MB/s | |
| Tag Manager | direkt | 100 % | 118 ms | 143 ms | 13,5 MB/s |
| unser Netzwerk | 100 % | 312 ms | 327 ms | 4,1 MB/s | |
| Formular-Verifizierung | direkt | 0 % | — | — | — |
| unser Netzwerk | 100 % | 169 ms | 263 ms | 1,5 MB/s |
72 Stichproben pro Zelle.
Was wir schlossen, und was wir falsch machten
Auf Basis dieser Daten schrieben wir, dass Google Fonts und der Tag Manager genau dort gelassen werden sollten, wo sie sind. Beide waren in 100 % der Versuche erreichbar, beide antworteten in rund 110 Millisekunden direkt gegen rund 300 über einen zusätzlichen Hop, und wir argumentierten – auf diesen Zahlen korrekt –, dass einen bereits gesunden Host woandershin zu leiten eine Latenzsteuer ist, die man bei jeder Anfrage ohne Nutzen zahlt.
Die Argumentation war solide. Die Vantage war es nicht. Wir hatten im selben Artikel geschrieben, dass „ist dieser Host um 21 Uhr von Shanghai aus gesund“ keine Frage ist, die man von irgendwo sonst beantworten kann – und sie dann von einem Rechenzentrum aus beantwortet.
Jeder, der tatsächlich eine Website in China betrieben hat, wird bei dieser Tabelle bereits eine Augenbraue heben, denn Google-eigene Hosts sind von einer chinesischen Verbraucherverbindung aus im Allgemeinen nicht nutzbar, und niemand, der dort arbeitet, braucht eine Messung, um ihm das zu sagen. Genau das macht das Ergebnis veröffentlichungswert. Wir haben nicht entdeckt, dass diese Hosts für Besucher scheitern. Wir haben entdeckt, dass unsere Probe das Gegenteil sagte, bei 111 Millisekunden, zweiundsiebzig von zweiundsiebzig Malen.
Eine Festland-Cloud-Instanz ist kein neutraler Beobachtungsposten. Sie ist ein kommerzielles Netzwerk mit eigenen Vereinbarungen, und für mindestens eine Kategorie von Hosts erstrecken sich diese Vereinbarungen eindeutig nicht auf die Person, die Ihre Seite von zu Hause aus lädt.
Jeder, der in China Software baut, kennt die Form davon bereits, denn es ist die tägliche Erfahrung der Toolchain. Upstream-Quellen, die der Rest der Welt als selbstverständlich ansieht, sind vom Festland aus nicht nutzbar, also betreiben die inländischen Clouds ihre eigenen Ersatzlösungen: Container-Registries, Package-Registries, Sprach-Runtimes. Wir verlassen uns selbst darauf – das Messpaket, das der Freiwillige ausführte, lädt seinen Browser und seine Runtime von einem inländischen Mirror herunter, weil die Upstream-Quellen von dort, wo er es ausführte, nicht erreichbar sind. Eine Umgebung, die stillschweigend einen funktionierenden Pfad für einen kaputten ersetzt, ist ein sehr bequemer Ort zum Bauen. Sie ist ein sehr schlechter Ort zum Messen.
Wir werden nicht über den spezifischen Mechanismus für diese bestimmten Hosts spekulieren – wir haben ihn nicht gemessen, und eine Erklärung, die wir nicht stützen können, ist weniger wert als die Beobachtung, die wir stützen können. Der Befund steht auf der Diskrepanz selbst, und die Diskrepanz ist total: 72 von 72 aus der Cloud, 0 von 112 von einer Heimleitung.
Die Verallgemeinerung ist der nützliche Teil. Wenn Ihre China-Messungen von einer Festland-Cloud-Instanz kommen – und fast alle veröffentlichten China-Messungen tun das –, können Sie nicht annehmen, dass sie beschreiben, was ein Besucher sieht. Das schließt unsere ein, bis wir sie so prüfen, wie wir diese geprüft haben.
Was passierte, als wir die Probe verschoben
Am 30. August 2026 führte ein Freiwilliger in Peking unseren Mess-Stack auf einer China-Mobile-Privatkunden-Breitbandleitung aus, mit demselben Code, derselben 60-Sekunden-Obergrenze und demselben Drei-Durchläufe-pro-Site-Design wie unsere Rechenzentrumsprobe. Dieser Lauf lud 88 echte Websites – 264 Seitenaufbauten – und zeichnete pro Anfrage jeden Host auf, der nie eine Antwort zurückgab.
Hier ist, was dieselben fünf Hosts taten:
| Host | Rechenzentrumsleitung (12 h, je 72 Stichproben) | Pekinger Heimleitung (2026-08-30) |
|---|---|---|
www.googletagmanager.com | 100 % Erfolg, 118 ms | 112 Anfragen, 112 nie beantwortet |
fonts.googleapis.com | 100 % Erfolg, 111 ms | 54 Anfragen, 54 nie beantwortet |
fonts.gstatic.com | 100 % Erfolg, 102 ms | 6 Anfragen, 6 nie beantwortet |
www.google.com (reCAPTCHA-Host) | 0 % Erfolg | 18 Anfragen, 18 nie beantwortet |
cdn.jsdelivr.net | 100 % Erfolg, 660 ms Median | 36 Anfragen, 0 Fehler |
Die beiden Hosts, die wir Ihnen zu belassen rieten, sind die beiden, die kein einziges Mal antworteten. Nicht langsamer. Nicht zeitweise. Null Antworten von 112 bzw. 54.
Das ist kein Artefakt des Timeouts
Der offensichtliche Einwand ist, dass diese Anfragen noch im Flug waren, als ein 60-Sekunden-Seitenaufbau abgebrochen wurde, und bei mehr Zeit abgeschlossen hätten. Hätten sie nicht. Die Prüfung ist, nur Seitenaufbauten zu betrachten, die erfolgreich abschlossen, und zu fragen, was dieselben Hosts in ihnen taten:
| Host | Vorkommen in abgeschlossenen Seitenaufbauten | Nie beantwortet |
|---|---|---|
www.googletagmanager.com | 14 | 14 |
geolocation.onetrust.com | 12 | 12 |
www.google.com | 4 | 4 |
Die Seite wurde fertig. Der Host antwortete trotzdem nie. Das sind keine Anfragen, denen die Zeit ausging; es sind Anfragen, die auf dieser Verbindung nie beantwortet werden würden.
Die Hosts, vor denen Sie niemand warnt
Über diese 264 Seitenaufbauten hinweg gaben 102 verschiedene Hosts überhaupt nie eine Antwort zurück, und 101 von ihnen – 99 % – waren Drittparteien, nicht die angeforderte Site. Nur 13 der 102 waren Google-eigen. Legt man diese als bereits verstanden beiseite, bleiben 89 Hosts. Das ist der Teil, der kein Allgemeinwissen ist, und der Teil, auf den zu handeln sich lohnt:
| Host | Was er tut | Angefordert | Nie beantwortet |
|---|---|---|---|
geolocation.onetrust.com | Geolokalisierung des Consent-Banners | 50 | 50 |
c.go-mpulse.net | Real-User-Monitoring | 12 | 12 |
use.typekit.net | Web-Font-Auslieferung | 11 | 11 |
cdn.optimizely.com | Experimentierung | 9 | 9 |
px.ads.linkedin.com | Werbe-Pixel | 9 | 9 |
d3e54v103j8qbb.cloudfront.net | Asset-CDN eines Site-Builders | 9 | 9 |
static.hotjar.com | Session-Analytics | 6 | 6 |
epsilon.6sense.com | Account Intelligence | 6 | 6 |
Der Consent-Banner-Host ist der, den man zweimal ansehen sollte. Ein Consent-Skript läuft üblicherweise vor allem anderen auf der Seite und blockiert häufig das Rendering, bis es aufgelöst ist; ein Geolokalisierungs-Lookup, der nie zurückkehrt, ist daher kein fehlender Cookie-Banner, sondern eine Seite, die nicht startet.
Die zeitweise ausfallenden Hosts sind interessanter als die toten, denn zeitweise ist der Fall, für den niemand plant:
| Host | Angefordert | Fehlgeschlagen | Fehlerrate |
|---|---|---|---|
fast.wistia.com | 15 | 6 | 40 % |
widget.trustpilot.com | 9 | 3 | 33 % |
cdn.weglot.com | 9 | 3 | 33 % |
challenges.cloudflare.com | 12 | 3 | 25 % |
uhf.microsoft.com | 12 | 3 | 25 % |
play.vidyard.com | 15 | 3 | 20 % |
rum.hlx.page | 18 | 3 | 17 % |
Ein Host, der eins von vier Malen scheitert, kann nicht diagnostiziert werden, indem man die Seite einmal lädt, was fast jeder prüft. Er kann auch nicht durch eine Faustregel behoben werden, denn die Regel müsste über einen Host richtig liegen, der die meiste Zeit richtig liegt.
Drei Viertel all dieser Fehler waren von einer bestimmten Art: Die Anfrage wurde gesendet, nichts kam zurück, und es wurde nie ein Fehler ausgelöst. Keine Ablehnung, kein Reset – Stille. Nichts in der Seite meldet ein Problem, denn aus Sicht des Browsers ist noch nichts schiefgegangen.
Und die Sites selbst waren meist in Ordnung: Von den 57 Sites, die nicht fertig luden, gab jede einzelne ein erstes Byte zurück, und zwei Drittel malten etwas auf den Bildschirm, bevor sie ins Stocken gerieten. Keine einzige war unerreichbar. Was eine Seite in China kaputt macht, ist üblicherweise nicht die Seite.
Das Ergebnis, das entscheidet, ob ein Formular funktioniert
www.google.com/recaptcha antwortete kein einziges Mal. Null erfolgreiche Anfragen von 72 auf der Rechenzentrumsleitung, über jede gesampelte Stunde, vom frühen Nachmittag über den Abend-Peak und nach Mitternacht hinaus. Durch unser Netzwerk 72 von 72. Auf der Pekinger Heimleitung scheiterte derselbe Host in allen 18 Anfragen, die ihn erreichten.
Das ist kein Latenzbefund, und es ist kein Gradient. Die Formular-Verifizierung ist das Tor für die Übermittlung: Wenn das Widget nie lädt, wird der Absende-Button nie aktiv. Eine Seite in diesem Zustand ist nicht langsam. Es ist ein Formular, das keinen einzigen Lead empfangen kann, und nichts in der Seite meldet einen Fehler, weil die Anfrage abgesetzt und einfach nie beantwortet wird.
Wenn Ihre China-Site ein geschütztes Kontaktformular hat und Sie genau diese Sache nie gemessen haben, ist es das Erste, das zu prüfen sich lohnt.
Das Ergebnis, das sich erst über die Zeit zeigt
Das öffentliche JS-CDN war in 100 % der Versuche über beide Routen auf der Rechenzentrumsleitung erreichbar und scheiterte in keiner seiner 36 Anfragen auf der Heimleitung. Die Erreichbarkeit sagte uns nichts Nützliches. Die Verteilung tat es:
| Chinesische Ortszeit | Direktes TTFB (Median) | Unser Netzwerk | Verhältnis |
|---|---|---|---|
| 16:00 | 477 ms | 103 ms | 4,6× |
| 17:00 | 932 ms | 99 ms | 9,4× |
| 19:00 | 987 ms | 104 ms | 9,5× |
| 21:00 | 1.076 ms | 102 ms | 10,5× |
| 23:00 | 548 ms | 103 ms | 5,3× |
| 01:00 | 728 ms | 110 ms | 6,6× |
Das direkte Time-to-First-Byte verdoppelte sich zwischen der ruhigsten gesampelten Stunde und dem 21:00-Peak mehr als. Über dieselben zwölf Stunden blieb die ausgelieferte Route zwischen 99 und 110 Millisekunden – eine Spanne von elf Millisekunden.
Die einzelne Zahl, die es erfasst, ist das Verhältnis des 95. Perzentils zum Median:
| Ressource | Direkt | Unser Netzwerk |
|---|---|---|
| Öffentliches JS-CDN | 2,7× | 1,1× |
| Font-Datei | 1,2× | 1,1× |
| Tag Manager | 1,2× | 1,0× |
Ein p95 von 1.757 ms gegen einen Median von 660 ms bedeutet, dass eine Anfrage von zwanzig fast zwei Sekunden braucht – und auf einer Seite mit einem Dutzend solcher Anfragen reicht es aus, dass eine davon in diesem Tail landet, um das Rendering aufzuhalten. Deshalb ist ein Durchschnitt die falsche zusammenfassende Statistik für China und deshalb ist eine einmal gesampelte Zahl sehr wenig wert.
Worauf das hinausläuft
Vier Fehlermodi, und nur einer von ihnen ist, was man üblicherweise mit „langsam in China“ meint:
- Manche Hosts sind wirklich in Ordnung – aber man muss sagen, von wo. Das öffentliche JS-CDN hielt auf beiden Vantages stand. Das ist eine Behauptung, die wir nun mit zwei Datenpunkten statt einem machen können, und es ist der einzige Host auf dieser Liste, der sie verdient hat.
- Manche Hosts sind erreichbar, aber instabil. Der Median sieht erträglich aus; der Tail ist, wo die Seite tatsächlich kaputtgeht. Das sieht man nicht, ohne über den Tag hinweg zu sampeln.
- Manche Hosts antworten überhaupt nie. Kein Fehler, kein Timeout-Ereignis, kein Signal – und wenn dieser Host Ihre Formular-Verifizierung ist, ist die geschäftliche Konsequenz total statt degradiert.
- Manche Hosts antworten von einem Ort innerhalb Chinas perfekt und von einem anderen nie. Das ist der, den wir vorher nicht hatten, und der, der unsere eigene Empfehlung umwarf. Eine Rechenzentrumsleitung und eine Verbraucherleitung im selben Land sind nicht dasselbe Netzwerk.
Die praktische Konsequenz ist enger und nützlicher als „alles routen“ oder „nichts routen“. Die Route muss pro Ressource entschieden werden, auf Messungen, die von dort genommen werden, wo Ihre Besucher tatsächlich sind – und ein Host, der von einer Cloud-Leitung durchkommt, ist nicht als von einer Heimleitung durchkommend nachgewiesen. Einen bereits schnellen Host unberührt zu lassen, ist weiterhin die richtige Handlung, wenn er für Ihre Besucher wirklich schnell ist. Was sich geändert hat, ist unsere Zuversicht darüber, welche Hosts das sind, und wie viel Beleg es braucht, um es zu sagen.
Warum das nicht nur eine Auslieferungsfrage ist
Alles oben dreht sich darum, welche Anfragen abschließen, und das ist ein Auslieferungsproblem. Aber die Lösung, zu der man greift – aus Festlandchina heraus ausliefern, sodass die Anfrage nie eine Grenze überqueren muss –, ist keine rein technische Entscheidung. Chinesischen Nutzern aus Festland-Infrastruktur zu dienen, bringt die ICP-Registrierungspflicht ins Spiel: Die Registrierung wird an eine Festland-Rechtseinheit ausgestellt und bindet an Ihre Hosting-Vereinbarung, und eine nicht registrierte Site kann nicht rechtmäßig von einem Festland-Zugangsanbieter geführt werden.
So beantwortet dieselbe Architekturentscheidung zwei Fragen auf einmal, und es lohnt sich, sie zusammen zu beantworten, statt die zweite spät zu entdecken: welche Ihrer Anfragen für einen echten Besucher abschließen, und ob Sie sie von dem Ort aus liefern dürfen, wo sie abschließen würden.
Grenzen
- Die Verbrauchermessung ist ein Freiwilliger, ein ISP, eine Nacht. Eine China-Mobile-Privatkundenleitung in Peking, über Nacht am 30. August 2026 ausgeführt. Ein zweiter ISP und eine zweite Stadt würden es zu einem Befund statt einem Datenpunkt machen. Die Pro-Host-Ergebnisse sind 100 % und 0 % statt Gradienten, mit 112 und 54 Anfragen hinter den beiden größten, weshalb wir bereit sind, es bei dieser Stichprobengröße zu veröffentlichen – aber eine einzelne Vantage ist eine einzelne Vantage.
- Die zwölfstündige Studie ist eine Rechenzentrumsleitung. Der internationale Transit von einer kommerziellen Cloud ist wesentlich besser als von einer Verbraucherverbindung, sodass jede Direktroute-Zahl in der ersten Hälfte dieses Artikels optimistisch ist. Die zweite Hälfte ist, was dieser Optimismus kostet.
- Verschiedene Browser-Builds. Die Rechenzentrumsprobe läuft mit Debians Chromium 151.0.7922.173; der Freiwillige führte Chrome for Testing 151.0.7922.77 aus. Abschluss und Time-to-First-Byte sind gegenüber diesem Unterschied unempfindlich; Paint-Zeiten sollten nur als richtungsweisend gelesen werden.
- Fünf Ressourcen, 88 Sites. Gewählt, weil sie häufig sind und weil sie in früheren Fehlerdaten auftauchten, nicht weil sie erschöpfend sind.
- Der Durchsatz schließt TTFB aus, was die faire Art ist, kleine Dateien zu vergleichen, aber bedeutet, dass die Durchsatzspalte und die TTFB-Spalte getrennt gelesen werden sollten.
- Der zwölfstündige Test schob jede Ressource beide Routen hinunter, was ein Vergleich erfordert und nicht, wie eine Site ausgeliefert wird. Die ausgelieferte Route dort ist zudem eine vereinfachte Konfiguration, gebaut für die Messbarkeit, nicht das Produktionsarrangement.
Was wir als Nächstes messen
Eine zweite Verbraucher-Vantage auf einem anderen Festland-ISP, was das Einzige ist, das das Pekinger Ergebnis von einem Datenpunkt zu einem Befund bewegen würde. Wir erweitern den Verbraucherlauf außerdem über die hier berichteten 88 Sites hinaus.
Wir veröffentlichen lieber eine Empfehlung, die umgeworfen wird, als sie stehen zu lassen, weil sie unsere war. Wenn Sie eine Architekturentscheidung auf Basis der ersten Hälfte dieses Artikels treffen, ist die zweite Hälfte der Teil, der Sie umstimmen sollte.
Die Methode hinter diesen Zahlen, einschließlich der acht Arten, auf die wir es zuerst falsch gemacht haben. Das weitere Bild ist in unserer 280-Site-Zählung, gemessen von innerhalb Chinas. Und wenn Sie sehen wollen, von welchen Drittanbieter-Hosts Ihre eigene Site abhängt, meldet unser China-Firewall-Test sie pro Ressource von innerhalb des Festlands.