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+ годинами, витраченими на гасіння післязапускових пожеж, які будь-який з цих пунктів запобіг би.

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