[Jangan] gunakan CDN

Hampir setiap artikel atau alat untuk mengoptimalkan kecepatan situs memiliki klausul sederhana “gunakan CDN.” Secara umum, CDN adalah jaringan pengiriman konten atau content delivery network. Kami di Method Lab sering menemui pertanyaan dari klien tentang topik ini; beberapa di antaranya mengaktifkan CDN mereka sendiri. Tujuan artikel ini adalah untuk memahami apa yang dapat diberikan CDN dalam hal kecepatan memuat situs, masalah apa yang mungkin timbul, dan dalam hal apa penggunaan CDN dapat dibenarkan.

Penundaan yang dilingkari pada gambar disebabkan oleh penggunaan CDN.

Sedikit sejarah

Seperti banyak teknologi lainnya, CDN muncul karena kebutuhan. Dengan berkembangnya saluran Internet di kalangan pengguna Internet, layanan video online pun bermunculan. Tentu saja, konten video memerlukan bandwidth yang jauh lebih besar dibandingkan dengan konten situs web biasa (gambar, teks, dan kode CSS atau JS).

Saat mencoba menyiarkan aliran video secara paralel ke banyak klien dari satu server, kemungkinan besar saluran Internet server akan menjadi hambatan. Biasanya, beberapa ribu thread sudah cukup untuk menyumbat saluran server pada umumnya. Tentu saja, mungkin ada keterbatasan sumber daya lainnya, namun hal tersebut tidak penting saat ini. Penting juga bahwa perluasan saluran server terlalu mahal (dan terkadang tidak mungkin), dan juga tidak praktis. Pemuatan saluran selama siaran akan bersifat siklis.

Masalah pembatasan saluran pada server individual diselesaikan dengan sempurna oleh CDN. Klien tidak terhubung ke server secara langsung, tetapi ke node di jaringan CDN. Dalam situasi ideal, server mengirimkan satu aliran ke node CDN, dan kemudian jaringan menggunakan sumber dayanya sendiri untuk mengirimkan aliran ini ke banyak pengguna. Dari sudut pandang ekonomi, kami hanya membayar untuk sumber daya yang benar-benar dikonsumsi (bisa berupa bandwidth atau lalu lintas) dan mendapatkan skalabilitas layanan kami yang sangat baik. Menggunakan CDN untuk mengirimkan konten berat sepenuhnya dibenarkan dan logis. Meskipun perlu dicatat bahwa pemain terbesar di bidang ini (misalnya Netflix) membuat CDN mereka sendiri daripada menggunakan CDN komersial besar (Akamai, Cloudflare, Fastly, dll.)

Seiring berkembangnya web, aplikasi web itu sendiri menjadi semakin kompleks. Masalah kecepatan pemuatan mengemuka. Penggemar kecepatan situs web dengan cepat mengidentifikasi beberapa masalah utama yang menyebabkan situs web dimuat dengan lambat. Salah satunya adalah penundaan jaringan (RTT - waktu pulang pergi atau waktu ping). Penundaan memengaruhi banyak proses dalam pemuatan situs web: membuat koneksi TCP, memulai sesi TLS, memuat setiap sumber daya (gambar, file JS, dokumen HTML, dll.)

Masalahnya diperburuk oleh kenyataan bahwa ketika menggunakan protokol HTTP/1.1 (sebelum munculnya SPDY, QUIC dan HTTP/2 ini adalah satu-satunya pilihan), browser membuka tidak lebih dari 6 koneksi TCP ke satu host. Semua ini menyebabkan downtime koneksi dan penggunaan bandwidth saluran yang tidak efisien. Masalahnya sebagian diselesaikan dengan domain sharding - pembuatan host tambahan untuk mengatasi batas jumlah koneksi.

