Salah satu hal pertama yang saya rekomendasikan kepada klien saya untuk mempercepat situs web akan tampak seperti paradoks pada awalnya: Anda harus menempatkan sumber daya statis di hosting Anda, menyerahkan infrastruktur CDN pihak ketiga. Dalam tulisan singkat ini dan, saya harap, posting yang sangat sederhana, saya ingin menguraikan kerugian menyimpan file statis Anda "di samping" dan keuntungan luar biasa dari hostingkan mereka di hosting saya.
Apa yang saya bicarakan?
Merupakan hal umum bagi pengembang untuk mengklik tautan ke aset statis, seperti perpustakaan atau plugin, yang terletak di situs dan sumber daya CDN. Contoh klasik adalah jQuery.
Ada sejumlah keuntungan yang jelas, tetapi tujuan saya kemudian dalam artikel ini adalah untuk mengekspos pendekatan ini, dan untuk menunjukkan bahwa kerugiannya jauh lebih lazim.
(Pertama, pertimbangkan manfaatnya).
- Ini nyaman. Ini membutuhkan sedikit usaha untuk menghubungkan file. Salin baris kode HTML, dan Anda selesai. Mudah
- Kami mendapatkan akses ke CDN. code.jquery.com disediakan oleh StackPath, ini adalah CDN. Dengan menghubungkan ke konten di sumber ini, kami mendapatkan pengiriman berkualitas CDN, gratis.
- File pengguna mungkin sudah di-cache. Jika situs web-a.com menautkan ke code.jquery.com/jquery-3.3.1.slim.min.js dan pengguna beralih dari sini ke situs web-b.com , yang juga menautkan ke code.jquery.com/jquery-3.3 .1.slim.min.js , maka pengguna akan memiliki file ini di cache.
Risiko: Penurunan Kecepatan dan Kegagalan
Saya tidak akan membahas terlalu banyak detail dalam posting ini. Saya memiliki seluruh artikel tentang kelayakan pihak ketiga dan risiko yang terkait dengan keterlambatan dan interupsi. Cukuplah untuk mengatakan bahwa jika Anda memiliki sumber daya kritis yang terkait dengan penyedia pihak ketiga, dan jika penyedia menderita crash dan penurunan kecepatan atau pemadaman, ini adalah berita yang sangat tidak menyenangkan bagi Anda. Anda akan menderita karena ini juga.
Jika Anda memiliki CSS pemblokiran render atau JS sinkron yang dihosting pada sumber daya pihak ketiga, silakan dan transfer mereka ke infrastruktur Anda sendiri segera. Aset kritis terlalu berharga untuk ditinggalkan di server pihak ketiga.
Risiko: Pengakhiran Layanan
Ini adalah kejadian yang jauh kurang umum, tetapi apa yang terjadi jika penyedia memutuskan bahwa mereka perlu menghentikan layanan? Inilah yang dilakukan Rawgit pada Oktober 2018, sejauh ini (pada saat penulisan), pencarian kasar pada kode GitHub masih menyediakan lebih dari satu juta tautan ke layanan, yang saat ini sedang ditutup, dan hampir 20.000 situs yang ada terus lihat itu.
Risiko: Kerentanan Keamanan
Hal lain yang perlu diperhatikan adalah masalah kepercayaan sederhana. Jika kami membawa konten dari sumber pihak ketiga ke halaman kami, kami harus berharap bahwa file yang kami terima persis apa yang kami harapkan akan terima, dan mereka melakukan persis seperti yang kami harapkan darinya.
Bayangkan kerugian yang bisa dilakukan jika seseorang bisa menguasai penyedia seperti code.jquery.com dan mulai mengirimkan konten yang dikompromikan atau berbahaya. Menakutkan memikirkannya!
Integritas Sub-Sumber Daya
Kami harus membayar upeti kepada semua penyedia pihak ketiga yang disebutkan sejauh ini dalam artikel ini, mereka melakukan segalanya untuk memastikan integritas sub-sumber daya (Subresource Integrity - SRI). SRI adalah mekanisme di mana penyedia menyediakan hash (secara teknis, hash diikuti oleh pengkodean Base64) dari file tertentu yang Anda harapkan dan akan digunakan. Browser kemudian dapat memverifikasi bahwa file yang Anda terima persis seperti yang Anda minta.
<script src="https://code.jquery.com/jquery-3.4.1.slim.min.js" integrity="sha256-pasqAKBDmFT4eHoN2ndd6lN370kFiGUFyTiUHWhU7k8=" crossorigin="anonymous"></script>
Sekali lagi, jika Anda benar-benar harus menghubungkan konten statis ke sumber daya pihak ketiga, pastikan bahwa SRI aktif. Anda dapat menghubungkan SRI sendiri.
Reckoning: Negosiasi Jaringan
Salah satu biaya terbesar dan paling mendesak yang kami keluarkan adalah biaya membuka koneksi TCP baru. Setiap sumber daya baru yang perlu kita kunjungi membutuhkan pembukaan koneksi, yang bisa sangat mahal: resolusi DNS, handshake TCP, negosiasi TLS, yang semuanya berkontribusi, dan cerita semakin memburuk karena koneksi tertunda.
Saya akan memberikan contoh yang diambil langsung dari halaman Memulai Bootstrap sendiri. Mereka menginstruksikan pengguna untuk melampirkan empat file.
Keempat file ini terletak pada tiga sumber daya yang berbeda, yaitu, kita perlu membuka tiga koneksi TCP. Berapa biayanya? Nah, dengan koneksi yang cukup cepat, konten file-file statis di samping adalah 311ms, atau 1,65x lebih lambat daripada ketika menempatkannya di hosting Anda sendiri.
Dengan menghubungi tiga sumber berbeda untuk melayani aset statis, kami secara kolektif kehilangan 805ms yang tidak perlu untuk persetujuan jaringan.
OK, itu tidak begitu menakutkan, tetapi Trainline, klien saya, menemukan bahwa ketika penundaan dikurangi 300ms, pengunjung membayar tambahan 8 juta pound per tahun. Ini adalah cara yang cukup mudah untuk menghasilkan 8 juta.
Hanya dengan memindahkan sumber daya kami ke domain Anda, kami sepenuhnya menghilangkan biaya koneksi tambahan.
Untuk koneksi yang lebih lambat, dengan penundaan yang lebih lama, ceritanya jauh lebih buruk. Untuk 3G, versi pihak ketiga lebih lambat dari 1.765-an. Saya pikir itu dimaksudkan untuk membuat situs kami lebih cepat.
Ketika menghubungkan dengan penundaan besar, total biaya jaringan 5.037s mengerikan. Apa yang bisa dihindari sepenuhnya.
Memindahkan file ke infrastruktur kami sendiri mengurangi waktu pengunduhan dari 5.4s menjadi 3.6s.
Jika ini bukan alasan yang bagus untuk meng-host sumber daya statis Anda, saya tidak tahu harus membawa apa lagi.
Pra-koneksi
Tentu saja, inti dari presentasi saya di sini adalah bahwa Anda tidak boleh memposting sumber daya statis di samping jika Anda dapat melakukan ini di hosting Anda. Namun, jika tangan Anda terikat, Anda dapat menggunakan preconnect Resource Hint untuk secara proaktif membuka koneksi TCP ke sumber tertentu: Selain itu, menggunakan mereka sebagai header HTTP akan lebih cepat.
Catatan Bahkan jika Anda menggunakan pra-koneksi, jumlah waktu yang hilang akan berkurang hanya sedikit: Anda masih perlu membuka koneksi yang sesuai, dan kemungkinan biaya tidak akan pernah bisa dibenarkan, terutama untuk koneksi yang lambat.
Reckoning: Kehilangan Prioritas
Penghitungan kedua datang dalam bentuk optimasi di tingkat protokol, yang kami lewatkan ketika kami membagi konten ke dalam domain. Jika Anda menggunakan HTTP / 2, apa yang harus dilakukan, Anda mendapatkan akses ke prioritisasi.
Semua aliran (karenanya sumber daya) dengan koneksi TCP yang sama mempertahankan prioritas, dan browser dan server bekerja bersama-sama untuk membangun pohon ketergantungan dari semua aliran yang diprioritaskan ini, sehingga kami dapat mengembalikan sumber daya kritis lebih cepat dan mungkin menunda pengiriman yang kurang penting.
Catatan Secara teknis, karena penggabungan koneksi HTTP / 2, permintaan dapat diprioritaskan sehubungan satu sama lain di berbagai domain, selama mereka berbagi alamat IP yang sama.
Jika kami mendistribusikan sumber daya kami di berbagai domain, kami harus membuka beberapa koneksi TCP yang unik. Kami tidak dapat referensi silang prioritas untuk koneksi ini, yaitu, kami kehilangan kemampuan untuk mengirimkan file dengan cara tertentu yang dipikirkan dengan matang.
Dengan meng-hosting semua konten pada satu hosting, kita dapat membangun pohon ketergantungan yang lebih kompleks. Setiap utas memiliki ID sendiri, karena mereka milik pohon yang sama. Jika kami menyediakan konten sebanyak mungkin dari satu domain, kami dapat membiarkan HTTP / 2 melakukan tugasnya dan memprioritaskan aset dengan harapan respons yang lebih cepat.
Caching
Pada umumnya, host sumber daya statis tampaknya cukup baik dengan menetapkan arahan max-age berumur panjang. Ini masuk akal karena konten statis pada URL versi (seperti yang dinyatakan di atas) tidak akan pernah berubah. Ini membuatnya sangat aman dan rasional untuk menegakkan kebijakan cache yang cukup agresif.
Namun, ini tidak selalu terjadi, dan dengan secara mandiri menempatkan sumber daya Anda, Anda dapat mengembangkan lebih banyak strategi caching individual.
Mitos: Caching Lintas-Domain
Lebih menarik adalah kemampuan untuk melakukan caching aset lintas domain. Artinya, jika banyak situs menautkan ke versi jQuery yang sama, yang terletak di CDN, maka tentunya pengguna sudah memiliki file khusus ini di komputer mereka. Sesuatu seperti berbagi sumber daya peer-to-peer. Ini adalah salah satu argumen paling umum untuk menggunakan penyedia aset statis pihak ketiga.
Sayangnya, tidak ada bukti yang dipublikasikan untuk mendukung klaim ini: tidak ada alasan untuk percaya bahwa ini benar. Sebaliknya, penelitian terbaru oleh Paul Calvano mengisyaratkan bahwa yang sebaliknya mungkin benar:
Ada perbedaan yang mencolok antara usia cache sumber daya CSS dan font web pihak pertama dan ketiga. 95% font pihak pertama lebih tua dari 1 minggu dibandingkan dengan 50% font pihak ketiga yang kurang dari 1 minggu. Ini memberikan alasan yang bagus untuk font web yang di-host-sendiri.
Secara umum, tampaknya konten pihak ketiga di-cache lebih buruk daripada kontennya sendiri.
Yang lebih penting lagi, Safari telah sepenuhnya menonaktifkan fitur ini karena kekhawatiran tentang penyalahgunaan privasi, sehingga teknologi cache bersama mungkin tidak berfungsi pada saat penulisan ini untuk 16% pengguna di seluruh dunia.
Singkatnya, meskipun secara teori ini bagus, tidak ada bukti bahwa caching lintas domain entah bagaimana efisien.
Akses CDN
Manfaat lain yang tersebar luas dari menghubungi penyedia sumber daya statis adalah bahwa ia kemungkinan akan menggunakan infrastruktur yang kuat dengan kemampuan CDN: distribusi global, skalabilitas, latensi rendah, dan ketersediaan tinggi.
Karena ini benar, jika Anda peduli dengan kinerja Anda, Anda harus menjalankan konten Anda sendiri dari CDN. Dengan tingkat harga hosting saat ini, ada beberapa alasan mengapa Anda tidak menggunakan ini untuk sumber daya Anda.
Dengan kata lain: jika Anda berpikir Anda membutuhkan CDN untuk jQuery Anda, Anda akan membutuhkan CDN untuk semuanya.
Host sumber daya statis di hosting Anda
Bahkan, ada sangat sedikit alasan untuk meninggalkan sumber daya statis Anda di infrastruktur orang lain. Manfaat yang mungkin sering merupakan mitos, dan bahkan jika tidak, kompromi sama sekali tidak layak. Memuat sumber daya dari berbagai sumber jauh lebih lambat. Selama beberapa hari berikutnya, habiskan sepuluh menit mengaudit proyek Anda dan kendalikan semua sumber daya statis pihak ketiga.