Plusy i minusy hostowanych skryptów [zamknięte]

12

Widziałem, jak niektórzy programiści używają hostowanych skryptów do łączenia swoich bibliotek.

cdn.jquerytools.org jest jednym przykładem.

Widziałem także ludzi narzekających na to, że hostowany link do skryptu został porwany.

Jak bezpieczne jest używanie hostowanych skryptów w rzeczywistości? Czy skrypty są automatycznie aktualizowane? Na przykład, jeśli jQuery 5 przechodzi do 6, czy automatycznie otrzymuję wersję 6, czy muszę aktualizować mój link?

Widzę też, że Google ma duży zestaw tych skryptów do hostingu.

Jakie są zalety i wady?

P.Brian.Mackey
źródło

Odpowiedzi:

11

Plusy

  • Twoje skrypty są ładowane szybciej . Jeśli masz mnóstwo zasobów, które należy załadować z jednej domeny, przeglądarka zazwyczaj wąskie gardło, tak że masz tylko kilka równoległych żądań do tego samego hosta. Więc jeśli ładujesz szesnaście osobnych skryptów, wiele obrazów i wiele dokumentów CSS, pojawi się kolejka, ponieważ każdy zasób czeka na swoją kolej. (Zdecydowanie spójrz na łączenie plików CSS i Javascript - ładowanie tylko dwóch zasobów skryptu będzie znacznie szybsze).
  • Jeśli jednak wydzielisz te zasoby w oddzielną domenę, przeglądarka nie będzie miała problemu z otwarciem dodatkowych połączeń z tym serwerem, co oznacza, że ​​więcej zasobów jest ładowanych jednocześnie, co powoduje szybsze wykonanie strony. Zezwalasz także innemu serwerowi na obsługę ładowania strony, co jest dobre dla twojego serwera, który prawdopodobnie pracuje z kilkoma żądaniami wykonania skryptu.
  • Ponadto te serwery CDN (sieci przekazywania treści) są skonfigurowane do działania jako CDN. Zazwyczaj nie wymagają one gotowania (w przypadku mniejszych rozmiarów pakietów) i są skonfigurowane z wyjątkowo lekkim serwerem, który zajmuje się wyłącznie udostępnianiem zasobów i buforowaniem powszechnie używanych zasobów, a nie tak bardzo codziennym podnoszeniem, że to coś w stylu torfowiska Serwer Apache wykona.
  • Korzystanie z sieci CDN, takiej jak Google czy Akami, ma również inne zalety - Google ma w szczególności serwery na całym świecie, a jej systemy routingu są wystarczająco inteligentne, aby sparować żądanie zasobu z najbliższą istniejącą kopią geograficzną. Twój serwer może próbować podać plik jQuery.js Vladimirowi w Rosji - Google prawdopodobnie ma te same zasoby na ulicy od Vladimira, co zmniejsza opóźnienie.
  • Ponadto, ponieważ tak wiele witryn już korzysta z tych sieci CDN, istnieje duże prawdopodobieństwo, że udostępniany przez Ciebie zasób został już zbuforowany przez użytkownika. Pliki jQuery.js z twojego serwera i jQuery.js z serwera Google nie są traktowane jako ten sam plik, bez względu na to, czy są dokładnie takie same - jeśli załadujesz z Google, będzie mógł użyć kopii z pamięci podręcznej z poprzedniej strony, która użytkownik odwiedził.
  • Same pliki nie ulegną zmianie, szczególnie w przypadku zasobów skryptowych, takich jak frameworki JavaScript. Jeśli pojawi się nowa wersja, Google będzie nadal hostować starą wersję (bez względu na to, jak okropne błędy), tak aby CDN nadal działał normalnie i nie obsługiwał żadnych złych żądań. Właśnie dlatego każdy plik CDN ma pełny przyrostek z odpowiednim numerem wersji.

Cons

  1. Istnieje możliwość, że Twój CDN nie będzie dostępny. Prawdopodobnie jednak szanse na to, że Twoja strona spadnie, są mniejsze. Większe sieci CDN, takie jak Google i Akami, mają wiele warstw przełączania awaryjnego.
  2. Utworzenie nowego połączenia może nie być tego warte, jeśli masz tylko jeden lub dwa zasoby do załadowania z własnego serwera.
  3. Nie masz żadnej kontroli nad obsługiwanym plikiem, więc nie możesz użyć niestandardowej wersji jQuery lub czegokolwiek, co próbujesz załadować, chyba że płacisz za własny CDN.

Bezpieczeństwo

Poleciłbym ten post El Stack plus sporą ilość Googlingu na ten temat. Każdy CDN będzie inny, choć w skrócie myślę, że byłby to niewielki problem.

Jarrod Pokrzywy
źródło
1

