Предоставление локальных ресурсов JS и CSS для откатов CDN

При условии

• CDN - это хорошая вещь, потому что они могут обслуживать ресурсы ближе к клиенту, клиент может их кэшировать, и вы можете уменьшить нагрузку на свой собственный сервер.
• В последних браузерах загрузка ресурсов со сторонних серверов не снижает безопасность благодаря Subresource Integrity (SRI) .
• CDN могут быть недоступны или заблокированы в некоторых странах и недоступны при разработке в автономном режиме ¹ .

Я думаю, что это является обязательным для использования CDN, но и быть готовым к тому, что они будут недоступны. Этот блог дает хорошее представление о различных подходах к предоставлению запасных вариантов. Если вы посмотрите на базовый пример, то увидите, что он уже содержит довольно много стандартного кода для обеспечения откатов только для jQuery и Bootstrap, в то время как предпочтительное решение предлагает использовать Fallback.js , который, по-видимому, практически не поддерживается в прошлом году. , Точно так же, наиболее актуальный вопрос SO для данной темы касается только предоставления запасного варианта для jQuery.

Тем не менее, в большинстве реальных проектов я бы ожидал иметь 5 или более ресурсов js / css, поэтому я чувствую, что вам не нужно повторять какой-то грязный шаблон, чтобы обеспечить запасные варианты для всех из них. Кроме того, каждый раз, когда вы добавляете или обновляете ресурс, вы должны

• Обновите ссылку CDN
• Обновите локальную резервную копию путем ручной загрузки или изменения версии в конфигурации npm / bower.
• Обновите ссылку на запасной вариант
• Обновите хэш SRI

В то время как в идеальном мире я ожидал бы добавить / обновить ресурс в одном файле конфигурации, а все остальные шаги выполнить автоматически (а затем запустить тесты, чтобы выяснить, не сработало ли обновление).

Есть ли уже установленный рабочий процесс для достижения этой цели?

Или CDN, и особенно SRI, еще слишком новы?

Или большинство людей просто не хотят предоставлять запасные варианты для ресурсов CDN?

_{1. Хотя у вас может быть сборка для разработчиков, которая не зависит от CDN, но я также считаю, что это форма запасного варианта, поскольку ее также необходимо поддерживать.}

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

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

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

Если CDN дает сбой, и вы начинаете получать весь трафик, передаваемый на ваш веб-сервер, он может упасть, иначе вам действительно не понадобится CDN.

Сайт, над которым я работаю на нашем CDN, становится все более важным для сайта. В начале мы просто использовали его для кэширования изображений / CSS / JS. На этом этапе у нас было свойство config, которое переписывало имя хоста этих ресурсов с www.mysite.com/ на www.cdn.com/, поэтому, если CDN вышел из строя, мы могли бы просто изменить это значение хоста или полностью его отключить и оставить URL-адреса, указывающие на наш веб-сервер.

Однако теперь мы перешли к кешированию в основном целых страниц с персонализированным контентом, загружаемым через AJAX. Наше CDN стало необходимым для нашего сайта, и мы могли бы работать без него так же, как наши собственные HTTP-серверы. Мы платим нашим CDN хорошие деньги отчасти из-за их устойчивости и SLA, обещающих время безотказной работы, поэтому откладывание времени и усилий на запасные варианты кажется пустой тратой времени. У нас действительно есть план аварийного восстановления, только если есть серьезная проблема с нашим провайдером, но это не простой автоматизированный процесс, и мы увидим период простоя, когда мы перейдем к нашей резервной CDN.

Таким образом, в ответ на ваш вопрос это зависит от того, насколько неотъемлемой частью вашего сайта является CDN. Если вы просто помещаете свои ресурсы в CDN и предполагаете, что ваши http-серверы могут справиться с нагрузкой при доставке этого контента, то вы можете использовать переключатель конфигурации, чтобы по существу включить или выключить CDN. В сочетании с инструментом мониторинга вы можете автоматизировать включение или выключение этого переключателя.

Я вижу 3 очень важных причины для использования CDN:

1. Уменьшите задержку сети для пользователей в отдаленных регионах. Когда у вас есть веб-сайт для глобальной аудитории, ваш хостинг в Северной Америке не будет быстрым для пользователей в Южной Азии, особенно в Китае. Разница в пользовательском опыте может быть настолько огромной, что это отговорит пользователей от использования вашего сайта. В этом случае мультирегиональный CDN будет иметь важное значение для вашего бизнеса.

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

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

Все это означает, что целью CDN является повышение доступности вашего контента для конечных пользователей. Если CDN дает сбой или становится медленным по какой-то причине, откат на стороне клиента значительно увеличит загрузку страницы, потому что он сначала попытается получить ресурс, который недоступен. Лучшее решение - иметь дизайн на стороне сервера, который будет выполнять замену базового URL в ссылках типа "{CDN} /js/jquery-version-min.js". Это позволит перенаправить трафик на сервер приложений вместо CDN, если проверка работоспособности CDN не удалась - клиенты не будут выполнять ненужные запросы и перейдут непосредственно к серверу приложений, что может стать вашим запасным вариантом с решением на стороне клиента. Это также решит проблему локального и промежуточного развертывания,