Подготовка сайта и оплаты к Чёрной пятнице

Сайты и e-commerce, 8 мин чтения. Автор: Sefa Aydın. Дата публикации: 29 октября 2026.

Коротко: Подготовка сайта к Чёрной пятнице состоит из семи задач: нагрузочный тест, охватывающий настоящую корзину и оплату, кеш и CDN для статических файлов, второй путь оплаты, ускоренная синхронизация остатков, бюджет скорости для страницы кампании, заморозка кода 20 ноября и письменный план связи на случай сбоя. Цель не в том, чтобы вырастить трафик, а в том, чтобы посетитель, которого привела реклама, не потерялся на шаге оплаты.

Какие работы по инфраструктуре сайта нужно сделать перед Чёрной пятницей?

Подготовка инфраструктуры сводится к семи задачам: нагрузочный тест, кеш и CDN, резерв оплаты, синхронизация остатков, скорость страницы кампании, заморозка кода и план на случай сбоя. Как бы удачно ни был распределён рекламный бюджет, сайт, на котором шаг оплаты не отвечает, даст этому бюджету сгореть. Бюджет и календарь описаны в статье план Чёрной пятницы 2026 для интернет-магазина, а готовность магазина проверит бесплатный аудит. Эта статья посвящена только технической стороне.

С точки зрения инфраструктуры выделяются два дня. 11 ноября, день шопинга 11.11, - первый пик и первое настоящее испытание вашей системы, а 27 ноября - основная вершина. Чтобы закрыть до 27 ноября узкие места, которые вы увидите 11.11, отведите период 12-19 ноября. Подробнее о самой дате читайте в руководстве день шопинга 11.11 в 2026 году.

Дата	Работа	Результат
29 октября-4 ноября	Написание сценария нагрузочного теста и первый прогон	Список узких мест с ответственным и датой
5-9 ноября	Исправления кеша, CDN и резерва оплаты	Исправленная среда и тестовый заказ
10 ноября	Заморозка кода к 11.11	Письменное объявление о заморозке
11 ноября	Наблюдение в реальном времени	Почасовая заметка об ошибках и завершении оплаты
12-19 ноября	Закрытие выводов по 11.11 и второй нагрузочный тест	Обновлённый список узких мест
20 ноября	Заморозка кода к Чёрной пятнице	Письменное объявление о заморозке
27-30 ноября	Наблюдение в реальном времени, готовый план на случай сбоя	Журнал инцидентов
1 декабря	Снятие заморозки	Список отката и уборки

Как проводить нагрузочное тестирование сайта?

Нагрузочное тестирование - это заранее измерить, продолжает ли ваш сайт отвечать при заданном числе одновременных пользователей. Тестируйте не главную страницу, а настоящий путь покупателя: страница кампании, страница товара, добавление в корзину, шаг оплаты и подтверждение заказа. Главная может отдаваться из кеша, а корзина и оплата требуют обработки на сервере для каждого пользователя. Основная нагрузка возникает именно там.

Прогнозируя целевой трафик, учитывайте пиковый час прошлого года, результаты 11.11 и дополнительных посетителей, которых принесёт запланированный рекламный бюджет. Задайте цель теста выше этого прогноза и наращивайте нагрузку постепенно, а не мгновенно. Проводите тест на копии рабочей системы и не нагружайте действующий сайт. Отдельно отслеживайте долю ошибок, время ответа и долю завершённых шагов оплаты. Каждое выявленное тестом узкое место внесите в список с ответственным и датой.

Тест не проводится один раз и забывается. Поскольку 11.11 даёт реальные данные о трафике, второй прогон выполните на этих данных в период 12-19 ноября.

Что решают кеширование и CDN в Чёрную пятницу?

Кеш и CDN снижают нагрузку на сервер: вместо того чтобы заново создавать один и тот же файл для каждого посетителя, они отдают готовую копию. По руководству web.dev о CDN, статическое содержимое вроде изображений, видео и версионируемых библиотек можно кешировать надолго. Чтобы CDN мог кешировать ресурс, обычно должен быть задан хотя бы один из заголовков Cache-Control: max-age, Cache-Control: s-maxage или Expires.

