Kompresi gzip/Brotli: Kenapa Response API 2MB Bisa Sampai ke Browser Cuma dalam 200KB?

Bayangin Budi Curiga Response API-nya Terlalu Kencang...

Bayangin Budi mengecek tab Network di browser setelah membuka halaman daftar produknya sendiri. Response JSON dari API-nya, kalau ditampilkan mentah-mentah, berukuran 2 MB (ribuan baris data produk lengkap dengan deskripsi panjang). Tapi kolom "Size" di Network tab cuma menunjukkan ~200 KB, dan halamannya terasa sangat kencang bahkan di koneksi 4G pelanggannya. Budi curiga ada yang salah hitung — bagaimana bisa 2 MB data terkirim secepat itu?

Masalahnya: Teks JSON Penuh dengan Pola yang Berulang-Ulang

Data JSON API biasanya sangat repetitif: nama key seperti "id", "title", "price", "description" muncul berulang-ulang di setiap satu dari ribuan objek. Mengirim teks mentah yang penuh pengulangan seperti ini lewat internet itu boros, padahal ada cara matematis untuk memampatkannya jauh lebih kecil sebelum dikirim.

Nah, Di Sinilah Kompresi 'gzip' dan 'Brotli' Masuk!

Browser dan Server sebenarnya diam-diam bernegosiasi setiap kali berkomunikasi:

1. Browser mengirim header Accept-Encoding: gzip, br di setiap request, artinya: "Saya sanggup menerima data yang dikompres pakai gzip atau Brotli, silakan kirim versi mampatnya kalau ada."
2. Server (lewat middleware seperti compression di Express, atau otomatis dari Nginx) memampatkan body response menggunakan algoritma gzip atau Brotli (yang lebih baru dan biasanya menghasilkan ukuran lebih kecil lagi) sebelum dikirim, lalu menambahkan header Content-Encoding: br.
3. Browser menerima data yang sudah mampat itu, otomatis mendekompresnya kembali secara transparan menjadi JSON 2 MB yang utuh, sebelum diberikan ke kode JavaScript aplikasi. Developer sama sekali tidak perlu menulis kode dekompresi manual di sisi frontend.

import compression from "compression";

app.use(compression()); // Express otomatis mengompres semua response teks

Karena data JSON penuh pola berulang, rasio kompresinya bisa sangat tinggi — teks 2 MB yang penuh kata "description" dan struktur berulang bisa menyusut hingga 85-90% menjadi sekitar 200 KB, persis seperti yang dilihat Budi.

Intinya: Kompresi HTTP itu hampir selalu untung besar untuk hemat bandwidth dan mempercepat loading, nyaris tanpa biaya tambahan di sisi kode aplikasi — tinggal pastikan middleware atau reverse proxy-nya aktif, dan biarkan browser yang mengurus sisanya secara otomatis.