Звідки ви включаєте бібліотеку jQuery? Google JSAPI? CDN?


242

Є кілька способів включити інтерфейс 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.


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

Відповіді:


153

Без сумніву, я вирішую, щоб JQuery обслуговувався серверами API Google. Я не пішов з методом 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. Thxs Аарон Вагнер за це.
Дарріл Хайн

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


7
Я з повагою не згоден, виходячи з вашої заявленої причини. Якщо ви отримуєте багато трафіку, то 18 кб за сеанс можуть швидко додати значну кількість трафіку. Особливо, якщо ваш веб-хостинг стягується за пропускною здатністю ...
Dscoduc

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 цілком легко провести ці запити (MITM) ці запити та подавати подвиги поряд із javascript, який ви збираєтесь надсилати людям. Подумайте про загальнодоступний Wi-Fi, зламані домашні маршрутизатори тощо як можливі MITM-адреси. Подивіться на всі змагання з власноруч: вони завжди використовують браузер, щоб потрапити.
Ганс-Крістоф Штайнер

8

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

Чи готові ви відключити роботу на своєму веб-сайті, коли інший (Google, jquery.com тощо) знизиться? Менш залежностей є ключовим.


2
Я ставлю досвід користувача (швидкий час завантаження) прямо там, з меншими залежностями.
Dscoduc

1
@slacy Ей ваш сайт знищений! насправді jk, але я помітив, що ви використовуєте аналітику google і маєте їх сценарій на початку замість кінця - що сповільнить ваш сайт частково, якщо Google буде повільним
Simon_Weaver

3
хм ... слабість використовує Google Analytics? Хіба він просто не сказав, що не хоче, щоб будь-який публічний сайт, розроблений ним, залежав від зовнішнього сайту? ;-)
Dscoduc

1
Нічого собі, чуваки, кілька суворих коментарів. :) Так, я використовую Analytics у своєму особистому блозі, але це не виробничий сайт, який приносить прибуток, тому я думаю, що це справді просто чудово. Я впевнений, що мій сайт працює протягом багатьох днів на рік. Пам'ятайте, що ви робите для особистих сайтів та для роботи - це не одне і те ж
збийте

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, усі відповідні плагіни та власний код та помістити його в один мінімізований файл.

З чого слід використовувати API Ajax Libraries від Google для хостингу? :

Що стосується завантаження разів, ви фактично завантажуєте два сценарії - сценарій jsapi та сценарій mootools (стисла версія зверху). Отже, це два з'єднання, а не один. На моєму досвіді я виявив, що час завантаження насправді в 2-3 рази повільніше, ніж завантаження з мого особистого спільного сервера, навіть якщо він надходив від Google, а моя версія стислого файлу була на пару K більше, ніж у Google. Це навіть після завантаження файлу та (імовірно) кешування. Тож для мене, оскільки пропускна здатність не має великого значення, значення не має значення.

Нарешті, у вас є потенційна проблема параноїдального браузера, який позначає запит як якусь спробу XSS. Зазвичай це не проблема з налаштуваннями за замовчуванням, але в корпоративних мережах, де користувач може не мати контролю над тим, який браузер він використовує, не кажучи вже про налаштування безпеки, у вас можуть виникнути проблеми.

Отже, врешті-решт, я не можу насправді бачити, як я використовую прикладний API AJAX Google для jQuery (принаймні "повніші" API-файли є різною історією), окрім публікацій прикладів тут.


Я не відчував жодного з питань, про які ви згадуєте. Просто завантаження речей у правильному порядку вирішить майже все, наскільки я розумію.
Дарріл Хайн

4

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


4

Я повинен проголосувати -1 за бібліотеки, розміщені в Google. Вони збирають дані, google analytics style, своїми обгортками навколо цих бібліотек. Як мінімум, я не хочу, щоб веб-переглядач робив більше, ніж я прошу, і тим більше що-небудь ще на сторінці. На гірше - це "нова версія" від 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 знижується? я б швидше мав повний контроль над файлом.
Jason Miesionczek

1
Крім того, я ненавиджу потрапляти на пропускну здатність людей jQuery таким чином. Вони вже пропонують по-справжньому класний безкоштовний інструмент, і мені б не хотілося, щоб вони знижувалися через витрати на пропускну здатність. Краще використовувати Google як своє зовнішнє джерело, якщо ви не хочете його розміщувати самостійно, оскільки вони надають його для цієї мети.
nezroy

Я рекомендую перейти на використання 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

Це не повинно надсилати всі файли cookie для 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-compressser, тут, але це не суть), щоб вони служили лише одним js-файлом із усім сайтом потреби, поставлені в ньому. Вам все одно доведеться обслуговувати свої js-файли, тому я не бачу причин не додавати зайвих байтів jquery туди - кілька кілограмів набагато дешевше для передачі, ніж більше запитів. Ви ні від кого не залежні, і як тільки ваш мінімізований js буде кешований, ви також дуже швидкі.

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

Цікаво, як цей момент майже ніколи не згадується, і як, схоже, CDN переймають світ :)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.