CDN(Content Delivery Network) - это подход, позволяющий хранить части страниц вашего сайта на других серверах. Обычно это кастомные шрифты, таблицы стилей, скрипты и иконки. CDN хорош тем, что позволяет кэшировать часто используемые библиотеки типа jQuery, не загружая их заново для каждого сайта. При большом количестве подключаемых файлов на странице, браузер не может делать много запросов к одному домену одновременно. Однако использование CDN, расположенного на другом домене, позволяет обойти эту проблему. На сайтах с огромной посещаемостью CDN позволяет экономить ресурсы серверов. В общем это замечательная технология. А под катом я расскажу, почему первым делом при получении сайта на поддержку, я вырезаю все ссылки на CDN и заменяю их на локальные ресурсы.
Интернет-цензура в мире крепнет с каждым годом. В моем случае это выливается в комичные ситуации, когда у российских провайдеров в бан улетают заграничные CDN, а у украинских - CDN, например, яндекса. Еще бывают проблемы самого хостинга, когда по какой-то причине сервера начинают "не видеть" подсети, в которых расположен CDN. Таким образом использование CDN в текущей обстановке - это риск того, что сайт может в любой момент перестать работать.
Второй важной проблемой является протухание ссылок на CDN. На старых проектах вы можете столкнуться с ситуацией, когда CDN удалил старую версию библиотеки, на которую все завязано. И вам теперь нужно срочно искать ее, или ближайшую подходящую версию.
Третья проблема - это скорость самих CDN. Во-первых она нестабильна сама по себе, и можно достаточно долго смотреть как в статус баре браузера меняются надписи "Ожидание ответа от *.cdn.net". После каждой смены надписи страница может кардинально перерисовываться, в зависимости от того какие стили и шрифты подгрузились. А что может быть лучше, чем когда за долю секунды до нажатия на кнопку, вы нажимаете на другую кнопку, которая внезапно оказывается у вас под пальцем? Особенно болезненно CDN ощущается на мобильном интернете, потому что по создание соединения там - гораздо более долгая операция, чем передача данных по уже открытому. А нестабильный характер самого мобильного интернета приводит к тому, что сайт может загружаться очень долго и в итоге не до конца.
Четвертая проблема - это локальная разработка. Если у тебя нет интернета в дороге или он плохой, то полноценно работать над сайтом невозможно.
Пятая проблема - CDN неоптимален. Даже если у вас все ссылки будут вести на минифицированные версии стилей и скриптов, то это все равно несколько запросов. И вам все равно придется загружать свои скрипты и стили, т.е. придется в любом случае делать несколько запросов в разные места. Использование сборщиков и минификация ресурсов позволит сократить количество запросов и уменьшить количество дерганий сайта при загрузке.
Шестая проблема - это поменявшийся характер использования интернета. Теперь пользователи довольно мало ходят по сайтам, придерживаясь нескольких основных, но посещая их регулярно. И тут плюсы кэширования сходят на нет - чем меньше сайтов посещает пользователь, тем меньше вероятность что в кэш будут попадать какие-то общие для этих сайтов библиотеки. Последнее помножается на количество этих библиотек и их версий. И есть шанс что на всех сайтах, посещаемых пользователем не будет ни одной общей версии Bootstrap или jQuery.
Нужен ли вам CDN? Скорее всего нет, если у вас не сотни тысяч посетителей в день. И от него для небольшого и среднего сайта будет больше вреда, чем пользы, особенно если значительная часть вашей предполагаемой аудитории использует мобильные устройства.
Комментарии (21)
Vasily_T
19.10.2021 13:23+4CDN хорош только для ресурсов с огромной посещаемостью (для снижения нагрузки), для остальных случаев оно не дает никакой выгоды или выгода совсем незначительна....
alexshy
19.10.2021 13:34+20Надо будет написать статью "Почему от категоричных заголовков начинающим авторам (и не только) всегда больше вреда, чем пользы".
P.S. Вообще-то общее правило таково: чем больше у человека опыт общения с предметом, тем более осторожные у него высказывания/заявления/выводы по данному предмету. Поэтому часто по одному заголовку можно уже решить, заслуживает материал, а вместе с ним и автор, внимания или нет.
P.P.S. Если, конечно, он не Эйнштейн с очередной общей теорией чего-нибудь там такого эдакого. Которую, кстати, потом еще целые поколения замучаются доказывать (или опровергать).
melanton Автор
19.10.2021 14:46+1Имхо будет больше вреда, если в вебе CDN будут делать не бездумно, априори потому что хорошая практика. Сейчас во многих тутриалах включение стилей и скриптов по CDN воспринимается как самой собой разумеющееся. Люди смотрят и повторяют не думая, что это за магические ссылки такие. Так что мой заголовок меньшее зло. Даже у тех кто не прочитает статью в голове где-то отложится, что нужно дважды подумать про CDN.
alexshy
19.10.2021 15:00Даже у тех кто не прочитает статью в голове где-то отложится, что нужно дважды подумать про CDN
Это касается ровным счетом всего. Не только применительно к веб-разработке. Более того, народная мудрость гласит "семь раз отмерь, один раз отрежь". Заметьте, семь, а не дважды.
А у нас лентяи и неумехи соберут сайт, как лего-конструктор, из всевозможных библиотек и фреймворков, благо, сейчас все делается для облегчения работы таким горе-создателям, а потом удивляются, почему он у них тихо ездит? или вообще только задом...
Поэтому начинать думать надо задолго до того, как встает вопрос о выборе или не выборе CDN. Но если этот выбор в конечном итоге мотивируется решениями на уровне интуиции, а не замерами производительности и шлифовкой кода, он никогда не будет оптимальным.
gruzoveek
19.10.2021 13:59+4Теперь еще и кеширование одних и тех же ресурсов для разных сайтов не работает, насколько я помню
SergeiMinaev
19.10.2021 15:37+3CDN хорош тем, что позволяет кэшировать часто используемые библиотеки типа jQuery, не загружая их заново для каждого сайта. При большом количестве подключаемых файлов на странице, браузер не может делать много запросов к одному домену одновременно. Однако использование CDN, расположенного на другом домене, позволяет обойти эту проблему.
В HTTP2 браузер может делать до 100 одновременных запросов (проверил на FF, насчёт Chrome не уверен).
Всё-таки CDN, в первую очередь, нужен для снижения задержки (RTT) для пользователей, находящихся физически далеко от вашего дата-центра.
На старых проектах вы можете столкнуться с ситуацией, когда CDN удалил старую версию библиотеки, на которую все завязано. И вам теперь нужно срочно искать ее, или ближайшую подходящую версию.
Вы пишете про вариант, когда на сайт вставляется готовая ссылочка на какую-то библиотеку, но это не единственный способ использования. Из документации по CDN Selectel (применимо ко всем CDN):
"Файл при первом запросе пользователя загружается в кэш CDN-серверов с основного сервера - источника контента. При последующих запросах того же файла, он отдается с кэширующих серверов CDN."Четвертая проблема - это локальная разработка. Если у тебя нет интернета в дороге или он плохой, то полноценно работать над сайтом невозможно.
Лично у меня в условном index.html всегда отличаются подключаемые скрипты в DEV и PROD версиях. Этим же способом решается и указанная проблема.
И от него для небольшого и среднего сайта будет больше вреда, чем пользы, особенно если значительная часть вашей предполагаемой аудитории использует мобильные устройства.
В сетях 4G высокий RTT (пинг). Если у вас сервер расположет в Москве и к вам на сайт зайдёт пользователь с Камчатки, то задержка может быть 200мс или выше. В случае с CDN, ресурсы с большой долей вероятности будут скачаны с сервера, физически расположенного ближе к пользователю.
melanton Автор
19.10.2021 16:12В HTTP2 браузер может делать до 100 одновременных запросов (проверил на FF, насчёт Chrome не уверен).
Всё-таки CDN, в первую очередь, нужен для снижения задержки (RTT) для пользователей, находящихся физически далеко от вашего дата-центра.
В сетях 4G высокий RTT (пинг). Если у вас сервер расположет в Москве и к вам на сайт зайдёт пользователь с Камчатки, то задержка может быть 200мс или выше. В случае с CDN, ресурсы с большой долей вероятности будут скачаны с сервера, физически расположенного ближе к пользователю.
Вы абсолютно правы. И когда все работает идеально, то так оно и есть. И если сделать фронтенд бандлом и закинуть его на CDN - все будет быстро и хорошо. Но таких людей реально единицы. Обычно я вижу кучу ссылок на разные CDN из-за чего загрузка сайта на телефоне, где соединения открываются медленно, это печалька. Чтобы CDN был полезен нужно чтобы люди понимали что он делает, какой ценой и какие проблемы решает. Я про случай когда единственный повод не использовать CDN для разработчика - лень скачивать и собирать библиотеку.
И раз вы упомянули HTTP 2. Не будет ли такого, что для SPA где весь index.html - это 50 строчек с подключением бандлов и минителом-контейнером, куда будет маунтиться сам приложение, будет быстрее подтянуть через то же соединение бандлы чем открывать новое до ближайшего CDN сервера?
Лично у меня в условном index.html всегда отличаются подключаемые скрипты в DEV и PROD версиях. Этим же способом решается и указанная проблема.
Какой у вас стэк и фреймворк?
SergeiMinaev
19.10.2021 17:33Какой у вас стэк и фреймворк?
Обычно, Django/Vite.js/Vue.js
Не будет ли такого, что для SPA где весь index.html - это 50 строчек с подключением бандлов и минителом-контейнером, куда будет маунтиться сам приложение, будет быстрее подтянуть через то же соединение бандлы чем открывать новое до ближайшего CDN сервера?
Согласен, мне тоже это не очень нравится. Возможно, в среднем, бандл лучше разместить на своём сервере, а с CDN загружать CSS/шрифты/иконки. Вообще, сложная тема :) В HTTP/1.1 нельзя отправлять новый запрос в одном соединении, пока сервер не ответит на предыдущий. А в HTTP/2 можно отправлять кучу запросов сразу, поэтому высокий пинг будет мешать только в самом начале. Это должно сильно зависеть от типа соединения и удалённости.
DmitryKazakov8
19.10.2021 22:32"Я про случай когда единственный повод не использовать CDN для разработчика — лень скачивать и собирать библиотеку"
Соответственно, статью надо назвать "Почему сегодня от загрузки библиотек из CDN больше вреда, чем пользы", и в главных минусах перечислить баны с точки зрения госполитики и отсутствие у современных браузеров "сквозного кеширования" по разным доменам (из-за соображений безопасности для предотвращения трекинга они отказались от такой схемы).
Остальные минусы вида "на случай работы в дороге", "дополнительный поиск DNS" и "удаление древнейших версий библиотек" локальны и их можно обойти.
В целом согласен был бы с контентом, если бы название было другим. Но хранение готовых либ и их загрузка с CDN — это второстепенное предназначение CDN, основное — доставка контента с серверов, имеющих минимальный пинг к пользователю. То есть для сайтов, работающих в разных частях мира. Крупные компании могут позволить себе иметь несколько серверов в разных зонах и соответствующе перенаправлять трафик, средние — нет, поэтому для них подобная схема — единственный разумный с точки зрения затрат вариант быстро доставлять контент для пользователей. И в этом плане от CDN намного больше пользы, чем вреда.
anonymous
00.00.0000 00:00Sabubu
19.10.2021 21:13+1Всё-таки CDN, в первую очередь, нужен для снижения задержки (RTT) для пользователей, находящихся физически далеко от вашего дата-центра.
Вот только большинство CDN рассчитано на иностранных пользователей, а не на россиян: у них может быть дата-центр в Европе, Азии, США, но нет центров в Калуге, Воронеже, Ростове — там, где живут пользователи российских сайтов. Соответственно, может получиться так, что CDN будет дальше от пользователя, чем арендованный в России сервер. Какой смысл в таком CDN? От иностранных CDN надо отказываться сразу. Плюс, как написано выше, используя иностранный CDN, вы рискуете попасть под бан Роскомнадзора и ваш сайт перестанет открываться.
Далее, если вы используете публичный бесплатный CDN, то вы не являетесь его клиентом и он вам ничего не обязан и не гарантирует. Я имею в виду ссылки вроде cdn.jsdelivr.net. Такое нельзя использовать в продакшене вообще — только для тестирования или разработки.
Получается, используя международный CDN для российского сайта, мы не улучшаем скорость доступа, зато усложняем всю систему, усложняем деплой и создаем новые точки отказа. Выгоднее разместить файлы у себя на сервере, упростив систему и снизив число точек отказа.
pda0
19.10.2021 16:21CDN сейчас используют по моему в первую очередь для защиты от DDoS. (Но это не точно.)
kaasnake
19.10.2021 17:33Выбирайте провайдера, у которого eсть PoP в регионах ваших пользователей.
Настройка редиректа и правил кжширования. + Куча дополнительных фич у разных провайдеров для периодического обновления ссылок + автоматизация очистки неактуального кэша.
см. п1 + prefetch или прогрев кэша
/etc/hosts с прямыми линками (в случае отсутствия защиты бэкенда) И зачем разрабатывать на проде?
HTTP2 уже говорили, но это вообще не проблема CDN а архитектуры приложения
Медиа контент всегда нужен и всегда нужно его оптимизировать. + Оптимизация маршрута траффика (в том числе динамичекого) от бэка к фронту. Как правило крупные провайдеры имеют свои сети и маршрутизируют траффик через них.
Не говоря уж о дополнительных возможностях как WAF защита о DDoS региональная балансировка, пред обработка запросов на стороне PoP. Всякие хранилища на стороне провайдера, оптимизация картинок на лету учитывая скорость соединения и устройство пользователя.
При этом часто можно сэкономить на стоимостри траффика.
Кейсов очень много и здоровые проекты с хорошим траффиком всегда используют CDN. Может вы неправильно его готовите или просто ваш проект не дорос до него.
Yeah
19.10.2021 22:19В моем случае это выливается в комичные ситуации, когда у российских провайдеров в бан улетают заграничные CDN, а у украинских - CDN, например, яндекса.
DNS-failover??? Не, не слышал... ))))
thegriglat
20.10.2021 01:12Ждём поддержку IPFS в браузерах, прям всемирный CDN с контролем целостности. И локальная разработка не страдает
Все скрипты/стили/тд по локальному адресу
bondeg
20.10.2021 08:41Если хоть немного уметь в js не составит труда написать fallback на локальную статику. Вот о чём стоило статью писать в первую очередь или как заключение к этой.
Так что автор не совсем прав.
polRk
20.10.2021 09:09Шестая проблема - это поменявшийся характер использования интернета. Теперь пользователи довольно мало ходят по сайтам, придерживаясь нескольких основных, но посещая их регулярно. И тут плюсы кэширования сходят на нет - чем меньше сайтов посещает пользователь, тем меньше вероятность что в кэш будут попадать какие-то общие для этих сайтов библиотеки.
Теперь браузеры не разрешают переиспользовать ресурсы. Для каждого сайта - своя копия.
В целом - статья полный булшит
Aleksandr-JS-Developer
Походу, если придерживаться вашей точки зрения, то наоборот, крупным вообще никак нельзя CDN, потому, что:
melanton Автор
Если придерживаться моей точки зрения, то не нужно пихать CDN без необходимости в каждый сайт. Крупный бизнес-то он справится. А вот у мелкого наоборот все поотваливается во время очередных обострений РКН.
Fox_exe
У крупного бизнеса, зачастую, вообще собственный CDN есть. Особенно, если у бизнеса множество разных сайтов.