Откуда вы включаете библиотеку jQuery? Google JSAPI? CDN?


242

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

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


8
Дэррил, отличный редактор. Могу ли я предложить вам переместить редактирование вверх в верхнюю часть страницы и изменить srcна более простой / безопасный / более быстрый синтаксис, который вы используете сейчас? Ваш ответ стал в основном каноническим, и оба изменения помогут людям быстро получить то, к чему они пришли.
Джош Смит

Ответы:


153

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

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

Второе: многие люди предпочитают размещать 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>

26
Я согласен со всеми тремя вашими причинами, поэтому я размещаю jquery от Google на своих производственных сайтах. Вместо динамического внедрения js для страниц SSL я просто ссылаюсь на URL в теге сценария без указания протокола. Кажется, работает хорошо для меня. <script src = "// ajax.google ..."> </ script>
Аарон Вагнер

1
Интересная идея ... Но если вы собираетесь использовать отравление DNS для перехвата загрузки JQuery, почему бы просто не перехватить весь запрос сайта? Или как насчет скрипта Google Analytics?
Dscoduc

9
Я также согласен со всем, кроме как для упрощения вещей, я использую этот формат: <script src = "// ajax.google ..."> </ script>. Тогда мне не нужно беспокоиться о http или https. Спасибо Аарону Вагнеру за это.
Дэррил Хейн

11
Я не вижу, что document.write()используется? простое <script src="..."></script>прекрасно разместить в шапке. → @ Dscoduc: ← это не будет быстрее, это просто уберет это предупреждение. Если ваш сайт использует защищенный https и вы извлекаете незашифрованный контент (например http://googleapis), вы получите это предупреждение. Что будет немного быстрее, если вы используете только http, но вы ссылаетесь на него https://googleapis, с «безопасной» кодировкой есть некоторые издержки. Таким образом, ссылка на http://googleapisбудет немного быстрее.
vol7ron

5
Также имейте в виду, что Google будет использовать это для отслеживания сайтов, на которые заходят пользователи. Поэтому, если вы создаете веб-сайт, который должен учитывать конфиденциальность, то размещение нескольких небольших файлов - это небольшая цена за конфиденциальность.
Ганс-Кристоф Штайнер

19

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

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

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

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


1
Другая причина заключается в том, что пользователи уже имеют jquery от Google в своем кеше, поэтому им может даже не понадобиться загружать его при первом посещении вашего сайта.
Кип

14

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


7
Я с уважением не согласен, основываясь на вашей заявленной причине. Если вы получаете много трафика, то 18k за сессию может быстро добавить к значительному объему трафика. Особенно, если ваш веб-хостинг по
трафику

1
На мой взгляд, это вызывает беспокойство, только если ваши посетители смотрят только на одну страницу. Если в вашем профиле меньше посетителей и несколько просмотров страниц, тогда минимальные издержки при распределении по просмотрам страниц на посетителя. То же самое для постоянных посетителей.
Кристен

2
если ваш сайт совсем крошечный, 18k всегда будет малой частью вашего трафика.
Ганс-Кристоф Штайнер

14

Если вы хотите использовать 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>

3
Использование HTTPS, потому что сайт HTTPS, так что вроде как.
Дэррил Хейн

1
Весь ваш контент основан на https или только некоторые из них?
Dscoduc

2
http ссылки на сайтах https раздражают, потому что IE (по крайней мере, по умолчанию) доставляет вам неприятные неудобства: «Этот сайт содержит смесь безопасного и небезопасного контента». ящики для подтверждения.
Клет

1
Сайт, с которого пришел код, полностью SSL - чрезвычайно надежная контактная информация.
Дэррил Хейн

1
Если вы заботитесь о безопасности своих пользователей, всегда используйте HTTPS для javascript. Без HTTPS довольно просто обработать эти запросы и обработать эксплойты вместе с javascript, который вы намереваетесь отправить людям. Подумайте об общедоступном Wi-Fi, взломанных домашних маршрутизаторах и т. Д. В качестве возможных мест MITM. Посмотрите на все эти состязания по принципу pwn-to-own: они всегда используют браузер, чтобы войти.
Ганс-Кристоф Штайнер

8

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

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


2
Я положил пользовательский опыт (быстрое время загрузки) прямо там с меньшим количеством зависимостей.
Dscoduc

1
@ Slacy Эй, ваш сайт не работает! на самом деле jk, но я заметил, что вы используете аналитику Google и у вас есть сценарий в начале, а не в конце, что замедлит ваш сайт, если Google работает медленно
Simon_Weaver

3
хм ... сласи использует Google Analytics? Разве он не сказал, что не хотел бы, чтобы какой-либо публичный сайт, который он разрабатывал, зависел от внешнего сайта? ;-)
Dscoduc

1
Вау, парни, там есть несколько резких комментариев. :) Да, я использую Analytics в своем личном блоге, но это не производственный сайт, который приносит доход, так что я думаю, что это действительно хорошо. Я уверен, что мой сайт не работает в течение многих дней в году. Помните, что вы делаете для личных сайтов и для работы не то же самое
Slacy

