Mengaktifkan kompresi dinamis

Kompresi dinamis secara otomatis mengompresi respons yang disalurkan oleh Cloud CDN. Ukuran data yang dikirim melalui jaringan berkurang 60% hingga 85% dalam kasus umum.

Pengurangan ukuran 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 mulai video dan pemuatan halaman.

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

Anda dapat mengaktifkan kompresi pada 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:

  • Kurangi ukuran CSS dan JavaScript, sehingga membantu halaman web dirender lebih cepat dan mengurangi waktu untuk First Contentful Paint, sebuah 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 adanya kunci berulang, spasi kosong, dan tanda kurung kurawal. Menyimpan API publik ke dalam cache selama 5-10 detik adalah pendekatan populer untuk mengurangi beban origin sekaligus mempertahankan keaktualan data.

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

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

Sebelum memulai

Pastikan Anda memiliki hal berikut:

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

Mengaktifkan kompresi pada 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 Advanced options untuk mengonfigurasi kompresi dinamis dengan memilih Automatic di daftar Compression mode.

Mengedit origin yang sudah ada

Untuk mengedit origin Cloud CDN yang ada:

  1. Di Konsol Google Cloud, buka halaman Asal Cloud CDN.

    Buka origin Cloud CDN

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

  3. Di bagian Dasar-dasar asal, klik Berikutnya.

  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 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 disukai.
  • DISABLED (default): Menonaktifkan kompresi.

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

Mode kompresi

Mode kompresi default adalah DISABLED.

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

  • Encoding yang diterima klien
  • Rasio kompresi yang diantisipasi
  • Kecepatan kompresi (throughput) Cloud CDN

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

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

Cloud CDN menentukan tingkat kompresi untuk menyeimbangkan total ukuran download dan biaya CPU pada klien. Tingkat kompresi yang lebih tinggi tidak selalu menguntungkan performa, terutama pada perangkat seluler yang menggunakan teknologi lebih rendah.

Saat pertama kali mengompresi konten, Cloud CDN 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 di-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 sebagai respons saat 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 disajikan dari backend (origin) 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 memiliki Accept-Encoding: *, respons tidak dikompresi.

Misalnya, dengan header Accept-Encoding dalam permintaan klien, respons 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 akan dikompresi.

Jenis konten umum dan jenis MIME-nya meliputi:

  • 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 bagaimana jenis MIME memengaruhi kompresibilitas.

  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-protobuf-protobuffer
application/x-protobuf/jsonw
image/x-protobuf image
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 mengompresinya. 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.
  • Class ini tidak memiliki header Content-Length.

  • Ini lebih kecil dari 1 KiB.

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

  • Ukurannya lebih besar dari 10 MiB.

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

  • Class ini memiliki header Vary: Accept-Encoding.

Permintaan rentang

Saat Cloud CDN mengompresi respons, Cloud CDN menambahkan header Accept-Ranges: none dan menggantikan header Accept-Ranges yang ada. Cache ditemukan untuk respons tersebut akan mengabaikan header Range.

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

ETags

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

Header Variasi

Saat menayangkan respons yang berpotensi dikompresi (bergantung pada permintaan), Cloud CDN 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 entitas yang kuat akan diganti dengan versi yang dilemahkan, ditunjukkan dengan awalan W/.
Terima-Rentang Tetapkan ke nilai none.
Content-Length Mungkin dihapus sepenuhnya, atau jika ada, disetel ke panjang konten isi yang dikompresi.
Transfer-Encoding Untuk protokol HTTP/1.1 dan yang lebih lama, jika Cloud CDN menghapus Content-Length, header ini akan ditambahkan dengan nilainya yang ditetapkan ke chunked, dan 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 yang relevan atau transfer data internet keluar (masing-masing) diukur terhadap byte terkompresi akhir yang dikirim ke klien.

Jika Anda menampilkan respons yang dapat dikompresi dalam jumlah besar, hal ini dapat mengurangi biaya transfer data keluar bulanan, serta meningkatkan performa bagi pengguna akhir.

Metrik

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

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

Jika Anda menyajikan 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 informasi selengkapnya, lihat Pemantauan.

Langkah selanjutnya