Откуда вы включаете библиотеку jQuery? Google JSAPI? CDN? - PullRequest
242 голосов
/ 13 февраля 2009

Есть несколько способов включить пользовательский интерфейс jQuery и jQuery, и мне интересно, что люди используют?

  • Google JSAPI
  • Сайт jQuery
  • ваш собственный сайт / сервер
  • другой CDN

Недавно я использовал Google JSAPI, но обнаружил, что для настройки SSL-соединения требуется много времени или даже только для разрешения google.com. Я использовал следующее для Google:

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

Мне нравится идея использовать Google, чтобы он кэшировался при посещении других сайтов и чтобы сэкономить трафик с нашего сервера, но если он продолжает оставаться медленной частью сайта, я могу изменить включение.

Что вы используете? Были ли у вас какие-либо проблемы?

Редактировать: Только что посетили сайт jQuery, и они используют следующий метод:

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

Edit2: Вот как я без проблем включал jQuery за последний год:

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

Разница заключается в удалении http:. Удаляя это, вам не нужно беспокоиться о переключении между http и https.

Ответы [ 16 ]

153 голосов
/ 13 февраля 2009

Без сомнения, я предпочитаю, чтобы JQuery обслуживался серверами Google API. Я не использовал метод jsapi, так как не использую другие API Google, однако, если это когда-либо изменится, я рассмотрю его ...

Первое: Серверы API api распределены по всему миру, а не на моем отдельном сервере. Более близкие серверы обычно означают более быстрое время ответа для посетителя.

Второе: Многие люди предпочитают размещать JQuery в Google, поэтому, когда посетитель заходит на мой сайт, он может уже иметь скрипт JQuery в своем локальном кэше. Предварительно кэшированный контент обычно означает более быстрое время загрузки для посетителя.

Третье: Моя веб-хостинговая компания взимает плату за используемую пропускную способность. Нет смысла тратить 18 КБ на сеанс пользователя, если посетитель может получить тот же файл в другом месте.

Я понимаю, что доверяю Google, чтобы обслуживать правильный файл сценария, быть в сети и доступным. До этого момента я не разочаровывался в использовании Google и буду продолжать эту настройку, пока в этом нет смысла.

На одну вещь стоит обратить внимание ... Если на вашем сайте есть смесь защищенных и небезопасных страниц, возможно, вы захотите динамически изменить источник Google, чтобы избежать обычного предупреждения, которое вы видите при загрузке небезопасного контента. на защищенной странице:

Вот что я придумал:

<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>

ОБНОВЛЕНИЕ 9/8/2010 - Некоторые предложения были сделаны, чтобы уменьшить сложность кода путем удаления HTTP и HTTPS и просто использовать следующий синтаксис:

<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>

Кроме того, вы также можете изменить URL, чтобы он отображал основной номер jQuery, если вы хотите убедиться, что загружена последняя основная версия библиотек jQuery:

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

Наконец, если вы не хотите использовать Google и предпочитаете jQuery, вы можете использовать следующий исходный путь (имейте в виду, что jQuery не поддерживает соединения SSL):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>
19 голосов
/ 13 февраля 2009

Одной из причин, по которой вам может потребоваться размещение на внешнем сервере, является обход ограничений браузером в отношении одновременных подключений к определенному серверу.

Однако, учитывая, что файл jQuery, который вы используете, скорее всего, будет меняться не очень часто, кеш браузера сработает и сделает этот момент спорным по большей части.

Вторая причина размещения его на внешнем сервере - это снижение трафика на ваш собственный сервер.

Однако, учитывая размер jQuery, скорее всего, это будет небольшая часть вашего трафика. Возможно, вам следует попытаться оптимизировать ваш фактический контент.

14 голосов
/ 13 февраля 2009

Если вы хотите использовать Google, прямая ссылка может быть более отзывчивой. У каждой библиотеки есть путь, указанный для прямого файла. Это путь jQuery

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

Просто перечитайте свой вопрос, есть ли причина, по которой вы используете https? Это тег скрипта, который Google перечисляет в их примере

<script src="http://www.google.com/jsapi"></script>
<script>
14 голосов
/ 13 февраля 2009

jQuery 1.3.1 мин. Размером всего 18 КБ. Я не думаю, что это слишком много, чтобы спросить при начальной загрузке страницы. Это будет кэшировано после этого. В результате я сам его принимаю.

8 голосов
/ 14 февраля 2009

Я бы не хотел, чтобы какой-либо публичный сайт, который я разрабатывал, зависел от какого-либо внешнего сайта, и поэтому я бы сам размещал jQuery.

Готовы ли вы к отключению на вашем сайте, когда другой (Google, jquery.com и т. Д.) Выходит из строя? Меньше зависимостей - это ключ.

6 голосов
/ 14 февраля 2009

Здесь есть несколько вопросов. Во-первых, указанный вами метод асинхронной загрузки:

<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>

имеет несколько проблем. Теги скрипта приостанавливают загрузку страницы, пока они извлекаются (при необходимости). Теперь, если они медленно загружаются, это плохо, но jQuery маленький. Реальная проблема с описанным выше методом состоит в том, что, поскольку загрузка jquery.js происходит независимо для многих страниц, они завершат загрузку и визуализацию до загрузки jquery, поэтому любой стиль jquery, который вы сделаете, будет видимым изменением для пользователя .

Другой способ:

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

