Berhenti Melakukan Kompresi JSON dalam Urutan yang Salah: minify vs gzip vs brotli, Terukur

Intinya: pisahkan dulu kompresi transport dari pemangkasan struktural. Jika gzip atau brotli belum aktif, perbaiki konfigurasi server — gzip -6 saja mencapai 94,5% dan menyisakan minify hanya bernilai 0,9 poin. Minify dengan 46,3% penuh baru berlaku ketika tagihan byte dicatat secara lokal: request body, 6 MB di Lambda, 1 MiB di Firestore, atau JSON yang ditulis ke disk dan log.

Badge "menghemat 35%" di minifier favorit Anda jujur — ia mengukur byte mentah. API Anda berjalan di atas gzip atau brotli, dan keduanya memakan redundansi yang persis sama. Mengalikan kedua angka itu menghasilkan jawaban yang salah.

1. Pisahkan "kompresi" menjadi dua hal berbeda

Apa yang orang sebut kompresi JSON sebenarnya dua operasi yang tidak berhubungan, dan mencampuradukkannya adalah awal dari setiap kesimpulan yang salah.

Dua baris terakhir adalah yang penting. Batas platform diukur setelah dekode: batas payload 6 MB di AWS Lambda, batas 1 MiB per dokumen di Firestore. Mengaktifkan gzip tidak membelikan Anda satu byte pun di sana, karena keduanya menghitung hasil yang sudah didekode.

2. Minify menghapus tepat satu hal: whitespace struktural

RFC 8259 mengizinkan whitespace (space, \t, \n, \r) di sekitar karakter struktural apa pun. Tidak ada hal lain dalam dokumen JSON yang opsional: nama key adalah data, number mempertahankan setiap digit, dan isi string tidak boleh disentuh byte demi byte.

Itu membuat seluruh operasi menjadi satu baris:

复制const minified = JSON.stringify(JSON.parse(pretty));
// RFC 8259 hanya mengizinkan whitespace di sekitar karakter struktural,
// jadi spasi di dalam string adalah data, bukan format
JSON.stringify(JSON.parse('{"note": "two spaces"}'));
// {"note":"two spaces"} - kedua spasi di dalam tetap dipertahankan

Yang perlu disebut adalah tiga operasi yang dikelompokkan sebagai "kompresi" padahal sebenarnya mengubah dokumen: membuang key yang nilainya null, membulatkan float, dan mengurutkan ulang key. Itu mengubah dokumen, bukan memformat ulang, jadi alat apa pun yang mengiklankan "deep compression" perlu persetujuan konsumen Anda sebelum Anda mengaktifkannya.

Karena minify hanya menghapus whitespace, manfaatnya hampir sepenuhnya bergantung pada berapa banyak file Anda berupa indentasi. Perkirakan hal itu muncul berulang di tabel-tabel berikut.

3. Pengukuran: empat dokumen, tiga level gzip, plus brotli

Lingkungan: Node v22.13.1, zlib.gzipSync pada level 1 / 6 / 9, brotliCompressSync pada kualitas default (11). Empat sampel sengaja mencakup bentuk yang benar-benar Anda kirim: 50 order bersarang (struktur dalam, key berulang), config 6 level (key panjang, value pendek), array log 200 baris (string panjang, hampir tanpa indentasi), dan media-manifest.json asli dari situs ini (bentuk campuran, string padat URL).

Langkah satu: byte mentah.

Dari sinilah badge "menghemat 35%" berasal, dan ia tidak berbohong. Masalahnya muncul di langkah dua.

Langkah dua: kompres setiap varian, lalu tanyakan berapa banyak yang masih ditambahkan minify.

Dokumen order bersarang yang sama yang kehilangan 46,3% byte mentahnya hanya mempertahankan 17,0% dari itu begitu gzip -6 berperan. Array log malah menjadi negatif: minify lalu kompres sedikit lebih besar daripada mengompres versi pretty aslinya. Nilai negatif bukan bug, itu justru yang seharusnya Anda harapkan, dan bagian berikut menjelaskan sebabnya.

Langkah tiga: pengurangan total terhadap dokumen pretty asli — angka yang benar-benar melintasi wire.

4. Mengapa gzip memakan kredit minify

gzip adalah LZ77 diikuti pengodean Huffman. Inti gerakan LZ77 adalah "lihat ke belakang melalui jendela 32 KB, temukan urutan berulang, ganti dengan pointer (jarak, panjang)." Indentasi adalah target termudah untuk gerakan itu: setiap level nesting mengeluarkan deret spasi identik, dan puluhan baris berdampingan mengulang kombinasi yang sama. Huffman lalu memberi kode pendek untuk simbol berfrekuensi tinggi, sehingga pola seperti \n plus delapan spasi — yang bisa berulang seribu kali dalam satu file — akhirnya hanya memakan dua atau tiga bit.

Jadi byte yang dihapus minify justru byte yang hampir gratis akan diruntuhkan oleh kompresor. Melakukannya sendiri berarti mengulang pekerjaan yang sudah dikuasai kompresor, dan 46% Anda menciut menjadi 17%. Itulah seluruh cerita di balik tabel di atas.

