Stack, protocolos y rendimiento real: qué está de verdad a la vanguardia sobre Cloudflare

Ergebnisse

1. Warum gRPC nicht funktioniert

Drei unabhängige Fakten, von denen jeder allein ausreichend ist.

Auf der Serverseite. Der Issue cloudflare/workerd#6455 dokumentiert, dass Workers und Durable Objects keine ausgehenden gRPC‑Aufrufe tätigen können, weil die Laufzeit kein bidirektionales HTTP/2‑Streaming unterstützt; der Issue selbst weist darauf hin, dass bereits die Unterstützung von rein unary gRPC — einem HTTP/2‑POST mit Protobuf‑Body plus Trailers — die meisten Anwendungsfälle freischalten würde, und das existiert noch immer nicht [1].

Auf der Browserseite. Dies ist keine Einschränkung von Cloudflare, sondern des Protokolls: die Web‑Client‑Bibliothek implementiert ein anderes Protokoll als das native gRPC genau weil Browser die HTTP/2‑Funktionen, die gRPC benötigt, nicht bereitstellen [3]. Folglich verwendet gRPC‑Web HTTP/1.1, „was einige der Vorteile von gRPC aufhebt“, und Client‑Streaming und bidirektionales Streaming bleiben unerreichbar [2].

Auf der Seite der Zwischinfrastruktur. Cloudflare dokumentiert in seinem eigenen Blog, dass HTTP‑Trailers — die gRPC für den Status benötigt — nicht vollständig unterstützt wurden von seinem Edge‑Proxy, und es gibt Berichte, dass gRPC‑Bodies und -Trailers durch Tunnel selbst bei TLS+ALPN+h2 am Ursprung entfernt werden [10][11].

Fazit. Es ist nicht so, dass gRPC hier schwierig wäre: Der Anwendungsfall, der gRPC rechtfertigen würde — effizientes, bidirektionales Binär‑Streaming — ist genau der, der weder in der Laufzeit noch im Browser verfügbar ist. Übrig bliebe Protobuf über HTTP/1.1 mit einem zusätzlichen Proxy: mehr Komponenten, mehr Latenz, schlechteres Debugging und ohne den Vorteil.

2. Was tatsächlich die Spitze auf dieser Plattform ist

Cloudflare bietet ein natives JavaScript‑RPC über Service Bindings, das dafür ausgelegt ist, „so nah wie möglich an das Aufrufen einer JavaScript‑Funktion innerhalb desselben Workers zu erinnern“ [4]. Seine Leistungscharakteristik lässt keinen Vergleich mit irgendeiner Netzwerkarchitektur zu: „es gibt keinen Overhead und keine zusätzliche Latenz. Standardmäßig laufen beide Workers im selben Thread desselben Cloudflare‑Servers“, und das RPC zu einem anderen Worker „kreuzt normalerweise nicht einmal ein Netzwerk“ [4][5].

Ein RPC, das das Netzwerk nicht kreuzt, kann von einem RPC, das das Netzwerk kreuzt, nicht übertroffen werden, egal wie effizient seine Serialisierung ist. Das ist der gesamte Vergleich.

Service Bindings unterstützen zwei Stile: Weiterleitung von fetch (ein vollständiges Request wird übergeben) und typisiertes RPC (Methoden werden direkt aufgerufen) [5]. Letzteres entspricht dem Challenge‑Motor, der das Modell des Schülers, den Bewertungs‑ und den Tutor‑Dienst aufruft.

3. HTTP/3, QUIC und was wirklich in einem überlasteten Netzwerk passiert

HTTP/3 ist in allen Cloudflare‑Plänen verfügbar und wird über einen Schalter in den Protokoll‑Optimierungseinstellungen aktiviert [6][7]. Es gibt keine Implementierungsarbeit, nur Verifikation.

Was es bringt, mit Zahlen:

• Paketverlust. Bei Verbindungen mit 1‑3 % Verlust — dem typischen Bereich für reale Mobilgeräte — berichten Studien von Google und Cloudflare von 10‑30 % Verbesserung der Ladezeit, weil die Isolation auf Stream‑Ebene verhindert, dass ein verlorenes Paket alle Anfragen blockiert [8]. Das ist exakt das Szenario von „Low‑End‑Android in Lateinamerika“, das der Master‑Plan als Zielmarkt benennt.
• Verbindungsaufbau. QUIC wurde für 0‑RTT/1‑RTT gebaut; mit 0‑RTT bei wiederkehrenden Besuchern kann die Einsparung über 300 ms betragen, genug, um die Bewertung der Core Web Vitals einer Seite zu verändern [8].

