Ratgeber · JSON 2026
Wie schnell ist JSON.parse wirklich?
V8 hat JSON.parse 2024 nochmal um 30 % beschleunigt. Bei < 5 MB Payload ist Parsing fast nie das Bottleneck - der Hot-Path liegt woanders.
Von Mateusz Viola
Betreiber & redaktionelle Verantwortung json-formatieren.de
Veröffentlicht
Aktualisiert:
Wie schnell ist JSON.parse?
In V8 (Chrome 130 / Node.js 22) erreicht JSON.parse auf moderner Hardware (z.B. Ryzen 7 5800X) etwa 1 GB pro Sekunde - bei flachen Objekten sogar 1,4 GB/s. Das entspricht 1,8 Millionen typischer API-Payloads (~500 Bytes) pro Sekunde pro Core.
Was V8 unter der Haube macht
V8 nutzt seit Mitte 2023 einen rewritten JSON-Parser, der speziell auf typische Object-Shapes optimiert ist. Bei wiederholten Aufrufen mit gleicher Struktur erkennt V8 die "hidden class" wieder und überspringt Field-Lookups - was den Parse-Throughput um 30 % erhöht.
Chrome 137 (Q1 2025) bringt SIMD-beschleunigtes Whitespace-Skipping. Für riesige Pretty-Printed-Files macht das bis zu 20 % Mehr-Throughput.
Reicht das?
Für 99 % aller Anwendungsfälle: ja. Eine API-Response von 5 KB wird in unter 5 Mikrosekunden geparst - das ist Größenordnungen schneller als jeder Netzwerk-Roundtrip (ms-Bereich) oder DB-Query (mehrere ms).
| Payload | JSON.parse-Zeit | Anteil an Total |
|---|---|---|
| 5 KB API-Response | ~5 µs | < 0,01 % |
| 100 KB GraphQL-Result | ~100 µs | ~0,5 % |
| 2 MB Search-Result | ~2 ms | ~5 % |
| 50 MB Daten-Dump | ~50 ms | ~30 % |
| 500 MB Export | OOM oder ~500 ms | relevant |
Wann lohnen Alternativen?
Spezialisierte Libraries werden interessant ab ~100 MB pro Request oder bei reinen ETL-Workloads mit 1k+ Files pro Stunde.
- simdjson (C++/WebAssembly): SIMD-vektorisiert, schafft 2-4 GB/s. Verfügbar als
simdjson-wasmin JS - aber WASM-Overhead frisst den Vorteil bei kleinen Payloads. - RapidJSON (C++): wenn Sie eh nativ arbeiten.
- jsmn: ultra-minimal in C, gut für embedded.
Anti-Patterns die Parse-Kosten unnötig hochtreiben
- Stringification + Re-Parsing für Deep-Copy:
JSON.parse(JSON.stringify(obj))ist 10-50× langsamer alsstructuredClone(obj)(verfügbar seit Node 17). Nur noch nutzen wenn man auf Pre-Node-17 ist. - JSON.parse auf Strings die schon Objekte sind: kein Typ-Check, einfach try/catch.
- Wiederholtes Parsing derselben Config: einmal beim App-Start, dann aus Memory.
- JSON.parse für Trivial-Validierung: wer nur Required-Felder checken will, ist mit einem schema-validate-Aufruf besser dran.
Reviver-Callback nur wenn nötig
JSON.parse(text, reviver) ruft den Callback für jeden Wert. Bei großen Dokumenten skaliert das linear mit der Anzahl Nodes - bei 1 Mio Objekten ein spürbarer Hit. Für Date-Deserialisierung allein lohnt der Reviver, für alles andere lieber nach dem Parsing transformieren.
Messen statt raten
Microbenchmarks mit console.time oder dem perf_hooks-Modul. Wichtig: warm-up runs nicht messen (V8-Optimization braucht ein paar Iterationen) und Variance über 100+ Runs averagen. Die Library benchmark.js ist der Klassiker.