Skąd dołączasz bibliotekę jQuery? Google JSAPI? CDN?

Istnieje kilka sposobów włączenia jQuery i jQuery UI i zastanawiam się, z czego korzystają ludzie?

• Google JSAPI
• Strona jQuery
• twoja własna strona / serwer
• inny CDN

Ostatnio korzystam z Google JSAPI, ale odkryłem, że konfiguracja połączenia SSL zajmuje dużo czasu, a nawet rozwiązanie google.com. Korzystam z następujących usług Google:

<script src="https://www.google.com/jsapi"></script>
<script>
google.load('jquery', '1.3.1');
</script>

Podoba mi się pomysł używania Google, więc jest buforowany podczas odwiedzania innych stron i oszczędzania przepustowości z naszego serwera, ale jeśli nadal jest powolną częścią witryny, mogę zmienić dołączenie.

Czego używasz? Czy miałeś jakieś problemy?

Edycja: Właśnie odwiedziłem witrynę jQuery i używają następującej metody:

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

Edycja2: Oto jak włączyłem jQuery bez żadnych problemów przez ostatni rok:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>

Różnica polega na usunięciu http:. Usuwając to, nie musisz się martwić przełączaniem między http a https.

Bez wątpienia wybieram obsługę JQuery przez serwery Google API. Nie zastosowałem metody jsapi, ponieważ nie wykorzystuję żadnych innych interfejsów API Google, jednak jeśli to się kiedykolwiek zmieni, to rozważę to ...

Po pierwsze: serwery API Google są dystrybuowane na całym świecie zamiast mojej lokalizacji na jednym serwerze: bliższe serwery zwykle oznaczają krótszy czas reakcji dla odwiedzającego.

Po drugie: wiele osób decyduje się na hosting JQuery w Google, więc kiedy odwiedzający odwiedza moją witrynę, może mieć już skrypt JQuery w lokalnej pamięci podręcznej. Zawartość pamięci podręcznej zwykle oznacza krótszy czas ładowania dla odwiedzającego.

Po trzecie: moja firma hostingowa nalicza opłaty za wykorzystaną przepustowość. Nie ma sensu zużywać 18 000 na sesję użytkownika, jeśli użytkownik może uzyskać ten sam plik w innym miejscu.

Rozumiem, że ufam w Google, aby udostępnić prawidłowy plik skryptu oraz być online i dostępny. Do tego momentu nie byłem rozczarowany używaniem Google i będę kontynuować tę konfigurację, dopóki nie będzie sensu tego nie robić.

Jedna rzecz, na którą warto zwrócić uwagę ... Jeśli masz w swojej witrynie mieszaninę bezpiecznych i niezabezpieczonych stron, możesz dynamicznie zmienić źródło Google, aby uniknąć zwykłego ostrzeżenia, które pojawia się podczas ładowania niezabezpieczonej zawartości na bezpiecznej stronie:

Oto, co wymyśliłem:

<script type="text/javascript">
    document.write([
        "\<script src='",
        ("https:" == document.location.protocol) ? "https://" : "http://",
        "ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>" 
    ].join(''));
</script>

AKTUALIZACJA 9/8/2010 - Pojawiły się pewne sugestie, aby zmniejszyć złożoność kodu poprzez usunięcie HTTP i HTTPS i po prostu użyć następującej składni:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Ponadto możesz również zmienić adres URL, aby odzwierciedlał numer główny jQuery, jeśli chcesz się upewnić, że załadowano najnowszą wersję główną bibliotek jQuery:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Wreszcie, jeśli nie chcesz korzystać z Google i wolisz jQuery, możesz użyć następującej ścieżki źródłowej (pamiętaj, że jQuery nie obsługuje połączeń SSL):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>

Jednym z powodów, dla których warto hostować na serwerze zewnętrznym, jest obejście ograniczeń przeglądarki dotyczących równoczesnych połączeń z danym serwerem.

Jednak biorąc pod uwagę, że plik jQuery, którego używasz, najprawdopodobniej nie zmienia się bardzo często, pamięć podręczna przeglądarki zostanie uruchomiona i w większości przypadków będzie to kwestia sporna.

Drugim powodem hostowania go na serwerze zewnętrznym jest zmniejszenie ruchu na własnym serwerze.