Di sinilah kemampuan CDN yang kedua muncul - mengurangi latensi (RTT) karena banyaknya titik dan kedekatan node dengan pengguna. Jarak memainkan peran yang menentukan di sini: kecepatan cahaya terbatas (sekitar 200 km/detik dalam serat optik). Artinya setiap 000 km perjalanan menambah penundaan 1000 ms atau 5 ms pada RTT. Ini adalah waktu minimum yang diperlukan untuk transmisi, karena ada juga penundaan pada peralatan perantara. Karena CDN biasanya mengetahui cara menyimpan objek dalam cache di servernya, kita bisa mendapatkan keuntungan dengan memuat objek tersebut melalui CDN. Kondisi yang diperlukan untuk ini: keberadaan objek dalam cache, kedekatan titik CDN dengan pengguna dibandingkan dengan server aplikasi web (server asal). Penting untuk dipahami bahwa kedekatan geografis dari node CDN tidak menjamin latensi rendah. Perutean antara klien dan CDN dapat dibangun sedemikian rupa sehingga klien akan terhubung ke host di negara lain, dan mungkin di benua lain. Di sinilah hubungan antara operator telekomunikasi dan layanan CDN (peering, koneksi, partisipasi dalam IX, dll.) dan kebijakan perutean lalu lintas CDN itu sendiri ikut berperan. Misalnya, Cloudflare, ketika menggunakan dua paket awal (gratis dan murah), tidak menjamin pengiriman konten dari host terdekat - host akan dipilih untuk mencapai biaya minimum.

Banyak perusahaan Internet terkemuka menarik minat masyarakat (pengembang web dan pemilik layanan) terhadap topik kecepatan memuat dan kinerja situs web. Di antara perusahaan-perusahaan ini adalah Yahoo (alat Yslow), AOL (WebPageTest) dan Google (layanan Page Speed ​​​​Insights), yang mengembangkan rekomendasi mereka sendiri untuk mempercepat situs (terutama berkaitan dengan pengoptimalan klien). Belakangan muncul alat pengujian kecepatan website baru yang juga memberikan tips meningkatkan kecepatan website. Masing-masing layanan atau plugin ini memiliki rekomendasi yang konsisten: “Gunakan CDN.” Pengurangan latensi jaringan biasanya disebut sebagai penjelasan atas efek CDN. Sayangnya, tidak semua orang siap untuk memahami secara pasti bagaimana efek percepatan CDN dicapai dan bagaimana hal tersebut dapat diukur, sehingga rekomendasi tersebut diterima begitu saja dan dijadikan sebagai dalil. Faktanya, tidak semua CDN diciptakan sama.

Menggunakan CDN Hari Ini

Untuk menilai kegunaan penggunaan CDN, CDN perlu diklasifikasikan. Apa yang sekarang dapat ditemukan dalam praktik (contoh dalam tanda kurung, tentu saja, tidak lengkap):

