Praktik terbaik penayangan konten

Halaman ini memberikan praktik terbaik untuk mengoptimalkan dan mempercepat penayangan konten dengan Cloud CDN. Bagian ini dibagi menjadi beberapa area utama.

Cloud CDN menggunakan Load Balancer Aplikasi eksternal sebagai asal untuk konten yang dapat di-cache. Load Balancer Aplikasi eksternal dapat mengirimkan campuran konten statis dan yang dibuat secara dinamis kepada pengguna melalui satu alamat IP global dari jenis backend berikut:

Karena integrasi yang lancar dengan Google Cloud, Anda memiliki beberapa opsi untuk men-deploy Cloud CDN dan mengelola konten. Gunakan praktik terbaik yang tercantum di sini untuk merencanakan dan meningkatkan kualitas deployment Anda. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Cloud CDN.

Mengoptimalkan rasio cache ditemukan

Praktik yang direkomendasikan berikut membantu mengoptimalkan rasio hit cache.

Cache konten statis

Sebagai praktik terbaik untuk meningkatkan performa, saat mengaktifkan Cloud CDN, Anda harus memilih mode cache yang tepat untuk aplikasi Anda.

Metode yang paling fleksibel dan umumnya lebih disukai untuk mengelola aturan cache adalah dengan menggunakan header kontrol cache. Jika Anda belum terbiasa menggunakan header kontrol cache asal, rekomendasi praktik terbaiknya adalah mengizinkan Cloud CDN untuk otomatis menyimpan konten statis ke dalam cache.

Untuk otomatis menyimpan respons statis dari origin Anda ke cache, Anda dapat menggunakan setelan --cache-mode=CACHE_ALL_STATIC (default). Setelan ini memungkinkan Cloud CDN menyimpan dalam cache jenis konten statis umum saat origin tidak menentukan direktif penyimpanan dalam cache apa pun di header respons. Pastikan konten Anda sesuai dengan kategori yang diuraikan; jika tidak, konten tidak di-cache.

Jangan menyimpan konten khusus pengguna dalam cache

Dalam beberapa kasus, browser dapat menyimpan konten khusus pengguna dalam cache. Jangan gunakan Cloud CDN untuk menyimpan konten khusus pengguna ke dalam cache.

Menggunakan kunci cache kustom untuk meningkatkan rasio hit cache

Untuk performa dan skalabilitas, penting untuk mengoptimalkan rasio hit cache. Secara default, Cloud CDN menggunakan URL permintaan lengkap untuk membuat kunci cache. Untuk membantu mengoptimalkan rasio hit cache, Anda dapat menggunakan kunci cache kustom sehingga Cloud CDN tidak memecah cache secara tidak perlu.

Penyimpanan key-value Cloud CDN (klik untuk memperbesar).

Kunci cache kustom memungkinkan Anda menyertakan atau menghapus kombinasi protokol, host, dan string kueri. Berikut beberapa contoh kapan Anda dapat menggunakan kunci cache kustom:

  • Anda memiliki dua host yang di-resolve ke alamat IP yang sama dan membuka layanan yang sama. Dalam contoh ini, seluruh situs sama di kedua host. Secara default, Cloud CDN menyimpan dua salinan dalam cache karena header Host: yang berbeda dalam permintaan HTTP. Dengan kunci cache kustom, Anda dapat membuat Cloud CDN mengabaikan bagian host permintaan dan membagikan entri cache.

  • Dalam contoh yang lebih spesifik, Anda mungkin memiliki dua situs di domain yang berbeda yang menggunakan logo yang sama. Konten situs berbeda, tetapi Anda menggunakan logo perusahaan yang sama di kedua domain, dan Anda memiliki layanan backend khusus yang menyimpan konten bersama. Saat Anda mengaktifkan Cloud CDN dan menyesuaikan kunci cache untuk layanan backend yang menyimpan logo, hapus tanda centang pada kotak Host agar cache mengabaikan domain, tetapi menyimpan logo.

  • Logo perlu di-cache, baik ditampilkan melalui HTTP maupun HTTPS. Saat Anda menyesuaikan kunci cache untuk layanan backend yang menyimpan logo, hapus centang pada kotak Protokol agar permintaan melalui HTTP dan HTTPS dihitung sebagai kecocokan untuk entri cache logo.