Coś, o czym nikt nie wspomniał, to kolejna opcja śledzenia dla Google. Nie oferują wszystkich tych usług bez żadnych kosztów bez powodu. AdSense i Analytics są wystarczające i przynajmniej można je filtrować. To duży oszustwo w mojej książce.

plakat
źródło
0

Plusy:

  • Nie musisz płacić za przepustowość związaną z udostępnianiem plików i ogólnie

Cons:

  • Podlegasz dostępowi dostawcy usług hostingowych, z którego korzystasz (jeśli z jakiegokolwiek powodu spadnie, twoja też nie działa).
  • Zmuszono Cię do dowolnej wersji skryptów, które mają dostawcy hostingu

Istnieją inne zalety korzystania z CDN, ale nie odnoszą się one bezpośrednio do korzystania z usługi hostingu trzeciego skryptu.

ryanzec
źródło
0

Jeśli chodzi o najlepsze praktyki, powszechnym podejściem do optymalizacji ładowania strony jest łączenie wszystkich zasobów JS, ze względu na ograniczoną liczbę połączeń do jednej domeny, jak wspomniał Jarrod, i ustawienie odpowiedzi w dalekiej przyszłości wygasa.

CDN wnosi taką mieszankę, zwłaszcza te popularne, jak zauważył Jarrod, że użytkownik już wcześniej uzyskał dostęp do adresu URL i może natychmiast pobrać zasób JS z pamięci podręcznej swojego klienta, nawet nie wymagając nawiązania połączenia.

W tym celu, jeśli wszyscy korzystaliśmy z sieci CDN i stosujemy najlepsze praktyki, możemy uratować użytkownika przed odzyskaniem dodatkowych ~ 10–50 KB, gdy początkowo uzyskują dostęp do naszych adresów URL i pozwalają im szybciej ładować strony.

Chciałbym gorąco polecam używać CDN z dwóch powodów: minusy Jarrod wymienione są tam, prawda, ale zupełnie bez znaczenia i jeśli już łączenie swoje źródła w jednym dokumencie, można zmusić wszystkich do pobrania, powiedzmy, część jQuery statyczne dokument (~ 33 KB) za każdym razem, gdy aktualizujesz jeden z dołączonych zasobów.

Nie wiem, jak ważne to dla Ciebie brzmi, ale przy ogromnej liczbie użytkowników prowadzi to do znacznego ograniczenia przepustowości i znacznych oszczędności, z których możemy przejść do bardziej naglących spraw, takich jak streaming pornografii i kupowanie piwa.

Filip Dupanović
źródło
-2

Nie rób tego

Osobiście nie polegałbym na skryptach hostowanych przez osoby trzecie. Jeśli wykorzystasz skrypty innych ludzi, jesteś na ich łasce. Jest kilka rzeczy do rozważenia:

  1. Jeśli ich witryna ulegnie awarii, strona może przekroczyć limit czasu lub błąd.
  2. Jeśli przestaną działać i wyłączą hosting, stracisz całą tę funkcjonalność
  3. Jeśli zostaną zhakowani, możesz również zostać zhakowany.
  4. Skrypty między witrynami mogą siać spustoszenie za pomocą certyfikatów SSL
  5. Czas ładowania strony może znacznie wzrosnąć
  6. Jeśli interfejs się zmieni, musisz zmodyfikować wszystkie wywołania funkcji

Bezpieczniej jest przechowywać kod na własnej stronie, zaufaj mi. Wystarczy, że raz się wypalisz, a 250 witryn, które zbudowałeś, a host zacznie się zachowywać śmiesznie, ponieważ polegałeś na skrypcie hostowanym w trzeciej części, który przestał działać.

Michael Riley - AKA Gunny
źródło
1
Myślę, że jeśli użyjesz dużej, niezawodnej sieci CDN, prawdopodobnie nie spotkasz się z wieloma obawami. 1.) Spodziewam się, że CDN Google będzie miał bardzo dobry czas pracy, 2.) Nie widzę, aby Google wkrótce przestał działać, 3.) Jest prawdopodobne, ale znowu spodziewam się bardzo szybkiego łatania / naprawy, 4 .) Nie widziałem żadnych problemów, 5.) Jeśli jest to przyzwoity CDN, ładowanie stron powinno faktycznie być szybsze niż to, co prawdopodobnie możesz sobie obsłużyć (między potokiem, buforowaniem wielu witryn i domenami bez plików cookie), 6.) Dla W bibliotekach z wersją rdzeniową, takich jak jQuery, nie powinno być problemu.
scunliffe
1
... nic też nie stoi na przeszkodzie, abyś wdrożył własne skrypty awaryjne w przypadku awarii zdalnych skryptów CDN.
scunliffe
Żaden z tych powodów wymienionych na liście Cape Cod Gunny nie dotyczy aktualnych sieci CDN, takich jak Google, czy wielu innych dużych dostawców CDN.
Jarrod Nettles