[WP] Gzip vs Brotli: Perbedaan 2 Algoritma Kompresi

Untuk mempercepat situs web, termasuk yang dibangun dengan CMS WordPress, mengatur kompresi data di server adalah langkah yang berguna. Dengan cara ini, data yang dikirim antara server web dan browser bisa dimuat lebih cepat, dan situs web pun menjadi lebih cepat. Ini adalah salah satu faktor yang banyak dipertimbangkan oleh admin yang mengelola situs web. Kompresi gzip banyak digunakan, dan di banyak server web kini terlihat tren peralihan bertahap dari gzip ke kompresi Brotli yang terus meningkat.

1️⃣ Apa Itu Kompresi?

Situs URL: saat Anda mengaksesnya, browser dan server mulai bercakap-cakap. Pada saat itu, browser memberi tahu server apakah konten yang dikompresi (Compression) bisa ia buka, dan algoritma kompresi apa yang ia gunakan. Informasi ini membantu browser mendekompresi data dengan benar saat server mengirimkannya dalam bentuk terkompresi. Jadi, dengan server dan browser yang mendukung algoritma kompresi, situs web bisa dimuat lebih cepat lagi.

Saat terhubung ke server, browser web mengirim header seperti kompresi gzip atau Brotli. Data yang dikompresi dengan salah satu dari keduanya dikirim ke browser, dan data terkompresi dimuat lebih cepat daripada data yang tidak dikompresi.

Content-encoding: gzip
Content-encoding: br

File yang dikompresi terutama berupa teks.
· HTML
· CSS
· JavaScript

2️⃣ Apa Itu Kompresi Gzip?

Algoritma kompresi umum yang banyak dipakai oleh penyedia web hosting adalah Gzip dan Brotli. Versi beta Gzip dibuat pada tahun 1992, dan versi 1.0 dirilis pada tahun 1993. Secara umum, Gzip adalah salah satu metode kompresi standar untuk mengompresi data yang dikirim melalui internet. Metode ini didasarkan pada DEFLATE, algoritma kompresi awal, dan namanya diambil dari gzip, program kompresi file Unix yang dikembangkan sebelumnya.

Kompresi DEFLATE adalah metode kompresi yang menggabungkan algoritma LZ77 (Lempel-Ziv 1977) dengan pengodean Huffman. LZ77 mengompresi data dengan mencari data yang berulang untuk menemukan string yang cocok, lalu mengganti string itu dengan kode. Pengodean Huffman mengompresi data dengan memakai frekuensi kemunculan setiap karakter untuk memberikan kode bit yang paling pendek.

Gzip mengompresi data dengan metode DEFLATE, dan melalui header ‘Accept-Encoding: gzip’ pada permintaan dan respons HTTP, kompresi hanya dilakukan jika klien mendukung kompresi Gzip. Dengan kompresi data ini, kecepatan pemuatan situs web bisa ditingkatkan.

3️⃣ Apa Itu Kompresi Brotli?

Kompresi Brotli dikembangkan pada tahun 2013 oleh karyawan Google, Jyrki Alakuijala dan Zoltán Szabadka.

Gzip awalnya dibuat untuk mengompresi file, tetapi kemudian diubah agar bisa dipakai juga di web. Sebaliknya, kompresi Brotli dikembangkan khusus untuk dipakai di web. Karena itu, dengan Brotli, server web dapat mengompresi konten sebelum mengirimkannya ke browser. Karena konten dikompresi sebelum di-stream ke browser, cara ini lebih baik dan lebih maju.

Kompresi Brotli menggunakan dua teknik inti yang sama dengan kompresi GZIP, yaitu LZ77 dan pengodean Huffman.

4️⃣ Kompresi Gzip vs Kompresi Brotli

Gzip mengompresi (& mendekompresi) data dengan metode DEFLATE, sedangkan Brotli memakai format sendiri yang menambahkan pemodelan konteks pada LZ77 dan pengodean Huffman.

• Gzip mengompresi lebih cepat daripada Brotli.
• Brotli dirancang khusus untuk web.
• Brotli memberikan rasio kompresi yang lebih baik (artinya, menghasilkan file terkompresi yang lebih kecil) di semua tingkat kompresi.
• Dibandingkan Gzip, rasio kompresi Brotli untuk 3 jenis file lebih baik, masing-masing HTML 21%, CSS 17%, dan JavaScript 14%.

Server web yang lebih memilih Brotli daripada Gzip makin lama makin banyak. Karena Brotli dirancang untuk mengompresi stream secara langsung, kecepatan dekompresi front-end secara keseluruhan diketahui bisa hingga 64% lebih cepat dibandingkan Gzip.

RFC 1952, yang terbit pada Mei 1996, menjelaskan bahwa format Gzip menggunakan metode kompresi DEFLATE dan menyertakan nilai CRC untuk mendeteksi kerusakan data. Di akhir data terkompresi, dicatat nilai CRC-32 dan ukuran data aslinya.

RFC 7932, yang terbit pada Juli 2016, menyebutkan bahwa Brotli mengompresi dengan menggabungkan algoritma LZ77 dan pengodean Huffman. Selain itu, Brotli memakai dua byte sebelumnya dari data yang belum dikompresi sebagai konteks untuk memilih kode Huffman, dan sebagai ganti string berulang, Brotli juga bisa merujuk kata dalam kamus statis berukuran 122,784 byte.

