Tingkatkan performa menggunakan jaringan penayangan konten (CDN).
Jaringan penayangan konten (CDN) meningkatkan performa situs menggunakan jaringan server terdistribusi untuk memberikan resource kepada pengguna. Karena CDN mengurangi beban server, CDN mengurangi biaya server dan cocok untuk menangani lonjakan traffic. Artikel ini membahas cara kerja CDN dan memberikan panduan yang tidak bergantung pada platform terkait memilih, mengonfigurasi, dan mengoptimalkan penyiapan CDN.
Ringkasan
Jaringan penayangan konten terdiri dari jaringan server yang dioptimalkan untuk mengirimkan konten dengan cepat kepada pengguna. Meskipun CDN dianggap paling terkenal untuk menyajikan konten yang di-cache, CDN juga dapat meningkatkan penayangan konten yang tidak dapat disimpan dalam cache. Secara umum, semakin banyak situs yang ditayangkan oleh CDN, semakin baik.
Pada tingkat tinggi, manfaat performa CDN berasal dari beberapa prinsip: Server CDN terletak lebih dekat dengan pengguna daripada server asal, sehingga memiliki latensi waktu round-trip (RTT) yang lebih singkat; pengoptimalan jaringan memungkinkan CDN menayangkan konten lebih cepat daripada jika konten dimuat "secara langsung" dari server asal; terakhir, cache CDN menghilangkan kebutuhan untuk melakukan perjalanan ke server asal.
Pengiriman resource
Meskipun mungkin tampak tidak intuitif, menggunakan CDN untuk memberikan sumber daya (bahkan yang tidak dapat di-cache) biasanya akan lebih cepat daripada meminta pengguna memuat sumber daya "secara langsung" dari server Anda.
Ketika CDN digunakan untuk mengirimkan resource dari asal, koneksi baru dibuat antara klien dan server CDN terdekat. Sisa perjalanan ini (dengan kata lain, transfer data antara asal dan server CDN) terjadi melalui jaringan CDN - yang sering kali mencakup koneksi persisten yang ada dengan asal. Manfaat dari hal ini ada dua: mengakhiri koneksi baru sedekat mungkin dengan pengguna akan menghilangkan biaya penyiapan koneksi yang tidak perlu (membuat koneksi baru mahal dan memerlukan beberapa roundtrip); menggunakan koneksi yang sudah dihangatkan memungkinkan data untuk segera ditransfer pada throughput maksimum yang memungkinkan.
Beberapa CDN memperbaiki hal ini lebih jauh dengan mengarahkan traffic ke asal melalui beberapa server CDN yang tersebar di Internet. Koneksi antara server CDN terjadi melalui rute yang andal dan sangat dioptimalkan, bukan rute yang ditentukan oleh Border Gateway Protocol (BGP). Meskipun BGP adalah protokol perutean de facto internet, keputusan peruteannya tidak selalu berorientasi pada performa. Oleh karena itu, rute yang ditentukan BGP cenderung kurang berperforma baik daripada rute antar-server CDN yang telah disesuaikan dengan baik.
Menyimpan ke cache
Menyimpan resource dalam cache di server CDN menghilangkan kebutuhan atas permintaan untuk melakukan perjalanan hingga ke lokasi asal agar dapat dilayani. Hasilnya, resource dikirimkan lebih cepat; hal ini juga mengurangi beban pada server asal.
Menambahkan resource ke cache
Metode yang paling umum digunakan untuk mengisi cache CDN adalah meminta CDN "menarik" resource sesuai kebutuhan - ini dikenal sebagai "origin pull". Saat pertama kali meminta resource tertentu dari cache, CDN akan memintanya dari server asal dan meng-cache respons. Dengan cara ini, konten cache akan bertambah dari waktu ke waktu saat ada permintaan tambahan untuk resource yang tidak di-cache.
Menghapus resource dari cache
CDN menggunakan penghapusan cache untuk menghapus resource yang tidak terlalu berguna dari cache secara berkala. Selain itu, pemilik situs dapat menggunakan pembersihan untuk menghapus resource secara eksplisit.
Penghapusan cache
Cache memiliki kapasitas penyimpanan terbatas. Ketika cache mendekati kapasitasnya, akan ada ruang bagi sumber daya baru dengan menghapus sumber daya yang belum diakses baru-baru ini, atau yang menggunakan banyak ruang. Proses ini dikenal sebagai penghapusan cache. Resource yang dikeluarkan dari satu cache tidak selalu berarti bahwa resource tersebut telah dikeluarkan dari semua cache di jaringan CDN.
Menghapus permanen
Pembersihan (juga dikenal sebagai "pembatalan validasi cache") adalah mekanisme untuk menghapus resource dari cache CDN tanpa harus menunggu hingga masa berlakunya habis atau dikeluarkan. Ini biasanya dijalankan melalui API. Penghapusan konten sangat penting dalam situasi ketika konten perlu dicabut (misalnya, mengoreksi kesalahan ketik, kesalahan harga, atau artikel berita yang salah). Selain itu, hal ini juga dapat memainkan peran penting dalam strategi caching situs.
Jika CDN mendukung pembersihan jarak dekat, pembersihan dapat digunakan sebagai mekanisme untuk mengelola penyimpanan konten dinamis ke dalam cache: menyimpan konten dinamis ke dalam cache menggunakan TTL yang panjang, lalu menghapus permanen resource setiap kali diupdate. Dengan cara ini, Anda dapat memaksimalkan durasi cache sumber daya dinamis, meskipun Anda tidak mengetahui sebelumnya kapan sumber daya akan berubah. Teknik ini terkadang disebut sebagai "hold-till-told caching".
Saat penghapusan digunakan dalam skala besar, pembersihan ini biasanya digunakan bersamaan dengan konsep yang dikenal sebagai "tag cache" atau "kunci cache surrogate". Mekanisme ini memungkinkan pemilik situs mengaitkan satu atau beberapa ID tambahan (terkadang disebut sebagai "tag") dengan resource yang di-cache. Tag ini kemudian dapat digunakan untuk melakukan pembersihan yang sangat terperinci. Misalnya, Anda mungkin menambahkan tag "footer" ke semua resource (misalnya,
/about,/blog) yang berisi footer situs Anda. Saat footer diupdate, instruksikan CDN untuk menghapus semua resource yang terkait dengan tag "footer".
Resource yang dapat di-cache
Jika dan bagaimana resource harus di-cache bergantung pada apakah resource tersebut bersifat publik atau pribadi; statis atau dinamis.
Referensi pribadi dan publik
Referensi Pribadi
Resource pribadi berisi data yang ditujukan untuk satu pengguna, sehingga tidak boleh di-cache oleh CDN. Resource pribadi ditunjukkan oleh header
Cache-Control: private.Referensi Publik
Resource publik tidak berisi informasi spesifik pengguna, sehingga dapat di-cache oleh CDN. Resource dapat dianggap dapat di-cache oleh CDN jika tidak memiliki header
Cache-Control: no-storeatauCache-Control: private. Durasi saat resource publik dapat di-cache bergantung pada seberapa sering aset berubah.
Konten dinamis dan statis
Konten dinamis
Konten dinamis adalah konten yang sering berubah. Respons API dan halaman beranda toko adalah contoh jenis konten ini. Namun, fakta bahwa konten ini sering berubah tidak selalu mencegahnya untuk disimpan dalam cache. Selama periode traffic padat, menyimpan respons ini dalam cache dalam waktu yang sangat singkat (misalnya, 5 detik) dapat mengurangi beban pada server origin secara signifikan, sekaligus berdampak minimal pada keaktualan data.
Konten statis
Konten statis jarang berubah, jika pernah. Gambar, video, dan library berversi biasanya merupakan contoh jenis konten ini. Karena konten statis tidak berubah, konten tersebut harus di-cache dengan Time to Live (TTL) yang panjang - misalnya, 6 bulan atau 1 tahun.
Memilih CDN
Performa biasanya menjadi pertimbangan utama saat memilih CDN. Namun, fitur lain yang ditawarkan CDN (misalnya, fitur keamanan dan analisis), serta harga, dukungan, dan orientasi CDN semuanya penting untuk dipertimbangkan saat memilih CDN.
Performa
Pada tingkat tinggi, strategi performa CDN dapat dipertimbangkan dalam hal kompromi antara meminimalkan latensi dan memaksimalkan rasio cache ditemukan. CDN dengan banyak titik kehadiran (PoP) dapat memberikan latensi yang lebih rendah, tetapi mungkin mengalami rasio cache ditemukan yang lebih rendah karena traffic terbagi ke lebih banyak cache. Sebaliknya, CDN dengan PoP yang lebih sedikit mungkin terletak secara geografis lebih jauh dari pengguna, tetapi dapat mencapai rasio cache ditemukan yang lebih tinggi.
Sebagai hasil dari kompromi ini, beberapa CDN menggunakan pendekatan bertingkat untuk caching: PoP yang terletak di dekat pengguna (juga dikenal sebagai "edge cache") dilengkapi dengan PoP pusat yang memiliki rasio cache ditemukan yang lebih tinggi. Jika tidak dapat menemukan resource, edge cache akan mencari PoP pusat untuk resource tersebut. Pendekatan ini mengorbankan latensi yang sedikit lebih besar untuk mendapatkan kemungkinan lebih tinggi bahwa resource dapat disalurkan dari cache CDN - meskipun tidak harus edge cache.
Kompromi antara meminimalkan latensi dan memaksimalkan rasio cache ditemukan adalah sebuah spektrum. Tidak ada pendekatan tertentu yang secara universal lebih baik; namun, bergantung pada sifat situs dan basis penggunanya, Anda mungkin menemukan bahwa salah satu pendekatan ini menghasilkan kinerja yang jauh lebih baik daripada yang lain.
Perlu juga diperhatikan bahwa performa CDN dapat sangat bervariasi bergantung pada geografi, waktu, dan bahkan peristiwa terkini. Meskipun sebaiknya melakukan riset sendiri tentang performa CDN, mungkin sulit untuk memprediksi performa yang akan Anda dapatkan dari CDN.
Efek pada Largest Contentful Paint (LCP)
Seperti yang diuraikan sebelumnya dalam artikel ini, tujuan utama CDN adalah mengurangi latensi dengan mendistribusikan resource ke server yang secara geografis lebih dekat ke pengguna. Oleh karena itu, manfaat utama CDN adalah meningkatkan performa pemuatan. Secara khusus, Time to First Byte (TTFB) resource dapat ditingkatkan secara signifikan saat memperkenalkan CDN ke arsitektur sisi server situs Anda.
Meskipun TTFB bukanlah metrik performa yang berfokus pada pengguna, TTFB merupakan metrik penting untuk mendiagnosis masalah dengan Largest Contentful Paint (LCP), yang merupakan metrik yang berfokus pada pengguna.
CDN sangat efektif dalam meningkatkan LCP karena dapat meningkatkan penayangan dokumen (dengan mengurangi TTFB dalam penyiapan koneksi dan dalam cache dokumen) serta dalam meningkatkan pengiriman resource statis yang diperlukan untuk merender elemen LCP.
Fitur tambahan
CDN biasanya menawarkan berbagai fitur selain penawaran CDN inti. Fitur yang umumnya ditawarkan meliputi: load balancing, pengoptimalan gambar, streaming video, edge computing, dan produk keamanan.
Cara menyiapkan dan mengonfigurasi CDN
Idealnya, Anda harus menggunakan CDN untuk menayangkan seluruh situs Anda. Pada tingkat tinggi, proses penyiapan untuk hal ini terdiri dari mendaftar ke penyedia CDN, lalu memperbarui data DNS CNAME agar mengarah ke penyedia CDN. Misalnya, data CNAME untuk www.example.com mungkin mengarah ke example.my-cdn.com. Akibat perubahan DNS ini, traffic ke situs Anda akan dirutekan melalui CDN.
Jika tidak memungkinkan untuk menggunakan CDN untuk menyajikan semua resource, Anda dapat mengonfigurasi CDN agar hanya melayani sebagian resource - misalnya, hanya resource statis. Anda dapat melakukan ini dengan membuat data CNAME terpisah yang hanya akan digunakan untuk resource yang seharusnya disalurkan oleh CDN. Misalnya, Anda dapat membuat data CNAME static.example.com yang mengarah ke example.my-cdn.com. Anda juga perlu menulis ulang URL resource yang disalurkan oleh CDN agar mengarah ke subdomain static.example.com yang Anda buat.
Meskipun CDN Anda akan disiapkan pada tahap ini, kemungkinan akan ada inefisiensi dalam konfigurasi Anda. Dua bagian selanjutnya dari artikel ini akan menjelaskan cara mendapatkan hasil maksimal dari CDN dengan meningkatkan rasio cache ditemukan dan mengaktifkan fitur performa.
Meningkatkan rasio cache ditemukan
Pengaturan CDN yang efektif akan menyajikan sebanyak mungkin resource dari cache. Hal ini biasanya diukur berdasarkan rasio cache ditemukan (CHR). Rasio cache ditemukan didefinisikan sebagai jumlah hit cache dibagi dengan jumlah total permintaan selama interval waktu tertentu.
Cache yang baru diinisialisasi akan memiliki CHR 0, tetapi akan meningkat saat cache diisi dengan resource. CHR sebesar 90% adalah sasaran yang bagus untuk sebagian besar situs. Penyedia CDN harus memberi Anda analisis dan pelaporan terkait CHR Anda.
Saat mengoptimalkan CHR, hal pertama yang harus diverifikasi adalah bahwa semua sumber daya yang dapat di-cache akan di-cache dan di-cache untuk jangka waktu yang benar. Tindakan ini adalah penilaian sederhana yang harus dilakukan oleh semua situs.
Tingkat pengoptimalan CHR berikutnya, secara luas, adalah menyesuaikan setelan CDN untuk memastikan bahwa respons server yang setara secara logis tidak di-cache secara terpisah. Ini adalah inefisiensi umum yang terjadi karena dampak faktor seperti parameter kueri, cookie, dan header permintaan terhadap cache.
Audit awal
Sebagian besar CDN akan menyediakan analisis cache. Selain itu, alat seperti WebPageTest dan Lighthouse juga dapat digunakan untuk memverifikasi dengan cepat bahwa semua resource statis halaman di-cache untuk jangka waktu yang benar. Hal ini dilakukan dengan memeriksa {i> header<i} Cache HTTP dari setiap sumber daya. Menyimpan resource ke dalam cache menggunakan Time To Live (TTL) maksimum yang sesuai akan menghindari pengambilan origin yang tidak perlu di masa mendatang sehingga meningkatkan CHR.
Setidaknya, salah satu header ini biasanya perlu ditetapkan agar resource dapat di-cache oleh CDN:
Cache-Control: max-age=Cache-Control: s-maxage=Expires
Selain itu, meskipun tidak memengaruhi apakah atau bagaimana resource di-cache oleh CDN, sebaiknya tetapkan juga perintah Cache-Control: immutable.Cache-Control: immutable menunjukkan bahwa resource "tidak akan diperbarui selama masa keaktualannya". Akibatnya, browser tidak akan memvalidasi ulang sumber daya ketika menyajikannya dari cache browser, sehingga menghilangkan permintaan server yang tidak perlu. Sayangnya, perintah ini hanya didukung oleh Firefox dan Safari - perintah ini tidak didukung oleh browser berbasis Chromium. Masalah ini melacak dukungan Chromium untuk Cache-Control: immutable. Memberi bintang pada masalah ini dapat membantu mendorong dukungan untuk fitur ini.
Untuk mengetahui penjelasan lebih detail tentang cache HTTP, lihat Mencegah permintaan jaringan yang tidak perlu dengan Cache HTTP.
Fine tuning
Penjelasan yang sedikit disederhanakan tentang cara kerja cache CDN adalah bahwa URL resource digunakan sebagai kunci untuk melakukan cache dan mengambil resource dari cache. Dalam praktiknya, hal ini masih banyak terjadi, tetapi sedikit rumit oleh dampak dari hal-hal seperti header permintaan dan parameter kueri. Oleh karena itu, menulis ulang URL permintaan adalah teknik penting untuk memaksimalkan CHR dan memastikan bahwa konten yang benar ditayangkan kepada pengguna. Instance CDN yang dikonfigurasi dengan benar mencapai keseimbangan yang tepat antara penyimpanan cache yang terlalu terperinci (yang berdampak buruk pada CHR) dan penyimpanan cache yang tidak cukup terperinci (yang menyebabkan respons yang salah ditampilkan kepada pengguna).
Parameter kueri
Secara default, CDN mempertimbangkan parameter kueri saat meng-cache resource. Namun, penyesuaian kecil pada penanganan parameter kueri dapat memiliki dampak yang signifikan terhadap CHR. Contoh:
Parameter kueri yang tidak diperlukan
Secara default, CDN akan meng-cache
example.com/blogdanexample.com/blog?referral_id=2zjksecara terpisah meskipun keduanya kemungkinan merupakan resource dasar yang sama. Hal ini diperbaiki dengan menyesuaikan konfigurasi CDN untuk mengabaikan parameter kuerireferral\_id.Urutan parameter kueri
CDN akan menyimpan
example.com/blog?id=123&query=dogske dalam cache secara terpisah dariexample.com/blog?query=dogs&id=123. Untuk sebagian besar situs, urutan parameter kueri tidak menjadi masalah, jadi mengonfigurasi CDN untuk mengurutkan parameter kueri (sehingga menormalisasi URL yang digunakan untuk meng-cache respons server) akan meningkatkan CHR.
Bervariasi
Header respons Variant memberi tahu cache bahwa respons server yang sesuai dengan URL tertentu dapat berbeda tergantung header yang disetel pada permintaan (misalnya, header permintaan Accept-Language atau Accept-Encoding). Akibatnya, CDN menginstruksikan CDN untuk menyimpan respons ini secara terpisah ke dalam cache. Header misc tidak didukung secara luas oleh CDN dan bisa mengakibatkan sumber daya yang bisa di-cache tidak disajikan dari cache.
Meskipun header misc bisa menjadi alat yang berguna, penggunaan yang tidak tepat dapat menurunkan CHR. Selain itu, jika Anda menggunakan Vary, menormalisasi header permintaan akan membantu meningkatkan CHR. Misalnya, tanpa normalisasi, header permintaan Accept-Language: en-US dan Accept-Language: en-US,en;q=0.9 akan menghasilkan dua entri cache terpisah, meskipun kontennya mungkin akan identik.
Kukis
Cookie ditetapkan pada permintaan melalui header Cookie; cookie ditetapkan pada respons melalui header Set-Cookie. Penggunaan header Set-Cookie yang tidak perlu harus dihindari karena cache biasanya tidak akan menyimpan respons server yang berisi header ini ke dalam cache.
Fitur performa
Bagian ini membahas fitur performa yang biasanya ditawarkan oleh CDN sebagai bagian dari penawaran produk intinya. Banyak situs lupa mengaktifkan fitur ini, sehingga kehilangan kemenangan kinerja yang mudah.
Kompresi
Semua respons berbasis teks harus dikompresi dengan gzip atau Brotli. Jika dapat memilih, pilih Brotli daripada gzip. Brotli adalah algoritma kompresi yang lebih baru, dan dibandingkan dengan gzip, dapat mencapai rasio kompresi yang lebih tinggi.
Ada dua jenis dukungan CDN untuk kompresi Brotli: "Brotli dari asal" dan "kompresi Brotli otomatis".
Brotli dari origin
Brotli dari origin adalah saat CDN melayani resource yang dikompresi Brotli oleh origin. Meskipun ini mungkin tampak seperti fitur yang harus langsung dapat didukung oleh semua CDN, fitur ini mengharuskan CDN untuk dapat meng-cache beberapa versi (dengan kata lain, versi yang dikompresi dengan gzip dan yang dikompresi Brotli) dari resource yang sesuai dengan URL yang diberikan.
Kompresi Brotli otomatis
Kompresi Brotli otomatis adalah saat resource Brotli dikompresi oleh CDN. CDN dapat mengompresi resource yang dapat di-cache dan yang tidak dapat disimpan dalam cache.
Pertama kali resource diminta, resource akan ditayangkan menggunakan kompresi "cukup baik" - misalnya, Brotli-5. Jenis kompresi ini berlaku pada sumber daya yang dapat disimpan dalam cache dan yang tidak dapat disimpan dalam cache.
Sementara itu, jika sumber daya dapat di-cache, CDN akan menggunakan pemrosesan offline untuk mengompresi sumber daya pada tingkat kompresi yang lebih kuat tetapi jauh lebih lambat - misalnya, Brotli-11. Setelah kompresi ini selesai, versi yang lebih dikompresi akan di-cache dan digunakan untuk permintaan berikutnya.
Praktik terbaik kompresi
Situs yang ingin memaksimalkan performa harus menerapkan kompresi Brotli di server asal dan CDN. Kompresi Brotli di origin akan meminimalkan ukuran transfer resource yang tidak dapat disalurkan dari cache. Untuk mencegah penundaan dalam melayani permintaan, origin harus mengompresi resource dinamis menggunakan level kompresi yang cukup konservatif - misalnya, Brotli-4; resource statis dapat dikompresi menggunakan Brotli-11. Jika origin tidak mendukung Brotli, gzip-6 dapat digunakan untuk mengompresi resource dinamis; gzip-9 dapat digunakan untuk mengompresi resource statis.
TLS 1.3
TLS 1.3 adalah versi terbaru Transport Layer Security (TLS), protokol kriptografi yang digunakan oleh HTTPS. TLS 1.3 memberikan privasi dan performa yang lebih baik dibandingkan TLS 1.2.
TLS 1.3 mempersingkat handshake TLS dari dua roundtrip menjadi satu. Untuk koneksi yang menggunakan HTTP/1 atau HTTP/2, mempersingkat handshake TLS menjadi satu kali bolak-balik secara efektif mengurangi waktu penyiapan koneksi sebesar 33%.
HTTP/2 dan HTTP/3
HTTP/2 dan HTTP/3 memberikan manfaat performa dibandingkan HTTP/1. Dari keduanya, HTTP/3 menawarkan potensi manfaat performa yang lebih besar. HTTP/3 belum sepenuhnya distandardisasi, tetapi akan didukung secara luas setelah hal ini terjadi.
HTTP/2
Jika CDN belum mengaktifkan HTTP/2 secara default, sebaiknya pertimbangkan untuk mengaktifkannya. HTTP/2 memberikan beberapa manfaat performa dibandingkan HTTP/1 dan didukung oleh semua browser utama. Fitur performa HTTP/2 mencakup: multiplexing, penentuan prioritas, dan kompresi header.
Multiplexing
Multiplexing bisa dikatakan sebagai fitur terpenting dari HTTP/2. Multiplexing memungkinkan koneksi TCP tunggal untuk menyajikan beberapa pasangan permintaan-respons secara bersamaan. Hal ini menghilangkan overhead penyiapan koneksi yang tidak perlu; mengingat jumlah koneksi yang dapat dibuka browser pada waktu tertentu terbatas, hal ini juga memiliki implikasi bahwa browser sekarang dapat meminta lebih banyak resource halaman secara paralel. Multiplexing secara teoritis menghilangkan kebutuhan akan pengoptimalan HTTP/1 seperti penyambungan dan sprite sheet - namun, dalam praktiknya, teknik ini akan tetap relevan mengingat file yang lebih besar dikompresi dengan lebih baik.
Penentuan prioritas streaming
Multiplexing memungkinkan beberapa streaming serentak; prioritas streaming menyediakan antarmuka untuk mengomunikasikan prioritas relatif dari setiap streaming tersebut. Hal ini membantu server untuk mengirim sumber daya yang paling penting terlebih dahulu - bahkan jika sumber daya tersebut tidak diminta terlebih dahulu.
Prioritas streaming ditentukan oleh browser melalui hierarki dependensi dan hanya merupakan pernyataan preferensi: dengan kata lain, server tidak berkewajiban untuk memenuhi (atau bahkan mempertimbangkan) prioritas yang disediakan browser. Penentuan prioritas streaming menjadi lebih efektif jika lebih banyak situs ditayangkan melalui CDN.
Implementasi CDN dari prioritas resource HTTP/2 sangat bervariasi. Untuk mengidentifikasi apakah CDN Anda mendukung prioritas resource HTTP/2 sepenuhnya dan benar, lihat Apakah HTTP/2 Cepat Belum?.
Meskipun mengalihkan instance CDN ke HTTP/2 sebagian besar adalah proses yang mudah, penting untuk menguji perubahan ini secara menyeluruh sebelum mengaktifkannya dalam produksi. HTTP/1 dan HTTP/2 menggunakan konvensi yang sama untuk header permintaan dan respons - tetapi HTTP/2 akan jauh lebih tidak memaafkan jika konvensi ini tidak dipatuhi. Akibatnya, praktik non-spesifikasi seperti menyertakan karakter non-ASCII atau huruf besar dalam header dapat mulai menyebabkan error setelah HTTP/2 diaktifkan. Jika hal ini terjadi, upaya browser untuk mendownload resource akan gagal. Upaya download yang gagal akan terlihat di tab "Jaringan" di DevTools. Selain itu, pesan error "ERR_HTTP2_PROTOCOL_ERROR" akan ditampilkan di konsol.
HTTP/3
HTTP/3 adalah penerus HTTP/2. Mulai September 2020, semua browser utama memiliki dukungan eksperimental untuk HTTP/3 dan beberapa CDN mendukungnya. Performa adalah manfaat utama HTTP/3 dibandingkan HTTP/2. Secara khusus, HTTP/3 menghilangkan pemblokiran head-of-line di tingkat koneksi dan mengurangi waktu penyiapan koneksi.
Penghapusan pemblokiran head-of-line
HTTP/2 memperkenalkan multiplexing, fitur yang memungkinkan satu koneksi digunakan untuk mengirimkan beberapa aliran data secara bersamaan. Namun, dengan HTTP/2, satu paket yang dilepas akan memblokir semua streaming pada koneksi (fenomena yang dikenal sebagai pemblokiran head-of-line). Dengan HTTP/3, paket yang dilepaskan hanya memblokir satu streaming. Peningkatan ini sebagian besar dihasilkan dari HTTP/3 yang menggunakan UDP (HTTP/3 menggunakan UDP melalui QUIC), bukan TCP. Hal ini membuat HTTP/3 sangat berguna untuk transfer data melalui jaringan yang padat atau lossy.
Mengurangi waktu penyiapan koneksi
HTTP/3 menggunakan TLS 1.3 sehingga berbagi manfaat performanya: membuat koneksi baru hanya memerlukan satu kali bolak-balik dan melanjutkan koneksi yang ada tidak memerlukan perjalanan bolak-balik.
HTTP/3 akan memiliki dampak terbesar pada pengguna pada koneksi jaringan yang buruk: bukan hanya karena HTTP/3 menangani kehilangan paket dengan lebih baik daripada pendahulunya, tetapi juga karena penghematan waktu absolut yang dihasilkan dari pengaturan koneksi 0-RTT atau 1-RTT akan lebih besar pada jaringan dengan latensi tinggi.
Pengoptimalan gambar
Layanan pengoptimalan gambar CDN biasanya berfokus pada pengoptimalan gambar yang dapat diterapkan secara otomatis untuk mengurangi ukuran transfer gambar. Misalnya: menghapus data EXIF, menerapkan kompresi lossless, dan mengonversi gambar ke format file yang lebih baru (misalnya, WebP). Gambar membentuk ~50% byte transfer di halaman web median, sehingga mengoptimalkan gambar dapat mengurangi ukuran halaman secara signifikan.
Minifikasi
Minifikasi menghapus karakter yang tidak diperlukan dari JavaScript, CSS, dan HTML. Sebaiknya lakukan minifikasi di server asal, daripada CDN. Pemilik situs memiliki lebih banyak konteks tentang kode yang harus diminifikasi, sehingga sering kali dapat menggunakan teknik minifikasi yang lebih agresif daripada yang digunakan oleh CDN. Namun, jika meminifikasi kode di asal tidak memungkinkan, minifikasi dengan CDN adalah alternatif yang baik.
Kesimpulan
- Gunakan CDN: CDN mengirimkan resource dengan cepat, mengurangi beban di server asal, dan sangat membantu untuk menangani lonjakan traffic.
- Simpan konten dalam cache se agresif mungkin: Konten statis dan dinamis dapat dan sebaiknya di-cache - meskipun dalam berbagai durasi. Audit situs Anda secara berkala untuk memastikan bahwa Anda meng-cache konten secara optimal.
- Aktifkan fitur performa CDN: Fitur seperti Brotli, TLS 1.3, HTTP/2, dan HTTP/3 meningkatkan performa lebih lanjut.