Minifikasi vs. Prettifikasi JSON: Kapan Memakai Masing-masing

Apa yang benar-benar berubah di antara keduanya

Minifikasi membuang setiap byte yang tidak mengubah makna: spasi setelah titik dua dan koma, newline, dan indentasi. Prettifikasi (disebut juga beautification) menambahkan kembali whitespace itu dalam pola yang konsisten — biasanya 2 atau 4 spasi per level nesting — agar manusia bisa melihat strukturnya sekilas.

// Minified (48 bytes)
{"user":{"id":7,"active":true,"tags":["a","b"]}}

// Prettified (2-space indent, 96 bytes)
{
  "user": {
    "id": 7,
    "active": true,
    "tags": ["a", "b"]
  }
}

Keduanya terurai menjadi object in-memory yang persis sama. Tambahan 48 byte pada versi prettified murni ada demi keterbacaan manusia — tidak membawa informasi semantik sedikit pun.

Kapan minifikasi adalah pilihan yang tepat

Respons dan permintaan API: setiap byte yang Anda buang adalah byte yang tak perlu diunduh klien. Pada payload besar — daftar terpaginasi berisi ratusan record — minifikasi bisa memangkas 15-25% ukuran transfer sebelum kompresi bahkan berjalan.

Konfigurasi yang disisipkan dalam bundle HTML atau JS: blob JSON minified yang di-inline ke tag <script> tidak menggemukkan bundle Anda dengan formatan yang tak dibutuhkan peramban mana pun.

Baris log dan penyimpanan: jika Anda menulis JSON ke berkas log atau kolom database satu record per baris, bentuk minified menjaga setiap record tetap dalam satu baris — penting untuk alat seperti grep, jq -c, dan log shipper berbasis baris.

Satu catatan: jika respons Anda sudah dilayani dengan kompresi gzip atau brotli (kebanyakan API begitu), penghematan byte dari minifikasi menyusut drastis — whitespace berulang terkompresi sangat baik. Minify-lah untuk kasus tak terkompresi (konfigurasi yang disisipkan, log) tempat dampaknya paling terasa.

Kapan prettifikasi adalah pilihan yang tepat

Apa pun yang akan dibaca manusia: contoh dokumentasi API, berkas konfigurasi yang diedit manual pengembang (package.json, tsconfig.json), keluaran debugging, dan diff code review. Blob JSON minified satu baris dalam git diff tampak sebagai satu baris berubah betapapun kecil perubahan aktualnya — JSON yang diprettifikasi menampilkan diff level baris yang bersih dan bisa direviu.

Konfigurasi yang berkontrol versi: indentasi dua spasi atau empat spasi dengan satu key per baris berarti git bisa menunjukkan persis key mana yang berubah, alih-alih menandai seluruh blob sebagai termodifikasi.

2 spasi vs. 4 spasi vs. tab

Tidak ada perbedaan fungsional — JSON.parse() mengabaikannya sepenuhnya. Dua spasi adalah konvensi paling umum di ekosistem JavaScript/TypeScript (npm, kebanyakan style guide JS) dan menjaga object bersarang dalam tetap tidak meleset dari layar. Empat spasi lebih umum di tooling dekat Python. Tab jarang dipakai khusus untuk JSON karena dirender tidak konsisten antar-editor dan penampil diff. Pilih satu dan tetap konsisten dalam satu proyek — indentasi campuran dalam JSON adalah sumber umum diff yang berisik.