👩🏼 🤫 🤳 Efisiensi Brotli di Dunia Nyata 🔣 🧖🏿 👨‍🎓

Salah satu aturan paling mendasar untuk mengembangkan situs web cepat adalah mengoptimalkan sumber dayanya. Jika kita berbicara tentang sumber daya teks - tentang kode yang ditulis dalam HTML, CSS dan JavaScript, ini berarti bahwa kita berbicara tentang kompresi data. Standar de facto untuk mengompresi sumber daya teks di web adalah metode Gzip. Yaitu, sekitar 80% dari sumber daya terkompresi yang diperoleh selama unduhan situs dikompres menggunakan Gzip. Untuk mengompresi sisa 20% sumber daya, digunakan algoritma yang jauh lebih baru - Brotli.

Tentu saja, 100% dari sumber daya terkompresi ini yang masuk ke browser ketika mereka menerima jawaban atas permintaan ke situs tidak termasuk semua sumber daya. Masih banyak sumber daya yang dapat dikompresi, atau yang dapat dikompresi. Tetapi sumber daya ini tetap tidak terkompresi. Metrik yang lebih rinci tentang kompresi dapat ditemukan di bagian Kompresi sumber daya Web Almanac.

Metode kompresi gzip sangat efisien. Pekerjaan All Shakespeare dalam teks biasa membutuhkan 5,3 MB. Dan setelah Gzip-kompresi (level kompresi 6) mereka hanya menempati 1,9 MB. Ini berarti bahwa ukuran file di mana data ini disimpan telah berkurang 2,8 kali. Pada saat yang sama, data tidak hilang selama kompresi. Bagus!

Bahkan lebih baik, tingkat kompresi Gzip dipengaruhi oleh adanya garis duplikat dalam file. Semakin banyak pengulangan dalam teks, semakin efisien kompresi. Ini sangat baik untuk web, karena kode yang ditulis dalam HTML, CSS dan JS memiliki sintaks yang seragam dan berisi banyak pengulangan.

Tapi, meskipun Gzip adalah metode kompresi yang sangat efisien, Gzip juga cukup lama. Itu muncul pada tahun 1992 (yang, tentu saja, membantu menjelaskan prevalensi yang meluas). Setelah 21 tahun, pada 2013, Google merilis Brotli, sebuah algoritma baru yang menjanjikan tingkat kompresi yang lebih tinggi daripada yang mampu dilakukan oleh metode Gzip. Karya-karya yang sama dari Shakespeare 5,2 MB dalam ukuran dikompres menggunakan Brotli ke ukuran 1,7 MB (dengan tingkat kompresi 6). Dan ini berarti pengurangan ukuran file 3,1 kali lipat. Ini bahkan lebih baik daripada menggunakan Gzip.

Menggunakan alat untuk memperkirakan tingkat kompresi data menggunakan Gzip dan Brotli, Anda cenderung mengetahui bahwa saat mengompresi beberapa data, Brotli jauh lebih efisien daripada Gzip. Sebagai contoh, data ReactDOM adalah 27% lebih kecil ketika dikompres menggunakan Brotli dengan tingkat kompresi maksimum (11) dibandingkan saat menggunakan Gzip dengan tingkat kompresi maksimum (9).

Berikut ini adalah perbandingan kompresi Brotli dengan kompresi Gzip saat memproses ReactDOM.

Tingkat kompresi	Ukuran (dalam byte)	Efisiensi Kompresi (Dibandingkan dengan Data yang Tidak Terkompresi)	% Peningkatan dibanding Gzip
1	43456	2.73	3%
2	39898	2.97	sebelas%
3	39416	3.08	lima belas%
4	38488	3.08	lima belas%
5	36323	3.27	sembilan belas%
6	36048	3.29	dua puluh%
7	35804	3.31	dua puluh%
8	35709	3.32	21%
9	35659	3.33	21%
10	33590	3.53	25%
sebelas	33036	3.59	27%

Seperti yang Anda lihat, pada semua level kompresi, Brotli mem-bypass Gzip. Pada tingkat kompresi maksimum yang tersedia dengan Brotli, ini 27% lebih efisien daripada Gzip.

Dan, berdasarkan pengamatan pribadi, saya perhatikan bahwa transisi dari salah satu klien saya dari Gzip ke Brotli menghasilkan pengurangan median ukuran file sebesar 31%.

