gRPC mit Protobuf ist nicht automatisch schneller als HTTP mit JSON

gRPC mit Protobuf hat einen klaren Ruf: schneller, schlanker, moderner als HTTP mit JSON. In der Praxis ist das Bild weniger sauber. Neue Benchmarks und ältere Vergleichstests zeigen zwar oft Vorteile für gRPC, aber eben nicht immer. Teilweise liegt HTTP/1 sogar vor gRPC. Das kratzt an einem beliebten Reflex in Backend-Teams: Binärformat plus HTTP/2 gleich mehr Tempo.

Der erste wichtige Punkt: Hier werden oft zwei Dinge vermischt. Transport und Datenformat. Wer gRPC gegen HTTP+JSON testet, vergleicht meist zugleich RPC gegen REST, HTTP/2 gegen HTTP/1.1 und Protobuf gegen JSON. Das macht die Ergebnisse für Architekturentscheidungen gefährlich. Wenn ein Test besser ausfällt, ist oft unklar, ob das am Protokoll liegt, an der Serialisierung oder schlicht an der Server-Implementierung.

Trotzdem gibt es ein Muster. Protobuf ist bei Größe und Serialisierung fast immer im Vorteil. Binäre Payloads sind kompakter als JSON. Das senkt Übertragungsvolumen und spart CPU beim Parsen. Dieser Effekt wird mit wachsenden Nutzdaten sichtbarer. Gerade bei interner Service-Kommunikation mit vielen Requests pro Sekunde ist das ein echter Hebel.

Bei der Transportseite wird es komplizierter. gRPC baut auf HTTP/2. Das bringt Multiplexing, Header-Kompression und Streaming. Auf dem Papier ist das stark. In Benchmarks taucht aber immer wieder ein anderer Effekt auf: HTTP/2 kann in bestimmten Setups langsamer laufen als erwartet, teils sogar hinter HTTP/1 zurückfallen. Wer daraus ableitet, gRPC sei überschätzt, greift aber zu kurz. Solche Resultate hängen stark an Implementierungsdetails, Laufzeitumgebung, Verbindungshandling und Lastprofil.

Für Teams heißt das: Ein Benchmark ist kein Freifahrtschein für einen Stack-Wechsel. Wer kleine Payloads verschickt, wenige Aufrufe pro Request hat und vor allem Browser- oder Public-API-Kompatibilität braucht, gewinnt mit gRPC oft weniger als gedacht. JSON bleibt dort attraktiv, weil es lesbar ist, breit unterstützt wird und Debugging einfacher macht.

Anders sieht es bei Microservices aus. Wenn Services untereinander in hoher Frequenz kommunizieren, schlagen die Vorteile von Protobuf und gRPC eher durch. Niedrigere Latenz, kleinere Nachrichten und Streaming können dort spürbar helfen. Vor allem dann, wenn Lastspitzen auftreten oder Systeme an CPU- und Netzwerkgrenzen laufen.

Ein zweiter Punkt wird oft unterschätzt: Skalierung. Mehrere Vergleichstests zeigen, dass JSON-basierte APIs bei größeren Payloads stärker abbauen, während Protobuf und gRPC robuster bleiben. Das ist keine akademische Randnotiz. Wer heute ein System baut, das morgen mehr Daten pro Request oder mehr interne Calls tragen muss, sollte diesen Verlauf ernster nehmen als einzelne Millisekunden aus einem Kurztest.

Auf Mobilgeräten kommt noch ein anderer Faktor dazu. Dort zählen Latenz und Request-Größe besonders stark. Kompaktere Payloads helfen direkt bei Laufzeit und Datentransfer. Das ist ein Bereich, in dem gRPC seine Stärken sauber ausspielen kann, sofern die Plattform und das API-Design dazu passen.

Die nüchterne Einordnung ist einfach: gRPC mit Protobuf ist oft schneller als HTTP mit JSON. Aber eben nicht automatisch. Wer nur auf ein Benchmark-Diagramm schaut, verpasst die eigentliche technische Arbeit. Entscheidend sind Payload-Größe, Request-Muster, Infrastruktur und Client-Typen. Für interne Hochlast-Kommunikation ist gRPC häufig die bessere Wahl. Für offene Web-APIs bleibt HTTP mit JSON oft der pragmatischere Standard.

Der Fehler liegt selten im Protokoll. Er liegt in der Annahme, ein modernes Protokoll löse jedes Performance-Problem von allein.