Odwoływanie się do zewnętrznego javascript a hosting własnej kopii

Powiedz, że mam aplikację internetową, która korzysta z jQuery. Czy lepiej jest przechowywać niezbędne pliki javascript na moich własnych serwerach wraz z plikami mojej witryny, czy odwoływać się do nich w CDN jQuery (przykład: http://code.jquery.com/jquery-1.7.1.min.js ) ?

Widzę zalety dla obu stron:

• Jeśli jest na moich serwerach, jest to jedna zależność zewnętrzna; jeśli aplikacja jQuery uległa awarii lub zmieniła strukturę hostingu lub coś w tym stylu, moja aplikacja się zepsuła. Ale czuję, że to się nie zdarza często; robi to wiele małych witryn, a zespół jQuery będzie chciał ich uniknąć.
• Jeśli jest na moich serwerach, jest to o jeden mniej zewnętrzny odnośnik, że ktoś mógłby nazwać problem bezpieczeństwa
• Jeśli odwołuje się do niego zewnętrznie, nie muszę się martwić o przepustowość do obsługi plików (choć wiem, że to niewiele).
• Jeśli jest to zewnętrzne odniesienie i wdrażam tę witrynę na wielu serwerach, które muszą mieć własne kopie wszystkich plików, oznacza to, że jest to jeden plik mniejszy, o którym muszę pamiętać, aby skopiować / zaktualizować.

Powinieneś zrobić oba:

Zacznij od hostingu z sieci CDN, takiej jak Google, ponieważ prawdopodobnie będzie ona działała krócej niż Twoja witryna i zostanie skonfigurowana pod kątem najszybszego czasu reakcji. Ponadto każdy, kto odwiedził stronę z linkiem do CDN, użyje swojej kopii pliku z pamięci podręcznej, więc nawet nie będzie musiał ponownie pobierać kopii, dzięki czemu wstępne ładowanie będzie jeszcze szybsze.

Następnie dodaj awaryjne odwołanie do własnego serwera na wypadek, gdyby CDN był wyłączony (mało prawdopodobne, ale bezpieczne jest bezpieczne). Awarie są stosunkowo łatwe do zrozumienia, ale należy je dostosować do używanego skryptu:

<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js"></script>
<script>
    if (!window.jQuery) document.write('<script src="/path/to/jquery-ver.sion.min.js"><\/script>');
</script>

Upewnij się, że nie piszesz </script>nigdzie w <script>elemencie, ponieważ zamknie on element HTML i spowoduje awarię skryptu. Prostym rozwiązaniem jest użycie backslash jako ucieczki: <\/script>.

_{Jeszcze jeden powód, aby zrobić jedno i drugie:}

Jeśli wybierzesz popularną sieć CDN, jest mało prawdopodobne, aby kiedykolwiek miała ona przestoje, jednak w dalekiej przyszłości (za 18 miesięcy, biorąc pod uwagę prawo Moore'a ), kiedy zmieni się format hostingu, adres zostanie zmieniony lub sieć jest umieszczona za zaporą lub cokolwiek innego, możliwe, że Twój link nie będzie działał w obecnej postaci. Jeśli skorzystasz z rezerwy, da ci to trochę czasu na dostosowanie się do nowego formatu hostingu, zanim będziesz musiał wracać przez każdą utworzoną stronę internetową i zmieniać linki CDN.

_{kolejny powód do zrobienia obu:}

Ostatnio zostałem dotknięty serią awarii internetowych. Byłem w stanie pracować lokalnie nad projektami, w których połączyłem lokalne kopie zasobów skryptu, i szybko odkryłem, że istnieje wiele projektów, które muszą mieć połączone kopie lokalne.

Miałem to samo pytanie, a następnie przeczytałem ten artykuł i sprzedano mi pomysł, aby Google mógł hostować moją bibliotekę jQuery.

W artykule wymieniono główne korzyści z udostępniania bibliotek przez Google Content Delivery Network (CDN):

• Zmniejszone opóźnienie - użytkownicy, którzy nie są fizycznie w pobliżu Twojego serwera, będą mogli pobierać jQuery szybciej od Google, niż jeśli zmusisz ich do pobrania go z dowolnego serwera.
• Zwiększona równoległość - przeglądarki ograniczają liczbę połączeń, które można nawiązywać jednocześnie. W zależności od przeglądarki limit ten może wynosić zaledwie dwa połączenia na nazwę hosta. Korzystanie z bibliotek Google AJAX CDN eliminuje jedno żądanie do Twojej witryny, umożliwiając równoległe pobieranie większej liczby treści lokalnych.
• Lepsze buforowanie - Korzystając z bibliotek Google AJAX, użytkownicy mogą w ogóle nie potrzebować pobierać jQuery. Z drugiej strony, jeśli hostujesz jQuery lokalnie, użytkownicy muszą go pobrać przynajmniej raz. Każdy z twoich użytkowników prawdopodobnie ma już kilkadziesiąt identycznych kopii jQuery w pamięci podręcznej przeglądarki, ale te kopie jQuery są ignorowane, gdy odwiedzają twoją stronę.

Jeśli chodzi o dwa punkty, które wymieniłeś jako plusy za hosting własnej biblioteki, pamiętaj, że to Google hostuje wersję w chmurze, a Google wie, co robią i można im ufać, jeśli chodzi o dostępność i bezpieczeństwo. Jednak @zzzzBov ma bardzo dobry punkt w swojej odpowiedzi na to pytanie, w którym zaleca również przechowywanie lokalnej kopii biblioteki i domyślną w przypadku mało prawdopodobnego przypadku, gdy nie można uzyskać dostępu do wersji CDN z jakiegokolwiek powodu.

Osobiście biorę wskazówkę ze strony http://html5boilerplate.com/

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>
<script>!window.jQuery && document.write(unescape('%3Cscript src="includes/js/libs/jquery-1.6.1.min.js"%3E%3C/script%3E'))</script>

Pobiera to główny plik jQuery z Google, ale jeśli z jakiegoś powodu się nie ładuje, następny wiersz ładuje go z twojego własnego serwera.

Lepszą praktyką jest korzystanie z CDN, a jeśli CDN to Google, tym lepiej - jak zauważyli zarówno @CFL_Jeff, jak i @ Morons.

Dodam tę odpowiedź, aby wskazać coś, co często jest pomijane, gdy wskazuje się gdzie indziej, co pozwala uniknąć ostrzeżenia o mieszanej zawartości . Rozważ użycie adresów URL bez protokołu, np .:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js" type="text/javascript">
</script>

Nadal występują pewne problemy z obsługą przy korzystaniu z adresów URL bez protokołu, więc przejrzyj również odpowiedzi na Czy mogę zmienić wszystkie moje linki http: // na po prostu //? na SO, ale przynajmniej spróbuj w jakiś sposób poradzić sobie z potencjalnymi ostrzeżeniami o mieszanej zawartości .

Powinieneś odwołać się do Biblioteki interfejsów API Google .

Głównym tego powodem jest przyspieszenie ładowania strony . Jeśli użytkownik odwiedził już inną witrynę odwołującą się do tej samej biblioteki, będzie ona już przechowywana w pamięci podręcznej przeglądarki i nie będzie potrzeby jej pobierania .

Mogę się mylić, ale implementacja document.write zastępuje wszystko, co ma DOM. Ponieważ dobrą praktyką jest umieszczanie plików JavaScript na końcu treści,

Proponuję następującą metodę w oparciu o poprzednie odpowiedzi:

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
<script type="text/javascript">

if(!window.jQuery)
{
    //Creates the script element
    var script = document.createElement('script'); 
    //Adds the type attribute with "text/javascript" value
        script.setAttribute('type', 'text/javascript'); 
    //Adds the source attribute and populates it
        script.setAttribute('src', 'Put_The_Relative_Path_To_Your_JavaScript_File_Here'); 
    //Adds it to the end of the body, as it is good practice, to prevent render-blocking.  
    document.body.appendChild(script);

}

//Note that there's no need for you to verify with an onload function, since all scripts
//must be loaded before going to the next one! 

</script>

Chciałbym dodać, że hosting lokalnej kopii jest najlepszą praktyką, ponieważ żaden z powyższych nie podaje niczego związanego z bezpieczną postawą, w której położenie geograficzne i ścisła biała lista są niezbędne. Lokalne nie hostowanie tego pliku powoduje zepchnięcie obniżonej pozycji bezpieczeństwa na klientów.