Храните статические ресурсы на своём хостинге

Автор оригинала: Harry Roberts
  • Перевод
Одна из первых вещей, которую я рекомендую своим клиентам, чтобы ускорить веб-сайты, сначала покажется парадоксом: вы должны разместить статические ресурсы на своём хостинге, отказавшись от сторонней CDN инфраструктуры. В этом коротком и, надеюсь, очень простом посте я хочу обрисовать недостатки хранения ваших статических файлов «на стороне» и потрясающие преимущества размещения их на своём хостинге.

О чём я говорю?


Это обычное дело для разработчиков — обращаться по ссылке к статическим активам, таким как библиотеки или плагины, которые находятся на сайтах и CDN ресурсах. Классический пример – jQuery.

Здесь есть ряд очевидных преимуществ, но моя цель далее в статье — разоблачить этот подход, и показать, что недостатки значительно преобладают.

(Сначала рассмотрим преимущества).

  • Это удобно. Это требует очень малых усилий для подключения файлов. Скопипастить строчку HTML кода, и всё готово. Легко.
  • Мы получаем доступ к CDN. code.jquery.com поставляется StackPath, это CDN. Подключаясь к контенту на этом ресурсе, мы получаем доставку CDN-качества, бесплатно.
  • Возможно, файлы пользователей уже кэшированы. Если website-a.com ссылается на code.jquery.com/jquery-3.3.1.slim.min.js, и пользователь переходит отсюда на website-b.com, который также ссылается на code.jquery.com/jquery-3.3.1.slim.min.js, затем у пользователя будет этот файл в кэше.

Риск: Падение скорости и Сбои


Я не буду вдаваться в слишком большое количество деталей в этом посте. У меня есть целая статья по поводу жизнеспособности третьей стороны и рисков, связанных с задержками и перебоями. Достаточно сказать, что если у вас есть какие-либо критичные ресурсы, связанные с провайдерами третьей стороны, и если провайдер страдает от сбоев и падения скорости или отключений, это довольно неприятная новость для вас. Вы тоже будете страдать от этого.

Если у вас есть какой-нибудь render-blocking CSS или синхронный JS, размещённый на сторонних ресурсах, идите и перенесите их в свою собственную инфраструктуру немедленно. Критичные активы слишком ценны, чтобы оставлять их на сторонних серверах.

Риск: Прекращение обслуживания


Это гораздо менее обычное явление, но что случится, если провайдер решит, что ему необходимо прекратить обслуживание? Это как раз то, что сделал Rawgit в октябре 2018 года, до сих пор (на момент написания статьи) грубый поиск по коду GitHub все еще даёт более миллиона ссылок на сервис, который сейчас находится в стадии закрытия, и почти 20 000 действующих сайтов продолжают ссылаться на него.

Риск: Уязвимости безопасности


Другая вещь, на которую следует обратить внимание, — это простой вопрос доверия. Если мы приносим контент из сторонних ресурсов на нашу страницу, нам приходится надеяться, что файлы, которые мы получаем, являются именно тем, что мы рассчитываем получить, и они делают именно то, что мы от них ожидаем.

Представьте себе вред, который мог бы быть причинён, если кому-нибудь удалось бы получить контроль над провайдером, таким как code.jquery.com и начать поставлять скомпрометированный или злонамеренный контент. Об этом страшно подумать!

Целостность Субресурсов


Надо отдать должное всем сторонним провайдерам, упомянутым до сих пор в этой статье, они делают всё, чтобы обеспечить целостность субресурсов (Subresource Integrity — SRI). SRI – это механизм, с помощью которого провайдер обеспечивает хэш (технически, хэш с последующим кодированием Base64) конкретного файла, который вы ожидаете и намереваетесь использовать. Браузер затем может проверить, что файл, который вы получили, является в точности тем, что вы запрашивали.

<script src="https://code.jquery.com/jquery-3.4.1.slim.min.js"
        integrity="sha256-pasqAKBDmFT4eHoN2ndd6lN370kFiGUFyTiUHWhU7k8="
        crossorigin="anonymous"></script>

Ещё раз, если вы точно должны подключить к стороннему ресурсу статический контент, убедитесь, что действует SRI. Вы можете подключить SRI самостоятельно.

Расплата: Сетевые Согласования


Одна из самых больших и безотлагательных затрат, которую мы несём, — это стоимость открытия новых TCP соединений. Каждый новый ресурс, который нам необходимо посетить, требует открытия соединения, что может быть очень накладно: разрешение DNS, TCP рукопожатие, TLS согласование, всё это вносит свою лепту, и история усугубляется по мере задержек в соединении.

