Mengaktifkan kompresi dinamis

Kompresi dinamis otomatis mengompresi respons yang ditayangkan oleh Cloud CDN. Ukuran data yang dikirim melalui jaringan dikurangi sebesar 60% hingga 85% dalam kasus biasa.

Pengurangan ukuran akan mengurangi waktu yang diperlukan untuk mendownload konten. Untuk aset penting seperti stylesheet (CSS), skrip (JavaScript), dan manifes video (HLS/DASH), hal ini dapat mengurangi waktu pemuatan halaman dan waktu mulai video.

Anda dapat mempelajari lebih lanjut manfaat mengompresi respons di panduan Dasar-Dasar Web.

Anda dapat mengaktifkan kompresi di layanan backend atau bucket backend.

Contoh kasus penggunaan

Kompresi dinamis secara langsung mengurangi ukuran data yang dikirim dari edge Cloud CDN ke klien. Tindakan ini dapat langsung melakukan hal berikut:

  • Mengurangi ukuran CSS dan JavaScript, sehingga membantu halaman web dirender lebih cepat dan mengurangi waktu untuk First Contentful Paint, yaitu metrik performa web yang penting.

  • Memiliki dampak positif yang besar saat meng-cache respons REST API, seperti payload JSON. Payload ini dikompresi dengan baik karena kunci, spasi kosong, dan tanda kurung berulang. Menyimpan API publik dalam cache selama 5-10 detik adalah pendekatan populer untuk mengurangi beban origin sekaligus mempertahankan keaktualan data.

    Bahkan tanpa cache, mengompresi respons ini dapat mengurangi total byte yang dikirim hingga 90%.

  • Meningkatkan waktu mulai pemutaran untuk pengiriman video dan latensi bergabung untuk live streaming. Playlist live (manifes) berukuran besar memiliki jumlah data berulang yang signifikan, termasuk awalan host + jalur dari setiap segmen, serta metadata playlist HLS atau DASH. Makin cepat playlist dimuat atau update playlist dapat didownload, makin sedikit waktu yang ditunggu klien untuk mengurai dan mulai mendownload segmen video yang dirujuk. Playlist HLS dan DASH sering kali mengalami pengurangan ukuran total lebih dari 90%.

Sebelum memulai

Pastikan Anda memiliki hal berikut:

  • Backend yang mendukung Cloud CDN telah dikonfigurasi. Jika belum mengonfigurasi Cloud CDN, Anda dapat mengikuti salah satu panduan penyiapan.
  • Backend Anda memiliki konten yang dapat dikompresi yang siap dikirim, seperti aset web atau manifes video antara 1 KiB dan 10 MiB (inklusif).
  • Klien tidak mengandalkan pengambilan konten sebagian dengan permintaan rentang atau dengan ETag yang kuat. Keduanya tidak kompatibel dengan kompresi dinamis.
  • Klien dapat menangani respons tanpa header Content-Length. Misalnya, cache yang tidak ditemukan yang dikompresi Cloud CDN tidak memiliki header Content-Length.
  • Peran Compute Load Balancer Admin IAM (roles/compute.loadBalancerAdmin), yang diperlukan untuk membuat perubahan pada konfigurasi backend Anda.

Mengaktifkan kompresi di layanan backend atau bucket backend

Untuk mengaktifkan kompresi, ikuti langkah-langkah berikut.

Konsol

Menambahkan origin baru

Untuk menambahkan dan menyiapkan origin baru, ikuti petunjuk di Ringkasan penyiapan untuk jenis backend yang sesuai. Saat membuat origin, gunakan bagian Opsi lanjutan untuk mengonfigurasi kompresi dinamis dengan memilih Otomatis dalam daftar Mode kompresi.

Mengedit origin yang ada

Untuk mengedit origin Cloud CDN yang ada:

  1. Di konsol Google Cloud, buka halaman Origins Cloud CDN.

    Buka Origins

  2. Klik nama asal yang ingin Anda edit, lalu klik Edit.

  3. Di bagian Origin basics, klik Next.

  4. Di bagian Host and path rules, klik Next.

  5. Di bagian Cache performance, buka Advanced options.

  6. Dalam daftar Compression mode, pilih Automatic.

  7. Untuk menerapkan perubahan, klik Selesai.

gcloud

Untuk layanan backend, gunakan perintah gcloud compute backend-services create atau perintah gcloud compute backend-services update dengan flag --compression-mode.

Untuk bucket backend, gunakan perintah gcloud compute backend-buckets create atau perintah gcloud compute backend-buckets update dengan flag --compression-mode.

Untuk layanan backend baru, gunakan perintah create:

gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

Untuk layanan backend yang ada, gunakan perintah update:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

Untuk bucket backend baru, gunakan perintah create:

gcloud compute backend-buckets create BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

Untuk bucket backend yang ada, gunakan perintah update:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

