Jangan anggap remeh pemilihan atau konfigurasi Web Compression Algorithms karena ini bisa membuat website kita tidak bekerja sebagai mana mestinya. Ini bukan sekedar masalah kode yang ditulis ataupun hosting yang dipilih.
Background
Di salah satu website yang saya kembangkan, saya menggunakan HTTP Stream untuk fitur chat. Aplikasi website saya bungkus menggunakan docker image lalu di deploy ke development environment dan production environment. DNS sudah di konfigurasi di Cloudflare dan di masing-masing server environment saya menggunakan Dokploy untuk maintain container deployment.
Di deployment terbaru, terjadi hal yang tidak konsisten, fitur chat di development environment berjalan lancar, tidak ada isu di HTTP Stream, encoding website juga tidak ada masalah. Namun setelah saya deploy ke production environment, fitur chat tidak bekerja dan mendapatkan error ERR_CONTENT_ENCODING_FAILED. Padahal tidak ada perubahan code, hanya upgrade patch dependency package saja. Akhirnya saya bolak balik downgrade, tapi tetap saja error, padahal sebelumnya berjalan normal.
Setelah cek sana sini dan bolak balik deploy, saya temukan kemungkinan masalah lainnya, dan salah satu kandidatnya adalah komunikasi antara fitur chat dengan service lainnya. Sebelumnya fitur chat tidak bergantung ke service yang lain, sedangkan di latest deployment arsitektur berubah. Tapi kenapa di development environment berjalan normal! 😤.
Setelah itu saya coba diskusi dengan GPT yang dilengkapi fitur Web Search. Tapi tidak semudah itu juga dapat solusi yang tepat, karena kita perlu berikan konteks yang cukup agar GPT dapat memberikan solusi yang tepat. Banyak solusi yang diberikan GPT, tapi karena saya skeptis saya hanya coba beberapa solusinya, dan isunya tetap tidak solve, jadi tambah skeptis 😁.
Setelah beberapa hari berjibaku dengan isu yang sama, akhirnya saya mau mencoba solusi lainnya yang pernah diberikan GPT, ditambah saya pertajam juga konteksnya. Finally, it solved! 😎.
Jadi begini, lokasi server development ada di Singapore, sedangkan lokasi server production ada di US. Perilaku dari Cloudflare ini berbeda, ketika /api/chat di hit di zona Singapore, encoding yang di pakai adalah Zstd, sedangkan di zona US, encoding yang dipakai adalah Brotli (br). Lalu saya ikuti saran GPT untuk disable Brotli (br) menggunakan Compression Rules dan hanya mengaktifkan Zstd di salah satu endpoint service di production environment. Alhasil, tidak ada lagi ERR_CONTENT_ENCODING_FAILED 🎉.
Kok bisa? 🤔
Mari kita coba pelajari mengenai Web Compression Algorithms.
Analisis Perbandingan Algoritma Kompresi
| Feature / Aspect | Zstd (Zstandard) | Brotli | Gzip | Deflate |
|---|---|---|---|---|
| Compression Ratio | Very high (better than gzip, close to Brotli at higher levels) | Excellent (best for static assets like HTML/CSS/JS) | Moderate (baseline standard) | Moderate (similar to gzip, sometimes slightly worse) |
| Speed (Compression) | Fast, especially at lower levels; scalable | Slower than gzip/zstd at high compression levels | Fast, widely optimized | Fast, but less efficient |
| Speed (Decompression) | Very fast (optimized for real‑time streaming) | Good, but slower than gzip/zstd | Very fast | Very fast |
| Streaming Support | Strong (designed for streaming and chunked data) | Weak (not ideal for streaming, expects full payload) | Strong | Strong |
| Browser Support | Modern browsers (Chrome, Firefox, Edge) support it | Widely supported in all modern browsers | Universally supported | Universally supported |
| Best Use Cases | APIs, streaming responses, large datasets | Static assets (HTML, CSS, JS) over HTTPS | General web compression, legacy compatibility | Legacy fallback, simple compression |
| Resource Usage | Efficient, tunable trade‑off between speed and ratio | Higher CPU usage at high compression levels | Low CPU usage | Low CPU usage |
| Adoption | Growing (Cloudflare, Facebook, modern CDNs) | Very common for web assets | Ubiquitous, default in many servers | Older, less common today |
Key Takeaways
- Zstd -> Cocok untuk streaming APIs dan data besar, seimbang antara kecepatan dan rasio kompresi.
- Brotli -> Cocok untuk static assets (HTML/CSS/JS) dimana kompresi maksimal itu penting.
- Gzip -> Aman, pilihan universal, biasanya bisa jalan dimanapun.
- Deflate -> Opsi legacy, jarang dipilih kecuali untuk kompatibilitas.
Nah! masalah yang saya ceritakan diatas itu terkait dengan streaming responses, dimana Zstd adalah yang paling bisa diandalkan karena memang didesain untuk streaming. Cloudflare tidak tau persis apakah suatu endpoint diakses menggunakan HTTP streaming atau tidak, maka dari itu kitalah sebagai software engineer yang harus paham sehingga bisa mengonfigurasi Cloudflare dengan tepat.
Gitu doank? yup gitu doank, tapi kalau gak paham, sampai lebaran tahun depan pun gak akan selesai 😅