6
Есть и другие веские причины использовать локальную копию: Google часто блокируется во многих странах, таких как Иран, Китай и т. Д. Таким образом, более миллиарда человек не будут иметь доступа.
Ганс-Кристоф Штайнер,

6

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

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

Минусы:

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

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


3
Это минусы Firefox, а не Google.)
Накилон

6

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

<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, все соответствующие плагины и собственный код и поместить его в один минимизированный файл.

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

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

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

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


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

4

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


4

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

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


Но вы уже используете Google Analytics на своем сайте? Поскольку я не думаю, что имеет большое значение, исходит ли JQuery от Google или нет, они, вероятно, уже знают, что я запускаю его на своем сайте ...
Dscoduc

Но он кешируется на 1 год - мы даже тем временем отправляем в Google 304 «Файл изменен»?
Кристен

Да, я также видел эти периодические звонки в Google (у менеджера активности Safari есть хороший список).
Дэррил Хейн

Dscoduc - да, используя Analytics. По крайней мере, с этой реализацией я заранее понял, что я отказываюсь от данных об использовании. Не так с JS libs.
JRO

3

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


3
Что вы подразумеваете под "хорошими манерами"? Google рекомендует вам ссылаться на их сервер. Он выкачан невероятной инфраструктурой Google.
Носредна

2
сначала возникает путаница, когда вы слышите об использовании Google. но , как nosredna сказал , что это будет поощряться «Мы боль из хостинг библиотеки, правильно настроить заголовки кэша, оставаясь в курсе самых последних исправлений ошибок, и т.д.» - code.google.com/apis/ajaxlibs
Simon_Weaver

3

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

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

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

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


2

Я просто включил последнюю версию с сайта jQuery: http://code.jquery.com/jquery-latest.pack.js Он соответствует моим потребностям, и мне никогда не придется беспокоиться об обновлении.

РЕДАКТИРОВАТЬ: для крупного веб-приложения, безусловно, контролировать его; скачать его и обслуживать его самостоятельно. Но для моего личного сайта мне было все равно. Вещи волшебным образом не исчезают, они обычно устаревают первыми. Я не отставал от этого достаточно, чтобы знать, что изменить в будущих выпусках.


1
я обнаружил, что этот метод опасен, что если изменение кода в библиотеке нарушит работу вашего сайта? или сайт jquery не работает? Я предпочел бы иметь полный контроль над файлом.
Джейсон Miesionczek

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

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

Я согласен с Джейсоном, автоматическое переключение на более новую версию очень опасно. Возможно, не так много, если вы используете только jquery, но с плагинами я определенно не рекомендую его. Я, например, использую плагин на одном сайте, который работает с 1.2.6, но не с 1.3.x (пока ...)
jeroen

2

Вот некоторый полезный ресурс, надеюсь, поможет вам выбрать свой CDN. MS недавно добавила новый домен для доставки библиотек через CDN.

Старый формат: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js Новый формат: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

Это не должно отправлять все куки для microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Вот некоторая статистика о наиболее популярных технологиях, используемых в сети во всех технологиях. http://trends.builtwith.com/

Надежда может помочь вам выбрать.


1

Если я ответственен за «живой» сайт я лучше быть в курсе всего , что происходит и в моем сайте. По этой причине я сам размещаю версию jquery-min либо на том же сервере, либо на статическом / внешнем сервере, но так или иначе, где только я (или моя программа / прокси) могу обновить библиотеку после проверки / тестирования каждого изменения


Я надеюсь, что Google никогда не изменит файл - для исправлений ошибок будет размещен новый файл с другим номером версии в имени файла. Или я наивный? Будут ли они развертывать "Незначительные исправления", используя то же имя файла?
Кристен

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

1

В голове:

  (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);
  })();

Конец тела:

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

0

Я размещаю его вместе с другими моими js-файлами на своем собственном сервере, и в этот момент объединяю и минимизирую их (с помощью django-compresser, здесь, но не в этом суть), чтобы они служили только одним js-файлом со всем сайтом необходимо положить в это. В любом случае вам нужно будет обслуживать свои собственные файлы js, поэтому я не вижу смысла не добавлять туда дополнительные байты jquery - еще несколько килобайт гораздо дешевле для передачи, чем больше запросов. Вы ни от кого не зависите, и как только ваши минимизированные js будут кэшированы, вы тоже будете очень быстры.

При первой загрузке решение на основе CDN может победить, поскольку вы должны загрузить дополнительные килобайты jquery со своего собственного сервера (но без дополнительного запроса). Я сомневаюсь, что разница заметна, хотя. И затем, при первой загрузке с очищенным кешем, ваше собственное размещенное решение, вероятно, всегда будет намного быстрее из-за большего количества запросов (и запросов DNS), необходимых для получения jquery CDN.

Интересно, как этот момент почти никогда не упоминается, и как CDN, кажется, захватывают мир :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.