Mengaktifkan kompresi dinamis

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

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 dalam panduan Dasar-Dasar Web.

Anda dapat mengaktifkan kompresi pada layanan backend atau bucket backend.

Contoh kasus penggunaan

Kompresi dinamis secara langsung akan mengurangi ukuran data yang dikirim dari edge Cloud CDN ke klien. Dampaknya secara langsung antara lain:

  • Mengurangi ukuran CSS dan JavaScript, sehingga membantu halaman web dirender lebih cepat dan mengurangi waktu untuk First Contentful Paint, yang merupakan metrik performa web yang penting.
  • Memberikan dampak positif yang besar saat meng-cache respons REST API, seperti payload JSON. Payload ini dikompresi dengan baik disebabkan ada pengulangan kunci, spasi kosong, dan kurung kurawal. Meng-cache API publik selama 5-10 detik adalah pendekatan populer untuk mengurangi beban server asal sekaligus mempertahankan keaktualan data.

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

  • Meningkatkan waktu mulai pemutaran untuk penayangan video dan latensi gabung untuk live streaming. Playlist live (manifest) berukuran besar memiliki sejumlah besar data berulang, termasuk awalan host + jalur tiap segmen, serta metadata playlist HLS atau DASH. Makin cepat playlist dimuat atau update playlist dapat didownload, makin sedikit waktu yang dibutuhkan 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-hal berikut:

  • Backend yang dikonfigurasi menggunakan Cloud CDN. Jika Cloud CDN belum dikonfigurasi, Anda dapat mengikuti salah satu panduan penyiapan.
  • Backend Anda memiliki konten yang dapat dikompresi yang siap disajikan, seperti aset web atau manifes video antara 1 KiB dan 10 MiB (inklusif).
  • Klien tidak mengandalkan pengambilan konten parsial dengan permintaan rentang atau dengan ETag yang kuat. Format ini tidak kompatibel dengan kompresi dinamis.
  • Klien dapat menangani respons tanpa header Content-Length. Misalnya, cache 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 pada layanan backend atau bucket backend

Untuk mengaktifkan kompresi, ikuti langkah-langkah berikut.

Konsol

Menambahkan server asal baru

Untuk menambahkan dan menyiapkan server asal baru, ikuti petunjuk di Ringkasan penyiapan untuk jenis backend yang sesuai. Saat membuat server asal, gunakan bagian Advanced options untuk mengonfigurasi kompresi dinamis dengan memilih Automatic dalam daftar Compression mode.

Mengedit server asal yang ada

Untuk mengedit server asal Cloud CDN yang ada:

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

    Buka Origins

  2. Klik nama server 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. Di daftar Compression mode, pilih Automatic.

  7. Untuk menerapkan perubahan, klik Done.

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 sudah 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 sudah ada, gunakan perintah update:

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

compression-mode dapat berupa salah satu dari berikut

  • AUTOMATIC: Otomatis menggunakan kompresi terbaik berdasarkan header Accept-Encoding yang dikirim oleh klien. Dalam sebagian besar kasus, hal ini menyebabkan kompresi Brotli lebih diutamakan.
  • 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 berikut

  • AUTOMATIC (direkomendasikan): Otomatis menggunakan kompresi terbaik berdasarkan header Accept-Encoding yang dikirim oleh klien. Dalam sebagian besar kasus, hal ini menyebabkan kompresi Brotli lebih diutamakan.
  • DISABLED (default): Menonaktifkan kompresi.

Dalam beberapa menit, konfigurasi Anda akan diterapkan ke semua lokasi edge. Konten yang dapat dikompresi yang disajikan dari backend akan dikompresi sebelum dikirimkan 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 untuk respons
  • Kecepatan kompresi (throughput) Cloud CDN

Brotli dapat menghasilkan pengurangan ukuran download tambahan sebesar 10% hingga 20% untuk sebagian besar jenis konten dibandingkan gzip, dengan performa dekompresi yang serupa, sehingga secara keseluruhan lebih cepat 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 meningkatkan performa, terutama pada perangkat seluler dengan daya yang lebih rendah.

Saat mengompresi konten untuk pertama kalinya, Cloud CDN akan menghapus header Content-Length dari respons. Hal ini diperlukan agar respons dapat disajikan secepat mungkin karena panjang konten lengkap tidak akan diketahui hingga seluruh respons dikompresi. Setelah respons dikompresi dan di-cache, Cloud CDN dapat menyertakan header Content-Length dalam respons berikutnya. (Untuk HTTP/1.1 dan yang lebih lama, Cloud CDN akan 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 dan disajikan dari backend (server 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 akan dikompresi.

Jenis konten umum dan jenis MIME-nya mencakup:

  • Konten HTML: text/html
  • Stylesheets: 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 cara 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-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 akan mengompresinya. Mengompresi ulang respons yang sudah dikompresi akan jarang mengurangi ukuran file, dan klien mungkin akan menunjukkan perilaku yang tidak terduga saat menerima respons semacam ini.

Kapan respons tidak akan dikompresi?

Kompresi dinamis tidak akan 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.
  • Memiliki header Content-Encoding.
  • Ukurannya kurang dari 1 KiB.

    Waktu yang dihabiskan untuk mengompresi dan mendekompresi sering kali tidak sebanding dengan manfaat apa pun yang diperoleh. Selain itu, konten yang dikompresi juga lebih sedikit, sehingga dapat mengurangi efektivitas kompresi dan menghasilkan rasio kompresi yang lebih rendah.

  • Ukurannya lebih besar daripada 10 MiB.

  • Memiliki header Cache-Control: no-transform.

  • Memiliki header Vary: Accept-Encoding.

Permintaan rentang

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

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

ETag

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

Header Vary

Saat menyajikan 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 telah terjadi:

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

Logging

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

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

Penagihan

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

Jika Anda menyajikan respons yang dapat dikompresi dalam jumlah besar, hal ini dapat mengurangi biaya transfer data keluar bulanan Anda, 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 yang dikompresi.

Anda dapat mengalami penurunan total byte respons (dan throughput transfer data keluar).

Jika Anda menyajikan sejumlah besar konten berbasis teks yang dikompresi dengan baik, seperti HTML, CSS, JavaScript, atau JSON, Anda mungkin akan mengalami penurunan besar pada byte respons.

Untuk mengetahui informasi selengkapnya, baca bagian Monitoring.

Langkah berikutnya

  • Untuk memahami cara mode cache mempermudah penyimpanan konten dalam cache, baca bagian Mengubah mode cache.
  • Untuk mengaktifkan Cloud CDN bagi instance dan bucket penyimpanan yang di-load balance pada koneksi HTTP(S), baca bagian Ringkasan penyiapan.
  • Untuk mempelajari cara menginvalidasi cache, baca bagian Ringkasan invalidasi cache.
  • Untuk menemukan titik kehadiran GFE, baca bagian Lokasi cache.