frontend · starter · 3d
Деплой статической страницы
Проведи статическую HTML/CSS-страницу от файла на диске до публичного URL деплоем который можно перезапускать — твоя первая настоящая поставка без шага сборки.
Результат
Статический сайт задеплоен на публичный URL повторяемым деплоем (Cloudflare Pages / Netlify / GitHub Pages) с заголовками кеша, страницей 404 и зелёным CWV в Lighthouse.
Этапы
0/4 · 0%- 01Подготовь и предпросмотри локально
Подготовь минимальную папку статического сайта: index.html, подключённый style.css, одну картинку с явными width/height и 404.html. Раздавай локально статическим сервером (например, npx serve или python -m http.server) — не открытием file:// — чтобы относительные ссылки, MIME-типы и обработка 404 вели себя как в проде. Открой на localhost и проверь отсутствие ошибок консоли, зарезервированное место под картинку (нет layout shift при загрузке) и показ 404.html на несуществующем пути при раздаче. Это артефакт который будешь деплоить; если он работает локально через сервер — заработает и удалённо.
Критерии готовности- Папка с index.html + style.css + картинкой (явные размеры) + 404.html раздаётся локально статическим сервером и грузится без ошибок консоли.
- Переход на несуществующий путь отдаёт 404.html (различие 200 vs 404 корректно для хоста) и картинка не вызывает CLS.
Самопроверка
Покажи локальную раздачу без ошибок консоли и обработку 404. Ревьюер проверяет явные размеры картинки и что предпросмотр не через file://.
- 02Задеплой на публичный URL
Задеплой папку на реальный хост — Cloudflare Pages (wrangler pages deploy), Netlify (drag-and-drop или CLI) или GitHub Pages — и получи публичный https:// URL. Деплой должен быть повторяемым: одна команда или git push пере-деплоит без ручных кликов по дашборду которые нельзя воспроизвести. Проверь что URL доступен с другого устройства (не только с твоего localhost) и что задеплоена именно та папка что превьюил локально (никакой скрытый шаг сборки не трансформирует её). Сохрани URL — это deliverable.
Критерии готовности- Сайт живёт на публичном https:// URL повторяемым деплоем (CLI-команда или git push) — проверено со второго устройства или инкогнито.
- Повтор той же команды деплоя обновляет живой сайт без ручных шагов в дашборде.
Самопроверка
Покажи публичный URL и повторяемую команду деплоя (не просто скрин дашборда). Ревьюер проверяет https URL и воспроизводимость деплоя.
- 03Заголовки кеша и полировка 404
Настрой правильное кеширование и сделай страницу 404 полезной. Статика с хешированными именами (если есть) может кешироваться на год (immutable), но index.html никогда нельзя кешировать надолго — иначе посетители продолжат видеть старую версию после фикса. На большинстве статических хостов это автоматически (хешированная статика → долгий кеш, html → no-cache), но проверь curl -I: сравни Cache-Control на index.html и ресурсе. Отполируй 404 чтобы она ссылалась на главную и объясняла что случилось — пустая 404 — тупик. Проверь оба: curl ресурса и index.html и сравни заголовки.
Критерии готовности- curl -I на index.html показывает no-cache / короткий кеш; на хешированном ресурсе (или картинке) — долгий immutable кеш, заголовки проверены и задокументированы.
- Страница 404 оформлена, ссылается на главную и возвращает статус 404 (не 200) на отсутствующем пути.
Самопроверка
Покажи curl -I заголовков index.html vs ресурса и страницу 404 с 404. Ревьюер проверяет корректность Cache-Control по типу файла.
- 04Lighthouse и CWV
Измерь задеплоенный сайт Lighthouse (mobile) и почини всё красное. Зафиксируй LCP (<2.5с), CLS (<0.1) и проверки доступности: контраст ≥4.5:1, alt-текст, видимый фокус клавиатуры. Типичные провалы первого деплоя: неоразмеренное hero-изображение даёт CLS, веб-шрифт без font-display: swap блокирует LCP, отсутствие alt или низкий контраст валит a11y. Почини в исходниках, пере-деплой той же повторяемой командой и покажи как оценки зеленеют. Урок — деплой не финиш, измерение — финиш.
Критерии готовности- Lighthouse mobile на публичном URL показывает LCP < 2.5с, CLS < 0.1 и нет критических провалов a11y — оценки до/после зафиксированы если требовался фикс.
- Пере-деплой после фикса той же повторяемой командой и новые оценки зелёные.
Самопроверка
Покажи публичный отчёт Lighthouse (LCP/CLS/a11y) до и после фиксов если были. Ревьюер проверяет что URL — задеплоенный и цели CWV достигнуты.
Стартер
fallowlone/skein-projects
projects/static-page-deploy
- README.md
- artifact/index.html
- artifact/style.css
- src/page.ts
- test/page.test.ts
npx degit fallowlone/skein-projects/projects/static-page-deploy static-page-deploy Реализуй заглушки, затем гоняй тесты, пока не позеленеют: bun test
Форкни репозиторий и запушь свою работу — workflow grade прогонит тесты и статические проверки на твоих раннерах.
Рубрика
| Джуниор | Миддл | Сеньор | |
|---|---|---|---|
| Повторяемый деплой | Сайт задеплоен но только ручными кликами по дашборду ненадолго воспроизводимыми из терминала. | Одна CLI-команда или git push пере-деплоит ту же папку; публичный URL — https и доступен с другого устройства. | Деплой CI-готов (может запускаться на push) и артефакт — та же папка что превьюилась локально, скрытый шаг сборки её не меняет. |
| Кеш и корректность 404 | Сайт жив но заголовки кеша не проверены и страница 404 пустая или отдаёт 200. | index.html no-cache, статика долгий кеш (или различие задокументировано), 404 отдаёт 404 с ссылкой на главную. | Может объяснить почему хеширование имён позволяет immutable кеш и почему долгий кеш на index.html ломает деплои. |
| CWV и a11y | Сайт грузится но LCP/CLS/a11y не измерены. | Lighthouse показывает LCP < 2.5с, CLS < 0.1, без критических проблем a11y, всё красное починено и пере-деплоено. | Может назвать какой ресурс определил каждый CWV (hero-картинка для LCP, размеры для CLS) и что сломает бюджет при будущем изменении. |
Эталонный разбор (спойлер)
Почему no-cache на index.html: HTML — точка входа ссылающаяся на хешированные ресурсы. Если сам HTML кешируется надолго, деплой меняющий HTML и хеши оставляет посетителей на старом HTML указывающем на старые хеши — они не увидят фикс пока кеш HTML не истечёт.
Почему file:// не превью: протокол file имеет другие правила origin, CORS и MIME-типов чем http. Сайт работающий через file:// всё равно может сломаться при раздаче — относительные ссылки, обработка 404 и импорты модулей ведут себя иначе. Всегда превьюй через статический сервер.
Сделай по-сеньорски
- Добавь кастомный домен с https и редирект с apex на www (или наоборот) чтобы у сайта был запоминаемый URL.
- Добавь файл _headers или _redirects чтобы задать явные Cache-Control и заголовки безопасности (X-Content-Type-Options, Referrer-Policy).