Apa yang disarankan ukuran objek minimum untuk manfaat kinerja gzip?

Saya sedang bekerja untuk meningkatkan waktu tampilan kecepatan halaman, dan salah satu metode adalah untuk gzip konten dari server web.

Google merekomendasikan :

Perhatikan bahwa gzipping hanya bermanfaat untuk sumber daya yang lebih besar. Karena overhead dan latensi kompresi dan dekompresi, Anda hanya boleh gzip file di atas ambang ukuran tertentu; kami merekomendasikan kisaran minimum antara 150 dan 1000 byte. Gzipping file di bawah 150 byte sebenarnya bisa membuatnya lebih besar.

Kami melayani konten kami melalui Akamai , menggunakan jaringan mereka untuk proxy dan CDN. Apa yang mereka katakan kepada saya:

Menindaklanjuti pertanyaan Anda mengenai berapa ukuran minimum Akamai akan mengkompres objek yang diminta saat mengirimnya ke pengguna akhir: Ukuran minimum adalah 860 byte.

Balasan saya:

Apa alasan mengapa ukuran minimum Akamai adalah 860 byte? Dan mengapa, misalnya, bukankah ini kasus untuk file yang dilayani Akamai untuk Facebook? ( lihat di bawah ) Google merekomendasikan untuk gzip lebih agresif. Dan yang tampaknya sesuai di situs kami di mana hit yang paling sering, sejauh ini, adalah panggilan AJAX yang <860 byte.

Tanggapan Akamai:

Alasan 860 byte adalah ukuran minimum untuk kompresi dua kali lipat: (1) Overhead kompresi objek di bawah 860 byte melebihi kenaikan kinerja. (2) Objek di bawah 860 byte dapat ditransmisikan melalui paket tunggal, jadi tidak ada alasan kuat untuk mengompresnya.

Jadi saya di sini untuk memeriksa fakta. Apakah batas 860 byte karena ukuran paket adalah akhir dari alasan ini? Mengapa situs lalu lintas tinggi mendorong ini ke batas 150 byte ... hanya untuk menghemat biaya bandwidth (karena CDN mendasarkan biaya mereka pada bandwidth yang diturunkan dari asal), atau adakah peningkatan kinerja dalam melakukannya?

Pembaruan 7/9/12: Saya bertanya kepada Steve Souders apakah ada peningkatan kinerja dalam respons gzipping yang sudah lebih kecil dari paket dan berapa ukuran objek minimum yang disarankan untuk manfaat kinerja gzip, dan ini adalah jawabannya:

Terima kasih untuk email anda. Ukurannya berkisar antara 1-5K. Apache memiliki default tetapi saya lupa apa itu - itu akan menjadi panduan yang baik.

Kami melakukan kompresi kami pada alat F5, jadi kami akan menurunkannya menjadi ~ 350 byte, karena ada jumlah panggilan AJAX yang layak antara itu dan 1K. Panggilan AJAX yang kurang dari 350 byte di situs web kami semuanya turun sekitar 70 byte ... kurang dari rekomendasi Google ... jadi sepertinya kembali ke: kenal situs web Anda dan sesuaikan berdasarkan kode Anda .

Saya akan kembali ke posting ini setelah pembaruan F5 berjalan di Production untuk sementara waktu. Saya pikir akan ada sedikit manfaat kinerja, tetapi kami akan menurunkan biaya Akamai kami sedikit karena mereka melayani lebih sedikit.

— utt73
sumber

@Steve, mengenai hasil edit April saya menambahkan welp untuk mengklarifikasi perasaan, karena pakar di bidang ini tidak menjawab kedua pertanyaan tersebut. Saya senang mendengar kabar dari Tuan Sounders tetapi dia juga tidak tahu jawaban pasti.

— utt73

Adapun "kembali ke pos ini setelah pembaruan F5 berjalan di Production untuk sementara waktu ," meskipun saya tidak bekerja dengan aplikasi web khusus ini lagi, kami berhasil dalam tujuan kami untuk mendapatkan baik memuat halaman rata-rata () acara dan Waktu untuk Interaktif (TTI) di bawah 2 detik, dan pengurangan dalam upaya payload ini adalah satu bagian kecil dari itu. Mengurangi jumlah panggilan lalu lintas http, memperluas cache browser, mengoptimalkan kode, dan praktik terbaik kinerja web lainnya, semuanya berkontribusi.

— utt73

Anda sedang berbicara tentang manfaat biaya bandwidth Anda, tetapi kemudian juga membandingkan kinerja pemuatan halaman di browser. Mereka adalah dua hal yang berbeda.

Kapan saja Anda mendapatkan permintaan, sesuatu harus benar-benar melakukan kompresi (dalam kasus Anda, F5) dan klien (atau proksi teknis) harus menangani dekompresi. Ini dapat menambahkan lebih banyak latensi ke permintaan Anda, tergantung pada kemampuan perangkat keras di kedua ujungnya.

"Ukuran minimum untuk gzip" didasarkan pada waktu yang dibutuhkan untuk mengompresi / mendekompresi data kecil yang tidak membantu dari perspektif pengalaman browser web. Jika Anda benar-benar berbicara tentang penghematan bandwidth, maka lanjutkan dan tetapkan minimum serendah yang Anda inginkan, tetapi lakukan itu dengan mengetahui bahwa Anda mungkin tidak memberikan keuntungan kinerja kepada pengguna akhir.

— Nicholas H
sumber