Pro dan kontra dari skrip yang dihosting [ditutup]


12

Saya telah melihat beberapa pengembang menggunakan skrip yang di-host untuk menghubungkan perpustakaan mereka.

cdn.jquerytools.org adalah salah satu contohnya.

Saya juga melihat orang-orang mengeluh bahwa tautan skrip yang di-host telah dibajak.

Seberapa amankah menggunakan skrip yang diinangi? Apakah skrip diperbarui secara otomatis? Misalnya, jika jQuery 5 masuk ke 6 apakah saya secara otomatis mendapatkan versi 6 atau apakah saya perlu memperbarui tautan saya?

Saya juga melihat bahwa Google memiliki sejumlah besar pengaturan skrip ini untuk hosting.

Apa pro dan kontra?

Jawaban:


11

Pro

  • Script Anda dimuat lebih cepat . Jika Anda memiliki banyak sumber daya yang perlu dimuat dari satu domain, browser Anda biasanya akan menghambat ini sehingga Anda hanya memiliki beberapa permintaan paralel ke host yang sama. Jadi, jika Anda memuat enam belas skrip terpisah, banyak gambar, dan beberapa dokumen CSS akan ada antrian karena setiap sumber daya menunggu giliran untuk dimuat. (Pasti melihat ke menyatukan file CSS dan Javascript Anda - memuat hanya dua sumber daya skrip akan secara signifikan lebih cepat).
  • Namun, jika Anda memutar sumber daya tersebut ke domain terpisah, peramban Anda tidak akan memiliki masalah dalam membuka koneksi tambahan ke server itu, yang berarti bahwa lebih banyak sumber daya yang dimuat secara bersamaan menghasilkan eksekusi halaman yang lebih cepat. Anda juga membiarkan server lain menangani bagian dari pemuatan halaman Anda, yang bagus untuk server Anda yang mungkin sedang mengerjakan beberapa permintaan eksekusi skrip.
  • Selain itu, server CDN ini (jaringan penyimpangan konten) dikonfigurasikan untuk beroperasi sebagai CDN. Mereka biasanya tidak bisa memasak (untuk ukuran paket yang lebih kecil) dan diatur dengan server yang sangat ringan yang sepenuhnya berkaitan dengan sumber daya penyajian dan caching sumber daya yang biasa digunakan dan tidak terlalu banyak dengan pengangkatan sehari-hari yang sesuatu seperti standar rawa Server Apache akan tampil.
  • Menggunakan CDN seperti Google atau Akami juga memiliki manfaat lain - Google terutama memiliki server di seluruh dunia dan sistem peruteannya cukup pintar untuk memasangkan permintaan sumber daya dengan salinan geografis terdekat yang ada. Server Anda mungkin mencoba melayani jQuery.js ke Vladimir di Rusia - Google mungkin memiliki sumber daya yang sama di jalan dari Vladimir, mengurangi latensi.
  • Juga, karena begitu banyak situs web sudah menggunakan CDN ini, ada kemungkinan besar bahwa sumber daya yang Anda layani telah di-cache oleh pengguna. jQuery.js dari server Anda dan jQuery.js dari server Google tidak diperlakukan sebagai file yang sama, tidak peduli apakah mereka persis sama - jika Anda memuat dari Google, itu akan dapat menggunakan salinan cache dari situs sebelumnya yang pengguna mengunjungi.
  • File itu sendiri tidak akan berubah, terutama untuk sumber daya skrip seperti kerangka kerja Javascript. Jika versi baru keluar, Google akan terus meng-host versi lama (tidak peduli seberapa keras bug) secara khusus sehingga CDN akan terus beroperasi secara normal dan tidak melayani permintaan yang buruk. Inilah sebabnya mengapa setiap file CDN penuh dengan suffix dengan nomor versi yang sesuai.

Cons

  1. Ada kemungkinan CDN Anda tidak tersedia. Namun, kemungkinannya lebih kecil daripada penurunan situs Anda. CDN yang lebih besar seperti Google dan Akami memiliki beberapa lapisan kegagalan.
  2. Membuat koneksi baru mungkin tidak sepadan jika Anda hanya memiliki satu atau dua sumber daya untuk dimuat dari server Anda sendiri.
  3. Anda tidak memiliki kontrol apa pun atas file yang dilayani, jadi menggunakan versi kustom jQuery Anda atau apa pun yang Anda coba muat keluar, kecuali Anda membayar CDN Anda sendiri.

Keamanan

Saya akan merekomendasikan posting El Stack ini ditambah jumlah Googling subjek yang baik. Setiap CDN akan berbeda, meskipun secara singkat saya pikir ini akan menjadi masalah kecil.


1

