Mengaktifkan kompresi dinamis

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

Pengurangan ukuran mempercepat download aset penting, seperti stylesheet (CSS), skrip (JavaScript), dan manifes video (HLS/DASH), yang dapat mengurangi waktu pemuatan halaman dan waktu mulai video secara signifikan.

Playlist (manifest) video live berukuran besar memiliki sejumlah besar data dan pengambilan yang berulang, termasuk awalan host dan jalur setiap segmen, serta metadata playlist HLS atau DASH. Semakin cepat playlist dimuat atau update playlist dapat didownload, semakin 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%.

Untuk mengetahui informasi selengkapnya tentang manfaat mengompresi respons, lihat panduan Dasar-Dasar Web.

Cara kerja kompresi dinamis

Jika kompresi dinamis diaktifkan, konten yang dapat dikompresi yang ditayangkan dari origin dapat dikompresi sebelum dikirimkan jika klien menerima salah satu algoritma kompresi yang didukung (br atau gzip).

Media CDN menambahkan header Vary: Accept-Encoding ke semua respons yang memenuhi syarat untuk kompresi. Untuk informasi terkait, lihat Konten yang tidak dapat dikompresi.

Selain itu, jika header Accept-Encoding permintaan menunjukkan preferensi untuk konten terkompresi dengan menentukan br atau gzip (dan secara opsional menyertakan parameter q yang tidak nol), Media CDN akan melakukan hal berikut:

• Menghapus header Content-Length dari respons; hal ini diperlukan untuk memungkinkan respons ditayangkan secepat mungkin karena panjang konten penuh tidak diketahui hingga seluruh respons dikompresi. Untuk HTTP/1.1 dan yang lebih lama, Media CDN menggunakan Transfer-Encoding: chunked dalam respons jika tidak menggunakan Content-Length.

  Setelah respons dikompresi dan di-cache, Media CDN dapat menyertakan header Content-Length dalam respons berikutnya dan menetapkan nilai ke panjang konten isi yang dikompresi.

• Menetapkan Accept-Ranges ke none. Tindakan ini memberi tahu klien bahwa permintaan rentang untuk resource ini diabaikan.

• Memperlemah header respons ETag yang kuat, sebagaimana diwajibkan oleh RFC 9110 bagian 8.8.3. Misalnya, ETag: "xyzzy" diganti dengan ETag: W/"xyzzy".

• Menetapkan header Content-Encoding ke br atau gzip, yang menandakan algoritma kompresi yang dipilih.

  CDN Media memilih algoritma kompresi terbaik berdasarkan perkiraan rasio kompresi respons dan kecepatan atau throughput kompresi.

  • Kompresi Brotli digunakan jika klien mendukungnya, meskipun algoritma kompresi lainnya memiliki nilai q yang lebih tinggi di header Accept-Encoding.

  • Manifes HLS dikompresi hanya menggunakan gzip.

  Media 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.

Mengonfigurasi kompresi dinamis

Anda dapat mengaktifkan kompresi dinamis pada rute yang melayani permintaan.

Sebelum memulai

Lakukan tindakan berikut:

• Identifikasi atau buat asal Media CDN dengan konten yang dapat dikompresi yang siap ditayangkan.

• Identifikasi atau buat layanan Media CDN dengan minimal satu aturan rute.

Mengaktifkan kompresi dinamis untuk aturan rute

Secara default, mode kompresi untuk aturan rute dinonaktifkan.

Menyetel mode ke otomatis akan mengaktifkan kompresi dinamis untuk setiap respons yang memenuhi syarat. Selain itu, perintah ini menginstruksikan Media CDN untuk memilih algoritma kompresi terbaik secara otomatis.

Untuk mengaktifkan kompresi dinamis, lakukan hal berikut:

