Firebase Hosting: быстрый старт для статических сайтов

Логотип Firebase

Быстрые ссылки

Что такое «статический» сайт?
Настройка развертывания Firebase
Привязка пользовательского домена и HTTPS
Чек-лист развертывания и отката

Что такое «статический» сайт?

Термин «статический» не означает устаревший дизайн. Статический сайт — это набор неизменяемых файлов (HTML, CSS, JS, изображения), которые сервер отдает как есть. Однофайловые приложения (SPA) на React, Vue или Svelte по-прежнему могут считаться статическими: сами файлы загружаются статично, а динамика реализуется на стороне клиента.

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

Почему статический подход популярен:

Простота развертывания и масштабирования.
Быстрая отдача через CDN.
Меньше рисков безопасности по сравнению с исполнением кода на сервере.
Удобство для сайтов документации, маркетинговых лендингов, блогов на статическом генераторе.

Когда статический сайт не подходит:

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

Важно: статическое не равно без JavaScript. JavaScript может динамически изменять страницу уже на клиенте.

Краткая модель принятия решения

Mermaid-диаграмма для выбора хостинга:

flowchart TD
  A[Нужен сайт] --> B{Динамика на сервере?}
  B -- Да --> C[Рассмотрите серверный хостинг или серверлесс 'Cloud Run, App Engine']
  B -- Нет --> D[Статический хостинг]
  D --> E{Нужен CDN и простота?}
  E -- Да --> F[Используйте Firebase Hosting / Netlify / Vercel]
  E -- Нет --> G[Просто S3/Cloud Storage + Load Balancer]

Требования и подготовка: GCP проект и Firebase CLI

Зарегистрируйте проект в Google Cloud Console (GCP). Firebase использует проект GCP под капотом.

Создать новый проект в GCP

Скачайте Firebase CLI для вашей ОС и запустите команду в терминале, чтобы войти и связать CLI с Google-аккаунтом:

firebase

Команда откроет браузер для аутентификации. Затем перейдите в каталог с кодом сайта и инициализируйте проект:

cd path/to/your/site
firebase init

Выберите функцию “Hosting” при инициализации.

Запуск firebase init

При выборе опции укажите добавление Firebase в существующий проект GCP или создайте новый. На практике иногда удобнее заранее создать проект в GCP, затем выбрать его в процессе инициализации.

Создать проект при настройке

Выберите публичную директорию (по умолчанию “public”). Если это SPA, ответьте «да» на вопрос об обработке маршрутов, чтобы все запросы переадресовывались на индексный файл.

Настройка хостинга

Первый деплой и последующие обновления

После настройки вы можете развернуть сайт:

firebase deploy

Эта команда синхронизирует локальную публичную директорию с Firebase Hosting.

Развернуть сайт командой firebase deploy

Адрес по умолчанию: projectname.web.app (или проект.web.app). Для обновлений повторяйте firebase deploy — изменения обычно видны менее чем через минуту.

Привязка пользовательского домена и DNS

Чтобы сайт был под вашим доменом, используйте консоль Firebase: выберите проект → Hosting → Add Custom Domain.

Настроить пользовательский домен

Firebase выдаст TXT-запись для подтверждения владения. Добавьте её у регистратора домена (Namecheap, Google Domains и др.) в разделе DNS.

Добавить TXT-запись у регистратора

После верификации Firebase предложит A-записи (IP-адреса). Замените существующие A-записи на те, которые предоставлены Firebase:

Заменить существующие A-записи

В течение нескольких минут сайт может показывать предупреждение о HTTPS — Firebase автоматически выдаст бесплатный SSL-сертификат и установит HTTPS.

Важно: время распространения DNS зависит от TTL у регистратора; иногда требуется несколько часов.

Пример firebase.json для SPA и маршрутов

Пример конфигурации, которая перенаправляет все запросы на index.html (нужно для клиентского роутинга):

{
  "hosting": {
    "public": "public",
    "ignore": ["firebase.json", "**/.*", "/node_modules/"],
    "rewrites": [
      { "source": "", "destination": "/index.html" }
    ]
  }
}

Сохраните файл в корне проекта перед firebase deploy.

Безопасность, кеширование и производительность

HTTPS: Firebase автоматически выдаёт бесплатные SSL-сертификаты. Не требуется ручная настройка.
Заголовки безопасности: добавляйте заголовки через headers в firebase.json для Content Security Policy, HSTS и т. п.
Кеширование: Firebase предлагает конфигурацию заголовков Cache-Control. Для статических активов (CSS, JS, изображения) указывайте долгий срок кеширования и версионирование имени файла (hash в имени). Для index.html используйте короткий срок или no-cache.

Пример блока headers:

"headers": [
  {
    "source": "/static/",
    "headers": [
      { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
    ]
  },
  {
    "source": "/index.html",
    "headers": [
      { "key": "Cache-Control", "value": "no-cache" }
    ]
  }
]

Стоимость и лимиты

Firebase Hosting предлагает бесплатный уровень, который подходит для небольших сайтов и тестовых проектов. Для роста учтите стоимость передачи данных и дополнительные сервисы (хранилище, функции). Если трафик высок, возможно, придётся платить за использование GCP и сетевых ресурсов.

Важно: не придумывайте метрик — проверяйте актуальные цены в консоли GCP и на странице тарифов Firebase.

Отладка и частые проблемы

DNS не распространяется: проверьте TTL у регистратора, используйте dig/nslookup для проверки.
SSL не активен: подождите несколько минут; если проблема не уходит — проверьте, правильно ли настроены A-записи.
SPA показывает 404 при перезагрузке страницы: убедитесь, что в firebase.json настроены rewrite на index.html.
Старые файлы кешируются: проверьте Cache-Control для index.html, используйте versioned filenames для ресурсов.

Полезные команды для диагностики:

firebase deploy --only hosting
firebase hosting:channel:deploy staging
firebase hosting:sites:list

Чек-лист перед первым релизом

[ ] Инициализировать проект через firebase init.
Проверить структуру публичной директории (index.html, assets).
Добавить firebase.json с нужными rewrite/headers.
Локально проверить SPA и маршруты.
[ ] Выполнить firebase deploy и проверить работоспособность на project.web.app.
Привязать пользовательский домен и добавить TXT запись для верификации.
Обновить A-записи у регистратора.
Проверить HTTPS и заголовки безопасности.

План отката и версия релиза

Рекомендуемый простой план отката:

Всегда храните рабочую сборку в репозитории/CI и в артефактах (например, в Git tag или в хранилище артефактов).
При необходимости отката — разверните предыдущую версию из стабильной папки/тега: распакуйте прежнюю версию в public и выполните firebase deploy.
Для критических ошибок: временно включите maintenance-страницу (index.html с сообщением) и быстро исправьте код.

Критерии приёмки перед деплоем:

Отсутствуют console.error в ключевых сценариях.
Маршруты работают после перезагрузки.
Формы и внешние API корректно отвечают.
HTTPS активен и нет смешанного контента.

Альтернативы Firebase Hosting

Vercel: простой деплой из Git, хорош для фронтенд‑фреймворков.
Netlify: поддержка билдов, CI и функций на краю.
AWS S3 + CloudFront: гибкость и масштабирование, требует больше настроек.
Google Cloud Storage + Load Balancer: корпоративный вариант для больших сайтов.

Выбор зависит от удобства интеграции с вашим CI/CD, требований к кешированию и бюджету.

Роли и задачи: кто за что отвечает

Разработчик: настраивает firebase.json, собирает приложение, фиксирует versioned assets.
Девопс/инженер платформы: проверяет DNS, SSL, лимиты проекта GCP, мониторинг.
Тестировщик: прогоняет сценарии восстановления сессий, маршрутизации и проверки кеширования.
Владелец продукта: подтверждает работу на пользовательском домене и корректность контента.

Когда статический подход не подойдёт (примеры)

Билеты с приватной информацией должны рендериться на сервере и не попадать в публичный HTML.
Если нужна серверная агрегация данных по запросу нескольких API с персональными данными.
Онлайн-редактор с сохранением в реальном времени и сложной логикой авторизации — лучше серверлесс или полноценный сервер.

Маленький глоссарий

SPA: single-page application — приложение, где навигация выполняется на клиенте.
CDN: content delivery network — сеть доставки контента ближе к пользователю.
TTL: time to live — время распространения DNS-записи.
A-record: запись DNS, которая указывает домен на IP-адрес.

Итог и следующий шаг

Firebase Hosting — удобный старт для проектов, которые могут быть выражены набором статических файлов и клиентской логики. Он даёт быстрый путь от кода до публичного сайта, бесплатный SSL и интеграцию с другими продуктами Google. Когда требования усложняются, легко комбинировать Firebase с Cloud Functions, Firestore или внешними API.

Краткие рекомендации:

Для SPA: настроить rewrite на index.html.
Для производительности: использовать versioned assets и правильные Cache-Control.
Для безопасности: настроить заголовки CSP и HSTS.

Notes: если у вас специфические ограничения или высокий трафик, предварительно проверьте тарифы GCP и лимиты проекта.

Ссылки и дальнейшее чтение

Документация Firebase Hosting (в консоли Firebase)
Руководства по настройке DNS у популярных регистраторов

Ключевые выводы:

Статический сайт — это набор неизменяемых файлов, но он может быть динамичным на клиенте.
Firebase упрощает деплой и автоматически управляет SSL.
Для SPA нужны правила rewrite; для производительности — правильные заголовки кеширования.
При росте трафика проверяйте тарифы GCP и переходите на более гибкие решения при необходимости.

Статический хостинг на Firebase — настройка и рекомендации