Страницы корзины, оплаты и аккаунта персональны. По web.dev, для персональных ответов используется Cache-Control: private, и промежуточные кеши такой ответ не хранят. Неверно настроенный CDN, который покажет одному пользователю корзину другого, обойдётся дороже проблем с нагрузкой. Поэтому проверьте правило настоящим тестовым заказом.

Для часто меняющегося содержимого, такого как цена кампании и остатки, делайте срок кеширования коротким или очищайте кеш в момент обновления. web.dev называет вариантом подход для содержимого, которое меняется с непредсказуемой частотой: кешировать надолго и очищать кеш при обновлении. Остальные шаги по скорости смотрите в руководстве скорость сайта и Core Web Vitals.

Какие резервы подготовить для платёжной инфраструктуры?

Для платёжной инфраструктуры нужно подготовить три резерва: второй путь оплаты, проверенный сценарий 3D Secure и канал связи с платёжным провайдером на день пика. Реклама приводит покупателя, а шаг оплаты - единственное место, где возникает выручка. Зависимость от одного провайдера делает это место единой точкой отказа.

Второй платёжный шлюз или второй провайдер нужен, чтобы заказ не потерялся, если первый выдаст ошибку. Заранее определите, будет ли переключение автоматическим или ручным, одинаковы ли в обоих путях доступные способы оплаты (карты, кошельки, альтернативные способы) и какова разница в комиссии. Проверьте переключение вместе с платёжным провайдером тестовым заказом до запуска.

По EMVCo, 3D Secure - протокол для подтверждения владельца карты при онлайн-платежах, и при рискованных операциях банк-эмитент может запросить дополнительную проверку. Этот шаг вне вашего контроля, а если покупатель здесь потеряется, оплата не завершится. Пробуйте тестовые заказы картами разных банков и на мобильных, проверьте, что видит покупатель, если код подтверждения задерживается. Чтобы форма оплаты оставалась простой, примените шаги из руководства как снизить долю брошенных корзин.

Как синхронизировать остатки и не продать больше, чем есть на складе?

Продажа сверх остатков (оверселл) это продажа товара, которого у вас нет, и чаще всего она возникает из-за задержки синхронизации между сайтом, маркетплейсом и системой учёта. В пиковый день заказы приходят за секунды, поэтому даже при короткой задержке последняя единица может быть продана сразу в нескольких каналах.

Работают три меры. Первая: не открывайте каждому каналу весь остаток, оставьте часть как страховой запас. Вторая: сократите интервал синхронизации на пиковый день и отслеживайте задержку. Третья: проверьте, что при нулевом остатке товар автоматически закрывается на сайте и в рекламном фиде. О распределении между маркетплейсом и собственным сайтом читайте в статье маркетплейс или свой сайт.

Если продажа сверх остатков всё же случилась, напишите покупателю как можно раньше, объясните причину и предложите варианты. Тихая отмена приводит к отзывам и спорам. Текст отмены и уведомления подготовьте заранее.

По каким порогам измерять скорость страницы кампании?

Скорость страницы кампании измеряется порогами Core Web Vitals от Google: LCP должен быть меньше 2,5 секунды, INP меньше 200 миллисекунд, CLS меньше 0,1. Измерение проводится по 75-му процентилю загрузок страницы, отдельно для мобильных и для компьютеров.

В ноябре страница кампании получает больше всего рекламного трафика на сайте, поэтому заведите для неё отдельный бюджет скорости. Не размещайте на странице неоптимизированные изображения высокого разрешения, тяжёлое видео и множество скриптов третьих сторон. Не вставляйте таймер и баннер кампании после загрузки страницы так, чтобы содержимое сдвигалось. Последнее измерение перед заморозкой проведите на настоящем мобильном устройстве.

Когда назначить заморозку кода?

Заморозка кода (code freeze) означает, что с определённой даты на рабочую систему перестают выкладывать новые функции и изменения. Для Чёрной пятницы вечер пятницы 20 ноября оставляет неделю запаса до 27 ноября. Для 11.11 по той же логике можно использовать 10 ноября.

Во время заморозки проходят только критические исправления ошибок, и для каждого есть утверждающий, план отката и запись о тестировании. Работы с содержимым, такие как цена кампании, остатки и тексты, остаются вне заморозки, но подчиняются простому правилу: они делаются в панели управления и не требуют кода. Объявите заморозку команде письменно и снимите её 1 декабря.

Что делать, если сайт упал?

