Забезпечення локальних ресурсів JS та CSS для відсидів CDN

Враховуючи це

• CDN - це хороша річ, оскільки вони можуть обслуговувати ресурси ближче до клієнта, клієнт може кешувати їх, а ви можете зменшити навантаження на свій власний сервер.
• У останніх веб-переглядачах завантаження ресурсів із сторонніх серверів не знижує безпеку завдяки Integrity Subresource (SRI) .
• CDN можуть бути відключені або заблоковані в деяких країнах і недоступні при розробці в режимі офлайн ¹ .

Я думаю, що це вимушено використовувати CDN, але також бути готовим до того, що вони будуть недоступними. Ця публікація в блозі дає приємне ознайомлення з різними підходами щодо надання резервних копій. Якщо ви подивитесь на базовий приклад, ви можете побачити, що він вже містить досить багато кодового шаблону, щоб забезпечити резервні копії для лише jQuery та Bootstrap, тоді як прихильне рішення пропонує використовувати Fallback.js , який, здається, значною мірою не відбувся протягом минулого року . Аналогічно, найбільш релевантне питання щодо теми стосується лише надання резервного 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 гарні гроші частково через стійкість і обіцянки угоди про угода про скорочення робочого часу, тому вкладення часу та зусиль на резервні запаси здається марною витратою часу. У нас є план ДР просто на випадок, якщо з нашим провайдером є основна проблема, але це не простий автоматизований процес, і ми побачимо б період відключення, коли ми переходимо на наш резервний CDN.

Тож у відповідь на ваше запитання залежить від того, наскільки цілісним є ваш веб-сайт CDN. Якщо ви вкладаєте в CDN лише ваші активи, і припускаєте, що ваші http-сервери можуть справлятись із завантаженням цього вмісту, то ви можете використовувати конфігураційний перемикач, щоб по суті ввімкнути або вимкнути CDN. У поєднанні з інструментом моніторингу ви можете автоматизувати включення чи вимкнення цього перемикача.

Я бачу 3 дуже важливих причини використання CDN:

1. Скоротити затримку мережі для користувачів у віддалених регіонах. Якщо у вас є веб-сайт для глобальної аудиторії, ваш хостинг у Північній Америці не здається швидким для користувачів у Південній Азії, особливо в Китаї. Різниця у користувацькому досвіді може бути настільки величезною, що це відштовхне користувачів від використання вашого сайту. У цьому випадку мультирегіональний CDN буде важливим для вашого бізнесу.

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

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

Все це означає, що мета CDN - збільшити доступність вашого контенту для кінцевих користувачів. Якщо CDN виходить з ладу або стає повільним з якихось причин, відпадання на стороні клієнта значно збільшить завантаження сторінки, оскільки воно спершу намагатиметься отримати недоступний ресурс. Краще рішення - створити серверний дизайн, який буде робити заміну базової URL-адреси за посиланнями типу "{CDN} /js/jquery-version-min.js". Це дозволить перенаправити трафік на сервер додатків замість CDN, якщо перевірка стану здоров’я CDN не вдасться - клієнти не виконають зайвих запитів і перейдуть безпосередньо до сервера додатків, що буде вашим резервним рішенням на стороні клієнта. Це також вирішить проблему локальних та поетапних розгортань,