Skip to main content
Назад к блогу
3 мин чтения

23 пункта предзапускового чеклиста, который я прогоняю перед каждым клиентским запуском

Каждый клиентский проект получает этот чеклист перед запуском. 23 пункта по безопасности, производительности, SEO, мониторингу и юридическим вопросам. Большинство занимают 5 минут. Вместе предотвращают 90% послезапусковых пожаров.

performancesecurity

Каждый проект, который я шиплю, получает один и тот же чеклист перед запуском. Прогон занимает 2–3 часа. Он находил проблемы на каждом проекте без исключения.

Вот все 23 пункта в порядке прогона.

Безопасность (пункты 1–6)

  1. Переменные окружения не в клиентском бандле. Поищите API-ключи в собранном JS. Если они там — утечка. Только NEXT_PUBLIC_* переменные должны быть видны клиенту.

  2. Auth-токены истекают. Бесконечно живущие токены — самая частая проблема безопасности. Сессионные токены: 24ч–7д. Refresh-токены: максимум 30д.

  3. Rate limiting на auth-эндпоинтах. Логин, регистрация, сброс пароля — всё должно иметь лимиты. 5 попыток в минуту на IP — разумный дефолт.

  4. CORS настроен корректно. Access-Control-Allow-Origin: * в продакшне — уязвимость. Вайтлист конкретных доменов.

  5. Нет секретов в git-истории. Если секреты когда-либо были закоммичены — ротируйте их.

  6. CSP-заголовки установлены. Content Security Policy предотвращает XSS-атаки.

Производительность (пункты 7–12)

  1. Lighthouse выше 90 на мобильном. Запускайте на продакшн-URL, не localhost. Я писал о достижении 98 — базовый уровень должен быть 90+.

  2. Изображения оптимизированы. WebP или AVIF. Правильные width/height. Только hero-изображение с priority. Ни одно изображение больше 200КБ при начальной загрузке.

  3. Шрифты селф-хостинг. Никаких ссылок на Google Fonts. WOFF2 с font-display: swap. Это предотвращает падение Lighthouse, которое я отлаживал.

  4. Нет ресурсов, блокирующих рендер. Проверьте аудит Lighthouse «Eliminate render-blocking resources».

  5. Страницы ошибок возвращают правильные статус-коды. curl -I yoursite.com/nonexistent должен вернуть 404, не 200.

  6. Время ответа API до 500мс (p95). Любой эндпоинт выше 500мс требует расследования.

SEO (пункты 13–17)

  1. Сайтмап существует и возвращает XML. Это реальный баг, который я ловил.

  2. robots.txt корректен. Разрешает / и указывает на сайтмап.

  3. Каждая страница имеет уникальный title и meta description. Описания до 155 символов с основным ключевым словом.

  4. hreflang-теги для мультиязычных сайтов. Каждая страница перечисляет все языковые альтернативы.

  5. Структурированные данные валидны. Тестируйте JSON-LD через Rich Results Test от Google.

Мониторинг (пункты 18–20)

  1. Трекинг ошибок настроен. Sentry с фильтрацией шума или аналог.

  2. Мониторинг аптайма активен. Внешний пинг каждые 5 минут.

  3. Аналитика собирает данные. Посетите сайт, проверьте дашборд через 5 минут.

Юридическое (пункты 21–22)

  1. Политика конфиденциальности опубликована и слинкована из футера. Гайд по GDPR-сетапу.

  2. Согласие на куки (если нужно). Только если используете куки для аналитики.

Финальный (пункт 23)

  1. Купите свой продукт. Если есть платёжный флоу — купите что-то реальной картой. Один этот тест ловит больше интеграционных проблем, чем 50 автотестов. Я усвоил это на собственном опыте.

Как я использую этот список

Прогоняю на стейджинге за 2 дня до запуска. Проваленные пункты исправляются в день 1. День 2 — повторный прогон проваленных + полный ручной обход основного пользовательского флоу.

В день запуска повторно прогоняю пункты 13, 18, 19, 20 и 23 на продакшн-URL. Это те, которые чаще всего ломаются при переходе стейджинг → продакшн.

Весь процесс: 2–3 часа на начальный прогон, 1 час на перепроверку в день запуска. Сравните с 20+ часами, потраченными на тушение послезапусковых пожаров, которые любой из этих пунктов бы предотвратил.

Хотите, чтобы этот чеклист был прогнан на вашем проекте перед запуском? Напишите — я прогоняю его на каждом клиентском запуске, и он спас каждого из них минимум от одного послезапускового инцидента.