Akibatnya, selama beberapa tahun terakhir, saya, bersama dengan pakar kinerja lainnya, telah mendorong pelanggan untuk beralih dari Gzip ke Brotli.

Saya akan mengatakan beberapa kata tentang dukungan browser untuk Gzip dan Brotli. Gzip begitu luas sehingga CanIUse bahkan tidak menampilkan tabel dengan informasi dukungan. Dikatakan demikian: "Header HTTP ini didukung di hampir semua browser (dimulai dengan IE6 +, Firefox 2+, Chrome 1+, dan sebagainya)." Dan Brotli, saat menulis materi ini, menikmati tingkat dukungan yang sangat menyenangkan .pada 93,17%. Dan ini sangat, sangat banyak! Jadi, jika situs Anda memiliki setidaknya beberapa ukuran yang signifikan, Anda mungkin tidak suka pengembalian sumber daya yang tidak terkompresi ke lebih dari 6% pengguna Anda. Tetapi menggunakan Brotli, Anda tidak akan kehilangan apapun. Pelanggan menggunakan model progresif dukungan untuk algoritma baru, sehingga pengguna yang tidak dapat menerima sumber daya Brotli hanya akan menggunakan opsi mundur dalam bentuk Gzip. Kami akan berbicara lebih banyak tentang ini di bawah ini.

Secara umum, terutama jika Anda menggunakan CDN, menyalakan Brotli hanya beberapa detik. Setidaknya demikian halnya dengan Cloudflare, layanan yang saya gunakan untuk situs CSS Wizardry. Namun, banyak klien saya, jika kita berbicara tentang beberapa tahun terakhir, tidak begitu berhasil. Beberapa dari mereka mendukung infrastruktur mereka sendiri, dan praktik menunjukkan bahwa menginstal dan menggunakan Brotli tidak sesederhana itu. Beberapa menggunakan layanan CDN yang tidak berbeda dalam kemampuan yang mudah diakses untuk mendukung algoritma baru.

Dalam kasus-kasus ketika kami tidak dapat beralih ke Brotli, kami selalu memiliki pertanyaan yang tidak terjawab: "Bagaimana jika ...". Akibatnya, saya akhirnya memutuskan untuk mempersenjatai diri dengan angka-angka dan memberikan jawaban atas pertanyaan apa yang membuat situs tersebut beralih ke Brotli.

Kurang belum tentu lebih cepat.

Namun, biasanya "kurang" berarti "lebih cepat." Sebagai aturan, jika Anda mengurangi ukuran file, itu akan ditransfer lebih cepat dari server ke klien. Tetapi jika Anda membuat file, katakanlah, 20% lebih kecil, ini tidak berarti bahwa itu akan tiba 20% lebih cepat. Intinya di sini adalah bahwa ukuran file hanyalah salah satu aspek dari kinerja web. Dan berapapun ukuran file, sumber daya yang dikirimkan ke browser dikaitkan dengan banyak faktor lain dan dengan banyak keterbatasan sistem - keterlambatan jaringan, kehilangan paket, dan sejenisnya. Dengan kata lain, menghemat ukuran file membantu mentransfer data yang sama seperti sebelumnya, mengirimkan lebih sedikit paket, tetapi transfer data antara server dan klien dibatasi oleh penundaan jaringan, akibatnya, kecepatan paket yang tiba di klien akan lebih kecil tidak akan berubah.

TCP, paket, keterlambatan pulang pergi

Jika sangat sederhana untuk mempertimbangkan mentransfer file dari server ke klien, kita harus melihat pada protokol TCP. Ketika kami menerima file dari server, itu tidak datang kepada kami dalam sekali jalan. Protokol TCP, di atas mana HTTP berfungsi, memecah file menjadi segmen yang disebut paket. Paket-paket ini dikirim ke klien secara berurutan. Klien mengonfirmasi penerimaan setiap paket dalam seri sebelum memulai transfer seri berikutnya. Ini terjadi sampai klien mengumpulkan semua paket yang diperlukan, sampai tidak ada paket yang belum terkirim di server, dan sampai klien dapat mengumpulkan paket menjadi sesuatu yang dapat dikenali sebagai file. Agar sesi transfer urutan paket berhasil diselesaikan, server harus mengirimnya ke klien, dan klien harus mengakui tanda terima mereka. Waktu,Jumlah data yang diperlukan untuk menerima data dan menerima konfirmasi penerimaan disebut Round Trip Time (RTT).