1. CDN gratis untuk mendistribusikan perpustakaan JS (MaxCDN, Google.Yandex).
2. Layanan CDN untuk pengoptimalan klien (misalnya, Google Fonts untuk font, Cloudinary, Cloudimage untuk gambar).
3. CDN untuk optimasi statis dan sumber daya di CMS (tersedia di Bitrix, WordPress, dan lainnya).
4. CDN tujuan umum (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN untuk akselerasi website (Cloudflare, Imperva, Airi).

Perbedaan utama antara jenis-jenis ini adalah seberapa banyak lalu lintas yang melewati CDN. Tipe 1-3 adalah penyampaian sebagian konten saja: dari satu permintaan hingga beberapa lusin (biasanya gambar). Tipe 4 dan 5 merupakan proksi penuh lalu lintas melalui CDN.

Dalam praktiknya, ini berarti jumlah koneksi yang digunakan untuk memuat situs. Dengan HTTP/2, kami menggunakan satu koneksi TCP ke host untuk memproses sejumlah permintaan. Jika kita membagi sumber daya menjadi host utama (asal) dan CDN, maka perlu mendistribusikan permintaan ke beberapa domain dan membuat beberapa koneksi TCP. Kasus terburuknya adalah: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Rumus ini tidak memperhitungkan penundaan jaringan seluler untuk aktivasi saluran radio perangkat (jika tidak aktif) dan penundaan pada menara seluler.

Berikut tampilan air terjun pemuatan situs (latensi untuk menyambung ke CDN disorot pada RTT 150 ms):

Jika CDN mencakup semua lalu lintas situs (kecuali layanan pihak ketiga), maka kita dapat menggunakan satu koneksi TCP, sehingga menghemat penundaan saat menyambung ke host tambahan. Tentu saja, ini berlaku untuk koneksi HTTP/2.

Perbedaan lebih lanjut ditentukan oleh fungsionalitas CDN tertentu - untuk tipe pertama hanya menghosting file statis, untuk tipe kelima mengubah beberapa jenis konten situs untuk tujuan optimasi.

Kemampuan CDN untuk akselerasi website

Mari kita jelaskan keseluruhan kemampuan CDN untuk mempercepat situs, tanpa memperhatikan fungsionalitas masing-masing jenis CDN, dan kemudian lihat apa yang diterapkan di masing-masing situs tersebut.

1. Kompresi sumber teks

Fitur paling mendasar dan mudah dipahami, namun sering kali diterapkan dengan buruk. Semua CDN menyatakan kehadiran kompresi sebagai fitur akselerasinya. Namun jika dicermati lebih detail, kekurangannya menjadi jelas:

• derajat rendah untuk kompresi dinamis dapat digunakan - 5-6 (misalnya, untuk gzip maksimumnya adalah 9);
• kompresi statis (file dalam cache) tidak menggunakan fitur tambahan (misalnya zopfi atau brotli dengan derajat 11)
• tidak ada dukungan untuk kompresi brotli yang efisien (menghemat sekitar 20% dibandingkan dengan gzip).

Jika Anda menggunakan CDN, ada baiknya memeriksa beberapa poin berikut: ambil file yang berasal dari CDN, catat ukuran kompresinya dan kompres secara manual untuk perbandingan (Anda dapat menggunakan beberapa layanan online dengan dukungan brotli, misalnya vsszhat.rf).

2. Mengatur header caching klien

Juga fitur percepatan sederhana: tambahkan header untuk cache konten oleh klien (browser). Header terbaru adalah kontrol cache, header yang sudah ketinggalan zaman sudah habis masa berlakunya. Selain itu, Etag dapat digunakan. Hal utama adalah bahwa usia maksimum kontrol cache cukup besar (dari satu bulan atau lebih). Jika Anda siap untuk menyimpan sumber daya dalam cache sebanyak mungkin, Anda dapat menambahkan opsi yang tidak dapat diubah.

CDN dapat menurunkan nilai max-age, sehingga memaksa pengguna untuk memuat ulang konten statis lebih sering. Tidak jelas apa hubungannya dengan ini: keinginan untuk meningkatkan lalu lintas di jaringan atau meningkatkan kompatibilitas dengan situs yang tidak tahu cara mengatur ulang cache. Misalnya, waktu cache header Cloudflare default adalah 1 jam, yang merupakan waktu yang sangat rendah untuk data statis yang tidak dapat diubah.

3. Optimasi gambar

Karena CDN mengambil fungsi caching dan menyajikan gambar, masuk akal untuk mengoptimalkannya di sisi CDN dan menyajikannya kepada pengguna dalam bentuk ini. Ayo segera reservasi karena fitur ini hanya tersedia untuk CDN tipe 2, 3 dan 5.

Anda dapat mengoptimalkan gambar dengan berbagai cara: menggunakan format kompresi tingkat lanjut (seperti WebP), encoder yang lebih efisien (MozJPEG), atau sekadar membersihkan metadata yang tidak diperlukan.

Secara umum, ada dua jenis optimasi: dengan penurunan kualitas dan tanpa penurunan kualitas. CDN biasanya berupaya menggunakan pengoptimalan lossless untuk menghindari kemungkinan keluhan pelanggan tentang perubahan kualitas gambar. Dalam kondisi seperti itu, keuntungan yang didapat akan minimal. Pada kenyataannya, sering kali tingkat kualitas JPEG jauh lebih tinggi dari yang diperlukan dan Anda dapat mengompresi ulang dengan aman dengan tingkat kualitas yang lebih rendah tanpa mengorbankan pengalaman pengguna. Di sisi lain, sulit untuk menentukan tingkat kualitas dan pengaturan secara universal untuk semua kemungkinan aplikasi web, sehingga CDN menggunakan pengaturan yang lebih konservatif dibandingkan dengan yang dapat diterapkan dengan mempertimbangkan konteks (tujuan gambar, jenis aplikasi web). , dll.)

