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

есть несколько способов включить 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, поэтому он кэшируется при посещении других сайтов и для экономии пропускной способности с нашего сервера, но если он продолжает оставаться медленной частью сайта, я могу изменить include.

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

Edit: только что посетил сайт 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 236
javascript jquery openssl google-ajax-libraries

16 ответов:

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

первый: серверы Google api распределены по всему миру вместо моего местоположения на одном сервере: более близкие серверы обычно означают более быстрое время отклика для посетителя.

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

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

Я понимаю, что я размещаю часть доверия на 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, вы можете использовать следующий исходный путь (keep in виду, что jQuery не поддерживает SSL-соединения):

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

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

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

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

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

18

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

14

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

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

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

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

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

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

7

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

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

плюсы:

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

интересно, если вы можете включить из Google, а затем проверить наличие какой-то глобальной переменной, или somesuch, и если отсутствие нагрузки с вашего сервера?

5

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

<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.минута.загрузка скриптов. Второй способ не будет иметь заметного мерцания. Первая воля. Лично я думаю, что это не хороший пользовательский опыт.

в качестве примера выполнения этого:

<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 (The сжатая версия сверху). Так то есть две связи, а не один. По своему опыту я обнаружил, что время загрузки было фактически 2-3 раза медленнее, чем загрузка с моего собственного личный общий сервер, даже если он шел от Google, и моя версия из сжатого файла была пара К больше, чем от Google. Это даже после того, как файл был загружен и (предположительно) кэшируется. Так что для меня, так пропускная способность не имеет значения много, не имеет значения.

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

так что в конце концов я не могу действительно видеть меня с помощью Google AJAX API для jQuery по крайней мере (более "полные" API-интерфейсы являются другая история в некотором смысле) много, кроме как размещать примеры здесь.

5

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

4

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

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

4

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

3

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

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

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

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

3

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

EDIT: для крупного веб-приложения, конечно, контролировать его; скачать его и обслуживать его самостоятельно. Но для моего личного сайта, я не мог заботиться меньше. Вещи не исчезают волшебным образом, они обычно сначала осуждаются. Я иду в ногу с ним достаточно, чтобы знать, что изменить для будущих релизов.

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

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

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

надеюсь, может помочь вам выбрать.

2

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

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

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

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

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

0