Was es nicht löst: HTTP/3 beschleunigt den Transport, nicht die Arbeit. Ein schweres JavaScript‑Bundle blockiert den Haupt‑Thread exakt gleich über QUIC wie über TCP. Deshalb ist das INP‑Budget (§4) wichtiger als das Protokoll.

4. INP: die Kennzahl, bei der dieses Produkt Gefahr läuft zu scheitern

Die “guten” Schwellenwerte im Jahr 2026: LCP unter 2,5 s, CLS unter 0,1, INP unter 200 ms — und die leistungsstärksten Seiten zielen auf INP unter 150 ms [9].

43 % der Seiten verfehlen die Schwelle von 200 ms für INP, was sie zur am häufigsten verfehlten Vital‑Kennzahl 2026 macht [9]. Der Grund, warum sie schwieriger ist als die anderen: sie misst jede Berührung und jeden Klick, nicht nur den ersten, und der Feind sind lange Aufgaben im Haupt‑Thread — schweres JavaScript, das den Browser daran hindert zu reagieren, wenn der Nutzer interagiert [9].

Dies ist ein spezifisches und benennbares Risiko für Math Challenge: Der Challenge‑Motor besteht aus React‑Islands, das Kind berührt häufig pro Sitzung, und jede Berührung wird gemessen. Ein Mathematik‑Spiel ist von Natur aus eine Anwendung mit hoher Interaktionsfrequenz — das genaue Profil, in dem INP scheitert.

Und das Bewertungs‑Framework schließt die Tür zur Selbsttäuschung: Google rankt mit Felddaten, nicht mit Labordaten; „ein perfektes 100 in Lighthouse bedeutet nichts, wenn reale Nutzer in 3G‑Netzen leiden“ [9].

5. Bilder

Das Ausliefern moderner Formate — AVIF oder WebP — erzeugt Dateien 25‑50 % kleiner [9]. Für LCP ist es am effektivsten, das LCP‑Bild mit fetchpriority="high" vorzupflegen und zusätzlich sein Gewicht zu optimieren [9].

Für dieses Produkt ist das Bildvolumen real: ~30 Kunstwerke der Savanne plus Illustrationen von Items (mc-40, D-019), die von R2 an die sieben Standorte ausgeliefert werden. Da die Kunst zwischen Sprachen wiederverwendet wird — die Savanne spricht nicht (D-019) — ist der Bildkatalog gemeinsam und damit hochgradig cache‑fähig.

6. Nativ auf vier Plattformen

Die Plattform‑Guidelines sind explizit und unterschiedlich: Android folgt Material Design, mit Material 3, das dynamische Farben und Design‑Tokens einführt; Apple deckt alle seine Plattformen mit den Human Interface Guidelines ab [12][13]. Damit sich eine PWA nicht wie das Web anfühlt, konvergiert die praktische Empfehlung in drei Punkte: systemeigene bevorzugte Schriftart, unterschiedlich für iOS/Android/Windows; Navigations‑Leisten, Tabs und Modals im Stil der jeweiligen Plattform; und erwartete Gesten — sanftes Scrollen, Pinch‑to‑Zoom, Wischen [13][14].

Die harten plattformspezifischen Einschränkungen sind bereits in mc-33 dokumentiert und ändern sich nicht: Auf iOS ist die Installation manuell und Push erfordert, dass die App installiert ist; Auf Android gibt es keine Installationsbarriere; Auf macOS Safari 17+ gibt es „Zum Dock hinzufügen“; Auf Windows ist die Installation über Edge/Chromium die am besten integrierte der vier.

Die Kosten der plattformspezifischen Anpassung sind keine Forschungs‑, sondern Ingenieur‑Kosten: Sie verdoppeln Komponenten, Tests und Design‑Entscheidungen. Es ist eine Produkt‑, keine Technik‑Entscheidung.

7. Die Auditoren‑Flotte

Ein Einsatz mit adversarialen Auditoren ist umsetzbar und passt zu der Art, wie dieses Projekt aufgebaut wurde. Er wird in zwei Klassen mit unterschiedlichen Kosten und Geschwindigkeiten unterteilt.

Deterministisch (12), bei jedem Commit, in Sekunden: Bundle‑Budget · Core Web Vitals mit Schwellenwerten aus §4 · axe‑core · Kontrast · Größe der taktilen Ziele pro Band (24 px WCAG AA / 44 px HIG / 88 px Kinder, gemäß mc-38 und mc-20) · Vollständigkeit der sieben Sprach‑Keys · JSON‑LD‑Validierung · hreflang‑Reziprozität · Geheimnis‑Scanning · Präfix math-challenge- (CLAUDE.md § Cloudflare) · Migrations‑Sicherheit · Offline‑Pre‑Cache‑Budget (~5 MB Audio, mc-42).

