Comments 21
Нужен ли вам CDN? Скорее всего нет, если у вас не сотни тысяч посетителей в день.
Походу, если придерживаться вашей точки зрения, то наоборот, крупным вообще никак нельзя CDN, потому, что:
у российских провайдеров в бан улетают заграничные CDN, а у украинских - CDN, например, яндекса. ... Таким образом использование CDN в текущей обстановке - это риск того, что сайт может в любой момент перестать работать.
Надо будет написать статью "Почему от категоричных заголовков начинающим авторам (и не только) всегда больше вреда, чем пользы".
P.S. Вообще-то общее правило таково: чем больше у человека опыт общения с предметом, тем более осторожные у него высказывания/заявления/выводы по данному предмету. Поэтому часто по одному заголовку можно уже решить, заслуживает материал, а вместе с ним и автор, внимания или нет.
P.P.S. Если, конечно, он не Эйнштейн с очередной общей теорией чего-нибудь там такого эдакого. Которую, кстати, потом еще целые поколения замучаются доказывать (или опровергать).
Имхо будет больше вреда, если в вебе CDN будут делать не бездумно, априори потому что хорошая практика. Сейчас во многих тутриалах включение стилей и скриптов по CDN воспринимается как самой собой разумеющееся. Люди смотрят и повторяют не думая, что это за магические ссылки такие. Так что мой заголовок меньшее зло. Даже у тех кто не прочитает статью в голове где-то отложится, что нужно дважды подумать про CDN.
Даже у тех кто не прочитает статью в голове где-то отложится, что нужно дважды подумать про CDN
Это касается ровным счетом всего. Не только применительно к веб-разработке. Более того, народная мудрость гласит "семь раз отмерь, один раз отрежь". Заметьте, семь, а не дважды.
А у нас лентяи и неумехи соберут сайт, как лего-конструктор, из всевозможных библиотек и фреймворков, благо, сейчас все делается для облегчения работы таким горе-создателям, а потом удивляются, почему он у них тихо ездит? или вообще только задом...
Поэтому начинать думать надо задолго до того, как встает вопрос о выборе или не выборе CDN. Но если этот выбор в конечном итоге мотивируется решениями на уровне интуиции, а не замерами производительности и шлифовкой кода, он никогда не будет оптимальным.
Теперь еще и кеширование одних и тех же ресурсов для разных сайтов не работает, насколько я помню
CDN хорош тем, что позволяет кэшировать часто используемые библиотеки типа jQuery, не загружая их заново для каждого сайта. При большом количестве подключаемых файлов на странице, браузер не может делать много запросов к одному домену одновременно. Однако использование CDN, расположенного на другом домене, позволяет обойти эту проблему.
В HTTP2 браузер может делать до 100 одновременных запросов (проверил на FF, насчёт Chrome не уверен).
Всё-таки CDN, в первую очередь, нужен для снижения задержки (RTT) для пользователей, находящихся физически далеко от вашего дата-центра.
На старых проектах вы можете столкнуться с ситуацией, когда CDN удалил старую версию библиотеки, на которую все завязано. И вам теперь нужно срочно искать ее, или ближайшую подходящую версию.
Вы пишете про вариант, когда на сайт вставляется готовая ссылочка на какую-то библиотеку, но это не единственный способ использования. Из документации по CDN Selectel (применимо ко всем CDN):
"Файл при первом запросе пользователя загружается в кэш CDN-серверов с основного сервера - источника контента. При последующих запросах того же файла, он отдается с кэширующих серверов CDN."
Четвертая проблема - это локальная разработка. Если у тебя нет интернета в дороге или он плохой, то полноценно работать над сайтом невозможно.
Лично у меня в условном index.html всегда отличаются подключаемые скрипты в DEV и PROD версиях. Этим же способом решается и указанная проблема.
И от него для небольшого и среднего сайта будет больше вреда, чем пользы, особенно если значительная часть вашей предполагаемой аудитории использует мобильные устройства.
В сетях 4G высокий RTT (пинг). Если у вас сервер расположет в Москве и к вам на сайт зайдёт пользователь с Камчатки, то задержка может быть 200мс или выше. В случае с CDN, ресурсы с большой долей вероятности будут скачаны с сервера, физически расположенного ближе к пользователю.
В 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 версиях. Этим же способом решается и указанная проблема.
Какой у вас стэк и фреймворк?
Какой у вас стэк и фреймворк?
Обычно, Django/Vite.js/Vue.js
Не будет ли такого, что для SPA где весь index.html - это 50 строчек с подключением бандлов и минителом-контейнером, куда будет маунтиться сам приложение, будет быстрее подтянуть через то же соединение бандлы чем открывать новое до ближайшего CDN сервера?
Согласен, мне тоже это не очень нравится. Возможно, в среднем, бандл лучше разместить на своём сервере, а с CDN загружать CSS/шрифты/иконки. Вообще, сложная тема :) В HTTP/1.1 нельзя отправлять новый запрос в одном соединении, пока сервер не ответит на предыдущий. А в HTTP/2 можно отправлять кучу запросов сразу, поэтому высокий пинг будет мешать только в самом начале. Это должно сильно зависеть от типа соединения и удалённости.
"Я про случай когда единственный повод не использовать CDN для разработчика — лень скачивать и собирать библиотеку"
Соответственно, статью надо назвать "Почему сегодня от загрузки библиотек из CDN больше вреда, чем пользы", и в главных минусах перечислить баны с точки зрения госполитики и отсутствие у современных браузеров "сквозного кеширования" по разным доменам (из-за соображений безопасности для предотвращения трекинга они отказались от такой схемы).
Остальные минусы вида "на случай работы в дороге", "дополнительный поиск DNS" и "удаление древнейших версий библиотек" локальны и их можно обойти.
В целом согласен был бы с контентом, если бы название было другим. Но хранение готовых либ и их загрузка с CDN — это второстепенное предназначение CDN, основное — доставка контента с серверов, имеющих минимальный пинг к пользователю. То есть для сайтов, работающих в разных частях мира. Крупные компании могут позволить себе иметь несколько серверов в разных зонах и соответствующе перенаправлять трафик, средние — нет, поэтому для них подобная схема — единственный разумный с точки зрения затрат вариант быстро доставлять контент для пользователей. И в этом плане от CDN намного больше пользы, чем вреда.
Всё-таки CDN, в первую очередь, нужен для снижения задержки (RTT) для пользователей, находящихся физически далеко от вашего дата-центра.
Вот только большинство CDN рассчитано на иностранных пользователей, а не на россиян: у них может быть дата-центр в Европе, Азии, США, но нет центров в Калуге, Воронеже, Ростове — там, где живут пользователи российских сайтов. Соответственно, может получиться так, что CDN будет дальше от пользователя, чем арендованный в России сервер. Какой смысл в таком CDN? От иностранных CDN надо отказываться сразу. Плюс, как написано выше, используя иностранный CDN, вы рискуете попасть под бан Роскомнадзора и ваш сайт перестанет открываться.
Далее, если вы используете публичный бесплатный CDN, то вы не являетесь его клиентом и он вам ничего не обязан и не гарантирует. Я имею в виду ссылки вроде cdn.jsdelivr.net. Такое нельзя использовать в продакшене вообще — только для тестирования или разработки.
Получается, используя международный CDN для российского сайта, мы не улучшаем скорость доступа, зато усложняем всю систему, усложняем деплой и создаем новые точки отказа. Выгоднее разместить файлы у себя на сервере, упростив систему и снизив число точек отказа.
Выбирайте провайдера, у которого eсть PoP в регионах ваших пользователей.
Настройка редиректа и правил кжширования. + Куча дополнительных фич у разных провайдеров для периодического обновления ссылок + автоматизация очистки неактуального кэша.
см. п1 + prefetch или прогрев кэша
/etc/hosts с прямыми линками (в случае отсутствия защиты бэкенда) И зачем разрабатывать на проде?
HTTP2 уже говорили, но это вообще не проблема CDN а архитектуры приложения
Медиа контент всегда нужен и всегда нужно его оптимизировать. + Оптимизация маршрута траффика (в том числе динамичекого) от бэка к фронту. Как правило крупные провайдеры имеют свои сети и маршрутизируют траффик через них.
Не говоря уж о дополнительных возможностях как WAF защита о DDoS региональная балансировка, пред обработка запросов на стороне PoP. Всякие хранилища на стороне провайдера, оптимизация картинок на лету учитывая скорость соединения и устройство пользователя.
При этом часто можно сэкономить на стоимостри траффика.
Кейсов очень много и здоровые проекты с хорошим траффиком всегда используют CDN. Может вы неправильно его готовите или просто ваш проект не дорос до него.
В моем случае это выливается в комичные ситуации, когда у российских провайдеров в бан улетают заграничные CDN, а у украинских - CDN, например, яндекса.
DNS-failover??? Не, не слышал... ))))
Ждём поддержку IPFS в браузерах, прям всемирный CDN с контролем целостности. И локальная разработка не страдает
Все скрипты/стили/тд по локальному адресу
Если хоть немного уметь в js не составит труда написать fallback на локальную статику. Вот о чём стоило статью писать в первую очередь или как заключение к этой.
Так что автор не совсем прав.
Шестая проблема - это поменявшийся характер использования интернета. Теперь пользователи довольно мало ходят по сайтам, придерживаясь нескольких основных, но посещая их регулярно. И тут плюсы кэширования сходят на нет - чем меньше сайтов посещает пользователь, тем меньше вероятность что в кэш будут попадать какие-то общие для этих сайтов библиотеки.
Теперь браузеры не разрешают переиспользовать ресурсы. Для каждого сайта - своя копия.
В целом - статья полный булшит
Почему сегодня от CDN больше вреда, чем пользы