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 server 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:

Berkat 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 menyempurnakan deployment Anda. Untuk mengetahui informasi selengkapnya, baca bagian Menyiapkan Cloud CDN.

Mengoptimalkan rasio cache ditemukan

Praktik yang direkomendasikan berikut membantu mengoptimalkan rasio cache ditemukan.

Meng-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 server asal, rekomendasi praktik terbaiknya adalah mengizinkan Cloud CDN untuk otomatis meng-cache konten statis.

Untuk otomatis meng-cache respons statis dari server asal, Anda dapat menggunakan setelan --cache-mode=CACHE_ALL_STATIC (default). Setelan ini memungkinkan Cloud CDN meng-cache jenis konten statis umum saat server asal tidak menentukan perintah caching apa pun di header respons. Pastikan konten Anda sesuai dengan kategori yang diuraikan. Jika tidak, konten tidak akan di-cache.

Jangan meng-cache konten khusus pengguna

Dalam beberapa kasus, browser dapat meng-cache konten khusus pengguna. Jangan gunakan Cloud CDN untuk meng-cache konten khusus pengguna.

Menggunakan kunci cache kustom untuk meningkatkan rasio cache ditemukan

Demi performa dan skalabilitas, rasio cache ditemukan sebaiknya dioptimalkan. Secara default, Cloud CDN menggunakan URL permintaan lengkap untuk membuat kunci cache. Untuk membantu mengoptimalkan rasio cache ditemukan, Anda dapat menggunakan kunci cache kustom agar Cloud CDN tidak meng-shard cache secara tidak perlu.

Penyimpanan nilai kunci Cloud CDN (klik untuk memperbesar).

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

  • Anda memiliki dua host yang di-resolve ke alamat IP yang sama dan mengarah ke layanan yang sama. Dalam contoh ini, seluruh situs sama di kedua host. Secara default, Cloud CDN meng-cache dua salinan karena header Host: 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 berbeda yang menggunakan logo sama. Konten situsnya berbeda, tetapi Anda menggunakan logo perusahaan yang sama di kedua domain, dan Anda memiliki layanan backend khusus yang menampung konten bersama. Saat Anda mengaktifkan Cloud CDN dan menyesuaikan kunci cache untuk layanan backend yang menampung logo, hapus centang dari kotak Host agar cache mengabaikan domain, tetapi meng-cache logo.

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

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

Mengoptimalkan performa

Praktik yang direkomendasikan berikut membantu mengoptimalkan performa.

Memastikan dukungan protokol HTTP/3 dan QUIC diaktifkan

HTTP/3 adalah protokol internet generasi berikutnya. HTTP/3 dibangun berdasarkan QUIC, protokol yang dikembangkan dari protokol Google QUIC (gQUIC) asli. HTTP/3 didukung di 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 menampung respons tersebut di dalam cache selama TTL yang ditetapkan. Hal ini dapat mengurangi beban pada server asal dan meningkatkan kualitas pengalaman pengguna akhir dengan mengurangi latensi respons.

Mengaktifkan data awal TLS

Penggunaan data awal TLS meningkatkan rasio koneksi 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, baca bagian 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. Metode ini lebih aman dan dapat digunakan dalam sebagian besar kasus.
  • PERMISSIVE: Mengaktifkan data awal untuk metode idempoten yang dapat mencakup parameter kueri. Saat menggunakan mode ini, Anda harus memantau dengan cermat perilaku aplikasi dan postur keamanan Anda.

Permintaan data awal yang menggunakan metode HTTP non-idempoten atau memiliki parameter kueri akan 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 baik untuk konten yang di-cache maupun tidak di-cache atau cache tidak ditemukan. Rekomendasi praktik terbaiknya adalah menggunakan Cloud Armor bersama dengan Cloud CDN, jika memungkinkan, untuk meningkatkan keamanan aplikasi web.

Menggunakan URL bertanda tangan

Jika Anda menggunakan URL bertanda tangan, perhatikan hal berikut:

Mengautentikasi server asal pribadi

Autentikasi server asal memberikan jaminan kuat bahwa permintaan hanya berasal dari layanan backend yang Anda konfigurasi sendiri. Fitur ini juga menawarkan perlindungan data dalam pengiriman untuk permintaan tersebut dan memberikan perlindungan dari penggunaan kembali bagian permintaan yang bertanda tangan.

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

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

Mengoptimalkan cache

Praktik yang direkomendasikan berikut membantu mengoptimalkan cache.

