Деплой на краю мережі Cloudflare, що просто працює
Заголовки, редиректи та кешування мають бути на краю мережі, а не в коді застосунку. Погляд на маленькі конфіги, які роблять основну роботу.
Коли статичний сайт деплоїться на Cloudflare Pages, найважливіші файли — не в
каталозі src/, а два звичайні текстові файли в public/, які край мережі
читає напряму.
Редирект на краю, а не в застосунку
Корінь / має вести на /en/. Можна було б згенерувати сторінку-редирект
Astro, але це зайвий перехід до статичного файлу, перш ніж браузер відскочить
далі. Правило _redirects натомість завершується на краю мережі:
/ /en/ 302
Налаштувати безпекові заголовки один раз
Усе, що не може жити в теґу <meta> — HSTS, захист від фреймів, заборона
вгадування MIME — іде у _headers і застосовується краєм мережі до кожної
відповіді:
/*
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
/fonts/*
Cache-Control: public, max-age=31536000, immutable
Ассети з хешем у назві отримують довгий незмінний кеш; шрифти, які не хешуються, — окремо й явно.
Зафіксувати конфіг збірки
Єдиний сценарій збою деплою, від якого варто страхуватися, — це збірка, що
проходить локально, але зависає віддалено. Закомітьте свій wrangler.jsonc, щоб
віддалена збірка використовувала саме той конфіг, який ви тестували, — не дайте
їй вгадувати. Деплой, який не можна відтворити, — це деплой, який ви не
контролюєте.
Спільний принцип усіх трьох пунктів: виносьте конфігурацію на шар, найближчий до користувача, а код застосунку лишайте про контент.