Я приведу пример, взятый прямо из собственной страницы Бутстрапа Getting Started. Они инструктируют пользователей подключить четыре файла.

Эти четыре файла находятся на трёх разных ресурсах, то есть, нам необходимо открыть три соединения TCP. Сколько это стоит? Ну, при достаточно быстром соединении, содержание этих статических файлов на стороне стоит 311мс, или 1,65х медленнее, чем при размещении их на собственном хостинге.

Связываясь с тремя различными источниками для обслуживания статических активов, мы в совокупности теряем ненужные 805мс на сетевые согласования.

ОК, не так уж страшно, но Trainline, мой клиент, обнаружил, что при уменьшении задержки на 300мс, посетители платят дополнительно 8 миллионов фунтов в год. Это довольно простой способ заработать 8 миллионов.

Только лишь переместив наши ресурсы на свой домен, мы полностью исключаем затраты на дополнительные соединения.

Для более медленного соединения, с большей задержкой, история намного хуже. Для 3G, сторонняя версия приходит медленнее 1.765с. Я полагал, что имелось в виду сделать наш сайт быстрее.

При соединении с большой задержкой, суммарные сетевые затраты составляют чудовищные 5.037с. Чего полностью можно избежать.

Перемещение файлов в нашу собственную инфраструктуру снижает время загрузки от 5.4с до 3.6с.

Если это недостаточный повод разместить ваши статические ресурсы у себя, я не знаю, какой ещё привести.

Preconnect


Естественно, весь смысл моего выступления здесь заключается в том, что вы не должны размещать какие-либо статические ресурсы на стороне, если способны сделать это у себя на хостинге. Однако, если у вас каким-то образом связаны руки, вы можете использовать Resource Hint preconnect, чтобы превентивно открыть соединение TCP c определённым источником (определёнными источниками): Более того, их развёртывание в качестве заголовков HTTP будет ещё быстрее.
Примечание. Даже если вы используете preconnect, размер потерянного времени уменьшится лишь чуть-чуть: вам всё ещё необходимо открыть соответствующие соединения, и маловероятно, что когда-либо затраты оправдаются, особенно для медленных соединений.

Расплата: Потеря Приоритезации


Вторая расплата приходит в форме оптимизации на уровне протокола, которую мы упускаем в момент, когда разделяем контент по доменам. Если вы используете HTTP/2, что следует делать, вы получаете доступ к приоритезации.

Все потоки (следовательно, ресурсы) с тем же самым TCP соединением, сохраняют приоритет, и браузер с сервером работают в тандеме, чтобы построить дерево зависимости всех этих приоритезированных потоков, чтобы мы могли вернуть критичные ресурсы быстрее и возможно, задержать доставку менее важных.

Примечание. Технически, вcледствие сращивания соединений HTTP/2, запросы могут быть приоритезированы по отношению друг к другу по разным доменам, пока они разделяют один IP адрес.

Если мы распределяем наши ресурсы по разным доменам, нам приходится открывать несколько уникальных TCP соединений. Мы не можем делать перекрёстные ссылки для приоритетов в этих соединениях, то есть мы теряем способность доставки файлов определённым хорошо продуманным способом.

Размещая весь контент на одном хостинге, мы можем построить более сложное дерево зависимостей. У каждого потока имеется свой ID, так как они принадлежат одному дереву. Если мы обеспечиваем как можно больше контента с одного домена, мы можем позволить HTTP/2 делать своё дело и приоритезировать активы более полно в надежде на более быстрый ответ.

Кэширование


По большому счету, хосты статических ресурсов, похоже, неплохо справляются с установлением долгоживущих директив max-age. Это имеет смысл, поскольку статический контент на версионных URL-адресах (как указано выше) никогда не изменятся. Это делает очень безопасным и рациональным усиление разумно агрессивной политики кэширования.

Тем не менее, это не всегда так, и, самостоятельно размещая свои ресурсы, вы можете разработать гораздо более индивидуальные стратегии кэширования.

Миф: Кросс-Доменное Кэширование


Более интересным является возможность междоменного кэширования активов. То есть, если множество сайтов ссылаются на одну и ту же версию jQuery, размещенную на CDN, то наверняка пользователи уже имеют этот конкретный файл на своем компьютере. Что-то вроде однорангового обмена ресурсами. Это один из самых распространенных аргументов в пользу применения стороннего поставщика статических активов.