Setiap koneksi TCP baru tidak dapat mengetahui bandwidth yang tersedia, dan seberapa andal koneksi tersebut (yaitu, berapa tingkat kehilangan paket). Jika server mencoba mengirim megabyte data melalui koneksi yang mendukung kecepatan transfer data satu megabit per detik, transfer semacam itu akan membanjiri koneksi dan menyebabkan kelebihan saluran komunikasi. Dan sebaliknya - jika server mencoba untuk mentransfer sejumlah kecil data melalui koneksi yang sangat cepat, koneksi akan digunakan secara tidak efisien, itu akan diam.

Untuk memecahkan teka-teki ini, TCP menggunakan mekanisme yang disebut slow start. Ini adalah bagian dari strategi manajemen jendela kelebihan. Setiap koneksi TCP baru dibatasi oleh kemampuan untuk mengirim hanya 10 paket data dalam urutan pertama paket (10 paket - ukuran jendela kongesti awal). Sepuluh segmen TCP adalah sekitar 14 KB data. Jika paket-paket ini berhasil diterima oleh klien, seri kedua sudah akan berisi 20 paket, maka akan ada 40, 80, 160 dan seterusnya. Pertumbuhan paket secara berurutan akan berlanjut sampai salah satu dari peristiwa berikut terjadi:

Sistem akan menghadapi kehilangan paket. Pada titik ini, server akan mengurangi jumlah paket dalam urutan berikut, membagi jumlah paket sebelumnya dengan 2, dan mencoba mentransfer data lagi.
Kami telah mencapai batas bandwidth yang tersedia dan dapat menggunakannya dengan kapasitas penuh.

Strategi sederhana dan elegan ini memungkinkan Anda untuk menyeimbangkan di ambang kehati-hatian dan optimisme. Ini berlaku untuk setiap koneksi TCP baru yang dibuat oleh aplikasi web.

Dengan kata sederhana, ukuran awal jendela kongesti koneksi TCP baru hanya sekitar 14 Kb. Atau sekitar 11,8% dari data ReactDOM yang tidak terkompresi. Baik 36,94% dari data yang dikompres menggunakan Gzip, atau 42,38% dari data yang dikompres menggunakan Brotli (pada tingkat kompresi maksimum).

Dan kemudian kita akan melambat. Transisi dari 11,8% menjadi 36,94% sudah merupakan peningkatan yang sangat nyata! Tetapi transisi dari 36,94% menjadi 42,38% - ini jauh dari mengesankan. Apa yang terjadi?

Nomor Sesi Data	Jumlah data yang ditransfer dalam satu sesi, Kb	Jumlah kumulatif data yang ditransfer, Kb	Urutan di mana data ReactDOM ditransfer
1	14	14
2	28	42	Gzip (37,904 Kb), Brotli (33,036 Kb)
3	56	98
4	112	210	Opsi tidak terkompresi (118.656 Kb)
5	224	434

Ternyata kedua data yang dikompres dengan Gzip dan data yang dikompres dengan Brotli ditransmisikan dalam seri paket yang sama. Mentransfer file membutuhkan dua urutan. Jika RTT ternyata cukup seragam ketika mentransmisikan semua urutan, ini berarti bahwa dibutuhkan waktu yang sama untuk mengirimkan data yang dikompres menggunakan Gzip dan Brotli. Di sisi lain, mentransfer versi data yang tidak terkompresi membutuhkan empat seri paket, bukan dua. Dan ini, terutama pada koneksi dengan latensi jaringan yang tinggi, dapat menghasilkan waktu yang agak mencolok untuk transfer data.

Saya cenderung di sini untuk fakta bahwa kecepatan transfer data tidak hanya tergantung pada ukuran file. Itu dipengaruhi oleh fitur fungsi protokol TCP. Kami tidak hanya perlu membuat file lebih kecil. Kita perlu membuatnya lebih kecil, membawanya ke ukuran yang akan memungkinkan mereka untuk ditransmisikan dalam urutan paket yang lebih sedikit.

Ini berarti, secara teori, bahwa agar algoritme Brotli menjadi lebih efisien daripada Gzip, ia harus mampu mengompres data jauh lebih agresif. Ini diperlukan agar data dapat ditransmisikan dalam urutan paket yang lebih sedikit daripada saat menggunakan Gzip. Dan saya tidak tahu bagaimana algoritma ini akan berkembang ...