Untuk mempelajari cara menyesuaikan kunci cache, lihat Menggunakan kunci cache.

Optimalkan performa

Praktik yang direkomendasikan berikut membantu mengoptimalkan performa.

Pastikan dukungan protokol HTTP/3 dan QUIC diaktifkan

HTTP/3 adalah protokol internet generasi berikutnya. Protokol ini dibuat berdasarkan QUIC, protokol yang dikembangkan dari protokol Google QUIC ) (gQUIC) asli. HTTP/3 didukung antara load balancer HTTP(S) eksternal, Cloud CDN, dan klien.

Untuk meningkatkan performa dengan Cloud CDN, pastikan HTTP/3 diaktifkan.

Menggunakan caching negatif

Caching negatif memberikan kontrol terperinci atas caching untuk error atau pengalihan umum. Saat menemukan kode respons tertentu, Cloud CDN akan menyimpan respons tersebut dalam cache untuk TTL yang ditetapkan. Hal ini dapat mengurangi beban pada asal Anda dan meningkatkan kualitas pengalaman pengguna akhir dengan mengurangi latensi respons.

Mengaktifkan data awal TLS

Penggunaan data awal TLS meningkatkan rasio koneksi yang dilanjutkan sebesar 30 % hingga 50 %. Untuk mengaktifkan data awal TLS, gunakan perintah gcloud compute target-https-proxies update dengan opsi tls-early-data. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi data awal TLS.

Anda dapat mengaktifkan data awal TLS dalam mode STRICT atau PERMISSIVE.

  • STRICT: Mengaktifkan data awal untuk metode idempoten (GET, HEAD, OPTIONS , dan TRACE), yang tidak memiliki parameter kueri lainnya. Ini adalah metode yang lebih aman dan berlaku dalam sebagian besar kasus.
  • PERMISSIVE: Mengaktifkan data awal untuk metode idempoten yang dapat menyertakan parameter kueri. Saat menggunakan mode ini, Anda harus memantau secara cermat perilaku aplikasi dan postur keamanan Anda.

Permintaan data awal yang menggunakan metode HTTP non-idempoten atau memiliki parameter kueri ditolak dengan kode status HTTP 425.

Mengoptimalkan keamanan

Praktik yang direkomendasikan berikut membantu mengoptimalkan keamanan.

Menggunakan Google Cloud Armor

Cloud Armor terintegrasi dengan Cloud CDN untuk konten yang di-cache dan yang tidak di-cache atau cache tidak ditemukan. Rekomendasi praktik terbaik adalah menggunakan Cloud Armor bersama dengan Cloud CDN jika memungkinkan untuk meningkatkan keamanan aplikasi web.

Menggunakan URL yang ditandatangani

Jika Anda menggunakan URL bertanda tangan, perhatikan hal berikut:

Mengautentikasi asal pribadi

Autentikasi asal menawarkan jaminan kuat bahwa permintaan hanya berasal dari layanan backend yang Anda konfigurasi sendiri. Selain itu, layanan ini menawarkan perlindungan data dalam pengiriman untuk permintaan dan melindungi dari penggunaan ulang bagian permintaan yang ditandatangani.

Sebaiknya gunakan autentikasi origin pribadi untuk bucket Amazon S3 atau penyimpanan objek yang kompatibel. Autentikasi asal pribadi membantu memastikan bahwa hanya koneksi tepercaya yang mengakses konten di asal pribadi Anda dan pengguna tidak mengaksesnya secara langsung.

Selain itu, jika firewall asal mencegah akses ke asal, gunakan daftar yang diizinkan IP untuk memastikan bahwa permintaan berasal dari Cloud CDN atau Load Balancer Aplikasi eksternal. Namun, tindakan ini tidak mencegah pelanggan Media CDN lain mencoba mengakses konten Anda dengan menentukan asal Anda dalam konfigurasi mereka.

Mengoptimalkan cache

Praktik yang direkomendasikan berikut membantu mengoptimalkan cache.

Mengoptimalkan TTL cache

Anda dapat menyetel atau mengganti TTL untuk menyesuaikan berapa lama Cloud CDN menyimpan respons Anda dalam cache dan kapan Cloud CDN memvalidasi ulang respons Anda.