Adversarial mit LLM (23), bei jedem PR, angeleitet, Verstöße zu finden und nicht zu genehmigen: rote Linien (die acht) · COPPA/GDPR‑K‑Privatsphäre · Anti‑Demütigung · Anti‑Betrug · dunkle Muster · Pädagogik · mathematische Strenge · wissenschaftliche Strenge (jede nachprüfbare faktische Aussage) · Larry‑Kanon · Serien und Bildschirmzeit · Kinder‑Modus · PWA iOS · PWA Android · PWA‑first/offline · Leistung bei langsamen Netzen · UX nach Altersgruppe · und einer pro Locale: en, es-MX, es-ES, fr-FR, pt-BR, pt-PT, de-DE.

Gesamt: 35.

Die beiden Regeln, die sie nützlich statt hinderlich machen. Erstens: jeder Auditor zitiert die Entscheidung oder das Dokument, das die Regel durchsetzt — ein Auditor, der keine Entscheidung aus decisions.md oder einen Befund aus research/ benennen kann, gibt nur eine Meinung ab, und sein Urteil blockiert nicht. Zweitens: einen Auditor zu annullieren erfordert, dass man begründet, warum, und diese Begründung bleibt im Verlauf. Ohne das Erste erzeugt die Flotte Lärm; ohne das Zweite wird sie zu einem Hindernis, das die Leute stillschweigend umschiffen lernen.

Bekanntes Risiko, offen ausgesprochen: 23 Auditoren mit LLM pro PR verursachen Kosten pro PR und eine Rate an Fehlalarmen. Die Gegenmaßnahme ist, dass nur die deterministischen Auditoren standardmäßig blockieren, und die adversarialen nur blockieren, wenn sie eine rote Linie oder eine explizite Entscheidung zitieren; der Rest meldet ohne zu blockieren.

Designimplikationen

1. Kein gRPC und kein gRPC-Web. Native RPC von Workers über Service Bindings für alles Internes (§1, §2).
2. HTTP/3 verifiziert, nicht angenommen, inklusive 0‑RTT für wiederkehrende Aufrufe; es ist eine Konfiguration, und man muss bestätigen, dass sie aktiv ist, bevor man sie beansprucht (§3).
3. Harter INP‑Budget ≤ 150 ms, nicht 200 — es ist ein Hochfrequenz‑Interaktionsspiel und die lockere Schwelle ist dort, wo 43 % des Webs scheitern (§4).
4. Messung mit Felddaten vom ersten Tag an, nicht mit Lighthouse; ein Labor‑100 sagt nichts über das Kind im 3G‑Netz (§4).
5. AVIF mit WebP‑Fallback für alle Grafiken, mit fetchpriority="high" im LCP‑Bild jeder Ansicht (§5).
6. Die Savannen‑Grafik wird einmal zwischengespeichert und an die sieben Regionen ausgeliefert, weil sie keinen Text enthält (D-019) — sie ist die günstigste Gewichts‑hebel des Produkts.
7. Plattformadaptive Schnittstelle: Material 3 auf Android, HIG auf iOS/macOS, System‑Steuerelemente unter Windows, jeweils mit System‑Typografie (§6).
8. Performance‑Budget als deterministischer Auditor, der blockiert, nicht als Bericht, der ignoriert wird (§7).
9. 35 Auditoren, mit den beiden Regeln aus §7: die durchzusetzen Entscheidung zitieren und schriftliche Aufhebung.
10. Nur die Deterministen blockieren standardmäßig; die adversarialen blockieren nur, wenn eine rote Linie oder eine explizite Entscheidung zitiert wird (§7).

Offene Fragen für den Projektinhaber

1. Was geschieht, wenn ein adversarialer Auditor und ein anderer sich widersprechen — zum Beispiel, Performance verlangt weniger JavaScript und Accessibility verlangt mehr Fokus‑Logik? Gibt es eine schriftliche Prioritätsreihenfolge?
2. Laufen die 23 Auditoren mit LLM bei jedem PR oder nur bei denen, die sensible Pfade berühren? Die Kosten pro PR und die Wartezeit ändern sich stark.
3. Auf welchem Referenzgerät wird das INP‑Budget von 150 ms gemessen? mc-33 schlägt ein Mittelklasse‑Android über langsames 3G vor; es muss festgelegt werden, sonst ist das Budget nicht prüfbar.
4. Beinhaltet die adaptive Schnittstelle Windows und macOS von Anfang an, oder nur Mobile in v1?