Kedua format ditandai di header respons sebagai [Content-Encoding: gzip] dan [Content-Encoding: br]. Nilai [br] didaftarkan sebagai content coding HTTP dalam RFC 7932.

5️⃣ Pengukuran Nyata Kompresi Gzip dan Brotli: Server Nginx + Apache

Di server WordPress yang memakai Nginx dan Apache bersamaan, respons untuk satu artikel yang sama, file CSS blok bawaan WordPress, dan file jQuery dibandingkan dengan hanya mengganti header permintaan. Permintaan dengan [Accept-Encoding] berisi gzip saja, berisi br saja, dan tanpa header dikirim dengan curl dari server yang sama.

for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done

== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833

HTML satu artikel dikompresi menjadi 21,390 byte untuk permintaan gzip dan 20,190 byte untuk permintaan br, sedangkan permintaan tanpa header dibalas dengan 90,833 byte tanpa kompresi. Respons br 1,200 byte (5.6%) lebih kecil daripada gzip.

for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done

== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553

Untuk permintaan gzip, file CSS dikompresi menjadi 19,655 byte dan file jQuery menjadi 30,633 byte. Jika hanya br yang diminta atau tanpa header, server mengirim file aslinya apa adanya, yaitu 140,829 byte dan 87,553 byte, tanpa header [Content-Encoding].

nginx -V 2>&1 | grep -c brotli

0

httpd -M 2>/dev/null | grep -E 'brotli|deflate'

 deflate_module (shared)
 brotli_module (shared)

File statis seperti CSS dan JS dilayani dan dikompresi langsung oleh Nginx, dan karena Nginx pada konfigurasi ini tidak memiliki modul Brotli, kompresinya hanya dengan gzip.

Untuk HTML, WordPress menjawab permintaan yang diteruskan Nginx ke Apache, lalu Apache mengompresinya. Apache memiliki modul Brotli sekaligus modul [mod_deflate] yang menangani kompresi Gzip.

for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done

== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633

Adanya modul Brotli di server tidak berarti browser menerima respons yang dikompresi dengan Brotli. Saat permintaan dikirim dengan [gzip, deflate, br, zstd], nilai yang sama dengan yang dikirim Edge 155, Apache juga mengompresi HTML dengan gzip, sehingga ketiga file dikirim dalam gzip.

Meskipun br ditaruh sebelum gzip atau ditandai sebagai prioritas seperti [br;q=1.0, gzip;q=0.5], HTML tetap dikirim dalam gzip. Saat artikel yang sama dan kedua file dibuka di Edge, semuanya juga dikirim dalam gzip.

Waktu byte pertama adalah median nilai [time_starttransfer] curl yang diukur 40 kali masing-masing dengan urutan permintaan diacak; setiap permintaan membuka koneksi baru, sehingga waktu koneksi TLS juga ikut terhitung. Untuk HTML, respons tanpa kompresi 22.7ms, gzip 26.3ms, br 26.5ms, dan permintaan seperti browser 25.0ms. CSS dan JS berada di 18~21ms, dengan atau tanpa kompresi.

Kecepatan kompresi Gzip dan Brotli tidak diukur sendiri, melainkan dibandingkan berdasarkan sumber publik. RFC 7932 menyebutkan bahwa Brotli mengompresi dengan rasio kompresi yang jauh lebih tinggi daripada program gzip, dan mendekompresi jauh lebih cepat daripada implementasi LZMA saat ini. Di repositori Brotli, Google menjelaskan bahwa kecepatan Brotli mirip dengan deflate, tetapi kompresinya lebih padat.

Pada tahun 2015, Cloudflare menguji kedua metode dengan 10,655 file HTML, CSS, dan JavaScript. Hasil Brotli pada kualitas tertinggi rata-rata 1.19 kali lebih kecil daripada zlib pada kualitas tertinggi, tetapi kecepatan kompresinya 0.5MB per detik, jauh lebih lambat daripada 41.9MB pada zlib level 9. Brotli level 4 memiliki rasio kompresi yang mirip dengan zlib level 8 dan sedikit lebih cepat secara rata-rata keseluruhan, tetapi 1.48 kali lebih lambat jika hanya melihat file yang lebih kecil dari 64KB.

Artikel ini telah membahas proses optimasi situs web melalui kompresi file seperti HTML, CSS, dan JavaScript. Untuk meningkatkan kecepatan situs web, kompresi file dan Optimasi Gambar bisa dikatakan termasuk elemen yang wajib ada.

🔢 FAQ & Konten yang Direkomendasikan

ℹ️ Pemberitahuan Afiliasi
Konten di situs ini berisi tautan afiliasi. Jika pengunjung membeli produk atau layanan melalui tautan tersebut, situs ini menerima komisi dari penjual. Harga yang dibayar pembeli^{(turun saat ada diskon promo ↓)}, tidak naik karena hal ini. Harga, diskon, dan informasi stok yang ditampilkan berlaku pada saat penulisan dan bisa berbeda dengan kondisi sebenarnya, jadi pastikan kembali di situs penjual sebelum membeli. Pemilihan dan penilaian produk dibuat berdasarkan standar kami sendiri, dan ada tidaknya komisi tidak memengaruhi urutan maupun isi penilaian.