Perlu dicatat bahwa model di atas cukup disederhanakan. Ada banyak faktor lain yang perlu dipertimbangkan. Misalnya - apakah ini koneksi TCP yang baru atau sudah terbuka? Apakah koneksi sedang digunakan untuk sesuatu yang lain? Apakah mekanisme prioritas lalu lintas server berhenti dan memulai transfer data? Apakah stream H / 2 memiliki akses eksklusif ke bandwidth? Bagian ini adalah studi yang lebih serius. Ini harus dianggap sebagai titik awal yang baik untuk penelitian Anda sendiri. Tetapi pertimbangkan untuk menganalisis data secara menyeluruh menggunakan sesuatu seperti Wireshark, dan baca materi ini , yang memberikan deskripsi yang lebih dalam tentang "sihir" pertama 14 Kb.

Di atas hanya berlaku untuk koneksi TCP baru. File yang ditransfer melalui koneksi yang ada tidak akan melalui prosedur mulai lambat. Ini membawa kita pada dua kesimpulan penting:

Saya pikir itu tidak layak diulang, tetapi saya akan ulangi: sumber daya statis harus di-host. Ini adalah cara yang bagus untuk menghindari penundaan mulai lambat, karena menggunakan server Anda sendiri, yang sudah "menghangat" berarti bahwa paket yang meninggalkan server ini memiliki akses ke bandwidth yang lebih luas. Kesimpulan ini membawa saya ke kesimpulan kedua.
, , . , . .

	, ,	,
1	14	14
2	28	42
3	56	98
4	112	210
5	224	434
6	448	882
7	896	1778
8	1792	3570
9	3584	7154
10	7168	14322
…	…	…
20	7340032	14680050

Pada akhir sesi transfer data ke-10, jumlah data yang ditransfer dalam satu sesi adalah 7168 Kb, sementara total 14322 Kb data telah ditransfer. Ini lebih dari cukup untuk pekerjaan biasa di Internet (yaitu, bukan untuk melihat Game of Thrones). Bahkan, biasanya terjadi bahwa kita memuat seluruh halaman web dan semua sumber dayanya tanpa mencapai batas bandwidth kita. Dengan kata lain, menggunakan saluran komunikasi serat optik 1 Gbit / s (yaitu, 0,125 GB / s) tidak akan membuat penelusuran normal tampak lebih cepat daripada menggunakan koneksi yang lebih lambat, karena sebagian besar saluran ini bahkan tidak akan digunakan.

Dan pada sesi transfer data ke-20, kami secara teoritis mentransfer 7,34 GB data dalam satu urutan paket.

Bagaimana dengan dunia nyata?

Sejauh ini, kami telah terlibat dalam pertimbangan teoritis. Dan saya mulai mengerjakan materi ini karena saya ingin tahu tentang dampak yang dapat ditimbulkan oleh Brotli di situs nyata.

Sejauh ini, angka yang diberikan di sini telah menunjukkan perbedaan besar antara kurangnya kompresi dan penggunaan Gzip, dan fakta bahwa keuntungan dari menggunakan Brotli, dibandingkan dengan Gzip, cukup sederhana. Ini memberitahu kita bahwa transisi dari kurangnya kompresi ke penggunaan Gzip akan memberikan peningkatan yang nyata, sementara transisi dari Gzip ke Brotli mungkin terlihat jauh lebih mengesankan.

Saya memilih, sebagai contoh, beberapa situs, dipandu oleh pertimbangan berikut:

Situs harus relatif terkenal (lebih baik menggunakan situs yang dapat dibandingkan dengan sesuatu).
Situs harus sesuai untuk pengujian. Artinya - ukurannya harus sesuai (sehingga akan lebih menarik untuk menganalisis materialnya untuk kompresi), dan pada saat yang sama tidak boleh mengandung terutama bahan yang tidak dikompresi menggunakan Gzip / Brotli - seperti, misalnya, YouTube.
Tidak semua situs dari koleksi harus milik perusahaan besar (ada baiknya menganalisis beberapa, katakanlah, situs "biasa").

Dengan persyaratan ini, saya memilih situs yang tercantum di bawah ini dan mulai menguji. Berikut adalah situs yang saya pilih:

Saya tidak ingin mempersulit tes, jadi saya menentukan indikator berikut:

Jumlah data yang ditransfer.
Waktu cat konten pertama (FCP).

Mereka dianalisis dalam situasi berikut:

