Großes JSON-Parsen beschleunigen

Kurz gesagt: Messen Sie zuerst Netzwerk, Parsen und Rendern getrennt – die meisten Fälle von „langsamem Parsen“ entpuppen sich als langsames Rendern – und steigen Sie dann in dieser Reihenfolge: weniger Parses, kleinere Payloads, Streaming, ein Worker und zuletzt ein binäres Format.

Beginnen Sie nicht mit einem Bibliothekswechsel. Einen Timer hinzuzufügen zeigt meist, dass das Rendern das Problem ist.

Schritt eins: die Stufen messen

复制const t0 = performance.now();
const response = await fetch(url);
const text = await response.text();
const t1 = performance.now();
const data = JSON.parse(text);
const t2 = performance.now();
render(data);
const t3 = performance.now();

Moderne Browser parsen 1 MB in etwa 5–15 ms und 10 MB in 80–150 ms. Dauert 10 MB zwei Sekunden, ist JSON.parse nicht Ihr Engpass.

Schritt zwei: weniger parsen

Der günstigste Gewinn und der am meisten übersehene.

• Hören Sie auf, dieselbe Payload wiederholt zu parsen. Zehn Komponenten, die je JSON.parse(localStorage.getItem(...)) aufrufen, sind zehn Parses. Einmal auf Modulebene cachen.
• Hören Sie auf, JSON.parse(JSON.stringify(x)) für Tiefenkopien zu verwenden. Es kostet mehr als das Doppelte des Datenvolumens; structuredClone nicht.
• Nicht auf dem Hauptthread parsen und das Objekt dann an einen Worker senden. postMessage klont es erneut. Senden Sie den Rohtext und lassen Sie den Worker parsen.
• Weniger Felder anfordern. Braucht die UI drei Eigenschaften, sollte die API nicht dreihundert senden.

Schritt drei: die Payload verkleinern

Paginierung nach page/size, Cursor statt tiefem offset, Zusammenfassungsfelder in Listen-Endpunkten. Das schlägt meist alle Frontend-Optimierungen zusammen, weil es Netzwerk, Parsen und Speicher gleichzeitig reduziert.

Schritt vier: streamen

Wenn die Daten als Ganzes verarbeitet werden müssen und wirklich groß sind:

复制import { parser } from 'stream-json';
import { streamArray } from 'stream-json/streamers/StreamArray';

const pipeline = fs.createReadStream('big.json').pipe(parser()).pipe(streamArray());
for await (const { value } of pipeline) {
  await handleOne(value);
}

Mehr Code und kein wahlfreier Zugriff – nur für Datensatz-für-Datensatz-Verarbeitung geeignet.

Schritt fünf: vom Hauptthread verlagern

Parsen ist schnell, aber blockierend. Legen Sie es in einen Worker und übergeben Sie den Text, nicht das geparste Objekt, sonst verdoppelt strukturiertes Klonen die Kosten.

Schritt sechs: das Format ändern, zuletzt

Für internen Traffic, der konstant zig Megabyte groß ist, streamt NDJSON natürlich, und Protobuf oder MessagePack sind kleiner und schneller. Beides sind Protokolländerungen, die Koordination erfordern.

Nicht tun

• JSON evalen: unsicher und nicht schneller
• JSON stringifizieren, um es in JSON einzubetten: verdoppelt die Größe
• Hunderttausende winziger Strings in einer Schleife parsen: sie bündeln

FAQ

Wie erkenne ich, ob Parsen oder Rendern der Engpass ist?

Messen Sie Anfrage, Textlesen, JSON.parse und Rendern getrennt mit performance.now(), und behandeln Sie die größte Stufe als echten Engpass. Moderne Browser parsen 1 MB in etwa 5–15 ms und 10 MB in 80–150 ms, eine 10-MB-Payload, die zwei Sekunden braucht, ist also selten ein JSON.parse-Problem.

Warum hilft ein Bibliothekswechsel meist nicht?

JSON.parse ist bereits nativ und schnell; die meiste „langsames Parsen“-Klage kommt von wiederholtem Parsen oder dem Rendern Zehntausender Knoten auf einmal. Ein Bibliothekswechsel bringt 10–30 %, während das Entfernen eines vollständigen Parses oft die Hälfte spart.

Sollte ich das Parsen in einen Web Worker verlagern?

Verlagern Sie es in einen Worker, wenn das Parsen den Hauptthread blockiert und die Seite einfriert oder Animationen Frames verlieren. Übergeben Sie den Rohtext statt des geparsten Objekts, sonst verdoppelt das strukturierte Klonen von postMessage die Kosten.

Weiterführende Literatur

• Große JSON-Dateien parsen, rendern und streamen
• JSON-Sicherheitscheckliste