Jednak biorąc pod uwagę rozmiar jQuery, są szanse, że będzie to niewielka część twojego ruchu. Prawdopodobnie powinieneś spróbować zoptymalizować swoją rzeczywistą zawartość.

jQuery 1.3.1 min ma tylko 18k wielkości. Nie sądzę, aby było to zbyt trafne pytanie przy pierwszym ładowaniu strony. Po tym będzie buforowany. W rezultacie sam go hostuję.

Jeśli chcesz korzystać z Google, bezpośredni link może być bardziej responsywny. Każda biblioteka ma ścieżkę do pliku bezpośredniego. To jest ścieżka jQuery

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Ponownie przeczytaj pytanie, czy istnieje powód, dla którego używasz protokołu https? To jest tag skryptu, który Google wymienia w swoim przykładzie

<script src="http://www.google.com/jsapi"></script>

Nie chciałbym, aby żadna publiczna witryna, którą opracowałem, zależała od jakiejkolwiek strony zewnętrznej, dlatego sam hostowałbym jQuery.

Czy chcesz, aby Twoja witryna przestała działać, gdy inne (Google, jquery.com itp.) Przestaną działać? Kluczem jest mniejsza zależność.

Plusy: Host w Google ma zalety

• Prawdopodobnie szybciej (ich serwery są bardziej zoptymalizowane)
• Obsługują buforowanie poprawnie - 1 rok (staramy się, abyśmy mogli wprowadzić zmiany, aby nagłówki trafiły na nasze serwery)
• Użytkownicy, którzy mieli już link do wersji hostowanej przez Google w innej domenie, mają już ten plik w pamięci podręcznej

Cons:

• Niektóre przeglądarki mogą widzieć to jako XSS między domenami i nie zezwalają na plik.
• W szczególności użytkownicy uruchamiający wtyczkę NoScript do przeglądarki Firefox

Zastanawiam się, czy możesz ZAWIERAĆ od Google, a następnie sprawdzić obecność jakiejś zmiennej globalnej, czy coś takiego, a jeśli nieobecność ładuje się z twojego serwera?

Tutaj jest kilka problemów. Po pierwsze, określono metodę ładowania asynchronicznego:

<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load('jquery', '1.3.1');
  google.setOnLoadCallback(function() {
    // do stuff
  });
</script>

ma kilka problemów. Znaczniki skryptu wstrzymują ładowanie strony podczas ich pobierania (w razie potrzeby). Teraz, jeśli ładują się powoli, jest to złe, ale jQuery jest małe. Prawdziwym problemem związanym z powyższą metodą jest to, że ponieważ ładowanie jquery.js odbywa się niezależnie dla wielu stron, zakończą ładowanie i wyrenderują przed załadowaniem jquery, więc każda stylizacja jquery będzie widoczną zmianą dla użytkownika .

Drugi sposób to:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Wypróbuj kilka prostych przykładów, takich jak: posiadaj prostą tabelę i zmień tło komórek na żółte za pomocą metody setOnLoadCallback () vs $ (document) .ready () ze statycznym ładowaniem jquery.min.js. Druga metoda nie będzie miała zauważalnego migotania. Pierwsza wola. Osobiście uważam, że nie jest to dobre doświadczenie użytkownika.

Jako przykład uruchom to:

<html>
<head>
  <title>Layout</title>
  <style type="text/css">
    .odd { background-color: yellow; }
  </style>
</head>
<body>
<table>
  <tr><th>One</th><th>Two</th></tr>
  <tr><td>Three</td><td>Four</td></tr>
  <tr><td>Five</td><td>Six</td></tr>
  <tr><td>Seven</td><td>Nine</td></tr>
  <tr><td>Nine</td><td>Ten</td></tr>
</table> 
<script src="http://www.google.com/jsapi"></script>
<script>
  google.load("jquery", "1.3.1");
  google.setOnLoadCallback(function() {
    $(function() {
      $("tr:odd").addClass("odd");
    });
  });
</script>
</body>
</html>

Powinieneś (powinnaś) zobaczyć, jak tabela się pojawia, a następnie wiersze stają się żółte.

