Brotli vs Zstandard: Memilih Kompresi untuk Website dan API

Ukuran HTML, CSS, JavaScript, JSON, dan berkas teks lain berpengaruh pada waktu unduh serta penggunaan bandwidth. Kompresi HTTP dapat mengecilkan data sebelum dikirim melalui jaringan, lalu browser atau klien mengembalikannya ke bentuk semula. Dua algoritma yang patut dipertimbangkan adalah Brotli dan Zstandard (zstd). Keduanya efektif, tetapi tidak selalu menjadi pilihan terbaik untuk pola lalu lintas yang sama.

Memilih algoritma bukan sekadar mengejar ukuran file terkecil. Server perlu mempertimbangkan waktu kompresi, biaya CPU, cache, dukungan CDN, dan kemampuan klien. Panduan ini membahas perbedaan praktisnya serta cara menguji perubahan tanpa mengganggu layanan.

Apa itu Brotli?

Brotli adalah algoritma kompresi lossless yang banyak digunakan untuk konten web berbasis teks. Browser mengiklankan dukungan melalui header permintaan Accept-Encoding, misalnya dengan nilai br. Jika server dan jalur pengiriman mendukungnya, respons dapat dikirim menggunakan Content-Encoding: br. Browser mendekompresi data secara otomatis sebelum konten diproses.

Brotli sering menarik untuk aset statis seperti CSS, JavaScript, HTML, dan font karena tingkat kompresinya dapat sangat baik. Aset yang jarang berubah dapat dikompresi lebih dahulu saat proses build, lalu disimpan di cache. Dengan cara ini, pekerjaan CPU tidak harus diulang pada setiap permintaan pengunjung.

Apa itu Zstandard?

Zstandard, biasa ditulis zstd, adalah algoritma kompresi lossless yang dirancang untuk menawarkan rentang pilihan antara rasio kompresi dan kecepatan. Tingkat kompresi dapat diatur sesuai kebutuhan: level lebih tinggi biasanya menghabiskan lebih banyak CPU untuk mengecilkan data, sedangkan level rendah cenderung memprioritaskan kecepatan.

Zstd berguna pada berbagai beban kerja, termasuk data aplikasi dan respons yang dibuat secara dinamis. Dukungan pada sisi server, proxy, CDN, dan klien tetap perlu diperiksa. Jangan mengaktifkannya hanya karena library kompresi tersedia di server; browser harus memahami encoding yang dikirim, dan semua perantara harus menangani header dengan benar.

Perbedaan utama Brotli dan Zstandard

• Rasio kompresi: Brotli dapat menghasilkan file teks statis yang sangat kecil, terutama jika dikompresi dengan pengaturan yang lebih berat saat build. Zstd juga kompetitif, tetapi hasil akhirnya bergantung pada jenis data dan level yang dipilih.
• Kecepatan kompresi: Zstd memiliki pilihan level yang fleksibel dan sering cocok untuk data yang harus dikompresi dengan cepat. Brotli pada level tinggi bisa lebih mahal untuk diproses, sehingga lebih masuk akal untuk aset yang dapat dipersiapkan sebelumnya.
• Waktu dekompresi: Keduanya dirancang untuk dekompresi yang efisien, tetapi hasil nyata berbeda menurut perangkat, implementasi, dan ukuran respons. Uji pada perangkat sasaran, bukan hanya server pengembangan.
• Dukungan infrastruktur: Brotli sudah umum di ekosistem pengiriman konten web. Dukungan zstd terus berkembang, tetapi tidak boleh diasumsikan seragam pada setiap browser, CDN, reverse proxy, atau perangkat lama.
• Operasional: Keduanya memerlukan pengaturan cache yang benar. Jika server memilih encoding berbeda berdasarkan Accept-Encoding, cache bersama perlu menghormati variasi tersebut.

Kapan sebaiknya memilih Brotli?