Mengoptimalkan TTL cache

Anda dapat menetapkan atau mengganti TTL untuk menyesuaikan berapa lama Cloud CDN akan meng-cache respons Anda dan kapan Cloud CDN akan memvalidasi ulang respons Anda.

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

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

Menetapkan waktu habis masa berlaku untuk konten yang sensitif waktu

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

Salah satu metode untuk memilih waktu habis masa berlaku adalah mengategorikan konten berdasarkan seberapa sering Anda memperbaruinya; 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 waktu habis masa berlaku menurut kategori konten. Misalnya, waktu habis masa berlaku lima detik mungkin sesuai untuk skor olahraga yang hampir real-time, dan waktu habis masa berlaku satu jam dapat digunakan untuk informasi cuaca. Untuk konten yang disimpan di Cloud Storage, tetapkan waktu habis masa berlakunya menggunakan metadata Cache-Control. Saat konten disajikan oleh Compute Engine, Anda dapat mengontrol waktu habis masa berlaku dengan mengonfigurasi software server web.

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

  Cache-Control: public, max-age=259200

Untuk memaksimalkan caching, ikuti panduan dalam Ringkasan caching. Ingat 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 panjang bersama dengan URL berversi.

Menggunakan URL berversi untuk memperbarui konten

Pembuatan versi konten akan menyajikan versi berbeda dari konten yang sama, yang secara efektif akan menghapus konten lama dengan menampilkan konten baru kepada pengguna sebelum masa berlaku entri cache tersebut berakhir. Karena pembuatan versi ini gratis, sebaiknya gunakan metode ini sebagai pendekatan default untuk memperbarui konten yang dapat di-cache.

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

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

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

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

  • Mengubah jalur: /v100/file.ext.

Saat parameter ditambahkan, nama file dan URL akan berubah. Perubahan ini memaksa cache untuk mengabaikan entri cache yang ada.

Menggunakan invalidasi seperlunya untuk menghapus konten

Invalidasi menghapus konten dari server cache terdistribusi Cloud CDN sebelum masa berlaku entri cache tersebut berakhir. Invalidasi memiliki konsistensi tertunda.

Sebaiknya gunakan invalidasi seperlunya dan hanya sebagai upaya terakhir. Misalnya, invalidasi akan berguna jika Anda perlu menghapus konten karena alasan hukum atau karena upload yang tidak disengaja. Jika tidak, sebaiknya Anda menggunakan pembuatan versi sejauh dimungkinkan atau menunggu hingga masa berlaku konten habis 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.

Invalidasi cache memiliki pembatasan kapasitas.

Untuk mempelajari lebih lanjut invalidasi, lihat Ringkasan invalidasi cache.

Mengoptimalkan konsistensi file yang diupload

Praktik yang direkomendasikan berikut membantu mengoptimalkan konsistensi upload file.

Menghindari pembaruan file yang ada

Alih-alih memperbarui file yang sudah 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 pengambilan versi baru tidak direkomendasikan karena pendekatan ini tidak mengatasi risiko caching pembaruan file server asal non-atomik, di mana file parsial atau tidak lengkap masih dapat di-cache.

Anda harus mengupload versi baru dependensi sebelum mengupload file yang merujuk kepadanya. Praktik ini membantu memastikan semua rujukan mengarah ke file yang lengkap dan terbaru, sehingga mengurangi risiko penyajian 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 memiliki nama unik, tetapi dapat mengarah ke file lain yang memiliki nama unik.

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

Saat file yang sudah ada diperbarui, caching rentang byte dapat menyebabkan Cloud CDN menampung rentang file lama setelah file baru diupload. Jika Cloud CDN telah meng-cache rentang file lama, permintaan untuk potongan yang hilang dapat menghasilkan respons sebagian. Hal ini terjadi karena Cloud CDN mendeteksi bahwa file server asal telah berubah (karena etag atau last-modified berubah), menghapus konten usang, menghentikan download yang sedang berlangsung, dan menghasilkan error, sehingga mendorong klien untuk mencoba lagi. Guna memitigasi masalah ini, terbitkan invalidasi untuk file yang di-cache berdasarkan rentang byte, yang sedang diperbarui.

Mengoptimalkan Monitoring dan Logging

Praktik yang direkomendasikan berikut membantu mengoptimalkan Monitoring dan Logging.

Memastikan logging diaktifkan untuk Cloud CDN

Praktik terbaik untuk mengelola Cloud CDN adalah 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. Sebaiknya mulai 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.