Что делать в первые минуты после сбоя, должно быть записано заранее, потому что принимать решения в кризис значит терять время. Если реклама продолжает работать при недоступном сайте, бюджет уходит впустую. Поэтому первый пункт плана - кто и при каком признаке ставит рекламу на паузу.

Важен и код состояния, который возвращает страница во время сбоя. По документации Google, если нужно закрыть сайт на 1-2 дня, информационную страницу рекомендуется отдавать с кодом состояния 503 и указать время повторной попытки заголовком Retry-After. Google считает ответы 503 и 429 ошибкой сервера и замедляет обход. URL в индексе какое-то время сохраняются, но если ошибка продолжается, они в конце концов выпадут из индекса, поэтому сбой нужно сделать коротким. О проблемах измерения на стороне рекламы читайте в разделе об исключении данных в статье настройки Google Ads и Meta на Чёрную пятницу.

План на случай сбоя должен письменно отвечать как минимум на пять вопросов:

Ответственный: назначен ли человек, который управляет инцидентом, и его замена?
Решение: кто и при каком признаке принимает решение поставить рекламу на паузу?
Связь с клиентами: есть ли готовые тексты для страницы обслуживания, соцсетей и службы поддержки?
Внешние контакты: есть ли у вас экстренные контакты платёжного провайдера и хостинг-компании?
Возврат: есть ли план включения рекламы после устранения проблемы и напоминаний о брошенных корзинах?

Какие показатели отслеживать в пиковый день?

В пиковый день отслеживайте на одном экране шесть показателей: число заказов в минуту, долю завершённых шагов оплаты, время ответа сервера, долю ошибок, задержку синхронизации остатков и отношение расхода на рекламу к потоку заказов. Ухудшение одного из них предупредит раньше остальных. Заранее запишите пороги, например: когда доля завершённой оплаты упадёт ниже обычного дня, кто кому позвонит. Проверьте тестовым заказом, что теги измерения работают верно, иначе вы можете по ошибке остановить кампанию, заказы которой не видны в панели.

Часто задаваемые вопросы

Когда проводить нагрузочный тест сайта перед Чёрной пятницей?

Первый прогон проведите до 11.11, второй - на данных 11.11 в период 12-19 ноября. Тестируйте не главную страницу, а настоящий путь покупателя со страницей кампании, корзиной и шагом оплаты, ставьте цель выше пикового часа прошлого года и запускайте тест на копии рабочей системы.

Когда начинать заморозку кода?

Мы рекомендуем вечер пятницы 20 ноября для Чёрной пятницы и 10 ноября для 11.11. Во время заморозки проходят только критические исправления ошибок, и для каждого ведутся утверждение, план отката и запись о тестировании. Снимите заморозку 1 декабря.

Какой код состояния должна возвращать страница ошибки, если сайт упал?

Если сбой временный, нужно возвращать 503. По документации Google, при отключении на 1-2 дня информационная страница отдаётся с кодом 503, а время повторной попытки можно указать заголовком Retry-After. Google считает ответы 503 и 429 ошибкой сервера, и если ошибка продолжается, URL в индексе в конце концов могут выпасть.

Должен ли CDN кешировать страницы корзины и оплаты в Чёрную пятницу?

Нет. Страницы корзины, оплаты и аккаунта персональны, и их нужно держать вне промежуточных кешей с помощью Cache-Control: private. Кешировать нужно статические файлы: изображения, CSS и JavaScript. Проверьте правило тестовым заказом.

Нужен ли второй путь оплаты?

Поскольку шаг оплаты - единственное место, где возникает выручка, зависимость от одного провайдера создаёт единую точку отказа. Второй платёжный шлюз или провайдер не даёт заказу потеряться, если первый выдаст ошибку. До запуска определите, будет ли переключение автоматическим или ручным, какие способы оплаты доступны в обоих путях и какова разница в комиссии.

Как не продать больше, чем есть на складе?

Не открывайте каждому каналу весь остаток, оставьте часть как страховой запас. Сократите интервал синхронизации на пиковый день и проверьте, что при нулевом остатке товар автоматически закрывается на сайте и в рекламном фиде. Если продажа сверх остатков всё же случилась, напишите покупателю заранее, с причиной и вариантами.

Как подготовить сайт и платёжную инфраструктуру к трафику Чёрной пятницы?