Комментарии 29
Картинка это отсылка к Назад в Будущее 3?
Конкатенацию файлов надо бы применять умно: конкатенировать группы файлов. Сначала те, которые важны для первоначальной загрузки страницы и загрузки остальных файлов, потом уже группа(-ы) второстепенных файлов.
Также, все популярные библиотеки и так закешированы и Google CDN наверняка быстрее и отказоустойчивее чем Akamai
Также, все популярные библиотеки и так закешированы и Google CDN наверняка быстрее и отказоустойчивее чем Akamai
Google CDN наверняка быстрее и отказоустойчивее чем Akamai
А откуда такие доводы? Приведите, пожалуйста, аналитику или хоть какое-нибудь обоснование.
Это сильно зависит от задачи.
В статье описан самый простой пример, который, однако вполне можно считать рабочим вплоть до 300-500 KB минифицированных скриптов/CSS (30-70 KB с gzip). А это размер крупного SPA.
Если больше, то можно начинать думать об оптимизации. Самое простое — разнести вендор-файлы и файлы приложения. Приложение обновляется намного чаще, чем библиотеки, поэтому в основном клиенты будут перекачивать лишь малую часть данных.
Если приложение совсем большое (или в каких-то разделах используются тяжёлые библиотеки), то можно уже группировать по частям — common + отдельные файлы для каждого раздела. В статье об этом не написано, потому что в общем случае это делается нетривиальным образом — или всё разносить по файлам руками, имея риск что-то забыть/перепутать, или с самого начала выбирать архитектуру приложения, исходя из этого требования. Здесь можно отметить яндексовские BEM + bem-tools и более новый webpack.
Есть и другой интересный момент — если файлов становится слишком много (включая все скрипты, стили и картинки), то чтобы не нарваться на ограничение на число параллельных запросов на один домен, можно начинать разносить статику по разным поддоменам штук по 6 ссылок на каждый. Но здесь уже всё совсем индивидуально — надо тестировать, экспериментировать, проверять на различных типах подключения и т.д., иначе можно скорее потерять в скорости загрузки сайта.
Насчёт библиотек по CDN. Использовать сторонние скрипты в HTML я бы никогда не стал и никому не советую. Во-первых, добавляется ещё одна точка отказа. Все падают — и Гугл, и Яндекс, и, думаю, мало кому из ваших клиентов понравится увидеть полностью неработающий сайт только потому что какой-то из внешних ресурсов отвалился (а обычно их прям пачкой добавляют). Во-вторых, вы точно осознаёте, что загружая скрипт с чужого сервера, вы по сути даёте кому-то полный контроль за вашим сайтом? Популярный CDN, конечно, не будет скорее всего кого-то ломать, но его ведь могут и самого поломать.
Да и эффективность такого решения по моему мнению сильно преувеличена — вы скорее проиграете на резолве домена и разогреве кэша, чем при прогоне десятка килобайт по открытому TCP-соединению с разогретым congestion window. (Какой-то крупный сайт публиковал отчёт по поводу процента клиентов с разогретым кэшом на главной странице, и цифры там были далеко не большие.)
В статье описан самый простой пример, который, однако вполне можно считать рабочим вплоть до 300-500 KB минифицированных скриптов/CSS (30-70 KB с gzip). А это размер крупного SPA.
Если больше, то можно начинать думать об оптимизации. Самое простое — разнести вендор-файлы и файлы приложения. Приложение обновляется намного чаще, чем библиотеки, поэтому в основном клиенты будут перекачивать лишь малую часть данных.
Если приложение совсем большое (или в каких-то разделах используются тяжёлые библиотеки), то можно уже группировать по частям — common + отдельные файлы для каждого раздела. В статье об этом не написано, потому что в общем случае это делается нетривиальным образом — или всё разносить по файлам руками, имея риск что-то забыть/перепутать, или с самого начала выбирать архитектуру приложения, исходя из этого требования. Здесь можно отметить яндексовские BEM + bem-tools и более новый webpack.
Есть и другой интересный момент — если файлов становится слишком много (включая все скрипты, стили и картинки), то чтобы не нарваться на ограничение на число параллельных запросов на один домен, можно начинать разносить статику по разным поддоменам штук по 6 ссылок на каждый. Но здесь уже всё совсем индивидуально — надо тестировать, экспериментировать, проверять на различных типах подключения и т.д., иначе можно скорее потерять в скорости загрузки сайта.
Насчёт библиотек по CDN. Использовать сторонние скрипты в HTML я бы никогда не стал и никому не советую. Во-первых, добавляется ещё одна точка отказа. Все падают — и Гугл, и Яндекс, и, думаю, мало кому из ваших клиентов понравится увидеть полностью неработающий сайт только потому что какой-то из внешних ресурсов отвалился (а обычно их прям пачкой добавляют). Во-вторых, вы точно осознаёте, что загружая скрипт с чужого сервера, вы по сути даёте кому-то полный контроль за вашим сайтом? Популярный CDN, конечно, не будет скорее всего кого-то ломать, но его ведь могут и самого поломать.
Да и эффективность такого решения по моему мнению сильно преувеличена — вы скорее проиграете на резолве домена и разогреве кэша, чем при прогоне десятка килобайт по открытому TCP-соединению с разогретым congestion window. (Какой-то крупный сайт публиковал отчёт по поводу процента клиентов с разогретым кэшом на главной странице, и цифры там были далеко не большие.)
А вот и прямое подтверждение: blog.jquery.com/2014/09/23/was-jquery-com-compromised/
Пишут что сама библиотека не была скомпрометирована, но обычно такие новости заставляют сильно задуматься, стоит ли загружать скрипты на своих сайтах непонятно откуда.
Пишут что сама библиотека не была скомпрометирована, но обычно такие новости заставляют сильно задуматься, стоит ли загружать скрипты на своих сайтах непонятно откуда.
Есть ли у вас автоматическая загрузка контента с основного домена в сеть CDN?
Например, чтобы при запросе static.example.com/image/logo.jpg ваш сервер запрашивал example.com/image/logo.jpg и загружал файл на облачный сервер.
Например, чтобы при запросе static.example.com/image/logo.jpg ваш сервер запрашивал example.com/image/logo.jpg и загружал файл на облачный сервер.
Советы применимы не только к статическим сайтам, но и вообще к статическом контенту.
Очередная статья, рассказывающая о том, чего и так в интернете полно. Еще, совершенно не понятно, какие преимущества будет иметь ваш noname CDN по сравнению с Google CDN?
>> Используйте возможности CDN
У меня как раз где-то неделю назад пробегала одна мысль по этому поводу…
Использовать Google Drive в качестве CDN.
То есть, через API (или какими другими «хитрыми» способами) загружать фотографии товаров, видео, скрипты и т.п. на диски google и расшаривать по ссылке.
В итоге получается, в принципе, отказоустойчивая система, не нагружающая непосредственно сервер с сайтом.
При этом, места хватит, чтобы хранить достаточно много различной информации.
Можно, «на всякий случай», завести несколько аккаунтов и выбирать их в случайном порядке.
У меня как раз где-то неделю назад пробегала одна мысль по этому поводу…
Использовать Google Drive в качестве CDN.
То есть, через API (или какими другими «хитрыми» способами) загружать фотографии товаров, видео, скрипты и т.п. на диски google и расшаривать по ссылке.
В итоге получается, в принципе, отказоустойчивая система, не нагружающая непосредственно сервер с сайтом.
При этом, места хватит, чтобы хранить достаточно много различной информации.
Можно, «на всякий случай», завести несколько аккаунтов и выбирать их в случайном порядке.
Вот хитрецы, а!
Спасибо за скриншот, я догадывался, что будет не всё так просто.
…
Но ведь есть много других хранилищ, тот же Яндекс.Диск, dropbox и т.п.
Или, например, picasa…
А если пойти дальше, то ВКонтакте, Фото Mail.ru и т.п.
Спасибо за скриншот, я догадывался, что будет не всё так просто.
…
Но ведь есть много других хранилищ, тот же Яндекс.Диск, dropbox и т.п.
Или, например, picasa…
А если пойти дальше, то ВКонтакте, Фото Mail.ru и т.п.
Хранилище != CDN
Dropbox: 20GB/Day
Yandex.disk: Когда объем публичных файлов, скачанных с вашего Диска, превышает доступный вам объем Диска в два раза, скорость скачивания ваших файлов ограничивается. Ограничение действует сутки: опубликованные вами файлы можно качать со скоростью не больше 64 Кбит/с. Через сутки счетчик скачанного объема сбрасывается.
Вконтакте и Mail.ru не имеют CDN.
Ну не бывает бесплатного сыра…
Dropbox: 20GB/Day
Yandex.disk: Когда объем публичных файлов, скачанных с вашего Диска, превышает доступный вам объем Диска в два раза, скорость скачивания ваших файлов ограничивается. Ограничение действует сутки: опубликованные вами файлы можно качать со скоростью не больше 64 Кбит/с. Через сутки счетчик скачанного объема сбрасывается.
Вконтакте и Mail.ru не имеют CDN.
Ну не бывает бесплатного сыра…
Блин, и тут тоже всё продумали!
>> Вконтакте и Mail.ru не имеют CDN.
Тут имелось ввиду не CDN, а загрузка данных в публичную часть через эмуляцию действий пользователя.
Грубо говоря, скрипт, который подобно пользователю создаёт альбомы и загружает туда изображения.
А потом записывает сгенерированную ссылку в базу и отдаёт уже на сайте.
>> Ну не бывает бесплатного сыра
Это не из-за желания бесплатного сыра, это больше ради интереса.
Так сказать, «А что, если...»
Ну и… вдруг не мне одному пришла мысль, «как обмануть всех».
>> Вконтакте и Mail.ru не имеют CDN.
Тут имелось ввиду не CDN, а загрузка данных в публичную часть через эмуляцию действий пользователя.
Грубо говоря, скрипт, который подобно пользователю создаёт альбомы и загружает туда изображения.
А потом записывает сгенерированную ссылку в базу и отдаёт уже на сайте.
>> Ну не бывает бесплатного сыра
Это не из-за желания бесплатного сыра, это больше ради интереса.
Так сказать, «А что, если...»
Ну и… вдруг не мне одному пришла мысль, «как обмануть всех».
Когда у вас будет достаточно много пользователей и серьезный трафик, то вы почувствуете подводные камни этого решения и будет уже поздно…
PS: как раз akme иллюстрирует
PS: как раз akme иллюстрирует
Кстати, если продукт РУ-ориентированный, хорошо бы смотреть и РУ-ориентированный CDN.
Т.е. не только Москва-СПБ, но и Нижний Новгород, Новосиб, Хабаровск и т.д.
А то международные CDN вполне могут часть запросов послать в Нидерланды, а часть — в Китай.
Т.е. не только Москва-СПБ, но и Нижний Новгород, Новосиб, Хабаровск и т.д.
А то международные CDN вполне могут часть запросов послать в Нидерланды, а часть — в Китай.
В статье же приводится ссылка на карту, на которой видно, что серверы у Akamai не только в Москве и Петербурге.
Да, мой комментарий больше для людей, которые будут выбирать CDN (ведь данный пост — не реклама одного akamai, я надеюсь).
Хотя у akamai самые восточные в России — Новосиб и Барнаул.
Остается поле для сравнения, если кому-то понадобятся более восточные точки.
Хотя у akamai самые восточные в России — Новосиб и Барнаул.
Остается поле для сравнения, если кому-то понадобятся более восточные точки.
Прочитал Ваш комментарий, и у меня тут же возник вопрос: а есть ли вообще какие-нибудь CDN, у которых в России есть точки присутствия восточнее Новосибирска? В дальневосточном регионе, напримре, есть у кого-нибудь точки присутствия?
Вообще, да.
skyparkcdn.ru/#pops
moscow.megafon.ru/operators/data_services/map_data_centers/
www.cdnvideo.ru/tekhnologiya/topologiya-seti-cdnvideo/
www.ngenix.net/network
Но дьявол кроется в деталях.
Во первых, мне кажется, эти CDN ориентированы больше на рунет.
Во вторых нужно смотреть на соотношение цена/профит, особенно для мелкой статики.
Вполне возможно, «в целом» по цене, удобству и присутствию в мире akamai наберет больше очков.
Возможно, каким-то проектам проще сделать свое — в нужной точке поставить/арендовать сервер, закинуть в tmpfs статику и отдавать самим.
skyparkcdn.ru/#pops
moscow.megafon.ru/operators/data_services/map_data_centers/
www.cdnvideo.ru/tekhnologiya/topologiya-seti-cdnvideo/
www.ngenix.net/network
Но дьявол кроется в деталях.
Во первых, мне кажется, эти CDN ориентированы больше на рунет.
Во вторых нужно смотреть на соотношение цена/профит, особенно для мелкой статики.
Вполне возможно, «в целом» по цене, удобству и присутствию в мире akamai наберет больше очков.
Возможно, каким-то проектам проще сделать свое — в нужной точке поставить/арендовать сервер, закинуть в tmpfs статику и отдавать самим.
wwwnui.akamai.com/gnet/globe/index.html
Сервера в России у них явно есть. А вот насчет правильной маршрутизации могут быть нюансы.
Сервера в России у них явно есть. А вот насчет правильной маршрутизации могут быть нюансы.
За какие конкретные нюансы вы опасаетесь? Так то они есть у всех CDN…
Ну я не то чтобы опасаюсь. Я с Akamai работал, правда на американский рынок. CDN у них мощнейший.
Просто например если Новосибирский сервер будет недоступен, пойдет запрос куда-нибудь в Монголию, вместо Иркутска. А в Беларуси вообще серверов у них нет. Откуда будет запрашиваться контент, предугадать сложно.
Просто например если Новосибирский сервер будет недоступен, пойдет запрос куда-нибудь в Монголию, вместо Иркутска. А в Беларуси вообще серверов у них нет. Откуда будет запрашиваться контент, предугадать сложно.
Вы вообще за Уралом были когда-нибудь? На российском Дальнем Востоке были? Представляете себе, какие там расстояния? Если контент пойдет на Камчатку не через Новосибирск, а через Монголию, то это вообще будет не заметно — расстояние примерно одно и то же. Более того, для Дальнего Востока точки присутствия в том же Китае будут горазо выгоднее по целому ряду причин.
А провод от провайдера идет через Монголию или таки через Москву?
Ближайшее расстояние по карте не всегда ближайшее же через интернет. И если CDN ориентирован на Россию, он это будет учитывать. А если нет, то могут (но не обязательно будут) нюансы.
Ближайшее расстояние по карте не всегда ближайшее же через интернет. И если CDN ориентирован на Россию, он это будет учитывать. А если нет, то могут (но не обязательно будут) нюансы.
Вот тут в общих чертах расписан механизм выбора пути.
Если CDN сделан грамотно, запрос пойдет в Москву.
Как в regexp, или в маршрутизации, если не сработает более конкретное правило «новосиб в новосиб», сработает более общее «россия в москву».
Как в regexp, или в маршрутизации, если не сработает более конкретное правило «новосиб в новосиб», сработает более общее «россия в москву».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статические сайты: настройка и оптимизация