Pertimbangkan Brotli untuk aset statis yang berubah saat rilis, seperti bundle JavaScript, stylesheet, HTML hasil build, dan font yang mendukung kompresi. Pipeline build dapat menghasilkan versi Brotli dan menyimpannya bersama aset asli. Server atau CDN kemudian memilih representasi yang sesuai dengan kemampuan klien.

Strategi ini mengurangi biaya kompresi pada waktu permintaan. Namun, pastikan proses deployment membersihkan atau memperbarui cache saat aset berubah. Jangan mengompresi ulang gambar JPEG, PNG, WebP, video, atau arsip yang sudah terkompresi tanpa pengukuran; penghematan biasanya kecil dan dapat menambah beban CPU.

Kapan Zstandard layak diuji?

Zstd patut diuji untuk respons dinamis atau layanan API yang mengirim banyak JSON dan teks, khususnya ketika biaya CPU dan latensi server penting. Fleksibilitas level kompresinya memungkinkan tim mencari titik seimbang antara ukuran respons dan waktu pemrosesan. Zstd juga berguna untuk proses internal seperti pengemasan data, backup, atau pertukaran antar-layanan apabila seluruh komponen mendukungnya.

Untuk lalu lintas web publik, lakukan uji kompatibilitas terlebih dahulu. Pastikan klien benar-benar mengiklankan dukungan encoding tersebut dan server tidak pernah mengirim zstd kepada klien yang tidak mendukungnya. Sediakan fallback yang sesuai, misalnya Brotli, gzip, atau respons tanpa kompresi berdasarkan negosiasi yang benar.

Checklist penerapan yang aman

1. Ukur baseline. Catat ukuran respons, waktu unduh, TTFB, penggunaan CPU, dan latensi persentil tinggi sebelum mengubah konfigurasi.
2. Pilih sampel yang mewakili. Uji HTML, JavaScript, CSS, dan JSON dengan ukuran serta pola perubahan yang berbeda. Jangan menarik kesimpulan dari satu file saja.
3. Periksa negosiasi encoding. Gunakan alat pengembang browser atau curl -I untuk memeriksa Content-Encoding dan Vary: Accept-Encoding bila relevan. Header saja belum membuktikan bahwa semua klien menerima respons dengan benar.
4. Validasi cache. Pastikan CDN menyimpan varian yang tepat, tidak mencampur respons terkompresi dengan yang tidak terkompresi, dan melakukan invalidasi saat aset berubah.
5. Rilis bertahap. Aktifkan untuk sebagian aset atau trafik, pantau error, penggunaan CPU, serta latensi, lalu perluas setelah hasilnya stabil.
6. Sediakan jalan kembali. Simpan konfigurasi sebelumnya dan pastikan Brotli, gzip, atau identitas dapat digunakan sesuai dukungan klien jika algoritma baru bermasalah.

Jangan melupakan cache dan Core Web Vitals

File yang lebih kecil dapat mengurangi transfer jaringan, tetapi bukan jaminan halaman terasa lebih cepat. Koneksi, waktu respons server, eksekusi JavaScript, cache, dan rendering tetap berpengaruh. Kaitkan pengujian kompresi dengan metrik pengguna nyata serta pemeriksaan performa, bukan hanya skor kompresi. Untuk konteks protokol pengiriman, baca juga panduan HTTP/2 vs HTTP/3 di Nazuaf.

Kesimpulan

Brotli merupakan pilihan kuat untuk aset web statis yang dapat dipersiapkan saat build. Zstandard menawarkan fleksibilitas yang menarik untuk beban kerja yang memerlukan keseimbangan antara rasio dan kecepatan kompresi, tetapi dukungan klien dan infrastruktur harus diverifikasi. Tidak ada pemenang universal: ukur jenis data sebenarnya, validasi negosiasi dan cache, lalu terapkan secara bertahap. Dengan pendekatan tersebut, kompresi dapat menghemat bandwidth tanpa menukar penghematan itu dengan masalah kompatibilitas atau beban server yang tidak perlu.