Anda juga dapat menentukan TTL yang menghadap klien untuk memanfaatkan cache browser secara maksimal.

Untuk mengetahui informasi selengkapnya, lihat Menggunakan setelan dan penggantian TTL.

Menetapkan masa berlaku untuk konten yang sensitif waktu

Setiap konten dalam cache Cloud CDN memiliki waktu habis masa berlaku terkait, dan penting untuk menetapkan waktu habis masa berlaku yang sesuai untuk kasus penggunaan Anda. Karena server asal harus mengirim ulang konten yang berakhir di server cache, Anda harus memilih waktu habis masa berlaku dengan cermat.

Salah satu metode untuk memilih tanggal habis masa berlaku adalah dengan mengategorikan konten berdasarkan seberapa sering Anda memperbarui konten; misalnya:

  • Pembaruan hampir real-time seperti feed live untuk acara olahraga atau lalu lintas
  • Pembaruan yang sering seperti informasi cuaca mingguan, harian, atau per jam atau gambar berita halaman depan
  • Pembaruan yang jarang dilakukan seperti logo situs atau file CSS atau JavaScript

Selanjutnya, pilih masa berlaku menurut kategori konten. Misalnya, masa berlaku lima detik mungkin sesuai untuk skor olahraga yang mendekati real-time, dan masa berlaku satu jam dapat digunakan untuk info cuaca. Untuk konten yang disimpan di Cloud Storage, tetapkan waktu habis masa berlaku menggunakan metadata Cache-Control. Saat konten ditayangkan oleh Compute Engine, Anda mengontrol waktu habis masa berlaku dengan mengonfigurasi software server web.

Waktu habis masa berlaku ditentukan oleh nilai max-age dan s-maxage di header Cache-Control. Header ini ditentukan oleh spesifikasi HTTP. Misalnya, header Cache-Control berikut membuat konten terkait dapat dibaca dan di-cache secara publik dengan masa berlaku cache 72 jam (259.200 detik):

  Cache-Control: public, max-age=259200

Untuk memaksimalkan penayangan cache, ikuti panduan dalam Ringkasan penayangan cache. Ingatlah bahwa nilai max-age dan s-maxage di kolom metadata Cache-Control bekerja sama dengan cara berikut:

  • Nilai max-age dan s-maxage diukur dalam detik.
  • Nilai s-maxage hanya berlaku untuk cache bersama, bukan cache browser.
  • Nilai max-age berlaku untuk semua cache kecuali jika s-maxage menggantikannya.

Untuk konten yang jarang berubah atau yang harus berubah bersama dengan konten terkait, sebaiknya gunakan waktu habis masa berlaku yang lama bersama dengan URL berversi.

Menggunakan URL berversi untuk memperbarui konten

Membuat versi konten menyajikan versi konten yang sama, yang secara efektif menghapusnya dengan menampilkan konten baru kepada pengguna sebelum entri cache berakhir. Karena pembuatan versi gratis, sebaiknya gunakan pembuatan versi sebagai pendekatan default untuk memperbarui konten yang dapat di-cache.

Untuk membuat versi konten, tambahkan parameter ke URL, seperti nomor versi. Ada berbagai cara untuk menyertakan parameter dalam URL, seperti:

  • Tambahkan string kueri: file.ext?v=100.

    Untuk bucket backend, string kueri yang digunakan untuk pembuatan versi harus ditentukan dalam konfigurasi bucket backend. Untuk mengetahui informasi selengkapnya, lihat Daftar sertakan string kueri untuk kunci cache Cloud Storage.

  • Ubah nama file: file.1.0.0.ext atau file_v100.ext.

  • Ubah jalur: /v100/file.ext.

Saat menambahkan parameter, Anda mengubah nama file dan URL. Perubahan ini memaksa cache untuk mengabaikan entri cache yang ada.

Gunakan pembatalan sesedikit mungkin untuk menghapus konten

Invalidasi menghapus konten dari server cache terdistribusi Cloud CDN sebelum entri cache berakhir. Pembatalan validasi memiliki konsistensi tertunda.