route_rule {
  description = "a route rule with dynamic compression, priority=2 (high)"
  priority    = 2
  match_rule {
    path_template_match = "/**.m3u8" # HLS playlists
  }
  match_rule {
    path_template_match = "/**.mpd" # DASH manifests
  }
  origin = google_network_services_edge_cache_origin.default.name
  route_action {
    cdn_policy {
      cache_mode = "FORCE_CACHE_ALL"
      client_ttl = "300s"
    }
    compression_mode = "AUTOMATIC"
  }
  header_action {
    response_header_to_add {
      header_name  = "x-cache-status"
      header_value = "{cdn_cache_status}"
    }
  }
}

Konfigurasi Anda akan segera disebarkan ke semua lokasi edge.

Jika kompresi dinamis diaktifkan untuk rute dan konfigurasi baru diterapkan di mesin produksi, Media CDN akan mulai mengompresi respons yang memenuhi syarat, meskipun ada versi yang di-cache yang tidak dikompresi. Saat Media CDN mengambil dan memadatkan konten baru, mungkin terjadi lonjakan sementara traffic ke server asal Anda.

Menonaktifkan kompresi dinamis untuk aturan rute

Untuk menonaktifkan kompresi dinamis, lakukan hal berikut:

Jika Anda mengalami masalah dengan kompresi dinamis untuk rute tertentu, seperti masalah kompatibilitas dengan klien tertentu (misalnya, smart TV atau perangkat streaming), untuk mencegah Media CDN menayangkan konten terkompresi di rute tersebut, nonaktifkan kompresi dinamis.

Menonaktifkan kompresi dinamis untuk rute menyebabkan Media CDN berhenti menayangkan konten terkompresi dari cache. Semua respons terkompresi yang di-cache sebelumnya menjadi tidak valid, dan CDN mengambil versi yang tidak dikompresi dari origin Anda.

Jenis konten yang dapat dikompresi

Kompresi dinamis berlaku untuk jenis MIME berikut, berdasarkan header respons HTTP Content-Type. Respons yang tidak memiliki header Content-Type tidak 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.

Format gambar dan video (seperti image/jpeg, image/png, dan video/mpeg4) hampir selalu sudah dikompresi. Jadi, Media 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.

Respons yang tidak dapat dikompresi

Media CDN tidak mengompresi respons yang memiliki satu atau beberapa karakteristik berikut:

• Respons tidak memiliki header Content-Type yang cocok dengan jenis konten yang dapat dikompresi.
• Respons tidak memiliki header Content-Length.
• Respons memiliki header Content-Encoding. Hal ini menunjukkan bahwa origin telah memadatkan respons. Jadi, Media CDN tidak boleh melakukan kompresi dinamis tambahan.

• Respons lebih kecil dari 1 KiB.

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

• Respons lebih besar dari 1 MiB.

  CDN media memampatkan respons hingga ukuran yang diizinkan untuk objek yang di-cache tanpa byte-range caching.

• Respons memiliki header Cache-Control: no-transform.

• Respons memiliki header Vary: Accept-Encoding, yang menyiratkan bahwa kompresi dinamis tidak diperlukan karena origin dapat mengompresi respons.

Logging dan pemantauan

Jika kompresi diaktifkan, metrik https/response_bytes_count yang ada di bagian edgecache.googleapis.com/EdgeCacheRouteRule melaporkan ukuran respons yang dikompresi. Anda dapat melihat penurunan total byte respons dan throughput transfer data keluar untuk konten yang dapat dikompresi.

Log Media CDN menyertakan kolom compressionAlgorithmApplied di jsonPayload, yang menunjukkan apakah respons dikompresi oleh load balancer serta jenis kompresi.

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.edgecache.v1.EdgeCacheLogEntry",
    cacheId: "IAD-862d661f",
    cacheStatus": "hit,stale",
    compressionAlgorithmApplied: "br"
  },
}

Penagihan

Saat respons dikompresi oleh Media CDN, biaya transfer data internet atau cache keluar yang relevan didasarkan pada 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.

Langkah berikutnya

• Mengonfigurasi rute layanan
• Mengonfigurasi logging permintaan