К сожалению, не существует опубликованных доказательств, подтверждающих эти утверждения: нет оснований предполагать, что это действительно так. И наоборот, недавнее исследование Пола Кальвано намекает на то, что может иметь место обратное:

Есть ощутимый разрыв между возрастом кэша ресурсов CSS и веб-шрифтов 1-й и 3-й стороны. 95% шрифтов 1-й стороны старше 1 недели по сравнению с 50% сторонних шрифтов, которые имеют возраст менее 1 недели. Это дает веские основания для самостоятельного размещения веб-шрифтов.

В общем, кажется, что сторонний контент кэшируется хуже, чем собственный.

Еще более важно то, что Safari полностью отключил эту функцию из-за опасения злоупотреблений в отношении конфиденциальности, поэтому технология общего кэша не может работать на момент написания этой статьи для 16% пользователей во всем мире.

Короче говоря, хотя теоретически это хорошо, нет никаких доказательств того, что кросс-доменное кэширование каким-то образом эффективно.

Доступ к CDN


Еще одно широко распространенное преимущество обращения к поставщику статических ресурсов заключается в том, что он, скорее всего, будет использовать мощную инфраструктуру с возможностями CDN: глобальное распределение, масштабируемость, низкая задержка и высокая доступность.

Так как это абсолютно верно, если вы заботитесь о своей производительности, вам следует запускать свой собственный контент из CDN. С уровнем текущих цен на хостинг остаётся очень мало оправданий, почему вы не используете это для своих ресурсов.

Другими словами: если вы думаете, что вам нужен CDN для вашего jQuery, вам понадобится CDN для всего.

Размещайте статические ресурсы у себя на хостинге


На самом деле, есть очень мало причин оставлять свои статические ресурсы в чужой инфраструктуре. Возможные выгоды часто являются мифом, и даже если нет, компромиссы просто не стоят этого. Загрузка ресурсов из разных источников происходит значительно медленнее. В течение следующих нескольких дней потратьте десять минут на аудит ваших проектов и возьмите все сторонние статические ресурсы под свой контроль.
Поделиться публикацией