Kurangnya kompresi.
Menggunakan gzip.
Menggunakan brotli.

Metrik FCP terlihat dekat dengan dunia nyata dan cukup universal untuk aplikasinya ke situs mana pun, karena memungkinkan Anda untuk mengevaluasi apa yang orang butuhkan dari situs web - yaitu, isi situs-situs ini. Selain itu, saya memilih metrik ini karena Paul Calvano , orang yang cerdas, mengatakan ini: "Pengalaman memberi tahu saya bahwa menggunakan Brotli mengarah pada peningkatan FCP, terutama ketika sumber daya CSS / JS kritis besar" .

Pengujian

Aku akan memberitahumu satu rahasia kotor. Banyak studi tentang kinerja web (tidak semua, tetapi banyak) tidak didasarkan pada penelitian tentang peningkatan kinerja, tetapi pada menarik kesimpulan dari yang berlawanan - dari penurunan kinerja. Sebagai contoh, BBC jauh lebih mudah untuk mengklaim bahwa "mereka kehilangan 10% pengguna untuk setiap detik yang mereka butuhkan untuk memuat situs mereka" daripada mengetahui apa yang terjadi berkat peningkatan satu detik. Jauh lebih mudah untuk memperlambat situs daripada mempercepatnya, dan Anda merasa bahwa inilah sebabnya banyak orang melakukan pekerjaan ini dengan sangat baik.

Mengingat hal ini, saya tidak mencoba untuk mengunduh situs yang menggunakan Gzip, dan kemudian, offline, memampatkan isinya menggunakan Brotli. Sebagai gantinya, saya menemukan situs yang menggunakan Brotli, dan kemudian mematikan kompresi. Saya beralih dari Brotli ke Gzip, dan kemudian dari Gzip ke non-kompresi, mengukur cara kerjanya di situs.

Meskipun saya tidak bisa, katakanlah, terhubung ke server Linkedin dan putuskan sambungan Brotli, saya cukup mengakses situs ini dari peramban yang tidak mendukung Brotli. Meskipun saya tidak dapat menonaktifkan dukungan Brotli di Chrome, saya dapat menyembunyikan dari server fakta bahwa browser saya mendukung Brotli. Browser memberi tahu server algoritma kompresi yang mereka dukung menggunakan header permintaancontent-encoding. Menggunakan Webpagetest, saya dapat menyesuaikan header sendiri. Jadi, semuanya sangat sederhana!

Fitur-fitur canggih dari WebPageTest memungkinkan kita untuk mengatur header permintaan kustom.

Berikut cara saya mengatur bidang Header Kustom:

Shutdown yang lengkap kompresi: accept-encoding: randomstring.
Menonaktifkan brötli, namun dukungan Gzip: accept-encoding: gzip.
Untuk menggunakan Brotli jika metode kompresi ini didukung oleh situs (dan asalkan didukung oleh browser): bidangnya tetap kosong.

Anda dapat mengetahui apakah ini berfungsi sebagaimana dimaksud dengan memeriksa ada (atau tidaknya) header content-encodingdi respons server.

hasil

Seperti yang diharapkan, transisi dari kurangnya kompresi ke Gzip berarti peningkatan yang signifikan, tetapi transisi dari Gzip ke Brotli tidak terlihat begitu mengesankan. Data mentah dari percobaan saya dapat ditemukan di sini . Berikut ini adalah temuan yang paling menarik minat saya:

Gzip : 73%.
FCP Gzip : 23.305%.
Brotli Gzip: 5.767%.
FCP Brotli Gzip: 3.462%.

Ini semua adalah nilai median. Berbicara tentang "ukuran materi," Maksud saya hanya HTML, CSS, dan JavaScript.

Berkat penggunaan Gzip, ukuran file berkurang 73% dibandingkan dengan versi yang tidak terkompresi. Dan penggunaan Brotli memungkinkan mengurangi ukuran file hanya dengan tambahan 5,7%. Jika kita berbicara tentang FCP, terima kasih kepada Gzip indikator ini meningkat sebesar 23% dibandingkan dengan kurangnya kompresi, dan Brotli menambahkan hanya 3,5% tambahan untuk ini.

Meskipun tampaknya hasil tersebut memperkuat teori, ada beberapa cara untuk meningkatkan hasil ini. Yang pertama adalah menguji jumlah situs yang jauh lebih besar, saya ingin membahas dua situs lebih detail.