Попробуйте несколько простых примеров, например, создайте простую таблицу и измените фон ячеек на желтый с помощью метода setOnLoadCallback () против $ (document) .ready () со статической загрузкой jquery.min.js. Второй метод не будет иметь заметного мерцания. Первая будет. Лично я думаю, что это не очень хороший пользовательский опыт.

В качестве примера запустите это:

<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>

Вы (должны) увидеть, как появляется таблица, а затем строки становятся желтыми.

Вторая проблема с методом google.load () заключается в том, что он содержит только ограниченный диапазон файлов. Это проблема для jquery, так как она сильно зависит от плагина. Если вы попытаетесь включить плагин jquery с тегом <script src="..."> и google.load(), вероятно, произойдет сбой плагина с сообщениями "jQuery не определен", поскольку он еще не загружен. Я действительно не вижу способа обойти это.

Третья проблема (с любым методом) заключается в том, что они представляют собой одну внешнюю нагрузку. Предполагая, что у вас есть несколько плагинов и ваш собственный код Javascript, у вас есть минимум два внешних запроса для загрузки вашего Javascript. Возможно, вам лучше получить jquery, все соответствующие плагины и собственный код и поместить его в один минимизированный файл.

С Если вы используете API библиотек Ajax для хостинга от Google? :

Что касается времени загрузки, вы на самом деле загрузка двух скриптов - скрипт jsapi и скрипт MooTools ( сжатая версия сверху). Так это две связи, а не один. По своему опыту я обнаружил, что время загрузки было на самом деле 2-3 раза медленнее, чем загрузка из моего собственного личный общий сервер, даже если он шел от гугла, а моя версия сжатого файла было пару К больше, чем у Google. Это даже после загрузки файла и (предположительно) кешируется. Так что для меня, так как пропускная способность не имеет большого значения, не имеет значения.

Наконец, у вас есть потенциальная проблема, связанная с тем, что браузер-параноик помечает запрос как своего рода попытку XSS. Обычно это не проблема с настройками по умолчанию, но в корпоративных сетях, где пользователь может не иметь контроля над тем, какой браузер он использует, не говоря уже о настройках безопасности, у вас может быть проблема.

Так что, в конце концов, я не вижу, чтобы я хотя бы использовал API Google AJAX для jQuery (более «полные» API - это отдельная история), за исключением публикации здесь примеров.

6 голосов
/ 13 февраля 2009

Плюсы: Хост в Google имеет преимущества

  • Вероятно, быстрее (их серверы более оптимизированы)
  • Они правильно обрабатывают кеширование - 1 год (мы изо всех сил пытаемся внести изменения, чтобы получить заголовки прямо на наших серверах)
  • Пользователи, у которых уже есть ссылка на версию, размещенную на Google в другом домене, уже имеют файл в своем кэше

Минусы:

  • Некоторые браузеры могут видеть его как междоменный домен XSS и запрещать файл.
  • В частности, пользователи, использующие плагин NoScript для Firefox

Интересно, можно ли ВКЛЮЧИТЬ из Google, а затем проверить наличие какой-либо глобальной переменной или что-то подобное, а также загрузку с вашего сервера в отсутствие?

4 голосов
/ 13 февраля 2009

Я должен проголосовать -1 за библиотеки, размещенные в Google. Они собирают данные в стиле Google Analytics, оборачивая их вокруг этих библиотек. Как минимум, я не хочу, чтобы клиентский браузер делал больше, чем я прошу, и тем более всего остального на странице. Хуже того, это «новая версия» Google - не быть злым - использовать ненавязчивый JavaScript для сбора большего количества данных об использовании.

Примечание: если они изменили эту практику, супер. Но в прошлый раз, когда я рассматривал возможность использования их размещенных библиотек, я отслеживал исходящий http-трафик на моем сайте, и я не ожидал увидеть периодические обращения к серверам Google.

4 голосов
/ 13 февраля 2009

В дополнение к людям, которые советуют размещать его на собственном сервере, я предложил хранить его в отдельном домене (например, static.website.com), чтобы браузеры могли загружать его отдельно от другого потока контента. Этот совет также работает для всех статических вещей, например, изображений и CSS.

3 голосов
/ 26 июня 2015

Я добавлю это в качестве причины для локального размещения этих файлов.

Недавно узел в Южной Калифорнии на TWC не смог разрешить домен ajax.googleapis.com (только для пользователей с IPv4), поэтому мы не получаем внешние файлы. Это было прерывистым вплоть до вчерашнего дня (теперь оно является постоянным.) Поскольку оно было прерывистым, у меня были тонны проблем, устраняющих проблемы пользователей SaaS. Потратил бесчисленные часы, пытаясь отследить, почему у некоторых пользователей не было проблем с программным обеспечением, а у других возникали проблемы. В моем обычном процессе отладки я не имею привычки спрашивать пользователя, отключен ли у него IPv6.

Я наткнулся на проблему, потому что я сам использовал этот конкретный «маршрут» к файлу, а также использую только IPV4. Я обнаружил проблему с инструментами разработчиков, сообщающими мне, что jquery не загружается, затем начал делать трассировки и т. Д., Чтобы найти реальную проблему.

После этого я, скорее всего, никогда не вернусь к файлам, размещенным извне, потому что: Google не нужно закрывать, чтобы это стало проблемой, и ... любой из этих узлов может быть скомпрометирован с перехватом DNS и доставить вредоносный JS вместо фактического файла. Всегда думал, что я в безопасности, так как домен Google никогда не выйдет из строя, теперь я знаю, что любой узел между пользователем и хостом может быть точкой отказа.

...