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

12

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

cdn.jquerytools.org это один пример.

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

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

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

Каковы плюсы и минусы?

P.Brian.Mackey
источник

Ответы:

11

Pros

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

Cons

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

Безопасность

Я бы порекомендовал этот пост в El Stack, а также поиск в Google по этой теме. Каждый CDN будет отличаться, хотя в двух словах я думаю, что это будет небольшая проблема.

Джаррод Крапива
источник
1

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

плакат
источник
0

Плюсы:

  • Вам не нужно платить за пропускную способность, связанную с обслуживанием файлов и, как правило,

Минусы:

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

Существуют и другие преимущества использования CDN, но они не имеют прямого отношения к использованию третьего хостинга скриптов.

ryanzec
источник
0

Что касается передового опыта, общий подход к оптимизации загрузки страниц состоит в объединении всех ваших ресурсов JS из-за ограниченного числа соединений с одним доменом, как упоминал Джаррод, и установки в ответе заголовка с истекшим сроком действия в будущем.

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

В связи с этим, если мы все использовали CDN и использовали лучшие практики, мы можем избавить пользователя от получения дополнительных ~ 10-50 КБ при первом обращении к нашим URL-адресам и позволить им быстрее загружать свои страницы.

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

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

Филипп Дупанович
источник
-2

Не делай этого

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

  1. Если их сайт закрывается, ваша страница может выйти из строя или выйти из строя.
  2. Если они выходят из бизнеса и отключают хостинг, вы просто теряете всю эту функциональность
  3. Если их взломают, вы также можете взломать.
  4. Межсайтовый скриптинг может разрушить SSL-сертификаты
  5. Время загрузки страницы может значительно увеличиться
  6. Если интерфейс меняется, вам нужно изменить все вызовы функций

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

Майкл Райли - AKA Gunny
источник
1
Я думаю, что если вы используете большой, надежный CDN, вы, скорее всего, не столкнетесь со многими своими проблемами. 1.) Я ожидаю, что у CDN Google будет очень хорошее время безотказной работы, 2.) Я не вижу, что Google скоро выйдет из бизнеса, 3.) Это правдоподобно, но опять же я ожидаю очень быстрое исправление / исправление, 4 .) Я не видел никаких проблем, 5.) Если это респектабельный CDN, загрузка страниц должна быть на самом деле быстрее, чем то, что вы, вероятно, сможете обслуживать самостоятельно (между конвейерной передачей, многосайтовым кэшированием и доменами без файлов cookie), 6.) Для Основные версии версий, таких как jQuery, не должны быть проблемой.
scunliffe
1
... кроме того, ничто не мешает вам реализовать собственные резервные сценарии на случай сбоя удаленных CDN.
scunliffe
Ни одна из этих причин, перечисленных в Cape Cod Gunny, не относится к современным CDN, таким как Google или многим другим крупным поставщикам CDN.
Джаррод Неттлс