4. Mengoptimalkan koneksi TLS

Sebagian besar lalu lintas saat ini berjalan melalui koneksi TLS, yang berarti kami menghabiskan waktu ekstra untuk negosiasi TLS. Baru-baru ini, teknologi baru telah dikembangkan untuk mempercepat proses ini. Misalnya, ini adalah kriptografi EC, TLS 1.3, cache dan tiket sesi, akselerasi enkripsi perangkat keras (AES-NI), dll. Pengaturan TLS yang benar dapat mengurangi waktu koneksi menjadi 0-1 RTT (tidak termasuk DNS dan TCP).

Dengan perangkat lunak modern, tidak sulit untuk menerapkan sendiri praktik tersebut.

Tidak semua CDN menerapkan praktik terbaik TLS; Anda dapat memeriksanya dengan mengukur waktu koneksi TLS (misalnya, di Webpagetest). Ideal untuk koneksi baru - 1RTT, 2RTT - level rata-rata, 3RTT dan banyak lagi - buruk.

Perlu dicatat juga bahwa meskipun menggunakan TLS di tingkat CDN, server dengan aplikasi web kita juga harus memproses TLS, tetapi dari sisi CDN, karena lalu lintas antara server dan CDN melewati jaringan publik. Dalam kasus terburuk, kita akan mendapatkan penundaan koneksi TLS ganda (yang pertama ke host CDN, yang kedua antara host tersebut dan server kita).

Untuk beberapa aplikasi, ada baiknya memperhatikan masalah keamanan: lalu lintas biasanya didekripsi pada node CDN, dan ini merupakan peluang potensial untuk intersepsi lalu lintas. Pilihan untuk bekerja tanpa pengungkapan lalu lintas biasanya ditawarkan dalam paket tarif teratas dengan biaya tambahan.

5. Kurangi penundaan koneksi

Manfaat utama CDN yang dibicarakan semua orang: latensi rendah (jarak lebih sedikit) antara host CDN dan pengguna. Dicapai dengan menciptakan arsitektur jaringan yang terdistribusi secara geografis, di mana host berada di titik konsentrasi pengguna (kota, titik pertukaran lalu lintas, dll.)

Dalam praktiknya, prioritas untuk jaringan yang berbeda mungkin berada di wilayah tertentu. Misalnya, CDN Rusia akan memiliki lebih banyak titik kehadiran di Rusia. Pihak Amerika pertama-tama akan mengembangkan jaringan di AS. Misalnya, salah satu CDN Cloudflare terbesar hanya memiliki 2 titik di Rusia - Moskow dan St. Petersburg. Artinya, kita bisa menghemat latensi maksimal sekitar 10 ms dibandingkan penempatan langsung di Moskow.

Kebanyakan CDN Barat tidak memiliki titik sama sekali di Rusia. Dengan terhubung ke mereka, Anda hanya dapat meningkatkan penundaan untuk pemirsa Rusia Anda.

6. Pengoptimalan konten (minifikasi, perubahan struktural)

Poin paling kompleks dan berteknologi maju. Mengubah konten saat pengiriman bisa sangat berisiko. Bahkan jika kita melakukan minifikasi: pengurangan kode sumber (karena spasi tambahan, struktur yang tidak penting, dll.) dapat mempengaruhi kinerjanya. Jika kita berbicara tentang perubahan yang lebih serius - memindahkan kode JS ke akhir HTML, menggabungkan file, dll. - risiko terganggunya fungsionalitas situs bahkan lebih tinggi.

