Kompresi Response: Dampak Kecil dengan Biaya Kecil

Dari sekian banyak optimasi performa yang saya urus untuk sistem klinik dan rumah sakit yang saya tangani, kompresi response adalah salah satu yang paling sering saya temukan dalam keadaan mati. Bukan karena timnya malas, tapi karena ini jenis pengaturan yang gampang terlewat: tidak ada error kalau lupa mengaktifkannya, aplikasi tetap jalan normal, cuma payload-nya lebih gemuk dari seharusnya. Padahal biaya untuk mengaktifkannya nyaris nol dibanding manfaatnya, terutama untuk aplikasi berbasis JSON API dan halaman web yang berat di sisi HTML/CSS/JS.

Kenapa Ini Penting

Response HTTP yang dikirim server pada dasarnya teks: JSON, HTML, CSS, JavaScript. Teks punya redundansi tinggi, jadi sangat cocok dikompresi. Tanpa kompresi, payload yang seharusnya bisa dipangkas signifikan malah dikirim apa adanya, membebani bandwidth klien dan menambah waktu transfer, terutama untuk pengguna dengan koneksi yang tidak stabil, situasi yang cukup umum saya temui di jaringan fasilitas kesehatan atau saat mengakses aplikasi dari luar kota.

Yang menarik, ini bukan optimasi yang butuh perubahan arsitektur, refactor kode, atau biaya infrastruktur tambahan. Cukup satu baris konfigurasi di web server atau reverse proxy, dan efeknya langsung terasa di setiap request yang lewat.

Gzip vs Brotli, Singkatnya

Gzip adalah algoritma kompresi yang sudah lama jadi standar de facto di web, didukung hampir semua browser dan server. Brotli lebih baru, dikembangkan Google, dan umumnya menghasilkan rasio kompresi lebih baik dibanding gzip pada level kompresi yang sepadan, terutama untuk teks seperti HTML dan JavaScript. Trade-off-nya ada di sisi CPU: brotli pada level kompresi tinggi butuh lebih banyak waktu proses saat encoding, jadi untuk konten yang dinamis (response API yang berubah tiap request) biasanya dipakai level kompresi rendah-menengah, sementara untuk aset statis yang bisa dikompresi sekali lalu di-cache, boleh pakai level tinggi.

Praktik yang saya pakai: aktifkan keduanya di reverse proxy (nginx misalnya), biarkan negosiasi content-encoding jalan otomatis lewat header Accept-Encoding dari klien. Browser modern akan minta brotli kalau didukung, fallback ke gzip kalau tidak.

Konfigurasi yang Sering Terlewat

Di nginx, konfigurasi dasarnya kurang lebih seperti ini sebagai ilustrasi:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 256;

brotli on;
brotli_types text/plain text/css application/json application/javascript text/xml;

Beberapa hal yang sering jadi jebakan:

• Lupa menambahkan MIME type baru. Kalau tim menambah endpoint yang mengembalikan content-type tidak umum, kompresi tidak otomatis berlaku kecuali eksplisit didaftarkan.
• Mengompresi ulang response yang sudah terkompresi. Gambar (JPEG, PNG), video, dan file zip sudah padat secara internal, mengompresinya lagi hanya buang-buang CPU tanpa manfaat berarti.
• gzip_min_length terlalu kecil atau tidak diset. Response yang sangat kecil justru bisa lebih besar setelah dikompresi karena overhead header, jadi ada baiknya ada batas minimum ukuran sebelum kompresi diterapkan.
• Reverse proxy dan aplikasi bertabrakan. Kalau framework aplikasi (misalnya Laravel lewat middleware tertentu) dan nginx sama-sama mencoba mengompresi, bisa terjadi double work atau konflik header. Saya lebih suka menyerahkan tugas ini sepenuhnya ke layer reverse proxy, bukan ke aplikasi.

Takeaway

Kompresi response itu low-hanging fruit yang sesungguhnya. Tidak butuh ubah kode aplikasi, tidak butuh biaya infrastruktur tambahan, cukup pastikan gzip atau brotli aktif di reverse proxy dengan MIME type yang tepat. Kalau belum pernah cek konfigurasi ini di server produksi, luangkan lima menit untuk memastikannya aktif, karena ini termasuk item yang jarang dicek ulang setelah setup awal selesai.