Подготовка сайта к нагрузке начинается за 4-6 недель до старта распродаж, а не в ночь перед акцией - это правило я соблюдаю жёстко для всех клиентов с выраженной сезонностью: интернет-магазины перед Чёрной пятницей, флористы перед 8 марта, турагентства перед летом. Если сайт падает в момент пика трафика, теряются не только заказы этого часа. Реклама и рассылки продолжают гнать людей на упавшую страницу, а поисковики фиксируют рост времени ответа и на пару недель проседают в выдаче.
Почему подготовка сайта к нагрузке - не разовая задача перед распродажей
Типичный сценарий, с которым сталкиваюсь на практике: магазин весь год держит 200-400 визитов в сутки, сервер справляется без проблем, а в первый день распродажи трафик подскакивает в 8-10 раз за счёт рассылки, рекламы и партнёрских ссылок. Хостинг, рассчитанный на обычную нагрузку, не падает мгновенно - он начинает тормозить: страницы грузятся по 5-7 секунд, форма заказа отправляется с третьей попытки, СДЭК-виджет с расчётом доставки зависает. Конверсия проседает даже без явного отказа сервера, просто потому что часть посетителей не дожидается загрузки.
Вторая причина держать подготовку на регулярной основе - сезонность редко ограничена одним днём. Черная пятница растягивается в акцию на неделю, а следом идёт предновогодний период с ещё большим трафиком. Разовая настройка под один день распродажи не защищает от накопительного эффекта: база разрастается заказами, логи переполняют диск, кэш устаревает быстрее, чем обновляется.
Хостинг и серверные ресурсы: проверка запаса прочности
Первое, что смотрю у клиента - тип хостинга и то, как он масштабируется под нагрузкой. Общий (shared) хостинг для сезонного пика почти всегда узкое место: там нет возможности быстро добавить ресурсы, а сосед по серверу может забрать процессорное время в самый неподходящий момент.
| Тип хостинга | Поведение под пиковой нагрузкой | Когда подходит |
|---|---|---|
| Shared-хостинг | Деградация уже при 3-5‑кратном росте трафика | Сайт-визитка без сезонных всплесков |
| VPS фиксированной конфигурации | Держит нагрузку до предела ресурсов, дальше - очередь запросов | Магазин с прогнозируемым пиком, ресурсы взяты с запасом |
| Облако с автомасштабированием | Добавляет мощность по метрикам CPU/RAM в реальном времени | Непредсказуемые всплески, крупные распродажи |
Если сайт стоит на VPS, за две-три недели до сезона поднимаю лимиты по CPU и RAM минимум вдвое от текущего использования в обычный день - фактическая нагрузка в пик обычно кратна росту трафика, а не линейна к нему из-за одновременных запросов к базе. Отдельно проверяю лимит одновременных соединений в PHP-FPM или Node - дефолтные значения хостинг-панелей (обычно 5-10 воркеров) захлёбываются уже при паре десятков одновременных пользователей на странице оформления заказа.
Оптимизация кода и базы данных перед пиковыми нагрузками
Сервер с запасом ресурсов не спасает, если код сайта делает лишние запросы к базе на каждой странице. На WooCommerce и на самописных решениях на Laravel я в первую очередь проверяю кэширование: включён ли объектный кэш (Redis или Memcached), кэшируются ли фрагменты каталога, стоит ли CDN для статики и изображений товаров. Без кэша каждая загрузка карточки товара - это 15-30 запросов к MySQL, и при параллельных сессиях база становится узким местом раньше, чем процессор сервера.
WooCommerce и Tilda - типичные узкие места
В WooCommerce перед сезоном отключаю или переношу в фоновые задачи тяжёлые хуки - пересчёт остатков на каждое действие, синхронизацию с 1С в реальном времени, лишние плагины аналитики, которые дергают внешние API синхронно при загрузке страницы. Один клиент с интернет-магазином на 3000+ товаров держал синхронизацию остатков с 1С на каждый просмотр товара - при обычном трафике это было незаметно, а в первый час распродажи очередь запросов к 1С забила канал и половина карточек товаров грузилась дольше 10 секунд.
На Tilda ситуация другая: сама платформа выдерживает нагрузку неплохо, а тормозят кастомные скрипты - виджеты расчёта доставки СДЭК, формы с внешней валидацией, интеграции с CRM через синхронные запросы. Перед сезоном стоит прогнать через DevTools вкладку Network при заполненной корзине и посмотреть, какие внешние запросы блокируют отрисовку страницы - обычно можно перевести часть на асинхронную загрузку без потери функциональности. Если нужна доработка именно кастомных скриптов под нагрузку, у меня это отдельная услуга - можно посмотреть на странице с услугами, что входит в доработку и интеграции для Tilda.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Приём платежей и логистика под нагрузкой: эквайринг и СДЭК
Оформление заказа - самое чувствительное место сайта в сезон, потому что там сходятся сразу три внешних сервиса: платёжный шлюз, расчёт доставки и уведомления. Виджет Т‑Банка (T‑Bank) для приёма платежей на WooCommerce обычно работает стабильно, но я всегда проверяю таймауты обращения к API эквайринга - если стоит значение по умолчанию в 30 секунд, а сервер банка в пиковые часы отвечает медленнее обычного, пользователь видит зависшую страницу оплаты вместо честной ошибки с предложением повторить попытку.
С СДЭК похожая история: виджет расчёта стоимости доставки по ПВЗ делает запрос к внешнему API на каждое изменение адреса. При высокой одновременной нагрузке на сайт это увеличивает время ответа формы заказа, а если у СДЭК в моменте плановые технические работы - форма может не отвечать вовсе. Разумный подход - кэшировать расчёт по городу на 15-30 минут и предусмотреть fallback: если внешний API не отвечает за 3-5 секунд, показывать фиксированную стоимость доставки с уточнением после оформления, а не блокировать заказ полностью.
Нагрузочное тестирование: как проверить сайт до старта сезона
Все перечисленные меры без проверки под реальной нагрузкой - это гипотезы. За неделю до сезона прогоняю нагрузочный тест инструментом вроде k6 или Apache Bench, эмулируя ожидаемый трафик умноженный на 1.5-2 для запаса.
k6 run --vus 150 --duration 5m load-test.jsВ сценарий теста включаю не только главную страницу, а полный путь пользователя: каталог, карточка товара, добавление в корзину, оформление заказа с расчётом доставки. Именно на этом пути обычно всплывают проблемы, которые не видны при простом пинге главной. По результатам смотрю на три метрики: время ответа 95-го перцентиля (должно укладываться в 1-2 секунды), процент ошибок 500 и 504, и загрузку базы данных - если CPU базы уходит за 80% при тестовой нагрузке, в реальный пик она станет узким местом раньше сервера приложения.
Мониторинг и план действий во время пиковых нагрузок
Подготовка не заканчивается стартом распродажи - важно видеть состояние сайта в реальном времени и иметь план, что делать при первых признаках деградации. Настраиваю связку мониторинга через n8n: сценарий каждые 1-2 минуты проверяет время ответа ключевых страниц и статус базы данных, и при превышении порога отправляет уведомление в Telegram через бота на aiogram - это быстрее, чем ждать жалоб от клиентов в поддержке.
В плане действий на случай пика прописываю заранее: кто отключает второстепенные фоновые задачи (импорт остатков, рассылки), кто масштабирует ресурсы сервера вручную, если автомасштабирование не настроено, и на какую страницу переключить трафик, если основной сайт всё же ляжет - обычно это упрощённая статическая страница с телефоном и мессенджером для приёма заказов. Готовые шаблоны такого мониторинга и алертов у меня собраны в библиотеке скриптов, можно взять за основу и адаптировать под свой стек.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
За сколько времени до сезона начинать подготовку сайта к нагрузке?
Оптимально - 4-6 недель. За это время успеваете провести нагрузочное тестирование, внести правки по его результатам и прогнать повторный тест перед стартом. Если начинать за неделю, времени хватит только на самые очевидные исправления вроде увеличения ресурсов сервера, без проверки кода и интеграций.
Хватит ли просто увеличить тариф хостинга перед сезоном?
Часто нет. Увеличение ресурсов решает проблему нехватки CPU и RAM, но не убирает узкие места в коде - синхронные внешние запросы, отсутствие кэша, медленные запросы к базе. Сайт с такими проблемами будет тормозить даже на мощном сервере, просто порог наступит немного позже.
Как понять, что сайт не выдержит ожидаемый трафик в сезон?
Самый точный способ - нагрузочное тестирование с эмуляцией реального пути пользователя, а не просто пинг главной страницы. Если 95‑й перцентиль времени ответа превышает 2-3 секунды или тест даёт ошибки 500/504 при трафике, близком к ожидаемому пику, значит сайт нуждается в доработке до старта распродажи.
Что делать, если сайт уже начал тормозить в разгар распродажи?
Первым делом отключить всё второстепенное, что грузит сервер и базу - фоновые синхронизации, рассылки, тяжёлую аналитику. Дальше смотреть на метрики: если упирается CPU или RAM - масштабировать ресурсы вручную, если тормозит база - проверить, не заблокированы ли таблицы долгими запросами. Заранее прописанный план действий экономит критичные минуты, когда решение нужно принимать быстро.