Data sumber daya sendiri dan data dari sumber eksternal

Dalam pengujian saya, saya mematikan Brotli di mana-mana, dan tidak hanya untuk server yang menyimpan data situs. Ini berarti bahwa saya mengukur tidak hanya manfaat yang diperoleh situs dari menggunakan Brotli, tetapi, dalam hal potensi, manfaat yang diperoleh Brotli dari sumber eksternal yang digunakan situs ini. Ini masuk dalam ruang lingkup kepentingan kami hanya jika sumber daya pihak ketiga digunakan dengan cara kritis dari situs yang sedang diselidiki, tetapi ini patut diingat.

Tingkat kompresi

Berbicara tentang kompresi, kita sering membahas hasil yang diperoleh dengan skenario aplikasi kompresi terbaik. Yaitu - saat menggunakan Gzip, kami memiliki tingkat kompresi ke-9, dan saat menggunakan Brotli - tingkat ke-11. Namun, kecil kemungkinan server yang sedang diselidiki akan dikonfigurasikan dengan cara yang paling optimal. Sebagai contoh, Apache menggunakan kompresi level 6 gzip, sedangkan NGINX hanya menggunakan yang pertama.

Menonaktifkan Brotli berarti kita beralih ke opsi mundur, ke Gzip, dan mengingat cara saya menguji situs, saya tidak bisa mengubah konfigurasi mundur atau bertindak entah bagaimana. Saya mengatakan ini karena bahan dari dua situs dalam tes sebenarnya bertambah besar ketika Brotli dinyalakan. Ini menunjukkan kepada saya bahwa tingkat kompresi Gzip sedemikian rupa sehingga memberikan kompresi yang lebih kuat daripada tingkat kompresi Brotli.

Memilih tingkat kompresi adalah kompromi. Semua orang ingin meminta tingkat kompresi tertinggi dan dalam hal ini masalah tersebut terselesaikan. Tetapi pendekatan semacam itu tidak praktis. Faktanya adalah bahwa waktu tambahan yang diperlukan server untuk melakukan kompresi ini secara dinamis sangat mungkin meniadakan manfaat dari tingkat kompresi yang lebih tinggi. Untuk mengatasi masalah ini, Anda dapat menggunakan yang berikut:

Anda dapat menggunakan tingkat kompresi pragmatis yang memberikan keseimbangan kecepatan dan efisiensi yang tepat selama kompresi data dinamis.
Anda dapat mengunggah sumber daya statis pra-kompresi ke server, yang tingkat kompresinya lebih tinggi daripada yang digunakan untuk kompresi dinamis. Dalam hal ini, untuk memilih tingkat kompresi dinamis, Anda dapat menggunakan ide yang diuraikan dalam paragraf pertama.

Ringkasan

Orang mendapat kesan bahwa, dengan alasan yang masuk akal, orang dapat mengenali tidak pentingnya keunggulan Brotli dibandingkan Gzip.

Jika mengaktifkan dukungan Brotli adalah masalah beberapa gerakan mouse di panel kontrol CDN Anda, maka Anda harus mengambil Brotli dan menyalakannya sekarang. Dukungan untuk algoritma kompresi ini cukup luas, browser yang tidak mendukung Brotli dengan mudah beralih ke mekanisme cadangan, dan bahkan sedikit peningkatan lebih baik daripada tidak sama sekali.

Jika memungkinkan, unggah sumber daya statis yang dipadatkan pada tingkat kompresi maksimum ke server. Dan untuk kompresi dinamis, gunakan bukan yang tertinggi, tetapi bukan tingkat kompresi terendah. Jika Anda menggunakan NGINX, pastikan Anda tidak menggunakan kompresi tingkat pertama standar untuk NGINX.

Namun, jika untuk menggunakan Brotli, Anda mungkin perlu beberapa minggu pengembangan, pengujian dan penyebaran, jangan panik - pastikan untuk menggunakan kompresi Gzip untuk semua yang dapat dikompresi (ini termasuk, di samping sumber daya teks, file .ico dan .ttf - jika mereka, tentu saja, digunakan dalam proyek Anda).

Saya kira versi singkat dari artikel ini mungkin terlihat seperti ini: jika Anda tidak boleh atau tidak dapat mengaktifkan Brotli, Anda tidak akan kehilangan begitu banyak.

Pembaca yang budiman! Apakah Anda berencana menggunakan Brotli?

Efisiensi Brotli di Dunia Nyata