Комментарии 47

    0

    Так и делаю.

    • НЛО прилетело и опубликовало эту надпись здесь
        +3

        Согласен с тем, что статья очень спорная. Никаких конкретных рекомендаций для конкретных случаев не увидел.
        Кратко — при прочих равных я вообще не делал бы свой хостинг для статики, а пользовался готовыми решениями. Риск компрометации — вообще смешно, т.к. в этом случае вообще опасно говорить о "чужом" хостинге — нужно вообще поднимать полностью свою инфраструктуру вплоть до каналов до точек обмена трафиком. Даже большой бизнес не может себе это позволить, что говорить тогда о сайтах-визитках? В общем, поэтому читая такие статьи внутри мне становится смешно.
        Единственный интересный факт, который я почерпнул — это про неработоспособность кросс-доменного кэширования. Вот про него можно было целое отдельное исследование забубенить

          +2
          Риск компрометации — вообще смешно

          Не настолько смешно. Компрометация CDN ставит под угозу десятки или даже сотни тысяч разных сайтов, причём одновременно, в то время как риск компрометации отдельно взятого сайта (особенно визитки) сравнительно низок.

          Даже на shared hosting (не говоря уже о VPS и DS) можно принять ряд мер чтобы снизить риск компрометации, или, как минимум, оперативно мониторить целостность, в то время как компрометация CDN с высокой вероятностью останется незамеченной владельцем сайта, по крайней мере какое-то время (до поступления жалоб от клиентов).

          Да, хостер имеет возможности сравнительно тайно вмешиваться в работу того что хостит (в определенных пределах), но если это вскроется (а это только вопрос времени) — это чудовищные репутационные потери, да и шанс что этим занимается кто-то крупный очень невысок. Максимум чего реально стоит опасаться — это блокирования доступа к хостингу, отказа в обслуживании, но уж точно не MitM.

          Если же говорить про РФ, то возможен вообще нездоровый вариант типа блокировки CDN известной организацией (по ошибке или любой другой причине), и всё, приплыли — сразу целая пачка сайтов разрушена (пусть даже временно).

          Ещё можно понять CDN когда нужно быть поближе к источнику запроса, при очень высокой нагрузке (как по траффику так и по rps), но если это не жутко загруженный сайт — то какой вообще смысл использовать CDN для bootstrap/jquery/etc? Потому что модно и «правильно», или потому что «все так делают»?

          И наконец, никогда не стоит забывать в случае бесплатных CDN — если вы не покупатель, то вы — товар, в том или ином виде. Если же CDN платный, то всё равно остаётся вопрос, что дешевле — свой хостинг или свой хостинг плюс CDN.
            0

            Понимаете, почему я написал, что риск компрометации смешно? Потому что есть куча провайдеров, которые могут Вас как клиента нагнуть.
            Предположим, что Вы клиент виртуального хостинга — тогда Вы полностью доверяете свои сертификаты ССЛ и приватные ключи владельцам этого ВХ. Боязно, да? Но в случае сайта-визитки действительно риски не такие высокие. В случае, если Вы хоститесь на виртуальных машинах — очевидно, что при прочих равных, провайдер имеет доступ к самим виртуальным машинам, вплоть до того, что может оттуда вытаскивать дампы памяти и файлы с дисков. Причем, что хуже по сравнению с ВХ — Вы об этом никогда не узнаете. Ну, и т.д. Все эти риски нужно учитывать. И если так подходить к вопросу то не то, что CDN, то вообще всю инфраструктуру нужно держать у себя, обвешать камерами и посадить безопасника. Дорого? Да. Безопасно? На самом деле даже в этом случае человеческий фактор никто не отменял. Вот дадут этому цепному псу денег конкуренты… и все… приплыли.
            Поэтому я скорее поверю зарубежному CDN с хорошей репутацией, чем местным провайдерам (которые при любом удобном случае сдадут ключики от моей инфры силовикам).


            И наконец, никогда не стоит забывать в случае бесплатных CDN — если вы не покупатель, то вы — товар, в том или ином виде.
            соглашусь. Но здесь больше вопрос для клиента в том, какой уровень сервиса этот CDN будет предоставлять. Скорее всего на бесплатном тарифе жесткие ограничения по трафику, по защите от DDoS атак и пр. Т.е. в случае ЧП — действительно, что доступность "защищаемого" пострадает. Но, как и везде — нужно включать голову. Допустимо это или нет. Какие риски и убытки могут быть. И т.п.

            Если же CDN платный, то всё равно остаётся вопрос, что дешевле — свой хостинг или свой хостинг плюс CDN.

            Тенденция такова, что при прочих равных выгоднее что-либо отдать профессионалам. Ибо делать самому дорого (нужны специально обученные люди, их ФОТ, специальное оборудование), а риски можно покрыть договорными отношениями.


            Ещё можно понять CDN когда нужно быть поближе к источнику запроса, при очень высокой нагрузке (как по траффику так и по rps), но если это не жутко загруженный сайт — то какой вообще смысл использовать CDN для bootstrap/jquery/etc? Потому что модно и «правильно», или потому что «все так делают»?

            И да, и нет. Как и обычно — есть три категории игроков. Маленькие, средние и большие. И для них будут разные правила игры. Например, мелкие могут страдать от того, что на них большой трафик и они будут биться за каждую копейку. Тогда действительно — почему бы не прикрыться cloudflare, закэшировать все что можно, а bootstrap & jquery отдавать с внешнего ресурса? Средние — уже почти наверняка сидят на каком-нибудь амазоне, где свои нюансы… А крупные… Ну, у них счет на трафик может исчисляться тысячами $ и любая микро-оптимизация может сэкономить круглую сумму.


            Если же говорить про РФ, то возможен вообще нездоровый вариант типа блокировки CDN известной организацией (по ошибке или любой другой причине), и всё, приплыли — сразу целая пачка сайтов разрушена (пусть даже временно).

            Это российская специфика — это раз. Два — пострадать может не только CDN, а вообще любой внешний по отношению к РФ хостер (scaleway & digitalocean до сих пор в бане). В третьих, есть CDN, у которых есть региональные филиалы в России, и провайдеры, у которых тоже есть точки присутствия в РФ.

              0
              Предположим, что Вы клиент виртуального хостинга — тогда Вы полностью доверяете свои сертификаты ССЛ и приватные ключи владельцам этого ВХ.

              Что мне мешает использовать свои сертификаты и приватные ключи к ним? Только тот факт что «всё включено» (не всегда, кстати)? Если провайдер виртуального хостинга не даёт даже это сделать самостоятельно — то я бы сильно подумал перед тем как у него хостится.

              И если уж мы говорим про виртуальный хостинг — то скорее всего это всё же очень небольшие нагрузки (причём без гарантий по доступности и ресурсам), а раз так — то снова вопрос в том, нужно ли ему вообще CDN?

              Поэтому я скорее поверю зарубежному CDN с хорошей репутацией, чем местным провайдерам

              Видимо, всё дело в том что для меня «местные» это для вас «зарубежные», у нас (в Германии, в частности) все эти ужасы (типа доступа к VM клиента) хоть и возможны, но серьезно караются, если вдруг чего. Да и выбор есть среди тех кто с хорошей репутацией.

              Но как дополнительную линию обороны можно использовать VPS/DS с шифрованным диском и своим загрузчиком, хотя он и перестанет быть reboot-safe. Да, провайдер, имея прямой доступ памяти и прочему, может конечно и в этом случае получить доступ (хотя и не всегда), но это случится только если вы станете конкретной целью, просто ради любопытства этим вряд-ли будут заниматься.

              Ибо делать самому дорого (нужны специально обученные люди, их ФОТ, специальное оборудование), а риски можно покрыть договорными отношениями.

              Честно говоря я не совсем понимаю — если человек (фирма) в состоянии настроить хостинг, что ещё ему нужно знать для того чтобы выложить статику у себя вместо CDN? Что в этом такого что нужно специальное оборудование и специально обученные люди?

              Основной смысл CDN — в разгрузке своего сайта, если сайт настолько загруженный или к нему высокие требования по доступности и времени отклика из любой точки мира — то да, потребуется и специальная инфраструктура, и специально обученные люди, дабы всё работало как часы, но для большинства сайтов это всё же не так. С другой стороны, доверять CDN (даже с хорошей репутацией) отдавать статические скрипты для сайта финтеха, банка, страховой etc — это в высшей степени неразумно, ибо от необхомости мониторить и защищать своё хозяйство не избавляет, но становится менее надёжным и менее безопасным (даже у Cloudflare бывают проблемы).

              Что ещё важно — посколько, с вероятностью 99.99%, бизнес-логика любого сайта (кроме визиток, пожалуй) строится не на том что распостраняется посредством CDN, то мониторить сайт и его бесперебойную работу всё равно придётся, ибо если он «ляжет», то CDN всё равно не спасёт — все jquery и прочие плюшки в момент станут бесполезными.

              Впрочем, исходя из ваших объяснений, я начинаю подозревать что скорее это актуально для РФ (или даже СНГ) — борьба за сокращение траффика и всё такое, ибо в Западной Европе или США это не так актуально, да и хостеры намного более адекватные.

                0
                Что мне мешает использовать свои сертификаты и приватные ключи к ним? Только тот факт что «всё включено» (не всегда, кстати)? Если провайдер виртуального хостинга не даёт даже это сделать самостоятельно — то я бы сильно подумал перед тем как у него хостится.

                Хотя бы два соображения:


                1. Если ВХ предоставляет веб-панель для установки сертификатов, то Вы их закачаете туда как в черный ящик. Соответственно, содержимое сертификата и публичного ключа будет раскрыто для ВХ. В худшем случае — по дороге — кому-то ещё.
                2. В любом случае приватный ключ и сертификат будут лежать в конфигурации веб-сервера и зачастую на ВХ для экономии он общий на всех клиентов. Бывают тарифные планы с индивидуальным обслуживанием (да и вообще при прочих равных лучше заказать виртуалку и настроить ее самому, но когда речь идёт о низкой цене без каких-либо компромиссов, то ВХ все ещё вне конкуренции), но это не столь принципиально. В общем, защита такого сервера скорее всего подхрамывает. Пользователи регулярно заражают его php-скриптами или попросту оставляют уязвимости и туда скрипт-киддиз закидывают свои скрипты. Теоретически спасает система прав юзеров и модули типа селинукс… Но не всегда.
                  Дальше продолжать?
                  Понятно, что я именно в вопросе ИБ не привязываюсь к ВХ, но это самый яркий пример такой… Дырявой услуги. Вот, ей-Богу, лучше уж тогда конструкторы сайтов типа.

                Впрочем, исходя из ваших объяснений, я начинаю подозревать что скорее это актуально для РФ (или даже СНГ) — борьба за сокращение траффика и всё такое, ибо в Западной Европе или США это не так актуально, да и хостеры намного более адекватные.

                Да, действительно в СНГ своя специфика. Но и зарубежом точно так же соображения экономии трафика имеют место быть.


                другой стороны, доверять CDN (даже с хорошей репутацией) отдавать статические скрипты для сайта финтеха, банка, страховой etc — это в высшей степени неразумно, ибо от необхомости мониторить и защищать своё хозяйство не избавляет, но становится менее надёжным и менее безопасным (даже у Cloudflare бывают проблемы).

                Согласен, что для финтех, банков и пр. нужен свой подход. У них свои требования к используемым информационным системам.

                0

                У блокировок есть и обратная строона: например, некоторые страны блокируют некоторые российские ресурсы, которые можно отнести к CDN в данном контексте. И подключая скрипты с них для своих сайтов бездумно, вы рискуете если не полной неработоспособностью сайта, то уходом пользователей до сетевого таймаута.

          +3

          Странная экономия на задержке в милисекундах. А если у хостера плата за исходящий трафик? Еще минус хранить у себя, это если ресурсов довольно много и есть наплыв пользователей, к примеру онлайн трансляция, то ваш хостинг будет будет ощущать довольно сильную нагрузку по полосе. В свое время освободил кучу полосы перенеся как раз таки сайт за Cloudflare.

          +18

          Абсолютно верная статья. У меня такое ощущение, что миф про выгоду CDN запускали сами владельцы CDN для привлечения клиентов. Мне эта идея всегда казалась бредовой, отдавать пару файлов через CDN, а все остальное (HTML, пользовательские картинки) — со своего сервера. Вот еще недостатки CDN:


          • нарушение сетевой связности. РКН в любой момент может забанить иностранные IP адреса CDN и ваш сайт из-за этого упадет. Глупо нести убытки из-за того, что кто-то разместил на Амазоне призыв выйти на митинг, телеграм-прокси или фразу про сказочного Путина.
          • политические риски. Из России постепенно прогоняют и будут прогонять западные сервисы, ухудшая к ним доступ.
          • ваш сайт скорее всего ближе к пользователям. Допустим, у вас магазин, ориентированный на жителей Гадюкинской области. Скорее всего сервер в Гадюкино будет ближе и каналы к нему будут толще, чем до западных CDN.
          • расходы времени разработчиков на настройку и подкючение CDN. Это будет стоить вам денег.
          • чем больше серверов вы используете, тем больше точек отказа и его вероятность
          • с CDN невозможно использовать проверку актуальности файла с помощью If-Modified-Since и надо включать "вечное кеширование" ресурсов, и схемы сброса этого кеша, на что, опять же, надо тратить небесплатное время разработчиков.

          Также, я думаю, что идея про кеширование не работает. Сейчас каждый сайт ставит кеширующие заголовки на все свои ресурсы, кеш постоянно переполняется и старые файлы вытесняются из него.


          Я помню историю, много лет назад, я сдал сайт и на нем jQuery был синхронно подключен через CDN. И надо же, этот CDN умудрился упасть как раз в тот момент, когда директор заказчика решил проверить сайт. С тех пор я всегда рекомендую не использовать CDN. Nginx на вашем сервере будет отдавать файлы так же хорошо, как и Nginx на сервере CDN. А вы думали, они какой-то специальный сервер используют?


          Естественно, могут быть ситуации, когда использование CDN выгоднее. Но если у вас обычный Интернет-магазин, рассчитанный на Россию и прежде всего на Москву, то вам не нужны точки раздачи файлов в Сигнапуре и Лондоне. Да и даже если бы были нужны — они вам не помогут ускорить загрузку для лондонца, так как CDN кеширует лишь маленькую часть файлов. а большинство все равно будет грузиться с вашего далекого сервера.

            0
            Мне эта идея всегда казалась бредовой, отдавать пару файлов через CDN, а все остальное (HTML, пользовательские картинки) — со своего сервера

            Согласен, что имеет смысл отдавать через cdn всю статику, но, как говорится, дьявол в деталях и надо смотреть по каждому конкретному случаю. Может вообще у всех пользователей сайта общих ресурсов только 1% и смысл тогда кэшировать остальные 99%

            +2
            CDN тоже разные бывают.
            Если мы говорим о CloudFront, Fastly или CloudFlare, то выгода от использования таких сервисов для средних и больщих проектов очевидна.
              0

              Особенно большая выгода, когда IP Амазона или CloudFlare опять заблокируют :)

                +1
                В этом случае проблема будет не в CDN
              +2
              Выгода от использования cdn даже если cdn хостите вы лично а не купили есть. Например при защите от ddos 7 уровня
              — вы всегда можете выявить начало атаки т.к. у вас на сервер поступают только запросы к приложению и они не теряются в общем потоке запросов статики.
              — для простых видов атак вы можете поставить фильтр по количеству запросов с одного адреса. Если идёт статика то вы не сможете установить ограничение по фильтров и.к. на один запрос к приложению буде приходить 50-100 запросов на статику
              — после установки защиты может оказаться что на ваш сайт есть ссылки на статику в почтовых сообщениях. Если эти ссылки открываются не через браузер а через почтовый клиент то защиту почтовый клиент не проходит и картинка будет недоступной. Аналогично например gmai подменяет ссылку в почтовом сообщении на свою с ылау и пытается забрать картинку ботом. Бот конечно тоже защиту не проходит

              С cdn таких проблем у Вас не будет

              Уже не говоря о том что cdn как правило ещё устраивают так чтобы приблизить доступ к контенту по сети.
                +1
                Использование облаков или специальных прокси (типа cloudflare) для защиты от ddos, конечно, смысл имеет. Но не то, что вы записали.

                Запросы к приложению и статике легко раздели на уровне конфига веб-сервера. Даже, если у них один домен. И логи писать отдельно и настроить фильтрацию по к-ву запросов (хотя, смысла в этом немного. Лучше с кэшированием на уровне веб-сервиса поиграться).

                В статье описывается подключение библиотек с CDN которые хостят эти библиотеки. А вы описываете вариант с кастомной настройкой cdn под конкретный сайт. Не смотря на то, что вы описали странный кейс, он все же совсем не о том, что пишут в самой статье.
                +2
                Мне хватило одного раза, когда после грозы у нас пропал интернет и я не могла работать даже локально из-за отсутствия библиотек. С тех пор для серьезных проектов — только собственный хостинг.
                  –1
                  Лучше сделать отдельный сервер в том же ДЦ, чтобы запросы к статике шли на другой домен, что то типа cdn.вашдомен.хх, а не к www.вашдомен.хх
                    +2
                    Чем это лучше в 2019 году?
                      0
                      тем что есть разница в итоговой скорости загрузки страницы в контексте браузера
                        +3
                        Эта разница была актуальна в 2005, когда сервера были дохлыми, nginx только начинался и http был первой версии.

                        В 2019 http2+nginx позволяют очень просто настроить систему так, что быстрее будет работать на одном сервере, если он не перегружен. Выносить статику смысл есть только если это часть контента и регулярно наполняется (картинки в статьях, аватарки пользователей и т.д.).
                        Для css, js, интерфейсных картинок и прочего, что является частью самого сайта, в этом давно нет смысла.
                          –2
                          Причем тут дохлый сервер или нет? Речь про браузеры. Вот например дефолтные настройки свежего фаерфокса

                          image

                          Если у вас статика будет отдаваться с другого домена (3-го уровня например), то у вас будет 12 одновременных коннектов. Если мелкой статики очень много, то это дает ощутимый выигрыш. Даже можете тот же самый сервер использовать если так уж хочется. Отдавать весь контент с 1 домена — это самый медленный путь.
                            +2
                            Думаю вам стоит почитать про HTTP/2, мультиплексирование и приоритизацию. Простите, но ваша информация про полезность шардинга доменов устарела как минимум на пару лет.
                              –2

                              Зачем спорить, можно просто провести замеры и для хттп/2 в том числе.

                              0
                              Используйте HTTP 2 (а ещё лучше SPDY) и все ваши ресурсы будут загружаться по одному соединению с максимальной скоростью.
                                +1
                                Чем SPDY лучше http2?
                                0
                                Даже если вы по каким-то причинам используете http 1 на сайте, где есть множество мелких запросов, ничего не мешает завести произвольное количество доменов на одном сервере. Второй то зачем?
                                  0

                                  Вы про что вообще? Расшифруйте, пожалуйста, свою мысль.
                                  И вообще — я не уверен, что та указанная опция Мозиллы лимитирует соединения именно на физический сервер (суть есть ip адрес), а по fqdn (т.е. по виртхостам по сути).

                                    +1
                                    лимитируется доменное имя, даже если айпи тот же самый
                                      0
                                      Ну вот, если 4-6 соединений не хватает, то просто делаются несколько виртуальных хостов. Только при использовании http2 это все ненужно уже.
                        +6

                        Извините, а где хранить статические пассивы?

                          0
                          Скажу со стороны параноидального пользователя.
                          Открываю страницу с NoScript, вижу 10-20 отсылок на другие сайты. Ну рекламные режутся сразу, а что касается cloudflare, не очевидно — это cdn ресурса или же это как-то пролезший зловред пытается загрузить payload.
                          Поэтому тоже поддерживаю идею «хранить статику у себя»
                            0
                            Cloudflare, как и некоторые другие CDN, любят ещё вставлять свой js для трекинга, аналитики и прочего, не говоря же что иногда пытаются «оптимизировать» то что получают от сервера (если явно это не отключить, хотя и это не всегда возможно).

                            В итоге иногда возникают совершенно мистические проблемы, которые невозможно воспроизвести, а получить адекватную поддержку от провайдера CDN не всегда возможно (если, конечно, вы не очень ценный клиент), чаще всего всё заканчивается чем-то вроде «вам нужно обновить приложение/сервер до версии X.Y».
                              0
                              CloudFlare имеет множество настроек. И, насколько мне известно, не изменяет контент, если не включить конкретные сервисы, которые делают это. Не знаю, кому эти сервисы помогают (возможно, очень криво настроенным сайтам на wordpress), но проблем создают немало. Однако, их не обязательно использовать, если используется CloudFlare.
                            +3
                            Пожалуйста, прекратите хранить статику на других серверах\чужих доменах — я устал на каждом сайте правила umatrix дополнять.
                              0
                              Универсального решения, в общем, нет.

                              Размещая статические ассеты у себя или на CDN нужно учитывать плюсы и минусы каждого варианта. И принимать решение исходя из баланса плюсов и минусов для конкрентного проекта.

                              А не так, что «все побежали держать все на CDN и я побежал»(с).
                                0

                                Что-то в последнее время на хабре зачастили упоминания jQuery :)

                                  +1
                                  по моему народ часто путает файлохранилище с CONTENT DELIVERY NETWORK.
                                  CDN, ну хорошо, отличный CDN это десятки, сотни, тысячи и даже десятки тысяч серверов по всему миру, который готовы отослать статику или не очень с ближайшего хопа до конечного клиента в кратчайщий путь.

                                  Всегда должен быть ориджин (для валидации и фуллбэка) + CDN, для более менее большого и международного проекта. Иначе пользователя из Австралии заходящие на сайт в ЮК будет чувствовать себя ущербными на скоростях диалапа. Провайдерский раутинг с 400-1000мс на АДЛС все еще реальность, про мобильный интернет можно даже не упоминать, там уже секунды. Без CDN файсбучик и любимый онлайн магазин были бы совсем убоги.
                                    0
                                    Провайдерский раутинг с 400-1000мс на АДЛС все еще реальность, про мобильный интернет можно даже не упоминать, там уже секунды.

                                    Причем, что интересно — это так в цивилизованных странах вроде стран Европы, Uk, США, Австралии и Новой Зеландии. И только в России в каждый дом заходит проводной интернет (*)


                                    (*) по крайней мере в мегаполисах

                                      +1
                                      В Украине с этим еще лучше. Причины те же, но территория более компактная, так что оптика уже в каждом цивилизованном селе. Торренты и прочее пиратство оказало весьма благотворное влияние на отрасль.
                                      В цивилизованных странах только недавно появился смысл в широких каналах. Тогда как у нас даже 15 лет назад вполне было чем забить 100мбит.
                                      0
                                      Все это хорошо, но cdn должен использоваться сайтом, только тогда это эффективно. А если на сайте используется 3-5 подключений к разным cdn (в том числе, разного качества), а потом еще и свои синхронные скрипты, то работать это будет все равно медленнее отдачи всего этого дела в упакованном виде через одно соединение. Как раз таки из-за пинга.
                                        0
                                        Вы забыли еще 5-6 систем аналитики и 6-8 баннерных систем :)
                                          0
                                          ну вы собрали все неграмотные случаи в кучу и конечно же результат будет негативный. А нужно же использовать грамотно и CDN. В разных хостах тоже ничего нет плохого, можно делать dns-prefetch и запускать все асинхронно, тогда загрузка именно страницы и всех ассетов будет в разы быстрей, чем синхронных локальных файлов :)

                                          опять же пинг. Сервер в ЮСА, клиент в Японии, пинги от 300мс и выше. Канал до США не резиновый, выдаст ну 1-10мбит. Подключаем клоудфрант/флайр/акамай и получаем пинги от 1мс до статических ресурсов. И канал до локальных ресурсов от 10мбит

                                          К большому сожалению я не знаю как в России :( Но думаю имеется Российский CDN с кучей хопов для максимальной быстрой доставки контента.
                                        +1

                                        Как по мне, то решение размещать часть статики на сторонних ресурсах — это оптимизация. И как часто бывает — преждевременная. По умолчанию в нынешних реалиях должно быть "всё своё ношу с собой".

                                          0
                                          Ахахахаха только пару часов назад прочитал статью, и тут вот vk.com/wall-145959938_25741

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое