Comments 47
Эти слова да в уши всем…
CDN — это самая большая проблема всех серьёзных сайтов. Буквально недавно лежал gitter просто потому, что их собственная cdn не отдавала данные, из-за чего сервер нормально работал, но сам сайт не функционировал. Конечно же это не единственный пример из жизни — я почти уверен, что у многих были такие же проблемы.
CDN — это самая большая проблема всех серьёзных сайтов. Буквально недавно лежал gitter просто потому, что их собственная cdn не отдавала данные, из-за чего сервер нормально работал, но сам сайт не функционировал. Конечно же это не единственный пример из жизни — я почти уверен, что у многих были такие же проблемы.
У нас суровые прокси-админы требуют имя сайта для добавления в белый лист, но потом оказывается что добрые разработчики напихали ссылки на десяток js скриптов и библиотек себе на сайтик (причем именно ссылок на другие сайты) и юзер после эпопеи мыторств с разблокировкой сайта получает нерабочий сайт и не знает кому жаловаться. И у нас не Китай, а просто корп. сеть. С техподдержкой (от слова худо) во Франции.
если минусующие не поняли, я поддерживаю стремление хостить весь необходимый контент на своём сайте во избежание трудностей с его разблокировкой на корп. проксях
Да не только из-за этого (из-за корп.сетей) стоит хостить у себя:
Плюсы CDN:
— Распределённая сеть, которая позволяет быстрее получать контент из разных точек мира
— Сервера заточены для раздачи статики
— Разгрузка основного сервера
Минусы CDN:
— Спорная выгода по скорости (может быть даже проигрыш):
— для подключения к cdn требуется новое подключение и новый резолв сервера\dns, а то что браузеры игнорят стандарт http/1.1 по части количества одновременных подключений к одному серверу ни для кого не секрет.
— скорость отдачи может быть такой же, как у родителя
— Почти всегда объединение и минификация ассетов в разы выигрышнее и удобнее, нежели отдача кусочками с разных серверов
— Gzip работает эффективнее
— Грузится один раз и кешируется — пользователь особо не заметит разницу между двумя скриптами\стилями по 300кб и одним в 600кб (учитывая издержки на создание нового подключения и существование проблемы «забитого канала» мелкими файликами — второй вариант может быть даже лучше)
— Не придётся придумывать всякие откаты, когда cdn лежит
— Если сайт работает — он работает весь, если не работает, то не работает весь — никаких полумер из-за проблем в cdn.
Итог:
Я соглашусь, что для хранения всякого видео или картиночек стоит использовать именно CDN — это довольно сильно разгрузит основной сервер и сократит трафик (при высоких нагрузках это более чем необходимо). Но для всяких скриптов и\или стилей — это в любом случае минус, нежели что-то необходимое.
Плюсы CDN:
— Распределённая сеть, которая позволяет быстрее получать контент из разных точек мира
— Сервера заточены для раздачи статики
— Разгрузка основного сервера
Минусы CDN:
— Спорная выгода по скорости (может быть даже проигрыш):
— для подключения к cdn требуется новое подключение и новый резолв сервера\dns, а то что браузеры игнорят стандарт http/1.1 по части количества одновременных подключений к одному серверу ни для кого не секрет.
— скорость отдачи может быть такой же, как у родителя
— Почти всегда объединение и минификация ассетов в разы выигрышнее и удобнее, нежели отдача кусочками с разных серверов
— Gzip работает эффективнее
— Грузится один раз и кешируется — пользователь особо не заметит разницу между двумя скриптами\стилями по 300кб и одним в 600кб (учитывая издержки на создание нового подключения и существование проблемы «забитого канала» мелкими файликами — второй вариант может быть даже лучше)
— Не придётся придумывать всякие откаты, когда cdn лежит
— Если сайт работает — он работает весь, если не работает, то не работает весь — никаких полумер из-за проблем в cdn.
Итог:
Я соглашусь, что для хранения всякого видео или картиночек стоит использовать именно CDN — это довольно сильно разгрузит основной сервер и сократит трафик (при высоких нагрузках это более чем необходимо). Но для всяких скриптов и\или стилей — это в любом случае минус, нежели что-то необходимое.
Основной плюс использования больших чужих CDN в том, что видя адрес библиотеки code.jquery.com/ui/1.9.0/jquery-ui.js браузер вообще никуда не пойдёт, а возьмёт её из кэша, где она появилась сто лет назад, когда пользователь заходил на другой сайт который подключал библиотеку с этого же CDN.
Если CDN свой, то вы скорее всего очень крупный проект и вам без CDN никак.
Если CDN свой, то вы скорее всего очень крупный проект и вам без CDN никак.
Также сомнительны тезисы:
— Почти всегда объединение и минификация ассетов в разы выигрышнее и удобнее, нежели отдача кусочками с разных серверов
Я уже выше написал, что при подключении популярных библиотек с CDN загрузки вообще скорее всего не будет. Грузить с разных хостов быстрее, потому что в браузере ограничение на количество соединений на один хост.Вы конечно могли бы склеить вообще все крипты в один файл, но тогда клиентам прийдется при малейшей правке сайта перетягивать все ваши мегабайты скриптов.
— Gzip работает эффективнее
Гзип работает эффективнее чего? CDNа? Это технологии которые решают схожие (но не одни и те же) проблемы разными способами, их вообще сомнительно сравнивать. И уж конечно все CDN'ы отдают библиотеки гзипованными (по крайней мере те которые я знаю).
— Грузится один раз и кешируется — пользователь особо не заметит разницу между двумя скриптами\стилями по 300кб и одним в 600кб
1) загрузки 300кб библиотеки скорее всего не будет, потому что она уже в кэше
2) при минимальном изменении вашего сайта прийдется перекачивать не только ваши 300кб но 300кб библиотеки, потому что вы все сжали в 1 файл
3) кэш вашего сайта может быть вытеснен и все прийдется перекачивать по новой, в то время как кэш CDN'овской библиотки с большей вероятностью будет живой (к нему обращения скорее всего будут идти чаще чем к вашему)
4) пользователи мобильного интернета замят разницу в 300кб.
— Почти всегда объединение и минификация ассетов в разы выигрышнее и удобнее, нежели отдача кусочками с разных серверов
Я уже выше написал, что при подключении популярных библиотек с CDN загрузки вообще скорее всего не будет. Грузить с разных хостов быстрее, потому что в браузере ограничение на количество соединений на один хост.Вы конечно могли бы склеить вообще все крипты в один файл, но тогда клиентам прийдется при малейшей правке сайта перетягивать все ваши мегабайты скриптов.
— Gzip работает эффективнее
Гзип работает эффективнее чего? CDNа? Это технологии которые решают схожие (но не одни и те же) проблемы разными способами, их вообще сомнительно сравнивать. И уж конечно все CDN'ы отдают библиотеки гзипованными (по крайней мере те которые я знаю).
— Грузится один раз и кешируется — пользователь особо не заметит разницу между двумя скриптами\стилями по 300кб и одним в 600кб
1) загрузки 300кб библиотеки скорее всего не будет, потому что она уже в кэше
2) при минимальном изменении вашего сайта прийдется перекачивать не только ваши 300кб но 300кб библиотеки, потому что вы все сжали в 1 файл
3) кэш вашего сайта может быть вытеснен и все прийдется перекачивать по новой, в то время как кэш CDN'овской библиотки с большей вероятностью будет живой (к нему обращения скорее всего будут идти чаще чем к вашему)
4) пользователи мобильного интернета замят разницу в 300кб.
Я уже выше написал, что при подключении популярных библиотек с CDN загрузки вообще скорее всего не будет.
1) Версии одного только Jquery
Скрытый текст
2.1.3, 2.1.2, 2.1.1, 2.1.0, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 1.11.2, 1.11.1, 1.11.0, 1.10.2, 1.10.1, 1.10.0, 1.9.1, 1.9.0, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.2, 1.7.1, 1.7.0, 1.6.4, 1.6.3, 1.6.2, 1.6.1, 1.6.0, 1.5.2, 1.5.1, 1.5.0, 1.4.4, 1.4.3, 1.4.2, 1.4.1, 1.4.0, 1.3.2, 1.3.1, 1.3.0, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0
2) Из cdn: google, yandex, microsoft, cdnjs, jsdelivr, amazon и боюсь ещё небольшая кучка найдётся. То что совпадёт и версия и cdn — шанс один на… хм… Вы действительно верите в этот мистический шанс?
3) Как уже выше было сказано — кеш периодически может чиститься (актуально у мобильных браузеров)
Гзип работает эффективнее чего? CDNа?
Gzip работает эффективнее на бо́льших объёмах данных, т.к. словарь больше. Как следствие результирующий (на отдачу) объём данных с jq и без него может быть почти что одинаковым.
А по поводу последнего:
Объём jquery (если на реальных цифрах) 34kb (не 300) — это примерно столько же, сколько одна картиночка на странице, размером 200х200 (например на том же сайте jquery). А своё мнение на все остальные аргументы я выше уже озвучил.
Давайте говорить предметно. Вот список jQuery в моем кеше:
Не такой уж и маленький список. А те разработчики, которые подключили одну из этих версий – молодцы, у меня их сайт загрузится на 0.5 секунды быстрее.
Посмотреть на содержимое своего кеша можно на служебной странице chrome://cache
ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js
ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js
ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js
cdnjs.cloudflare.com/ajax/libs/jquery/2.1.3/jquery.min.js
yandex.st/jquery/1.7.1/jquery.min.js
yandex.st/jquery/1.7.2/jquery.min.js
yandex.st/jquery/1.8.3/jquery.min.js
yandex.st/jquery/1.9.1/jquery.min.js
yandex.st/jquery/2.1.0/jquery.min.js
yastatic.net/jquery/1.6.2/jquery.min.js
yastatic.net/jquery/1.8.3/jquery.min.js
yastatic.net/jquery/1.11.0/jquery.min.js
Не такой уж и маленький список. А те разработчики, которые подключили одну из этих версий – молодцы, у меня их сайт загрузится на 0.5 секунды быстрее.
Посмотреть на содержимое своего кеша можно на служебной странице chrome://cache
но тогда клиентам прийдется при малейшей правке сайта перетягивать все ваши мегабайты скриптов
Именно для этого собирают не в один файл, а в несколько логических, и не заставляют пользователя перезагружать то, что не меняется.
Но тогда всплывет проблема установления соединения (хотя есть надежда что используется Keep-Alive), которая приводится как минус использования CDN, ограничение на количество запросов на один хост (котрого кстати нет в случае CDN) еще и куки надо по сети лишний раз гонять, и кэш не общий с другими сайтами. В общем если жать в несколько файлов то совсем не понятно почему бы просто не использовать CDN. Если критична работоспособность на случай падения yandex.st или ajax.googleapis.com можно сделать фоллбэк.
В добавление к этому можно добавить ещё немного логики для short circuiting (circuit breaker), чтобы в случае недоступности CDN не все пользователи ждали таймаута, а только первые.
А хостить jquery у себя — не выход???
А то сейчас расплодятся завирусованные роутеры, подсовывающие левую jquery и начнут тырить все, до чего дотянутся…
А то сейчас расплодятся завирусованные роутеры, подсовывающие левую jquery и начнут тырить все, до чего дотянутся…
предпочитаю делать сборку скриптов в один файл через RequireJS, а jquery и прочее подтягивать через bower
Когда-то раньше я так и делал. Но к сожалению на практике проверка существования библиотеки работала ненадежно. Не знаю почему.
Немного не тот случай, но тоже о важности контроля чужих скриптов. Есть такой известный сайт продажи билетов ponominalu.ru. Захожу как-то, прохожу все круги процесса заказа, остается последняя и самая важная кнопка собственно заказа и перехода к оплате. И она не работает. Занажимайся. Страницу перезагрузил, адблок выключил — не работает. Полез в JS-консоль и все прояснилось. Они вешают на кнопку заказа событие яндекс-метрики, а у меня в hosts mc.yandex.ru указывает на 127.0.0.1. В общем, скрипт метрики у меня не грузится, а событие не проверяет существует ли объект метрики перед обращением к нему. То есть они сделали самую важную, приносящую деньги кнопку, зависимой от стороннего скрипта. Забавно еще, что так как эти сбои и связаны со скриптом метрики, в статистике они этих отказов не увидят и будут думать, что все хорошо.
Эта проблема известна. На самом деле потери подобных клиентов — 1%. Если рассчитывать на то, что каждый клиент будет себе что-то прописывать в hosts файле, или будет использовать, например, IE 6, кнопка «оформить заказ» не покроет расходов на разработку. Можно было бы еще в hosts файле указать ponominalu.ru на 127.0.0.1 и написать об этом пост на хабре, что сайт не работает.
В большинстве случаев, возможно, это так, однако в частных случаях эта мелочь может стать решающей.
Прожив в Китае всего год, я был поражен насколько мало сервисов заботится о таких как я пользлователях, почти каждый день наталкиваюсь на не рабочие сайты. Пользователей интернета в Китае не так мало, чтобы не думать о них совсем, особенно если ваш сервис расчитан на азиатский рынок.
Прожив в Китае всего год, я был поражен насколько мало сервисов заботится о таких как я пользлователях, почти каждый день наталкиваюсь на не рабочие сайты. Пользователей интернета в Китае не так мало, чтобы не думать о них совсем, особенно если ваш сервис расчитан на азиатский рынок.
Ну конечно, то что я прописал в hosts домен яндекса — моя проблема. Однако сервис может быть недоступен по другой причине. Ту же метрику может блокировать какой-нибудь плагин браузера, да и вообще она может просто упасть. Наверное метрика падает очень редко, но это дополнительная точка отказа. Да и 1% может быть немало в денежном эквиваленте.
Спасибо. Поправили.
буквально вчера столкнулся с проблемой неработающего jQuery на сайте Кинопоиск. Причина оказалась в том, что они подгружают jQuery c yandex.st, а расширение Disconnect для хрома по моему указанию режет лишние запросы к яндексу — в итоге был заблокирован и запрос к jQuery-библиотеке
Код не рабочий. Надо как-то так:
document.write(unescape("%3Cscript src='/js/jquery.js' type='text/javascript'%3E%3C/script%3E"));
Раз уже речь зашла о Китае, у них есть локальные CDN (Baidu CDN Library, Sina Public Resources, UpYun Library) — context.tips/seo/hosting-javascript-bibliotek-pri-prodvizhenii-v-kitae/
Чем строить сайт «по-модному», когда через десяток CDN и хостов грузятся пара десятков файликов css и js, куда лучше собрать их в единый css и в единый js, и отдавать со своего сервера. Выйдет мало что быстрее, так еще и надежнее.
Дело в том, что логика «jQuery юзают все, так что, указав его cdn как источник файла, можно заставить файл не грузиться, а браться из кеша браузера» разбивается о то, что
1) версий jQuery не одна и не две (умножайте, кстати, на два: кто-то .min использует, кто-то — «просто»). Не факт, что у юзера в кеше есть нужная, зато факт, что на ДНС-ресолвинг и на установление соединения уйдет свое время.
2) сайты нынче толстые, время жизни кеша не глядя ставят в огромные значения. На выходе имеем, что эпизодические посещение одних сайтов выдавливает из кеша важдые библиотеки из cdn-ов, использованных на других сайтах. Получается, что от кеша эффекта куда меньше, чем хочется увидеть.
Но вот шанс сломать себе сайт или затянуть его загрузку от использования чужого хоста как источника файлика с normalize.css или jquery.min.js — он вполне реальный, и, увы, не нулевой. Если же через cdn у вас грузятся еще и веб-фонты, все становится еще грустнее: страница висит пустой долгие секунды, и юзеры, не дождавшись, могут вообще ее закрыть.
Вывод: если вы не гугл по посещению, не страдайте «оптимизацией» там, где это не необходимо!
Дело в том, что логика «jQuery юзают все, так что, указав его cdn как источник файла, можно заставить файл не грузиться, а браться из кеша браузера» разбивается о то, что
1) версий jQuery не одна и не две (умножайте, кстати, на два: кто-то .min использует, кто-то — «просто»). Не факт, что у юзера в кеше есть нужная, зато факт, что на ДНС-ресолвинг и на установление соединения уйдет свое время.
2) сайты нынче толстые, время жизни кеша не глядя ставят в огромные значения. На выходе имеем, что эпизодические посещение одних сайтов выдавливает из кеша важдые библиотеки из cdn-ов, использованных на других сайтах. Получается, что от кеша эффекта куда меньше, чем хочется увидеть.
Но вот шанс сломать себе сайт или затянуть его загрузку от использования чужого хоста как источника файлика с normalize.css или jquery.min.js — он вполне реальный, и, увы, не нулевой. Если же через cdn у вас грузятся еще и веб-фонты, все становится еще грустнее: страница висит пустой долгие секунды, и юзеры, не дождавшись, могут вообще ее закрыть.
Вывод: если вы не гугл по посещению, не страдайте «оптимизацией» там, где это не необходимо!
На самом деле это не совсем панацея. Я как-то не мог скайп скачать потомучто у меня CDN от майкрософт не работал. А таймаут стоял такой зверский, что я просто устал ждать прогрузки страницы…
Видимо лучший вариант на данный момент все JS сжимать на сайте в один файлик и грузить со своего сервера.
Видимо лучший вариант на данный момент все JS сжимать на сайте в один файлик и грузить со своего сервера.
Почему-то в каждом втором комментарии вспоминают про кеширование с CDN (которое не факт что происходит), но никто не задумывается о лимите параллельных соединений браузера. А ведь это по идее тоже влияет на скорость загрузки сайта, даже если не учитывать кеширование.
В последнее время стало модно говорить о доступности (accessibility) при разработке сайтов, писать rel, alt, делать версию для слабовидящих и так далее, однако почему бы сначала не подумать о нормальных пользователях. Подключая jQuery из CDN:
Какой-то бред! Причём здесь противопоставление с accessibility? Да и какое вообще отношение это имеет к accessibility (как на уровне хаба, так и на уровне тегов)?
Призыв-то хороший, только по-моему у вас в голове каша и перепутаны понятия accessibility и availability.
- Accessibility — это свойство продукта, характеризующее возможность его использование наибольшим числом лиц, обладающих ограничениями. То есть речь о каких-то проблемах на стороне пользователя, например, физических (нарушения зрения, слуха и пр.) или технических (невозможность обработать контент, передаваемый не универсальной технологией, типа Flash и пр.).
- Availability — это свойство некой системы, характеризующее степень невыполненного обслуживания пользователя. То есть речь о ликвидации сбоев и минимизации простоев.
Ваш пост про availability, и как уж обеспечение accessibility может помешать и перехватить приоритеты у availability совсем не понятно. Разве что на уровне общего бюджета проекта, но тогда противопоставлять можно всё, что угодно. Да и, откровенно говоря, если разработчик не научился писать alt, которые декларируются спецификацией, то о какой проверке доступности CDN вообще можно говорить, ему мат. часть надо идти учить.
Accessibility refers to the design of products, devices, services, or environments for people with disabilities
Да, с хабом погорячился.
На счет помешать и перехватить приоритеты, ресурсы всегда ограничены, будь то время или деньги, и в первую очередь стоит уделить время на проработку наиболее узких мест в проекте, одним из которых может стать внешний cdn или, как пример из коментариев, метрика.
Забыли дописать в плюсы хранения у себя то, что при атаке на сайт популярной JS библиотеки недавно очень много сайтов оказались под угрозой, используя копию библиотеки от поставщика
В том же самом boilerplate есть решение короче:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.11.2.min.js"><\/script>')</script>
Да, мы ужасно долбались с этим аспектом. Сначала в России прибили часть адресов CloudFlare, потом в Китае грохнули нашу собственную CDN, в результате код для загрузки скриптов выглядит как атомная война — эвристики, запасные варианты всякие.
Проблема усложняется, когда на сайте много пользователей и «локальная» jquery.min.js, отданная с мастер-сервера без CDN, за сутки сжирает терабайт трафика.
Проблема усложняется, когда на сайте много пользователей и «локальная» jquery.min.js, отданная с мастер-сервера без CDN, за сутки сжирает терабайт трафика.
Как-то не круто говорить, что люди делают херово и приводить в пример тоже херовый вариант — unescape является deprecated методом.
Sign up to leave a comment.
Не CDN единым