Oleh karena itu, hanya beberapa CDN tipe 5 yang melakukan hal ini. Tentu saja, tidak mungkin mengotomatiskan semua perubahan yang diperlukan untuk mempercepat—diperlukan analisis dan pengoptimalan manual. Misalnya, menghapus kode yang tidak digunakan atau duplikat adalah tugas manual.

Biasanya, semua pengoptimalan tersebut dikontrol oleh pengaturan dan yang paling berbahaya dinonaktifkan secara default.

Dukungan kemampuan akselerasi berdasarkan tipe CDN

Jadi, mari kita lihat potensi peluang percepatan yang diberikan oleh berbagai jenis CDN.

Untuk kenyamanan, kami ulangi klasifikasinya.

1. CDN gratis untuk mendistribusikan perpustakaan JS (MaxCDN, Google.Yandex).
2. Layanan CDN untuk pengoptimalan klien (misalnya, Google Fonts untuk font, Cloudinary, Cloudimage untuk gambar).
3. CDN untuk optimasi statis dan sumber daya di CMS (tersedia di Bitrix, WordPress, dan lainnya).
4. CDN tujuan umum (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN untuk akselerasi website (Cloudflare, Imperva, Airi).

Sekarang mari kita bandingkan fitur dan jenis CDN.

Kesempatan
Ketik 1
Ketik 2
Ketik 3
Ketik 4
Ketik 5

Kompresi teks
+–
-
+–
+–
+

Header cache
+
+
+
+
+

Gambar
-
+–
+–
-
+

TLS
-
-
-
+–
+

Penundaan
-
-
-
+
+

Kadar
-
-
-
-
+

Dalam tabel ini, “+” digunakan untuk menunjukkan dukungan penuh, “–” untuk tidak ada dukungan, dan “+–” untuk dukungan parsial. Tentu saja, mungkin ada penyimpangan dari tabel ini pada kenyataannya (misalnya, beberapa CDN tujuan umum akan mengimplementasikan fitur untuk mengoptimalkan gambar), tetapi secara umum ini berguna.

Hasil

Semoga setelah membaca artikel ini Anda memiliki gambaran yang lebih jelas mengenai rekomendasi “gunakan CDN” untuk mempercepat situs Anda.

Seperti dalam bisnis apa pun, Anda tidak dapat mempercayai janji pemasaran dari layanan apa pun. Dampaknya perlu diukur dan diuji dalam kondisi nyata. Jika Anda sudah menggunakan CDN, periksa efektivitasnya menggunakan kriteria yang dijelaskan dalam artikel.

Ada kemungkinan bahwa penggunaan CDN saat ini memperlambat waktu pemuatan situs Anda.

Sebagai rekomendasi umum, kami dapat fokus pada hal berikut: pelajari audiens Anda, tentukan cakupan geografisnya. Jika audiens utama Anda terkonsentrasi dalam radius 1-2 ribu kilometer, Anda tidak memerlukan CDN untuk tujuan utamanya - mengurangi latensi. Sebaliknya, Anda dapat menempatkan server Anda lebih dekat dengan pengguna Anda dan mengkonfigurasinya dengan benar, mendapatkan sebagian besar optimasi yang dijelaskan dalam artikel (gratis dan permanen).

Jika audiens Anda benar-benar tersebar secara geografis (radius lebih dari 3000 kilometer), menggunakan CDN yang berkualitas akan sangat berguna. Namun, Anda perlu memahami terlebih dahulu apa sebenarnya yang dapat dipercepat oleh CDN Anda (lihat tabel kemampuan dan deskripsinya). Namun, akselerasi situs web masih menjadi tugas kompleks yang tidak dapat diselesaikan dengan menghubungkan CDN. Selain optimasi di atas, cara akselerasi yang paling efektif tetap berada di belakang CDN: optimasi bagian server, perubahan lanjutan pada bagian klien (menghapus kode yang tidak digunakan, mengoptimalkan proses rendering, bekerja dengan konten, font, kemampuan beradaptasi, dll. )

Sumber: www.habr.com