Плюси і мінуси розміщених сценаріїв [закрито]


12

Я бачив, як деякі розробники використовують розміщені сценарії для зв'язку своїх бібліотек.

cdn.jquerytools.org є одним із прикладів.

Я також бачив, як люди скаржаться, що захоплене посилання на скрипт було викрадено.

Наскільки безпечно реально використовувати розміщені сценарії? Чи сценарії автоматично оновлюються? Наприклад, якщо jQuery 5 переходить до 6, я автоматично отримую версію 6 чи мені потрібно оновити своє посилання?

Я також бачу, що Google має великий набір цих сценаріїв для налаштування хостингу.

Які плюси і мінуси?

Відповіді:


11

Плюси

  • Ваші сценарії завантажуються швидше . Якщо у вас є велика кількість ресурсів, які потрібно завантажити з одного домену, ваш браузер, як правило, вузьким місцем, щоб мати лише кілька паралельних запитів до того ж хоста. Тож якщо ви завантажуєте шістнадцять окремих скриптів, декількох зображень та декількох CSS-документів, там буде черга, оскільки кожен ресурс чекає завантаження своєї черги. (Однозначно задумайтесь про об'єднання файлів CSS та Javascript - завантаження лише двох ресурсів сценарію буде значно швидше).
  • Якщо ви відкрутите ці ресурси в окремий домен, однак у вашого браузера не виникне проблем із відкриттям додаткових підключень до цього сервера, а це означає, що більше ресурсів завантажується одночасно, що призводить до швидшого виконання сторінки. Ви також дозволяєте іншому серверу обробляти частину завантаження сторінки, що добре для вашого сервера, який, ймовірно, працює над кількома запитами на виконання сценарію, як це є.
  • Крім того, ці сервери CDN (мережі відхилення контенту) налаштовані для роботи як CDN. Вони, як правило, без файлів cookie (для менших розмірів пакетів) і створені з надзвичайно легким сервером, який повністю стосується обслуговування ресурсів та кешування загальновживаних ресурсів, а не стільки щоденним підйомом, що щось на кшталт болотного стандарту Сервер Apache виконає.
  • Використання такого CDN, як Google або Akami, має і інші переваги - Google особливо має сервери у всьому світі, а його системи маршрутизації досить розумні, щоб поєднати запит на ресурс з найближчою географічною копією, яка існує. Ваш сервер, можливо, намагається обслуговувати jQuery.js для Володимира в Росії - Google, ймовірно, має той самий ресурс по вулиці від Володимира, зменшуючи затримку.
  • Крім того, оскільки стільки веб-сайтів уже використовують ці CDN, існує велика ймовірність того, що користувач, який ви обслуговуєте, вже кеширований користувачем. jQuery.js з вашого сервера та jQuery.js з сервера Google не трактуються як один і той же файл, незалежно від того, чи точно вони однакові - якщо ви завантажите з Google, він зможе використовувати кешовану копію з попереднього сайту, яка користувач відвідав.
  • Самі файли не змінюватимуться, особливо для таких сценаріїв, як рамки Javascript. Якщо вийде нова версія, Google продовжить розміщувати стару версію (незалежно від того, наскільки грізні помилки), зокрема, щоб CDN продовжував нормально працювати і не обслуговував поганих запитів. Ось чому будь-який файл CDN є повним суфіксом з відповідним номером версії.

Мінуси

  1. Існує можливість вашого CDN бути недоступним. Однак, ймовірно, менше, ніж ваш сайт знижується, ймовірно. Більш великі CDN, такі як Google і Akami, мають кілька шарів відмови.
  2. Створювати нове з'єднання, можливо, не варто, якщо у вас є лише один або два ресурси для завантаження з вашого власного сервера.
  3. Ви не маєте ніякого контролю над файлом, який обслуговується, тому використання вашої власної версії jQuery або будь-якого іншого, що ви намагаєтеся завантажити, виключається, якщо ви не платите за власний CDN.

Безпека

Я рекомендував би цю публікацію El Stack плюс гарну кількість гуглати теми. Кожна CDN буде різною, хоча, кажучи коротко, я думаю, що це буде незначною проблемою.


1

Щось, про яке ніхто не згадував, - це ще одна можливість відстеження для Google. Вони не пропонують усі ці послуги без жодних причин без жодних причин. AdSense і Analytics цілком достатньо, і принаймні їх можна відфільтрувати. Це велика суперечка в моїй книзі.


0

Плюси:

  • Вам не доведеться платити за пропускну здатність, пов’язану з обслуговуванням файлів і взагалі

Мінуси:

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

Є й інші переваги використання CDN, але вони не стосуються безпосередньо використання 3-го сервісу хостингу скриптів.


0

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

Що сприяє такому поєднанню CDN, особливо популярних, як зазначав також Джаррод, - це те, що користувач уже отримав би доступ до URL-адреси і може негайно отримати ресурс JS з кеш-пам'яті свого клієнта, навіть не вимагаючи встановлення з'єднання.

З цією метою, якщо ми всі використовували CDN та застосовували кращі практики, ми можемо врятувати користувача від отримання додаткових ~ 10-50 КБ, коли вони спочатку отримують доступ до наших URL-адрес, і дозволяють їм швидше завантажувати свої сторінки.

Я настійно рекомендую використовувати CDN з двох причин: мінуси, про які говорив Джаррод, є правдивими, але абсолютно незначними, і якщо ви вже згрупуєте свої джерела в один документ, ви змусите всіх отримати, скажімо, статичну частину jQuery документ (~ 33 КБ) щоразу, коли ви оновлюєте один з пакетних ресурсів.

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


-2

Не робіть цього

Особисто я б не покладався на сценарії, розміщені сторонніми сторонами. Якщо ви користуєтеся сценаріями інших народів, ви знаходитесь у них на користь. Слід розглянути кілька речей:

  1. Якщо їхній веб-сайт знижується, ваша сторінка може вичерпатись або помилка.
  2. Якщо вони припиняють свою діяльність і відключають хостинг, ви просто втратили всю цю функціональність
  3. Якщо вони будуть зламані, ви також можете зламатись.
  4. Сценарії на різних сайтах можуть грати в хаос із сертифікатами SSL
  5. Час завантаження сторінки може різко збільшитися
  6. Якщо інтерфейс змінюється, вам потрібно змінити всі функціональні виклики

Безпечніше розмістити код на власному сайті, повірте мені. Вам потрібно лише один раз спалитись, і 250 веб-сайтів, які ви створили та розмістили, починають діяти смішно, оскільки ви покладалися на третю частину розміщеного сценарію, який перестав працювати.


1
Я думаю, що якщо ви використовуєте великий, надійний CDN, ви, швидше за все, не зіткнетесь із багатьма своїми проблемами. 1.) Я сподіваюся, що CDN Google матиме дуже хороший час роботи, 2.) Я не бачу, щоб Google скоро вийшов з бізнесу, 3.) Це правдоподібно, але я знову очікую дуже швидкого виправлення / виправлення, 4 .) Я не бачив жодних проблем, 5.) Якщо це респектабельний CDN, завантаження сторінок насправді повинно бути швидшим, ніж те, що ви, ймовірно, можете обслуговувати самостійно (між конвеєрним керуванням, кешуванням на декількох сайтах та без cookie-доменів), 6.) Для Основні версії, на зразок jQuery, не повинно виникнути проблем.
сканліфф

1
... також ніщо не зупиняє вас реалізовувати ваші власні резервні сценарії у випадку виходу з ладу віддалених CDN.
сканліфф

Жодна з цих причин, перерахованих Кейп-Код Ганні, не є поважною проблемою щодо сучасних CDN, таких як Google, або багатьох інших великих постачальників CDN там.
Джарод Кропива
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.