Sebaiknya gunakan pembatalan dengan hemat dan hanya sebagai upaya terakhir. Misalnya, pembatalan berguna jika Anda harus menghapus konten karena alasan hukum atau karena upload yang tidak disengaja. Jika tidak, sebaiknya Anda menggunakan pembuatan versi jika memungkinkan atau menunggu hingga konten berakhir secara normal. Server cache Cloud CDN secara rutin mengeluarkan konten yang jarang diakses untuk memberi ruang bagi konten baru. Konten yang tidak diakses selama 30 hari akan dihapus tanpa syarat.

Pembatalan cache dibatasi frekuensinya.

Untuk mempelajari pembatalan lebih lanjut, lihat Ringkasan pembatalan cache.

Mengoptimalkan konsistensi file yang diupload

Praktik yang direkomendasikan berikut membantu mengoptimalkan konsistensi upload file.

Menghindari pembaruan file yang ada

Daripada memperbarui file yang ada, upload versi baru.

Untuk file baru, gunakan nama unik yang dapat menyertakan nomor versi atau tanggal. Menambahkan nomor versi (misalnya, file_v2.css) atau tanggal (misalnya, file_20230806.js) ke nama file akan membantu memastikan Cloud CDN mengambil versi yang benar dan terbaru. Menambahkan parameter ke URL file (misalnya, file.css?v=2) untuk memaksa versi baru diambil tidak direkomendasikan karena pendekatan ini tidak mengatasi risiko meng-cache update file asal non-atomik, yang mana file sebagian atau tidak lengkap masih dapat di-cache.

Anda harus mengupload versi baru dependensi sebelum mengupload file yang mereferensikannya. Praktik ini membantu memastikan bahwa semua referensi mengarah ke file yang lengkap dan terbaru, sehingga mengurangi risiko penayangan file yang diperbarui sebagian atau terpotong.

Membuat update atomik pada file

Jika perlu memperbarui file yang ada, lakukan secara atomik.

Jika file diakses dan di-cache sebelum upload selesai, file tersebut mungkin di-cache sebagai file yang tidak lengkap atau terpotong. Misalnya, file seperti /index.html tidak boleh memiliki nama unik, tetapi dapat menunjuk ke file lain yang memiliki nama unik.

Mengupload file dengan nama targetnya dapat menyebabkan file yang tidak lengkap di-cache saat diakses selama proses upload. Sebagai gantinya, upload file dengan nama sementara, lalu ganti namanya menjadi nama target hanya setelah upload selesai. Praktik ini membantu memastikan bahwa file tersedia sepenuhnya dan langsung saat dirujuk.

Saat file yang ada diperbarui, penyimpanan cache rentang byte dapat menyebabkan Cloud CDN menyimpan rentang file sebelumnya setelah file baru diupload. Jika Cloud CDN telah menyimpan rentang file sebelumnya dalam cache, permintaan untuk potongan yang hilang dapat menyebabkan respons parsial. Hal ini terjadi karena Cloud CDN mendeteksi bahwa file asal telah berubah (karena etag atau last-modified berubah), menghapus konten yang tidak relevan, menghentikan download yang sedang berlangsung, dan menghasilkan error, yang meminta klien untuk mencoba lagi. Untuk mengurangi masalah ini, batalkan validasi file yang di-cache rentang byte yang sedang diupdate.

Mengoptimalkan Monitoring dan Logging

Praktik yang direkomendasikan berikut membantu mengoptimalkan Monitoring dan Logging.

Pastikan logging diaktifkan untuk Cloud CDN

Praktik terbaik untuk mengelola Cloud CDN adalah dengan memastikan bahwa logging diaktifkan untuk semua backend yang mendukung Cloud CDN.

Menggunakan dasbor pemantauan kustom untuk Cloud CDN

Untuk memastikan keandalan dan performa yang lebih baik, praktik terbaiknya adalah meninjau metrik pemantauan yang terkait dengan Cloud CDN secara rutin. Tempat yang tepat untuk memulai adalah dengan dasbor pemantauan kustom Cloud CDN.

Meninjau pengujian performa pihak ketiga

Tinjau laporan dari penyedia pihak ketiga, seperti laporan ketersediaan, latensi, dan throughput yang disediakan oleh Citrix Radar.