Hasil negatif pada array log layak penjelasan sendiri. Sampel itu hampir seluruhnya string panjang (baris log, URL, base64), yang berarti sedikit pengulangan dan entropi tinggi — sedikit redundansi untuk dihapus kompresor sejak awal. Newline di versi pretty kebetulan memberi matcher batas yang stabil. Hapus mereka dan LZ77 kehilangan jangkar itu: pada sampel ini, mengompres versi pretty asli dengan gzip -1 menghasilkan 1.508 byte, sementara minify lalu kompres menghasilkan 1.518 byte. Sepuluh byte lebih buruk.

Diurutkan berdasarkan besaran, tuas-tuasnya berbaris seperti ini:

Lompatan dari 0 ke 94,5% adalah kerja gzip. Lompatan dari 94,5% ke 95,4% — sembilan persepuluh poin — adalah kerja minify. Tabel ini menetapkan di mana usaha Anda seharusnya berada.

5. Level kompresi adalah variabel tersembunyi

Argumen apa pun yang mengasumsikan satu level gzip tetap berdiri di atas pasir, karena level itu langsung mengubah nilai marginal minify:

Semakin lemah kompresi transport Anda, semakin besar manfaat minify. Itu memberi aturan praktis: pada instalasi Nginx standar yang gzip_comp_level-nya masih 1, minify memberi Anda 21%. Setelah Anda menyetel ke 9 atau beralih ke brotli, angkanya turun ke 9-11% dan biasanya Anda bisa melewatinya.

Sebelum berdebat ke arah mana pun, ukur tingkat mana yang sebenarnya Anda pakai:

复制# Ambil respons yang sama dengan tiga nilai Accept-Encoding dan bandingkan apa yang diterima
for enc in identity gzip br; do
  size=$(curl -s -o /dev/null -w '%{size_download}' \
    -H "Accept-Encoding: $enc" https://api.example.com/v1/orders)
  echo "$enc -> $size bytes"
done

Tiga angka menjawab tiga pertanyaan sekaligus: apakah kompresi bahkan aktif, pada level berapa, dan berapa banyak ruang tersisa untuk minify. Jika identity dan gzip kembali hampir identik, kompresi tidak aktif sama sekali — dan yang perlu diperbaiki adalah Nginx, bukan JSON Anda:

复制gzip on;
gzip_comp_level 6;
gzip_min_length 256;      # lewati respons kecil, mereka hanya membesar
gzip_types application/json application/javascript text/css;

6. Kapan minify benar-benar bermanfaat

Satu uji yang menentukan: apakah byte yang Anda hemat akan tercatat di suatu tempat, atau Anda akan menabrak batas yang menghitung byte mentah? Jika ya, 46% penuh berlaku. Jika jawabannya "ia hanya ada di wire," maka 17% adalah nilai sebenarnya.

Pertama, request body HTTP. Sebagian besar server tidak mendekompres request body, dan gzip dikonfigurasi hampir eksklusif untuk respons. JSON yang Anda POST biasanya tidak punya perlindungan lapisan transport sama sekali, jadi penghematan minify datang dengan harga penuh. Hal yang sama berlaku untuk callback webhook, telemetri MQTT, dan frame WebSocket yang tidak pernah menegosiasikan permessage-deflate.

Kedua, kanal dengan plafon byte keras — dan semuanya menghitung byte yang sudah didekode:

Di kategori ini minify bukan optimasi, melainkan pembeda antara request yang terkirim dan yang gagal. Menyematkan JSON ke query string URL adalah kasus paling tajam: URL tidak pernah dikompres dan mereka memang punya batas panjang, jadi minify dulu, lalu putuskan apakah Anda memerlukan base64 sama sekali.

Ketiga, JSON yang ditulis ke disk atau log. Log dan indeks menyimpan byte literal tanpa lapisan transport yang terlibat. Ada satu catatan yang sering menjegal orang: minify hanya membantu jika sejak awal Anda menulis JSON pretty. Sampel log 200 baris itu hanya menghemat 4,1%, karena barisnya sudah compact dan indentasi hampir tidak menyusun file itu. Sebaliknya, jika logger Anda memanggil JSON.stringify(obj, null, 2), menghapus argumen ketiga adalah uang gratis.

Satu catatan terakhir: ketika byte mentah benar-benar ketat, nama key biasanya tuas yang lebih besar daripada indentasi. Pada media-manifest.json, mengganti 14 key uniknya dengan k0 sampai k13 membawa bentuk terminifikasi dari 21.222 B turun ke 18.887 B — 11,0% lagi. Setelah dikompres, keunggulan tersisa itu menciut menjadi 2,4% di bawah gzip -6 dan 1,3% di bawah brotli. Mekanisme yang sama seperti semua di atas: indentasi dan nama key keduanya informasi struktural berulang, dan kompresor mengklaim dividen yang sama untuk keduanya.

7. Empat kasus ketika hal ini menjadi bumerang

Jangan minify file yang Anda commit. Ubah "qty": 2 menjadi 3 dan file pretty memperlihatkan satu baris bersih di git diff; file terminifikasi menulis ulang seluruh baris, dan dengan ratusan field Anda tidak bisa menemukan perubahannya sama sekali. Ini mekanisme yang sama yang dibahas di Cara Menyelesaikan Konflik Merge JSON — alat diff bekerja per baris, jadi JSON satu baris mengubah setiap edit menjadi "seluruh baris berbeda." Simpan file pretty di repositori dan minify hanya di output build atau saat menulis ke penyimpanan.

Jangan mengompres respons kecil. Respons yang hanya berisi {"ok": true} adalah 16 byte setelah indentasi ditambahkan, dan 36 byte setelah gzip -6 — dua puluh byte lebih besar, karena kamus dan header gzip sendiri memakan ruang. Ini bukan teori; justru inilah alasan gzip_min_length ada. Default Nginx-nya 20 byte jauh terlalu rendah untuk produksi, di mana 256 adalah lantai yang biasa.

Jangan berharap parsing lebih cepat. Menskalakan kumpulan order yang sama ke 4.000 record, dokumen pretty berukuran 2.374.378 byte dibanding 1.282.358 terminifikasi — 46% lebih kecil — namun median waktu JSON.parse hanya bergerak dari 5,7 ms ke 5,0 ms, kira-kira 12% lebih cepat. Memangkas ukuran menjadi separuh tidak memangkas waktu menjadi separuh, karena parser menghabiskan sebagian besar anggarannya untuk memotong string dan mengonversi number; melewati whitespace hanyalah efek samping. Yang sebenarnya menentukan biaya parsing adalah jumlah key dan isi string, yang diuraikan detail oleh Parsing, Rendering dan Streaming File JSON Besar.

Jangan menambahkannya secara retrofit ke layanan yang sudah menjalankan brotli atau gzip -9. Manfaatnya turun ke 9-11%, sementara biayanya — kehilangan keterbacaan permanen saat Anda melakukan debugging — tetap ada. Periksa sebaliknya apakah gzip_types bahkan mencakup application/json. Banyak situs mengaktifkan gzip dan hanya pernah mengompres text/html, meninggalkan JSON sepenuhnya tanpa kompresi; dalam situasi itu minify bukan langkah pertama, memperbaiki konfigurasi Anda adalah.

8. Tabel keputusan: langkah mana lebih dulu

Aturan satu kalimat: lihat neraca byte mana yang ingin Anda kecilkan — yang tercatat secara lokal (disk, kuota, batas platform, request body) atau yang hanya ada di wire. Lokal dulu berarti minify; hanya-wire berarti aktifkan brotli atau gzip dulu.

Dalam praktik, jalankan loop curl di atas untuk memastikan kompresi transport aktif, lalu dorong sampel melalui alat JSON Minify dan baca angka penghematannya. Jika angka itu di atas 40% sementara curl melaporkan identity dan gzip hampir sama ukurannya, hambatan Anda adalah konfigurasi server, bukan JSON. Jika dua angka curl sudah berdekatan, dokumen ini hampir tidak punya sisa untuk diberikan dan Anda sebaiknya memangkas field atau menambahkan pagination — subjek dari Esensi Desain Kontrak JSON API.

Apakah JSON terminifikasi masih JSON yang valid?

Ya. minify hanya menghapus whitespace yang diizinkan RFC 8259 di sekitar karakter struktural dan tidak pernah menyentuh isi string, sehingga JSON.parse menghasilkan nilai identik dengan aslinya. Satu-satunya korban adalah keterbacaan manusia.

brotli atau gzip?

Pada sampel terminifikasi yang sama, brotli menghemat 96,9% dan gzip -6 menghemat 95,4% — selisih sempit. Gunakan gzip -6 untuk respons dinamis agar CPU tetap rendah, dan sisakan brotli untuk aset statis yang dikirim melalui HTTPS yang bisa Anda pra-kompres menjadi file .br.

Saya sudah minify JSON tetapi API tidak menjadi lebih cepat. Mengapa?

Periksa respons dengan curl -sI untuk header Content-Encoding: gzip. Banyak pengaturan Nginx menetapkan gzip_types hanya ke text/html, sehingga JSON tidak pernah tercakup — dan kurang dari seperlima dari 46% Anda pernah mencapai wire.

Apakah file konfigurasi sebaiknya di-commit dalam bentuk terminifikasi?

Tidak. Alat diff membandingkan baris per baris, jadi JSON satu baris mengubah setiap edit menjadi "seluruh baris berubah," dan menyelesaikan konflik jauh lebih mahal daripada byte yang Anda hemat. Simpan versi pretty di repositori dan minify saat build.

Seberapa besar respons sebelum gzip layak dipakai?

Ambang umumnya 256 byte sampai 1 KB. Respons sekecil {"ok": true} — 16 byte dengan indentasi — membesar menjadi 36 byte di bawah gzip -6, karena kamus dan header memakan lebih banyak daripada yang mereka pulihkan. Itulah tepatnya yang dikendalikan gzip_min_length.