Mempercepat parsing JSON berukuran besar

Intinya: ukur network, parse dan render secara terpisah lebih dulu — sebagian besar "parsing lambat" ternyata adalah render lambat — lalu naiki tangga secara berurutan: lebih sedikit parse, payload lebih kecil, streaming, worker, dan format biner paling akhir.

Jangan mulai dengan mengganti library. Tambahkan satu timer dan biasanya Anda akan menemukan bahwa render adalah masalahnya.

Langkah satu: ukur setiap tahap

复制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();

Browser modern mem-parsing 1MB dalam sekitar 5–15ms dan 10MB dalam 80–150ms. Jika 10MB butuh dua detik, JSON.parse bukan bottleneck Anda.

Langkah dua: parse lebih sedikit

Kemenangan termurah, dan paling sering terlewat.

• Berhenti mem-parsing payload yang sama berulang kali. Sepuluh komponen yang masing-masing memanggil JSON.parse(localStorage.getItem(...)) berarti sepuluh parse. Cache sekali di level modul.
• Berhenti memakai JSON.parse(JSON.stringify(x)) untuk deep copy. Biayanya lebih dari dua kali volume data; structuredClone tidak.
• Jangan parse di main thread lalu mengirim objeknya ke worker. postMessage mengkloningnya lagi. Kirim teks mentahnya dan biarkan worker yang mem-parsing.
• Minta lebih sedikit field. Jika UI butuh tiga properti, API tidak seharusnya mengirim tiga ratus.

Langkah tiga: perkecil payload

Pagination dengan page/size, cursor alih-alih offset yang dalam, field ringkasan di endpoint daftar. Ini biasanya mengalahkan semua optimasi frontend digabung, karena sekaligus mengurangi network, parse dan memori.

Langkah empat: streaming

Ketika data harus diproses secara keseluruhan dan memang besar:

复制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);
}

Lebih banyak kode, dan tanpa akses acak — hanya cocok untuk pemrosesan catatan per catatan.

Langkah lima: pindahkan dari main thread

Parsing itu cepat tetapi memblokir. Pindahkan ke worker dan kirim teks, bukan objek hasil parse, atau structured cloning menggandakan biayanya.

Langkah enam: ganti format, paling akhir

Untuk lalu lintas internal yang konsisten puluhan megabyte, NDJSON mengalir secara alami, dan Protobuf atau MessagePack lebih kecil dan lebih cepat. Keduanya adalah perubahan protokol yang membutuhkan koordinasi.

Jangan

• eval JSON: tidak aman dan tidak lebih cepat
• Stringify JSON untuk menyematkannya dalam JSON: menggandakan ukuran
• Parse ratusan ribu string kecil dalam loop: batch-kan

FAQ

Bagaimana saya tahu apakah parsing atau render yang menjadi bottleneck?

Ukur waktu request, pembacaan teks, JSON.parse dan render secara terpisah dengan performance.now(), lalu anggap tahap terbesar sebagai bottleneck sebenarnya. Browser modern mem-parsing 1MB dalam sekitar 5–15ms dan 10MB dalam 80–150ms, jadi payload 10MB yang butuh dua detik jarang merupakan masalah JSON.parse.

Mengapa mengganti library biasanya tidak membantu?

JSON.parse sudah native dan cepat; sebagian besar "parsing lambat" berasal dari parsing berulang atau merender puluhan ribu node sekaligus. Mengganti library memberi 10–30%, sementara menghapus satu parse penuh sering menghemat separuh.

Haruskah saya memindahkan parsing ke Web Worker?

Pindahkan ke worker ketika parsing memblokir main thread dan halaman membeku atau animasi kehilangan frame. Kirim teks mentah alih-alih objek hasil parse, jika tidak structured cloning postMessage menggandakan biayanya.

Bacaan lanjutan

• Parsing, rendering dan streaming JSON besar
• Checklist keamanan JSON