Kompresi data adalah teknik pengoptimalan performa yang telah teruji oleh waktu yang mengurangi ukuran resource halaman yang memenuhi syarat. Selama beberapa waktu, hal yang umum dilakukan adalah menggunakan gzip di server web untuk mengompresi resource halaman berbasis teks umum, seperti file HTML, CSS, dan JavaScript, dan mengirimkannya ke klien tempat file tersebut dapat didekompresi. Hasilnya adalah waktu pemuatan yang lebih cepat untuk resource tanpa memengaruhi perilaku halaman yang diinginkan.
Meskipun {i>gzip<i} sangat efektif, peningkatan lebih lanjut dalam kompresi di web telah direalisasikan dalam beberapa tahun terakhir. Pada tahun 2016, algoritma Brotli diluncurkan di Chrome, yang memberikan rasio kompresi yang lebih baik secara keseluruhan untuk resource yang memenuhi syarat. Pada akhir tahun 2017, semua browser modern mendukung Brotli, dan dukungan server untuk Brotli mulai meluas. Baru-baru ini, Chrome telah menghadirkan kompresi ZStandard.
Namun, pekerjaan tidak berhenti di situ! Tim Chrome telah berupaya agar kamus bersama dapat digunakan di web, yang kini tersedia dalam uji coba origin untuk Brotli dan ZStandard. Kamus bersama dapat melengkapi kompresi Brotli dan ZStandard untuk memberikan rasio kompresi yang jauh lebih tinggi untuk situs yang sering mengirimkan kode yang diperbarui, dan dapat—dalam beberapa kasus—memberikan rasio kompresi 90% atau lebih baik. Postingan ini membahas lebih detail cara kerja kamus yang dibagikan, dan cara mendaftar ke uji coba origin yang akan digunakan untuk Brotli dan ZStandard di situs Anda.
Penjelasan kamus bersama
Kompresi adalah proses menemukan urutan yang redundan dalam input dan menggunakan informasi tersebut untuk membuat output yang jauh lebih kecil, yang dapat dibatalkan nantinya. Kompresi berfungsi dengan baik di web karena secara substansial mengurangi waktu pemuatan resource. Brotli dan ZStandard dapat lebih meningkatkan efektivitasnya dengan menggunakan kamus kompresi, yang merupakan kumpulan pola tambahan yang dapat digunakan algoritma ini selama kompresi. Bahkan, efisiensi tinggi Brotli dapat dicapai sampai tingkat tertentu dengan menggunakan kamus internal.
Namun, kamus kustom kustom yang diseleksi pengguna dapat digunakan dengan Brotli dan ZStandard yang berisi pola khusus untuk resource tertentu. Dalam praktiknya, kamus khusus adalah file eksternal yang dapat diterapkan ke input apa pun. Kamus bisa sangat spesifik untuk kode produksi aplikasi, atau sangat spesifik konten apa pun. Seberapa berlaku kamus tertentu terhadap inputnya, dapat berdampak besar terhadap efisiensi kompresi secara keseluruhan. Kamus yang sangat mirip dengan konten input akan menghasilkan output dengan rasio kompresi lebih tinggi daripada kamus dengan konten generik atau berbeda.
Berikut adalah contoh seberapa efektif kamus kompresi kustom: katakanlah situs Anda menggunakan framework Angular, dan versi saat ini yang Anda gunakan adalah versi 1.7.9. Versi framework Angular ini berukuran sekitar 172 KiB tanpa dikompresi. Ketika dikompresi dengan pengaturan default Brotli, ukurannya menjadi sekitar 53 KiB. Cara ini menghasilkan rasio kompresi hampir sebesar 70%. Namun, katakanlah Anda memutuskan untuk mengupgrade ke Angular 1.8.3 nanti. Mengingat bahwa versi Angular ini kira-kira berukuran sama dengan versi 1.7.9, Anda dapat mengharapkan rasio kompresi yang hampir sama dengan versi sebelumnya.
Di sinilah kamus khusus dapat berguna dengan menggunakan proses yang dikenal sebagai kompresi delta , yaitu saat kamus dari versi resource sebelumnya dapat digunakan untuk mengompresi versi yang lebih baru. Menggunakan contoh sebelumnya, jika Anda mengompresi versi 1.8.3 dari Angular menggunakan versi 1.7.9 sebagai kamus, outputnya akan lebih dari 4 KiB. Ini mewakili rasio kompresi hampir 98%. Jelas, kamus kompresi dapat memberikan dampak besar pada performa pemuatan, dan efektivitasnya telah terwujud dalam aplikasi dunia nyata.
Namun, ada tantangan dalam membuat alur ini berfungsi di web. Jawabannya adalah, jika Anda menggunakan kamus untuk mengompresi resource, Anda memerlukan kamus yang sama untuk mendekompresi resource tersebut. Alur ini telah dicoba di web sebelumnya—yaitu SDCH—tetapi sulit untuk diterapkan dengan aman. Proposal terbaru untuk kompresi kamus bersama ini mengatasi masalah tersebut sekaligus memberikan manfaat besar untuk resource statis dan dinamis.
Cara Chrome mengiklankan dukungan untuk kamus bersama
Semua browser mengiklankan algoritma kompresi yang didukungnya melalui header permintaan Accept-Encoding. Konten header adalah daftar encoding yang didukung yang dipisahkan koma:
Accept-Encoding: gzip, br, zstd
Header Accept-Encoding ini menyatakan bahwa browser yang meminta resource mendukung algoritma kompresi gzip, Brotli, dan ZStandard. Server web yang merespons permintaan kemudian dapat memutuskan algoritma mana yang akan digunakan saat merespons permintaan tersebut.
Jika dukungan kamus bersama diaktifkan dan kamus yang relevan tersedia untuk resource, token tambahan akan ditambahkan ke header Accept-Encoding. Token ini adalah br-d untuk Brotli dan zstd-d untuk Zstandard. Chrome juga akan menyertakan hash kamus yang tersedia, yang akan dibahas selanjutnya.
Accept-Encoding: gzip, br, zstd, br-d, zstd-d
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Jika server web dikonfigurasi untuk mengenali token ini, dan mengenali kamus, server web dapat merespons permintaan tersebut dengan sumber daya yang dikompresi menggunakan kamus untuk pengkodean yang berlaku. Cara mencapai hal ini dalam praktiknya bergantung pada apakah permintaan tersebut untuk resource statis atau dinamis.
Kompresi kamus bersama untuk resource statis
Resource halaman statis adalah resource yang selalu menghasilkan respons yang sama untuk URL yang diminta. Contoh umum resource halaman statis yang dapat dikompresi adalah file JavaScript dan CSS. Resource ini biasanya diberi versi untuk keperluan cache dengan cara tertentu—terkadang dengan hash konten file dalam nama file (misalnya styles.abcd1234.css), atau metode lain untuk melakukan pelacakan resource. Jenis resource ini adalah kandidat bagus untuk kompresi delta yang disediakan kamus bersama, karena resource statis sering di-cache untuk jangka waktu yang lama dan cenderung diperbarui dengan beberapa frekuensi.
Kamus dapat ditentukan untuk resource statis dengan menyetel header respons Use-As-Dictionary untuk resource tersebut. Header mengambil salah satu dari beberapa key-value pair, tetapi satu-satunya yang diperlukan adalah match, yang menerima sintaksis URLPattern yang menentukan jalur resource tempat kamus harus digunakan:
Use-As-Dictionary: match="/dist/styles.*.css"
Anggaplah header Use-As-Dictionary sebagai mekanisme yang berlaku untuk versi resource mendatang yang cocok dengan pola yang ditentukan di dalamnya. Jadi, anggap saja situs Anda mengirimkan semua gayanya dalam satu file CSS. Untuk memudahkan, misalkan versi pertama resource tersebut terletak di /dist/styles.v1.css, dan dikirim dengan header respons Use-As-Dictionary yang berisi nilai match /dist/styles.*.css.
Setelah beberapa waktu, Anda harus memperbarui CSS situs dan mengirimkan versi barunya yang terletak di /dist/styles.v2.css. Karena nilai match yang digunakan dalam header respons Use-As-Dictionary dari versi sebelumnya berlaku untuk permintaan ini, browser akan mengirim header Available-Dictionary yang berisi hash kamus yang dienkode sebagai urutan byte kolom terstruktur:
Accept-Encoding: gzip, br, zstd, br-d, zstd-d
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Pada tahap ini, server dapat mengonfigurasi kompresi di ujungnya untuk memastikan kamus yang cocok digunakan. Resource yang dikompresi dengan kamus tersebut akan dikirim, dan kamus yang tersedia dalam cache browser pengguna akan digunakan untuk melakukan dekompresi.
Jika Anda sering mengirimkan kode baru untuk situs Anda, kompresi delta dapat sangat bermanfaat. Namun, prosesnya fleksibel. Jika browser tidak menentukan apakah kamus tersedia di cache browser pengguna, browser tidak akan menentukan token br-d atau zstd-d tambahan di header Accept-Encoding. Dalam hal ini, alur kompresi standar akan berlaku.
Kompresi kamus bersama untuk resource dinamis
Resource dinamis juga dapat memanfaatkan kompresi kamus bersama. Resource dinamis adalah resource yang berubah berdasarkan konteks, misalnya situs berita yang halaman utamanya sering diperbarui sebagai berita terbaru. Dokumen HTML sering kali merupakan resource dinamis. Jika demikian, kamus dapat berisi sebagian besar struktur HTML umum dan kode template situs yang mengarah ke halaman terkompresi, yang hanya mengirim bagian unik dari setiap halaman.
Karena sifat dari resource yang dibuat secara dinamis, kamus harus dimuat pada klien untuk digunakan nanti. Memuat kamus terlebih dahulu berarti menerapkan kompresi kamus bersama ke resource dinamis bersifat spekulatif. Harapan dalam kasus seperti itu adalah bahwa situs web Anda menerima lalu lintas yang cukup sehingga biaya kamus dapat diamortisasi melalui sejumlah besar navigasi. Jika Anda memutuskan untuk mencobanya, langkah pertama adalah menentukan lokasi kamus melalui elemen <link> di HTML halaman Anda:
<link rel="dictionary" href="/dictionary.dat">
Saat menemukan elemen <link> ini, Chrome dapat mengambil kamus setelah halaman tidak ada aktivitas, dan pada prioritas rendah sebagai upaya untuk menghindari pertentangan bandwidth. Respons untuk kamus itu sendiri harus menentukan header Use-As-Dictionary dan menentukan jalur resource dinamis mana yang berlaku:
Use-As-Dictionary: match="/product/*"
Dari sini, alurnya sebagian besar sama dengan alur untuk sumber daya statis. Browser akan melihat bahwa kamus itu sendiri berlaku untuk resource yang cocok, dan browser akan melampirkan header Available-Dictionary ke permintaan dengan hash konten kamus, sekali lagi, mirip dengan alur resource statis yang dijelaskan sebelumnya.
Mengompresi resource statis pada waktu build
Jika sudah terbiasa dengan pemaket, Anda mungkin familier dengan berbagai plugin untuknya yang dapat mengompresi resource pada waktu build, lalu menyalurkan resource yang dikompresi tersebut. Misalnya, Apache memungkinkan Anda menggunakan perintah untuk menyalurkan resource yang telah dikompresi tersebut pada saat permintaan.
Sebagian besar pemaket berbasis Node.js yang mendukung kompresi menggunakan library Zlib bawaan Node. Zlib menawarkan dukungan untuk Brotli dan pemaket yang menggunakannya yang biasanya menawarkan antarmuka untuk meneruskan opsi langsung ke Zlib, yang mendukung kompresi berbantuan kamus. Berikut adalah beberapa pemaket yang mendukung penggunaan kamus:
CompressionWebpackPluginwebpack, melalui antarmukacompressionOptions-nya.rollup-plugin-brotlimenawarkan konfigurasioptionsyang langsung mengarah ke Zlib di Node.js, tempat kamus dapat ditentukan.- Plugin pihak ketiga
esbuild-plugin-compressuntuk esbuild juga menawarkan akses ke opsi Zlib di Node.js.
Perhatikan bahwa kamus yang tersedia untuk setiap versi sumber daya tertentu mungkin menggunakan salah satu versi sumber daya sebelumnya. Ini berarti Anda perlu menganalisis traffic pengguna dan membuat rencana yang sesuai. Targetkan keseimbangan dan hasilkan sumber daya yang paling bermanfaat bagi jumlah maksimum pengguna yang kembali. Penyedia CDN saat ini bereksperimen dengan kompresi kamus bersama. Belum ada implementasi yang tersedia untuk penggunaan publik, tetapi kami berharap dapat berubah.
Cobalah!
Mengintegrasikan kompresi kamus bersama dengan kemampuan kompresi yang ada di browser berpotensi meningkatkan performa pemuatan secara signifikan untuk situs yang sering mengirim kode produksi yang diperbarui dan menerima traffic yang signifikan dari pengunjung yang kembali. Jika tertarik untuk mencoba kompresi kamus bersama, Anda memiliki dua opsi:
- Jika Anda hanya ingin mengotak-atik kompresi kamus bersama untuk mengetahui cara kerjanya, Anda dapat mengaktifkan fitur eksperimental Transpor kamus kompresi di halaman
chrome://flags. - Jika Anda tertarik untuk mencobanya di situs produksi dan ingin mengetahui manfaat kompresi kamus bersama, daftar ke uji coba origin untuk mendapatkan token, dan baca cara kerja uji coba origin.
Kesimpulan
Kami cukup antusias dengan kemajuan besar dalam teknologi kompresi di web ini, dan kecepatannya membuat aplikasi yang ada yang digunakan orang setiap hari. Sebaiknya Anda mencobanya. Dan yang terpenting, kami ingin mendengar pendapat Anda jika Anda tertarik. Jika Anda menemukan bug, laporkan di crbug.com. Untuk referensi dan alat tambahan, lihat use-as-dictionary.com. Terakhir, jika Anda ingin mempelajari lebih dalam cara kerjanya, penjelasan adalah langkah berikutnya.