Drugi problem związany z metodą google.load () polega na tym, że obsługuje ona tylko ograniczony zakres plików. Jest to problem dla jquery, ponieważ jest bardzo zależny od wtyczki. Jeśli spróbujesz dołączyć wtyczkę jquery do <script src="...">tagu, a google.load()wtyczka prawdopodobnie zawiedzie z komunikatami „jQuery nie jest zdefiniowane”, ponieważ nie została jeszcze załadowana. Naprawdę nie widzę sposobu na obejście tego.

Trzeci problem (z każdą z tych metod) polega na tym, że stanowią one jedno obciążenie zewnętrzne. Zakładając, że masz jakieś wtyczki i własny kod JavaScript, masz co najmniej dwa zewnętrzne żądania załadowania kodu JavaScript. Prawdopodobnie lepiej jest pobrać jquery, wszystkie odpowiednie wtyczki i własny kod i umieścić go w jednym zminimalizowanym pliku.

Od Czy powinieneś używać Google Ajax Libraries API do hostingu? :

Jeśli chodzi o czas ładowania, tak naprawdę ładujesz dwa skrypty - skrypt jsapi i skrypt mootools (skompresowana wersja z góry). To dwa połączenia, a nie jedno. Z mojego doświadczenia wynika, że ​​czas ładowania był w rzeczywistości 2-3 razy wolniejszy niż ładowanie z mojego osobistego współdzielonego serwera, mimo że pochodził z Google, a moja wersja skompresowanego pliku była kilka K większa niż Google. To nawet po załadowaniu pliku i (prawdopodobnie) buforowaniu. Więc dla mnie, ponieważ przepustowość nie ma większego znaczenia, nie będzie miała znaczenia.

Wreszcie masz potencjalny problem z przeglądarką paranoiczną oznaczającą żądanie jako próbę XSS. Zwykle nie jest to problem z ustawieniami domyślnymi, ale w sieciach korporacyjnych, w których użytkownik może nie mieć kontroli nad używaną przeglądarką, nie mówiąc już o ustawieniach bezpieczeństwa, możesz mieć problem.

Tak więc ostatecznie nie widzę, jak korzystam z interfejsu API Google AJAX dla jQuery (bardziej „kompletne” interfejsy API to inna historia) pod wieloma względami oprócz zamieszczania tutaj przykładów.

Oprócz osób, które zalecają hostowanie go na własnym serwerze, zaproponowałem, aby przechowywać go w osobnej domenie (np. Static.website.com), aby umożliwić przeglądarkom ładowanie go w innym wątku. Ta wskazówka działa również dla wszystkich rzeczy statycznych, powiedzmy obrazów i css.

Muszę głosować -1 za biblioteki hostowane w Google. Zbierają dane, w stylu Google Analytics, ze swoimi opakowaniami wokół tych bibliotek. Przynajmniej nie chcę, aby przeglądarka kliencka działała więcej niż wymagam, a tym bardziej na stronie. Co gorsza, jest to „nowa wersja” Google'a, która nie jest zła - używa dyskretnego javascript do gromadzenia większej ilości danych o użytkowaniu.

Uwaga: jeśli zmienili tę praktykę, super. Ale ostatnim razem, gdy rozważałem użycie hostowanych bibliotek, monitorowałem wychodzący ruch http w mojej witrynie, a okresowe połączenia z serwerami Google nie były czymś, czego się spodziewałem.

Być może jestem w tej sprawie oldschoolowy, ale wciąż marszczę brwi, gdy chodzi o hotlinkowanie. Może Google jest wyjątkiem, ale ogólnie rzecz biorąc, to naprawdę dobre maniery do przechowywania plików na własnym serwerze.

Dodam to jako powód do lokalnego hostowania tych plików.

Ostatnio węzeł w południowej Kalifornii na TWC nie był w stanie rozwiązać domeny ajax.googleapis.com (tylko dla użytkowników z IPv4), więc nie otrzymujemy plików zewnętrznych. To było sporadyczne do wczoraj (teraz jest trwałe). Ponieważ było sporadyczne, miałem mnóstwo problemów w rozwiązywaniu problemów użytkowników SaaS. Spędziłem niezliczone godziny, próbując ustalić, dlaczego niektórzy użytkownicy nie mieli problemów z oprogramowaniem, a inni tankowali. W moim zwykłym procesie debugowania nie mam zwyczaju pytać użytkownika, czy ma wyłączony protokół IPv6.

