Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 41
Реквестирую таблицу популярности CDN'ов. Любопытно, на каком месте jsdelivr.com.
На шестом месте, в статье это есть.
Прошу прощения, проглядел.
Добавлю количество JS-библиотек, размещаемых на каждой CDN:
Google: популярность 86.5801, 12 библиотек
jQuery: популярность 11.7989, 6 библиотек
Cloudflare: популярность 5.1126, 671 библиотека с возможностью добавления
Yandex: популярность 3.0438, 18 библиотек
Microsoft: популярность 1.6633, 18 библиотек
JsDelivr: популярность 0.4145, 940 библиотек с возможностью добавления
Сам пользуюсь JsDelivr.
Добавлю количество JS-библиотек, размещаемых на каждой CDN:
Google: популярность 86.5801, 12 библиотек
jQuery: популярность 11.7989, 6 библиотек
Cloudflare: популярность 5.1126, 671 библиотека с возможностью добавления
Yandex: популярность 3.0438, 18 библиотек
Microsoft: популярность 1.6633, 18 библиотек
JsDelivr: популярность 0.4145, 940 библиотек с возможностью добавления
Сам пользуюсь JsDelivr.
Тоже задумывался над вопросом хранения js/css на клиенте, на первый взгляд решением был бы cache manifest, но там запрос разрешения, это смущает. А так, если подумать -десяток мегабайт самых востребованных библиотек могли бы сэкономить прилично траффика, в глобальном отношении.
Судя по данным, которые я получил из датасета — даже одного jQuery будет достаточно.
Я основные идеи с клиентским кешем вложил в расширение. Посмотрим, какую статистику с него можно будет снять.
А как только расширения появятся в мобильных браузерах — это будет победа :)
Я основные идеи с клиентским кешем вложил в расширение. Посмотрим, какую статистику с него можно будет снять.
А как только расширения появятся в мобильных браузерах — это будет победа :)
AFAIK он и так в кэше браузера более чем у 90% пользователей.
Тоже задумывался над вопросом локального хранилища популярных библиотек таких как jQuery. Но потом понял, то такое хранилище уже есть и предлагает много больше, чем я мог себе представить. Называется оно — кеш браузера. В самом деле, если браузеру приходится опрашивать CDN в поисках нужной библиотеки для сайта, для другого сайта она с большей степенью вероятности уже будет в кеше (естественно, если оба сайта обращаются к CDN по одному url). Уже потом я нашёл статью уважаемого Dave Ward aka Encosia, которая называется 6,953 reasons why I still let Google host jQuery for me. В этом труде 2010 года приводится аналогичная статистика и один из выводов:
sites must reference exactly the same CDN URL in order to obtain the cross-site caching benefit
Ну и еще один вывод: разработчики должны грамотно писать софт.
Однако в реальном мире всё не так.
Возвращаясь к кешу — CDN и кеширование просто рождены друг для друга.
Однако многие до сих пор подключают скрипты локально и не умеют пользовать заголовки для кеша. И если браузерное размещение ресурсов из CDN погоды особо не сыграет (хотя и 100% безопасно), то возможность не загружать ресурсы самого хоста может стать киллер-фичей.
Однако в реальном мире всё не так.
Возвращаясь к кешу — CDN и кеширование просто рождены друг для друга.
Однако многие до сих пор подключают скрипты локально и не умеют пользовать заголовки для кеша. И если браузерное размещение ресурсов из CDN погоды особо не сыграет (хотя и 100% безопасно), то возможность не загружать ресурсы самого хоста может стать киллер-фичей.
У расширения действительно есть киллер-фича: одна из [многих] причин локального размещения скриптов — возможность работы над своей копией сайта без подключения к Интернету. После установки расширения можно указывать внешние URL'ы и ничего не бояться.
Я дико извиняюсь, но как вы считали проценты в «Профиле загрузки скриптов из Google CDN»?
Мы считали проценты точно так же, как сайт Сочи2014: у нас возможны «двойные» ответы. т.е. 1 сайт грузит 2-3 скрипта из набора одновременно. Процент в каждом случае считается относительно всех сайтов, грузящих скрипты из Google CDN, а не относительно уникальных запросов. Т.е. суммирование по процентам тут не покатит.
Хочу предложить интересные ссылки по теме статьи.
Статистика по использованию CMS и javascript (переключайте вкладки) в российских национальных зонах:
statonline.ru/metrics/webapp_cms?tld=ru — в качестве репрезентативной выборки выступают сайты в зоне ru
statonline.ru/metrics/webapp_cms?tld=rf — в качестве репрезентативной выборки выступают сайты в зоне рф
statonline.ru/metrics/webapp_cms?tld=su — в качестве репрезентативной выборки выступают сайты в зоне su
Статистика по использованию CMS в зоне ru за 2013 год:
stat.nic.ru/reports/whist-ru/cms2013.html
На следующих страницах в качестве репрезентативной выборки используются первые 10 миллионов участников рейтинга Alexa:
w3techs.com/technologies/overview/javascript_library/all
w3techs.com/technologies/overview/content_management/all
Статистика по использованию CMS и javascript (переключайте вкладки) в российских национальных зонах:
statonline.ru/metrics/webapp_cms?tld=ru — в качестве репрезентативной выборки выступают сайты в зоне ru
statonline.ru/metrics/webapp_cms?tld=rf — в качестве репрезентативной выборки выступают сайты в зоне рф
statonline.ru/metrics/webapp_cms?tld=su — в качестве репрезентативной выборки выступают сайты в зоне su
Статистика по использованию CMS в зоне ru за 2013 год:
stat.nic.ru/reports/whist-ru/cms2013.html
На следующих страницах в качестве репрезентативной выборки используются первые 10 миллионов участников рейтинга Alexa:
w3techs.com/technologies/overview/javascript_library/all
w3techs.com/technologies/overview/content_management/all
У меня вопрос:
Не совсем понимаю, почему CDN это более правильно чем просто jquery на том же сервере, что и сайт?
2.Популярные сайты, использующие jQuery, переходят на подключение библиотеки из CDN. С каждым годом правильных ребят всё больше.
Не совсем понимаю, почему CDN это более правильно чем просто jquery на том же сервере, что и сайт?
Потому что, загруженные данные браузер кэширует и не загружает повторно.
Когда пользователь будет посещать разные сайты, на которых jquery подключается с CDN, то этот jquery будет загружен всего один раз.
А на каждом новом сайте со «своим» jquery, он будет загружаться заново.
Есть и другие фичи связанные с огрничением подключений к одному домену, задержки между пользователем и серверами вашими и cdn. Но это погуглите.
Когда пользователь будет посещать разные сайты, на которых jquery подключается с CDN, то этот jquery будет загружен всего один раз.
А на каждом новом сайте со «своим» jquery, он будет загружаться заново.
Есть и другие фичи связанные с огрничением подключений к одному домену, задержки между пользователем и серверами вашими и cdn. Но это погуглите.
У меня как-то так случилось, что провайдер блокировал Майкрософтовский CDN уж не знаю почему. Все сайты майкрософта грузились по несколько минут (ждали JS-библиотеку). Это единственная причина, почему я избегаю CDN сейчас.
<script>//ajax.aspnetcdn.com/ajax/jQuery/jquery-2.1.0.min.js</script>
<script>
window.jQuery || document.write('<script src="/path/to/your/jquery"></script>');
</script>
Соответственно, если jQuery не обнаруживается, то цепляем из другого источника. Хоть локального, хоть другого cdn.
в require.js это штатная фича http://requirejs.org/docs/api.html#pathsfallbacks.
С другой стороны, jquery в проде часто прилепляют к остальным скриптам. Не уверен что в этом случае имеет смысл цеплять jquery отдельно из CDN.
Кстати, а те ребята, которые придумывают различные стандарты Веба, не думали ли про усовершенствование системы кеширования?
Первое, что приходит в голову (по теме статьи) – сделать кеш браузера единым для различных сайтов, по ETag, например. Потенциально, есть узкое место в безопасности, но этот вопрос можно решить.
Первое, что приходит в голову (по теме статьи) – сделать кеш браузера единым для различных сайтов, по ETag, например. Потенциально, есть узкое место в безопасности, но этот вопрос можно решить.
>> Популярные сайты, использующие jQuery, переходят на подключение библиотеки из CDN.
У моего провайдера случился заскоко и половина сайтов стала разваленными и недоступными. Оказывается многие CDN просто перестали грузится.
Задумался.
У моего провайдера случился заскоко и половина сайтов стала разваленными и недоступными. Оказывается многие CDN просто перестали грузится.
Задумался.
Добавлю свои 5 копеек.
Во-первых, пора великим и ужасным «распространенным движкам» (это и WP, и Битрикс) переставать указывать версии css и js файлов в коде. Это, конечно, костыль, но, не будь его, ускорение многих бы сайтов свелось к установке (и должной настройке) mod_pagespeed (http://code.google.com/p/modpagespeed/). Оно уже одно сразу оправдывает усилия.
Во-вторых, библиотеки, откуда бы они не отдавались, имеют проблему множественности версий. Загрузите в кеш только все версии jQuery, Bootstrap,… (подставьте здесь сами все библиотеки и фреймворки, что знаете), да еще в версии «просто» и "-min" каждый файл — и вот уже наш кеш и забит. Добавьте в кеш еще столь модные загружаемые с Google Fonts шрифты — опа, а библиотеки-то уже и выдавлены из кеша!
В-третьих, давате пожалеем мобильный юзеров. У них на планшетах и телефонах кеши буквально в мегабайты (и это сейчас, раньше еще меньше было), им вообще всегда все качать приходится с нуля. Зато лишний DNS запрос, связь с хостом и прочее добавляет некоторое время к времени загрузки страницы.
Вывод: авторам надо думать о своих движках и сайтах, а авторам библиотек — делать их максимально совместимыми с прошлыми версиями, тогда не придется держать в кеше десятки версий разных библиотек и фреймворков. Этим выгадаем место в кеше, и хоть как-то улучшим его эффективность.
Пока же… остается перехватывать код страницы на выводе из CMS, в нем все "?ver=7896789" убирать, и тогда уже отдавать этот код на обработку в минификатор/оптимизатор (pagespeed или еще что). Тогда можем на что-то надеяться. А без этого, боюсь, у нас только академическое исследование сферического CDN-а в вакууме ).
P.S. Ах да, не забываем про CDN-ы «имени CMS» (возьмем тот же Битрикс-CMS). Вы думаете, он мало забивает кеш теми же библиотеками, но уже со своих URL-ов, специфических для сайтов?
Во-первых, пора великим и ужасным «распространенным движкам» (это и WP, и Битрикс) переставать указывать версии css и js файлов в коде. Это, конечно, костыль, но, не будь его, ускорение многих бы сайтов свелось к установке (и должной настройке) mod_pagespeed (http://code.google.com/p/modpagespeed/). Оно уже одно сразу оправдывает усилия.
Во-вторых, библиотеки, откуда бы они не отдавались, имеют проблему множественности версий. Загрузите в кеш только все версии jQuery, Bootstrap,… (подставьте здесь сами все библиотеки и фреймворки, что знаете), да еще в версии «просто» и "-min" каждый файл — и вот уже наш кеш и забит. Добавьте в кеш еще столь модные загружаемые с Google Fonts шрифты — опа, а библиотеки-то уже и выдавлены из кеша!
В-третьих, давате пожалеем мобильный юзеров. У них на планшетах и телефонах кеши буквально в мегабайты (и это сейчас, раньше еще меньше было), им вообще всегда все качать приходится с нуля. Зато лишний DNS запрос, связь с хостом и прочее добавляет некоторое время к времени загрузки страницы.
Вывод: авторам надо думать о своих движках и сайтах, а авторам библиотек — делать их максимально совместимыми с прошлыми версиями, тогда не придется держать в кеше десятки версий разных библиотек и фреймворков. Этим выгадаем место в кеше, и хоть как-то улучшим его эффективность.
Пока же… остается перехватывать код страницы на выводе из CMS, в нем все "?ver=7896789" убирать, и тогда уже отдавать этот код на обработку в минификатор/оптимизатор (pagespeed или еще что). Тогда можем на что-то надеяться. А без этого, боюсь, у нас только академическое исследование сферического CDN-а в вакууме ).
P.S. Ах да, не забываем про CDN-ы «имени CMS» (возьмем тот же Битрикс-CMS). Вы думаете, он мало забивает кеш теми же библиотеками, но уже со своих URL-ов, специфических для сайтов?
Зря боитесь.
Как показывают цифры выше — достаточно десятка версий самых популярных библотек (jQuery, Boostrap, Angular, Backbone, ...) для того, чтобы наступило массовое счастье.
Мой экстеншен уже сейчас имеет все версии jQuery, популярные версии boostrap и font awesome, скрипты статистики гугла и яндекса и соцкнопки твиттера и гугла. Всё это добро в ужатом виде весит 1.65 мб, в распакованном виде 4.5 мб. Злые птицы весят примерно 30 мб.
Сможет ряд пользователей отказаться от трижды пройденной игры ради заметного ускорения интернета? Думаю да.
Все ваши проблемы с вымыванием кеша вообще — решаются моим расширением. Надеюсь, такой механизм когда-нибудь попадёт в браузеры хотя бы частично. Можно сказать, что я «изобрёл» аналог shared virtual memory для фронтэнд-библиотек.
Как показывают цифры выше — достаточно десятка версий самых популярных библотек (jQuery, Boostrap, Angular, Backbone, ...) для того, чтобы наступило массовое счастье.
Мой экстеншен уже сейчас имеет все версии jQuery, популярные версии boostrap и font awesome, скрипты статистики гугла и яндекса и соцкнопки твиттера и гугла. Всё это добро в ужатом виде весит 1.65 мб, в распакованном виде 4.5 мб. Злые птицы весят примерно 30 мб.
Сможет ряд пользователей отказаться от трижды пройденной игры ради заметного ускорения интернета? Думаю да.
Все ваши проблемы с вымыванием кеша вообще — решаются моим расширением. Надеюсь, такой механизм когда-нибудь попадёт в браузеры хотя бы частично. Можно сказать, что я «изобрёл» аналог shared virtual memory для фронтэнд-библиотек.
«Ваши бы слова...» :)
Было бы, конечно, удачно, чтобы браузеры из коробки умели такое «грамотное» использование библиотек. Но, или чтобы ваш плагин хотя бы оказался на первых позициях в списке рекомендованных плагинов под каждый из браузеров.
Скажите, а версии под FF (хотя бы), под Оперу (новую, видимо), IE ждать? А то Хром — Хромом, но масса людей
Было бы, конечно, удачно, чтобы браузеры из коробки умели такое «грамотное» использование библиотек. Но, или чтобы ваш плагин хотя бы оказался на первых позициях в списке рекомендованных плагинов под каждый из браузеров.
Скажите, а версии под FF (хотя бы), под Оперу (новую, видимо), IE ждать? А то Хром — Хромом, но масса людей
Вот скажите: зачем грузить разные версии одной и той же библиотеки?
Yandex на главной грузит jQuery 1.8.3, а на странице поиска 1.7.2.
Т.е. если я первый раз зашел на яндекс, а потом что-то искал, то получаю две версии.
Yandex на главной грузит jQuery 1.8.3, а на странице поиска 1.7.2.
Т.е. если я первый раз зашел на яндекс, а потом что-то искал, то получаю две версии.
Потому что над разными модулями работают разные люди и исторически модули писались в разное время с разными либами в основе.
А потом поверх «багов» старой версии jQuery начали писать свои костыли, завязываясь на реализацию конкретной версии.
А потом еще и API в jQuery изменился, и проапгрейдить либу становится крайне затратно.
Это болезнь любого крупного проекта.
А потом поверх «багов» старой версии jQuery начали писать свои костыли, завязываясь на реализацию конкретной версии.
А потом еще и API в jQuery изменился, и проапгрейдить либу становится крайне затратно.
Это болезнь любого крупного проекта.
Я бы понял, если бы это был какой-нибудь стартап.
Все-таки яндекс.
И дай бог бы еще разные проекты. Там допустим Я.Диск или Я.Деньги, а то страница одного и того же сайта по сути.
Ну да ладно.
Просто для коммерческого сайта ориентированного на трафик с поиска Яндекса, встает дилемма — какую версию с CDN Яндекса использовать.
Все-таки яндекс.
И дай бог бы еще разные проекты. Там допустим Я.Диск или Я.Деньги, а то страница одного и того же сайта по сути.
Ну да ладно.
Просто для коммерческого сайта ориентированного на трафик с поиска Яндекса, встает дилемма — какую версию с CDN Яндекса использовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статистика использования javascript-библиотек и CDN