compression-mode dapat berupa salah satu dari hal berikut:

  • AUTOMATIC: Otomatis menggunakan kompresi terbaik berdasarkan header Accept-Encoding yang dikirim oleh klien. Pada umumnya, hal ini menyebabkan kompresi Brotli lebih disukai.
  • DISABLED (default): Menonaktifkan kompresi.

API

Untuk layanan backend, gunakan metode backendServices.insert atau metode backendServices.update.

Untuk bucket backend, gunakan metode backendBuckets.insert atau metode backendBuckets.update.

Gunakan salah satu perintah berikut:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET

Tambahkan cuplikan berikut ke isi permintaan JSON:

"compressionMode": AUTOMATIC

compression-mode dapat berupa salah satu dari hal berikut:

  • AUTOMATIC (direkomendasikan): Otomatis menggunakan kompresi terbaik berdasarkan header Accept-Encoding yang dikirim oleh klien. Pada umumnya, hal ini menyebabkan kompresi Brotli lebih disukai.
  • DISABLED (default): Menonaktifkan kompresi.

Dalam beberapa menit, konfigurasi Anda akan diterapkan ke semua lokasi edge. Konten yang dapat dikompresi yang ditayangkan dari backend dikompresi sebelum dikirim ke klien.

Mode kompresi

Mode kompresi default-nya adalah DISABLED.

Mode AUTOMATIC memungkinkan Cloud CDN memilih metode kompresi terbaik berdasarkan hal berikut:

  • Encoding yang diterima klien
  • Rasio kompresi yang diperkirakan untuk respons
  • Kecepatan kompresi (throughput) Cloud CDN

Brotli dapat menghasilkan pengurangan ukuran download tambahan sebesar 10% hingga 20% untuk sebagian besar jenis konten melalui gzip, dengan performa dekompresi yang serupa, sehingga lebih cepat secara keseluruhan jika mempertimbangkan waktu download dan kecepatan dekompresi di klien.

Cloud CDN menunjukkan metode kompresi yang dipilih sebagai gzip atau brotli di header Content-Encoding dalam respons.

Cloud CDN menentukan tingkat kompresi untuk menyeimbangkan total ukuran download dan biaya CPU di klien. Tingkat kompresi yang lebih tinggi tidak selalu memberikan manfaat pada performa, terutama pada perangkat seluler dengan daya yang lebih rendah.

Saat Cloud CDN awalnya mengompresi konten, Cloud CDN akan menghapus header Content-Length dari respons; hal ini diperlukan agar respons dapat ditayangkan secepat mungkin karena panjang konten lengkap tidak diketahui hingga seluruh respons telah dikompresi. Setelah respons dikompresi dan disimpan dalam cache, Cloud CDN mungkin menyertakan header Content-Length dalam respons berikutnya. (Untuk HTTP/1.1 dan yang lebih lama, Cloud CDN menggunakan Transfer-Encoding: chunked dalam respons jika tidak menggunakan Content-Length.)

Kapan respons dikompresi?

Jika permintaan memiliki header Accept-Encoding yang secara eksplisit mencantumkan dukungan untuk algoritma gzip atau Brotli, respons yang tidak dikompresi yang ditayangkan dari backend (asal) dengan header Content-Type yang cocok dengan jenis konten yang dapat dikompresi akan dikompresi dengan gzip atau Brotli. Jika permintaan tidak memiliki header Accept-Encoding, atau jika memiliki Accept-Encoding: *, respons tidak akan dikompresi.

Misalnya, dengan header Accept-Encoding dalam permintaan klien, respons akan dikompresi (atau tidak) sesuai dengan informasi dalam tabel berikut:

Header permintaan Accept-Encoding Encoding respons
gzip, compress, br Brotli (br)
deflate Tidak dikompresi
deflate, gzip gzip
identity Tidak dikompresi
* Tidak dikompresi

Jenis konten yang dapat dikompresi

Kompresi dinamis berlaku untuk jenis MIME berikut, berdasarkan header respons HTTP Content-Type. Respons yang tidak memiliki header respons Content-Type tidak dikompresi.

Jenis konten umum dan jenis MIME-nya mencakup hal berikut:

  • Konten HTML: text/html
  • Stylesheet: text/css
  • JavaScript: application/javascript
  • JSON: application/json
  • Playlist HLS: application/x-mpegURL atau application/vnd.apple.mpegURL
  • Manifes DASH: application/dash+xml

Tabel berikut merangkum pengaruh jenis MIME terhadap kemampuan kompresi.

  Jenis MIME yang dapat dikompresi
