Откуда вы включаете библиотеку 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, чтобы он кэшировался при посещении других сайтов и для экономии пропускной способности с нашего сервера, но если он продолжает оставаться медленной частью сайта, я могу изменить включение.
Что ты используешь? Были ли у вас какие-либо проблемы?
Изменить: только что посетил сайт 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 ответов
Без сомнения, я предпочитаю, чтобы 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>
ОБНОВЛЕНИЕ 8/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>
Одна из причин, по которой вам может потребоваться размещение на внешнем сервере, заключается в том, чтобы обойти ограничения браузера для конкретных соединений с конкретным сервером.
Однако, учитывая, что файл jQuery, который вы используете, скорее всего, будет меняться не очень часто, кеш браузера сработает и по большей части станет спорным.
Вторая причина разместить его на внешнем сервере - снизить трафик на ваш собственный сервер.
Однако, учитывая размер jQuery, скорее всего, это будет небольшая часть вашего трафика. Возможно, вам следует попытаться оптимизировать ваш фактический контент.
Размер jQuery 1.3.1 min составляет всего 18 КБ. Я не думаю, что это слишком много, чтобы спросить при начальной загрузке страницы. Это будет кэшировано после этого. В результате я принимаю это сам.
Если вы хотите использовать 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>
Я бы не хотел, чтобы какой-либо публичный сайт, который я разработал, зависел от какого-либо внешнего сайта, и поэтому я бы сам размещал jQuery.
Готовы ли вы к отключению на вашем сайте, когда другой (Google, jquery.com и т. Д.) Выходит из строя? Меньше зависимостей - это ключ.
Плюсы: Хост на Google имеет преимущества
- Вероятно, быстрее (их серверы более оптимизированы)
- Они обрабатывают кеширование правильно - 1 год (мы изо всех сил пытаемся внести изменения, чтобы получить заголовки прямо на наших серверах)
- Пользователи, у которых уже есть ссылка на размещенную в Google версию в другом домене, уже имеют файл в своем кэше
Минусы:
- Некоторые браузеры могут видеть его как междоменный XSS и запрещать файл.
- В частности, пользователи, использующие плагин NoScript для Firefox
Интересно, можно ли ВКЛЮЧИТЬ из Google, а затем проверить наличие какой-нибудь глобальной переменной или что-то такое, а также отсутствие загрузки с вашего сервера?
Здесь есть несколько вопросов. Во-первых, указанный вами метод асинхронной загрузки:
<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, все соответствующие плагины и собственный код и поместить его в один минимизированный файл.
Следует ли использовать Google Ajax Libraries API для хостинга?:
Что касается времени загрузки, вы фактически загружаете два скрипта - скрипт jsapi и скрипт mootools (сжатая версия сверху). Так что это две связи, а не одна. Исходя из своего опыта, я обнаружил, что время загрузки на самом деле в 2-3 раза медленнее, чем загрузка с моего личного общего сервера, даже если он исходил от Google, и моя версия сжатого файла была на пару К больше, чем у Google. Это даже после того, как файл был загружен и (предположительно) кэширован. Так что для меня, поскольку пропускная способность не имеет большого значения, не будет иметь значения.
Наконец, у вас есть потенциальная проблема, связанная с тем, что браузер-параноик помечает запрос как своего рода попытку XSS. Обычно это не проблема с настройками по умолчанию, но в корпоративных сетях, где пользователь может не иметь контроля над тем, какой браузер он использует, не говоря уже о настройках безопасности, у вас могут быть проблемы.
Так что, в конце концов, я не вижу, как я использую API Google AJAX для jQuery, по крайней мере (более "полные" API - это отдельная история), за исключением публикации здесь примеров.
Я должен проголосовать -1 за библиотеки, размещенные в Google. Они собирают данные в стиле Google Analytics, оборачивая их вокруг этих библиотек. Как минимум, я не хочу, чтобы клиентский браузер делал больше, чем я его просил, и тем более всего остального на странице. Хуже того, это "новая версия" Google - не быть злым - использовать ненавязчивый javascript для сбора большего количества данных об использовании.
Примечание: если они изменили эту практику, супер. Но в последний раз, когда я рассматривал возможность использования их размещенных библиотек, я отслеживал исходящий http-трафик на моем сайте, и я не ожидал увидеть периодические обращения к серверам Google.
В дополнение к людям, которые советуют размещать его на собственном сервере, я предложил хранить его в отдельном домене (например, static.website.com), чтобы браузеры могли загружать его отдельно от другого потока контента. Этот совет также работает для всех статических вещей, например, изображений и CSS.
Я мог бы быть старой школы об этом, но я все еще нахмурился на хотлинкинг. Возможно, Google является исключением, но в целом, это просто хорошие манеры для размещения файлов на вашем собственном сервере.
Я добавлю это в качестве причины для локального размещения этих файлов.
Недавно узел в Южной Калифорнии на TWC не смог разрешить домен ajax.googleapis.com (только для пользователей с IPv4), поэтому мы не получаем внешние файлы. Это было прерывистым вплоть до вчерашнего дня (теперь оно является постоянным.) Поскольку оно было прерывистым, у меня были тонны проблем, устраняющих проблемы пользователей SaaS. Потратил бесчисленные часы, пытаясь отследить, почему у некоторых пользователей не было проблем с программным обеспечением, а у других возникали проблемы. В моем обычном процессе отладки я не имею привычки спрашивать пользователя, отключен ли у него IPv6.
Я наткнулся на проблему, потому что я сам использовал этот конкретный "маршрут" к файлу, а также использую только IPV4. Я обнаружил проблему с инструментами разработчиков, сообщающими мне, что jquery не загружается, затем начал делать трассировки и т. Д., Чтобы найти реальную проблему.
После этого я, скорее всего, никогда больше не вернусь к файлам, размещенным извне, потому что: Google не нужно останавливаться, чтобы это стало проблемой, и... любой из этих узлов может быть скомпрометирован с перехватом DNS и доставкой вредоносных js вместо фактического файла. Всегда думал, что я в безопасности, так как домен Google никогда не выйдет из строя, теперь я знаю, что любой узел между пользователем и хостом может быть точкой отказа.
Вот некоторый полезный ресурс, надеюсь, поможет вам выбрать свой 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
Вот некоторая статистика о наиболее популярных технологиях, используемых в сети во всех технологиях. http://trends.builtwith.com/
Надежда может помочь вам выбрать.
Я просто включил последнюю версию с сайта jQuery: http://code.jquery.com/jquery-latest.pack.js Он соответствует моим потребностям, и мне никогда не придется беспокоиться об обновлении.
РЕДАКТИРОВАТЬ: для крупного веб-приложения, безусловно, контролировать его; скачай и подай сам. Но для моего личного сайта мне было все равно. Вещи волшебным образом не исчезают, они обычно устаревают первыми. Я не отставал от этого достаточно, чтобы знать, что изменить в будущих выпусках.
Если я отвечаю за "живой" сайт, мне лучше знать обо всем, что происходит на моем сайте. По этой причине я сам размещаю версию jquery-min либо на том же сервере, либо на статическом / внешнем сервере, но в любом случае могу разместить только я (или мою программу / прокси), обновив библиотеку после проверки / тестирования каждого изменения.
В голове:
(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>
Я размещаю его вместе с другими моими js-файлами на своем собственном сервере, и, в этот момент, объединяю и минимизирую их (с помощью django-compresser, здесь, но не в этом суть), чтобы они служили только одним js-файлом со всем сайтом необходимо положить в это. В любом случае вам нужно будет обслуживать свои собственные файлы js, поэтому я не вижу смысла не добавлять туда и дополнительные байты jquery - еще несколько килобайт гораздо дешевле передать, чем большее количество запросов. Вы ни от кого не зависите, и как только ваши минимизированные js будут кэшированы, вы тоже будете очень быстры.
При первой загрузке решение на основе CDN может выиграть, потому что вы должны загрузить дополнительные килобайты jquery со своего собственного сервера (но без дополнительного запроса). Я сомневаюсь, что разница заметна, хотя. И затем, при первой загрузке с очищенным кешем, ваше собственное размещенное решение, вероятно, всегда будет намного быстрее из-за большего количества запросов (и запросов DNS), необходимых для извлечения jquery CDN.
Интересно, как этот момент почти никогда не упоминается, и как CDN, кажется, захватывают мир:)