Чем грозит CDN вашему сайту?
Администратор
05.08.2019
  • F.Studio
  • /
  • Чем грозит CDN вашему сайту?

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

О чем идет речь?

Сейчас для разработчиков вполне обыденно подключать плагины и библиотеки через публичные CDN-сервисы. Классический пример такого подкллючения — jQuery, который зачастую используется так:

<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js"></script>

Существует множесто плюсов от использования такого подключения ( о них можно почитать в статье студии: Зачем нам CDN и как его подключить? ), но сегодня у меня обратная цель — разрушить мифические представления о CDN или показать, как стоимость такого инструмента значительно превышает результат. В кратце:

  • Это удобно. Не требуется особых затрат и умений, чтобы использовать CDN — это легко.
  • Применение CDN. Вы получаете качество CDN ресурса бесплатно.
  • Удобство. Пользователь, возможно, уже посещал сайт, который использует тот же CDN-ресурс (например, с jquery) и ему не потребуется качать файл заново, а ваш сайт загрузится быстрее.

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

Риск: замедление и перебои в работе

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

Проще говоря, если Вы храните на публичных CDN-сервисах CSS и JS файлы, блокирующие рендер — есть повод задуматься и перенести все файлы на свой сервер.

Риск: Отключение сервиса

Эта проблема встречается очень редко, но все же случается. Так в Октябре 2018 года сервис Rawgit просто отключил свои сервера. В настоящее время более миллиона проектов на GitHub до сих пор содержат упоминания отключенного сервиса. Более того, около 20’000 работающих сайтов пытаются подгрузить ресурсы с Rawgit.

HTTPArchive выборка работающий сайтов, использующих Rawgit

Риск: Безопасность проекта

Другой проблемой, которая может Вас настигнуть при использовании CDN где надо и где не надо — это безопасность. К примеру, возьмем все тот же jQuery — его используют практически в каждом проекте повсеместно. А теперь представьте, что некто получил доступ к провайдеру CDN code.jquery.com и добавил свой компромитирующий код или какой-либо вирус. Ужас, не так ли ?

Не все так плохо — решение есть!

К счастью, добросовестные CDN сервисы позаботились о безопасности подключаемых библиотек и использують SRI (англ. Subresource Integrity). SRI — это механизм, с помощью которого провайдер предоставляет хэш (технически, сам хэш кодируется в base64) конкретного файла, который Вы оба — и сервис, и клиент — ожидаете получить. Затем браузер может проверить, что запрошенные и полученные файлы это одно и то же и никто не добавил вредоносный код в тот или иной скрипт, используемый на сайте.

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

Проблема: разделение источников

Одной из самых больших и самых распространненых проблем при использовании CDN является потеря так желаемой скорости. Почему так происходит? Просто чем больше Вы используете раличных платформ и сервисов, тем больше новых TCP соединений будет вынужден установить браузер посетителя.

Рассмотрим пример: вот что предлагает своим пользователям упомянутый в первой статье Bootstrap.

<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="..." crossorigin="anonymous">
<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="..." crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" integrity="..." crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="..." crossorigin="anonymous"></script>

Предложенные для подключения файлы расположены на трех разных серверах. Сколько же придется заплатить за такое количество соединений?

Быстрое соединение. Вариант, предложенный Bootstrap (3 разных CDN)
Бысрое соединение, но файлы уже на нашем сервере

В общем и целом немного, а именно 311ms, но это с быстрым интернетом, а что будет с мобильным 3G ? Мы теряем 1.765 секунды, а это уже значительно.

3G-соединение, файлы на серверах CDN
3G-соединение, файлы на нашем ресурсе

Удобный костыль — preconnect

Конечно, будет лучше, если Вы будите хранить все статические файлы (библиотеки) у себя на сервере, но если у Вас нет выбора — используйте preconnect.

Эта функция позволит Вам избежать больших затрат на открытие дополнительных TCP соединений, а применение ее в HTTP заголовках будет даже еще быстрее.

Проблема: потеря приоритетов

Эта проблема исходит от оптимизации на уровне протоколов, о которой мы начинаем жалеть, когда разделяем контент между несколькими доменами. Если вы используете HTTP/2 (который к настоящему моменту я настоятельно рекомендую использовать), то вы получаете доступ к приоритезации. Все потоки внутри одного подключения имеют приоритеты и браузер в тандеме с сервером выстраивают соответствующее дерево зависимостей из этих потоков, чтобы загрузить в первую очередь самые важные библиотеки.

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

Применено несколько CND-сервисов
Здесь все ресурсы находятся на нашем сервере

Вывод: если мы будем использовать как можно больше ресурсов с одного домена (IP адреса), мы позволим HTTP/2 сделать свое дело и приотизировать библиотеки и загрузить их в правильном порядке.

Проблема: кеширование

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

Миф: Одинаковые библиотеки для разных сайтов

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

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

В общем, это очень привлекательная теория, но нет никакого подтверждения, что кеширование общих ресурсов для нескольких доменов хоть сколько-нибудь эффективно.

Заключение

В заключение стоит сказать, что на деле Вы действительно используете CDN, но стоит ли оно того? Да, вы получаете все преимущества распределенной сети серверов, но при этом оставляете файлы на чужих серверах, доверяя безопасность и стабильность Вашего проекта владльцам CDN-сервиса. Более того, вы даже замедляете сайт, заставляя пользователей устанавливать несколько TCP соединений. Если Вы все же хотите использовать CDN и пользоваться его преимуществами — воспользуйтесь платными ресурсами и разместите все нужные Вам файлы на одном домене.