Natknąłem się na ten problem, ponieważ sam używałem tej konkretnej „trasy” do pliku, a także używam tylko IPV4. Odkryłem problem z narzędziami programistycznymi mówiącymi, że jquery się nie ładuje, a potem zacząłem traceroutes itp., Aby znaleźć prawdziwy problem.

Po tym najprawdopodobniej nigdy nie wrócę do plików hostowanych zewnętrznie, ponieważ: Google nie musi zejść na dół, aby stało się to problemem, i ... którykolwiek z tych węzłów może zostać przejęty przez przejęcie DNS i dostarczenie złośliwego pliku js zamiast rzeczywistego pliku. Zawsze myślałem, że jestem bezpieczny, ponieważ domena Google nigdy nie upadnie, teraz wiem, że każdy węzeł między użytkownikiem a hostem może być punktem awarii.

Po prostu dołączam najnowszą wersję ze strony jQuery: http://code.jquery.com/jquery-latest.pack.js. Odpowiada moim potrzebom i nigdy nie muszę się martwić o aktualizację.

EDYCJA: W przypadku dużej aplikacji internetowej z pewnością ją kontroluj; pobierz i podaj sam. Ale dla mojej osobistej strony nie obchodzi mnie to mniej. Rzeczy nie magicznie znikają, zwykle są najpierw przestarzałe. Nadążam za tym, by wiedzieć, co zmienić w przyszłych wydaniach.

Oto kilka przydatnych zasobów, które mogą pomóc w wyborze CDN. MS niedawno dodało nową domenę do dostarczania bibliotek poprzez ich CDN.

Stary format: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js Nowy format: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

To nie powinno przesłać wszystkich plików cookie dla microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Oto statystyki dotyczące najpopularniejszych technologii używanych w Internecie we wszystkich technologiach. http://trends.builtwith.com/

Nadzieja może pomóc ci wybrać.

Jeśli jestem odpowiedzialny za stronę „na żywo”, lepiej być świadomym wszystkiego, co dzieje się na mojej stronie. Z tego powodu sam hostuję wersję jquery-min albo na tym samym serwerze, albo na serwerze statycznym / zewnętrznym, ale w każdym razie miejsce, w którym tylko ja (lub mój program / serwer proxy) mogę zaktualizować bibliotekę po zweryfikowaniu / przetestowaniu każdej zmiany

W głowie:

  (function() {
    var jsapi = document.createElement('script'); jsapi.type = 'text/javascript'; jsapi.async = true;
    jsapi.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google.com/jsapi?key=YOUR KEY';
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('head')[0]).appendChild(jsapi);
  })();

Koniec ciała:

<script type="text/javascript">
google.load("jquery", "version");
</script>

Hostuję go z moimi innymi plikami js na moim własnym serwerze, i właśnie w tym momencie łączę je i minimalizujemy (z django-compresser, tutaj, ale nie o to chodzi), aby były obsługiwane jako jeden plik js, z całą witryną trzeba w to włożyć. I tak będziesz musiał obsługiwać własne pliki js, więc nie widzę powodu, aby nie dodawać tam również dodatkowych bajtów jquery - niektóre więcej KBS są znacznie tańsze do przesłania niż więcej żądań. Nie jesteś zależny od nikogo, a gdy tylko twój zminimalizowany js zostanie zbuforowany, jesteś również super szybki.

Przy pierwszym ładowaniu rozwiązanie oparte na sieci CDN może wygrać, ponieważ musisz załadować dodatkowe kilobajty jquery z własnego serwera (ale bez dodatkowego żądania). Wątpię jednak, aby różnica była zauważalna. A potem, przy pierwszym załadowaniu z wyczyszczoną pamięcią podręczną, twoje własne hostowane rozwiązanie prawdopodobnie zawsze będzie znacznie szybsze, z powodu większej liczby żądań (i wyszukiwań DNS), aby pobrać jquery CDN.

Zastanawiam się, jak ten punkt prawie nigdy nie jest wspomniany i jak CDN wydają się przejmować świat :)