Pencocokan persis application/x-javascript
application/x-sdch-dictionary
application/javascript
application/xml
application/csv
application/json
application/json+protobuf
application/signed-exchange
application/vnd.apple.mpegurl
application/wasm
application/x-plist
application/x-protobuffer
application/x-protobuf
application/x-nacl
application/x-pnacl
font/ttf
font/otf
font/eot
image/svg+xml
image/pwg-raster
image/x-icon
image/vnd.microsoft.icon
video/vnd.mpeg.dash.mpd
audio/mpegURL
application/dash+xml
application/vnd.ms-sstr+xml
Pencocokan pola application/*+json
application/*+xml
application/*mpegURL
text/*

Format gambar dan video (seperti image/jpeg, image/png, dan video/mpeg4) hampir selalu sudah dikompresi, sehingga Cloud CDN tidak mengompresi format tersebut. Mengompresi ulang respons yang sudah dikompresi jarang mengurangi ukuran file, dan klien mungkin menunjukkan perilaku yang tidak terduga saat menerima respons semacam ini.

Kapan respons tidak dikompresi?

Kompresi dinamis tidak mengompresi respons yang memiliki satu atau beberapa karakteristik berikut:

  • Respons tidak memiliki header Content-Type yang cocok dengan jenis konten yang dapat dikompresi.
  • Tidak memiliki header Content-Length.
  • Kolom ini memiliki header Content-Encoding.

  • Ukurannya lebih kecil dari 1 KiB.

    Waktu yang dihabiskan untuk mengompresi dan mendekompresi sering kali mengimbangi manfaat apa pun. Selain itu, ada lebih sedikit konten yang akan dikompresi, yang dapat mengurangi efektivitas kompresi dan menyebabkan rasio kompresi yang lebih rendah.

  • Ukurannya lebih dari 10 MiB.

  • Kolom ini memiliki header Cache-Control: no-transform.

  • Kolom ini memiliki header Vary: Accept-Encoding.

Permintaan rentang

Saat Cloud CDN mengompresi respons, Cloud CDN akan menambahkan header Accept-Ranges: none dan mengganti header Accept-Ranges yang ada. Hit cache untuk respons tersebut mengabaikan header Range.

Hal ini mencegah penayangan konten parsial yang salah kepada klien karena tidak ada cara untuk memastikan apakah klien mengharapkan rentang byte dari bentuk resource yang terkompresi atau tidak terkompresi.

ETag

Saat kompresi dinamis mengompresi respons, header ETag yang kuat akan diperlemah, seperti yang diwajibkan oleh RFC 7232 bagian 2.3. Misalnya, ETag: "xyzzy" diganti dengan ETag: W/"xyzzy".

Header vary

Saat menayangkan respons yang berpotensi dikompresi (bergantung pada permintaan), Cloud CDN akan menambahkan header Vary: Accept-Encoding ke respons.

Ringkasan perubahan respons

Tabel berikut meringkas perubahan yang dilakukan Cloud CDN pada header respons saat kompresi terjadi:

Header respons Nilai header setelah kompresi
Content-Encoding Tetapkan ke gzip atau brotli.
ETag Setiap tag entity yang kuat akan diganti dengan versi yang lebih lemah, yang ditunjukkan dengan awalan W/.
Accept-Ranges Tetapkan ke nilai none.
Content-Length Mungkin dihapus sepenuhnya, atau jika ada, ditetapkan ke panjang konten isi yang dikompresi.
Transfer-Encoding Untuk HTTP/1.1 dan protokol yang lebih lama, jika Cloud CDN menghapus Content-Length, Cloud CDN akan menambahkan header ini, dengan nilainya ditetapkan ke chunked, dan mengelompokkan isi respons.

Logging

Log Cloud CDN menyertakan kolom compressionStatus di jsonPayload yang menunjukkan apakah respons dikompresi oleh load balancer serta jenis kompresi.

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    statusDetails: "response_sent_by_backend"
    cacheId: "IAD-862d661f"
    compressionStatus: "br"
  }
}

Penagihan

Saat respons dikompresi oleh Cloud CDN atau Cloud Load Balancing, transfer data cache keluar atau transfer data internet keluar yang relevan (masing-masing) diukur berdasarkan byte terkompresi akhir yang dikirim ke klien.

Jika Anda menayangkan respons yang dapat dikompresi dalam jumlah besar, hal ini dapat mengakibatkan pengurangan biaya transfer data keluar bulanan, serta peningkatan performa untuk pengguna akhir.

Metrik

Jika kompresi diaktifkan, metrik https/response_bytes_count yang ada di bagian loadbalancing.googleapis.com akan melaporkan ukuran respons yang dikompresi.

Anda akan melihat penurunan total byte respons (dan throughput transfer data keluar).

Jika Anda menayangkan konten berbasis teks dalam jumlah besar yang dikompresi dengan baik, seperti HTML, CSS, JavaScript, atau JSON, Anda mungkin melihat penurunan besar dalam byte respons.

Untuk mengetahui informasi selengkapnya, lihat Pemantauan.

Langkah selanjutnya