Sesuatu yang tidak ada yang disebutkan adalah opsi pelacakan lain untuk Google. Mereka tidak menawarkan semua layanan ini tanpa biaya tanpa alasan. AdSense dan Analytics sudah cukup dan setidaknya itu bisa difilter. Itu tipuan besar dalam buku saya.


0

Pro:

  • Anda tidak perlu membayar bandwidth yang terkait dengan penyajian file dan umumnya

Cons:

  • Anda tunduk pada ketersediaan penyedia hosting yang Anda gunakan (jika mereka turun karena alasan apa pun, turun juga).
  • Anda dipaksa untuk versi skrip apa pun yang dimiliki penyedia hosting

Ada manfaat lain menggunakan CDN tetapi tidak terkait langsung dengan menggunakan layanan hosting skrip ke-3.


0

Sejauh praktik terbaik berjalan, pendekatan umum untuk mengoptimalkan pemuatan halaman adalah menggabungkan semua sumber daya JS Anda, karena jumlah koneksi yang terbatas ke satu domain seperti yang disebutkan Jarrod, dan menetapkan tajuk kedaluwarsa yang kedaluwarsa dalam respons.

Apa yang dibawa CDN ke campuran seperti itu, terutama yang populer, seperti ditunjukkan Jarrod juga, adalah bahwa pengguna sebelumnya telah mengakses URL dan dapat mengambil sumber daya JS segera dari cache kliennya tanpa perlu membuat koneksi.

Untuk itu, jika kita semua menggunakan CDN dan menerapkan praktik terbaik, kita dapat menyelamatkan pengguna dari mengambil tambahan ~ 10-50KB ketika mereka awalnya mengakses URL kita dan memungkinkan mereka memuat halaman mereka lebih cepat.

Saya akan sangat menyarankan untuk menggunakan CDN karena dua alasan: kontra yang disebutkan Jarrod ada di sana, benar, tetapi sama sekali tidak signifikan dan jika Anda sudah menggabungkan sumber Anda ke dalam satu dokumen, Anda akan memaksa semua orang untuk mengambil, katakanlah, bagian jQuery statis dari dokumen (~ 33KB) setiap kali Anda memperbarui salah satu sumber daya yang dibundel.

Saya tidak tahu seberapa penting kedengarannya bagi Anda, tetapi dengan basis pengguna yang besar ini mengarah pada pengurangan bandwidth yang signifikan dan penghematan yang signifikan, yang dapat kita alihkan ke hal-hal yang lebih mendesak, seperti streaming pornografi dan membeli bir.


-2

Jangan lakukan itu

Secara pribadi, saya tidak akan bergantung pada skrip yang dihosting pihak ketiga. Jika Anda memanfaatkan skrip orang lain, Anda berada di tangan mereka. Ada beberapa hal yang perlu dipertimbangkan:

  1. Jika situs mereka turun halaman Anda mungkin habis atau kesalahan.
  2. Jika mereka keluar dari bisnis dan mematikan hosting Anda baru saja kehilangan semua fungsi itu
  3. Jika mereka diretas, Anda juga bisa diretas.
  4. Script lintas-situs dapat memainkan malapetaka dengan sertifikat SSL
  5. Waktu pemuatan halaman dapat meningkat secara dramatis
  6. Jika antarmuka berubah, Anda perlu memodifikasi semua panggilan fungsi

Lebih aman meng-host kode di situs Anda sendiri, percayalah. Anda hanya perlu terbakar sekali dan memiliki 250 situs web yang Anda buat dan host mulai bertindak lucu karena Anda mengandalkan skrip yang di-host bagian ketiga yang berhenti berfungsi.


1
Saya pikir jika Anda menggunakan CDN yang besar dan andal Anda kemungkinan tidak akan menghadapi banyak masalah Anda. 1.) Saya berharap bahwa CDN Google akan memiliki waktu kerja yang sangat baik, 2.) Saya tidak melihat Google akan gulung tikar dalam waktu dekat, 3.) Ini masuk akal, tapi sekali lagi saya berharap penambalan / perbaikan yang sangat cepat, 4 .) Saya belum melihat masalah apa pun, 5.) Jika itu adalah CDN yang terhormat, pemuatan halaman seharusnya lebih cepat daripada apa yang mungkin Anda lakukan sendiri (antara pipelining, caching multi-situs, dan domain tanpa masak), 6.) Untuk inti versi lib seperti jQuery seharusnya tidak ada masalah.
scunliffe

1
... juga, tidak ada yang menghentikan Anda menerapkan skrip mundur sendiri jika yang CDN jauh gagal.
scunliffe

Tak satu pun dari alasan-alasan ini yang terdaftar di Cape Cod Goni adalah kekhawatiran valid dengan CDN modern seperti Google, atau banyak penyedia CDN besar lainnya di luar sana.
Jarrod Nettles
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.