WordPress на Gutenberg в 2026: на каких хостингах сайт падает под нагрузкой и как это проверить до оплаты?

Сравниваем варианты по критериям и говорим, в каком случае что брать.

Gutenberg сам по себе не роняет сайт, но блочные темы и плагины генерируют тяжёлые запросы к БД и много PHP-работы на каждый рендер. Дешёвый shared-хостинг режет CPU, память и число одновременных PHP-воркеров, поэтому при пике трафика или агрессивном краулере сайт уходит в 508/503 или отдаёт 10+ секунд TTFB. Проблема проявляется не в тестах на пустой странице, а на реальных шаблонах с кэшем, плагинами и авторизованными пользователями. Проверить это до оплаты можно только нагрузочным тестом на пробном периоде или тестовом домене.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Сайт на Gutenberg падает не из-за блоков, а из-за лимита PHP-воркеров на тарифе, который вы ещё не оплатили. В момент пика shared-хостинг возвращает 508 или 503, TTFB уходит за 10 секунд, краулер фиксирует недоступность, и заказы утекают к конкуренту, у которого в этот момент просто хватило процессов.

Ниже — сравнение двух лагерей: массовый shared за 500–5000 ₽/мес и VPS или managed-тариф от 2 vCPU и 4 ГБ RAM. С критериями, сценариями теста и с честной оговоркой, где цифры нельзя обещать без замеров.

Вердикт за 30 сек

• Витрина на кэше, до 5–50 тыс. визитов в месяц, нет кабинета и тяжёлых плагинов — shared тянет, но проверьте пейдж-кэш и лимит воркеров до оплаты.
• Корзина, личный кабинет, авторизованные пользователи, REST API под редактором — берите от 2 vCPU и 4 ГБ RAM с отдельными MySQL и Redis. Shared умрёт на динамике, а не на главной.
• Провайдер без trial, без метрик в панели и с запретом нагрузочных тестов — не ваш вариант. Это не экономия, это лотерея на сезон.

Почему Gutenberg меняет профиль нагрузки

Gutenberg сам по себе безобиден. Проблема в том, что вокруг него собирается инфраструктура: блочная тема, пять-семь плагинов, конструктор запросов, WooCommerce, формы, SEO-модуль. Каждый рендер страницы — это десятки обращений к базе и заметная работа PHP. На пустом WordPress с дефолтной темой вы этого не увидите никогда.

Кэш разделяет трафик на две неравные половины. Анонимный посетитель попадает в page cache и получает готовый HTML почти бесплатно. Авторизованный — в корзину, кабинет, оформление заказа — обходит кэш полностью, и каждый его клик упирается в живой PHP и живую MySQL. Именно здесь заканчивается «безлимитный» тариф: лимит на CPU-секунды и на число одновременных процессов выбирается тремя-четырьмя покупателями.

Дальше добавляется третий поток. Редактор и REST API (/wp-json) создают отдельную нагрузку, которую владелец магазина не видит: пока вы правите карточку в админке, сайт уже держит два-три воркера занятыми. Плюс агрессивный краулер, который проходит 20–50 URL одновременно и не спрашивает, удобно ли вам. Page cache его частично сглаживает, но краулер бьёт и по некешируемым URL — пагинация, фильтры, поиск, параметры сортировки.

Поэтому вопрос «какой хостинг держит Gutenberg» без указания сценария бессмысленен. Один и тот же тариф выдержит 20–50 RPS на кэшированных анонимных страницах и упадёт на 3–10 RPS в корзине. Разница не в железе, а в том, что вы тестируете.

Shared против VPS и managed: где начинаются падения

Сравнение по критериям, которые реально решают судьбу сайта под пиком. Цифры RPS — ориентир для SMB, а не гарантия: многое зависит от темы, числа плагинов и настроек кэша.

Когда shared, когда VPS

Условия, в которых выбор перестаёт быть спором.

Берите shared, если всё совпало

• Контентный сайт или лендинг, анонимный трафик, форм на странице мало, кабинета нет.
• Бюджет 500 ₽/мес, и рядом нет человека, который настроит PHP-FPM, MySQL и Redis на голом VPS.
• Провайдер даёт метрики, разрешает нагрузочный тест и возврат в течение 7–30 дней.

Берите VPS или managed, если есть хоть один признак

• WooCommerce с корзиной и оформлением заказа: динамика неизбежна.
• Личный кабинет, подписки, авторизованные пользователи в заметной доле трафика.
• Пики в 2–3 раза выше обычного: распродажа, сезон, реклама, рассылка.
• VPS без настройки — ловушка. Голый сервер с дефолтным PHP-FPM и MySQL на том же диске падает не хуже shared. Если нет своего техлида, берите managed или тариф с преднастроенным стеком.

Компромисс, который работает чаще, чем крайности: shared под витрину и статику плюс тариф повыше под динамику, если бюджет 5000 ₽/мес уже не пугает. Один сайт, но с запасом по воркерам и с Redis в комплекте.

Метрики, которые показывают предел тарифа

RPS сам по себе врёт. Сайт может отдать 50 RPS и при этом половину запросов — за 10 секунд. Смотрите на связку: p95 TTFB, доля ответов 5xx, потребление CPU и RAM, число соединений к MySQL и slow queries. Для ориентира: пик в 2–3 раза выше обычного трафика не должен поднимать долю 5xx выше 0,5%. Если поднимает — тариф выбран неверно, и апгрейд дешевле потерянного сезона.

Отдельно про PHP-воркеры. Очередь запросов при занятых процессах — первый признак, что упёрлись в лимит, а не в код. На shared вы это увидите как 508 и «resource limit reached», на VPS — как растущий TTFB при низком CPU. Разные симптомы, одна причина: процессов меньше, чем одновременных запросов.

И про диск. NVMe важен, но на первом месте CPU и число воркеров: рендер блоков и плагинов упирается в процессор. Дальше RAM под MySQL и Redis — иначе запросы уходят на диск и I/O wait съедает всё, что вы сэкономили на ядрах.

Как проверить до оплаты, а не после

Сначала зафиксируйте базовую конфигурацию: тема, список плагинов, состояние кэша (page cache, object cache), версии PHP и MySQL/MariaDB. Без этого список выйдет из-под контроля, и вы будете сравнивать несравнимое.

1. Разверните копию сайта на тестовом домене и отдельной базе у провайдера с trial или возвратом в течение 7–30 дней. Не пустой WordPress — реальную копию со всеми плагинами и кэшем.
2. Прогоните три сценария через k6 или Locust с внешней машины: анонимный трафик на главную и карточку, авторизованный в админку и кабинет, одновременный краул 20–50 URL.
3. Повторите каждый сценарий с включённым и выключенным кэшем. Разница покажет, где именно упирается тариф: в PHP, в базе или в кэше.

Смотрите не только на RPS. p95 TTFB, доля 5xx, CPU/RAM по панели, MySQL connections, slow queries. Тест на пустом сайте бессмысленен: он покажет возможности сервера, а вам нужен предел вашего сайта. Подробнее о том, как мы собираем такие стенды, — в описании managed-тарифов.

Когда это не сработает

Схема с тестовым стендом разваливается, если у провайдера нет trial и возврата, нагрузочные тесты запрещены правилами, а метрик в панели нет вообще. Тогда вы покупаете файл, не решение: сравнивать нечего, проверить нечем, остаётся верить на слово. Отдельная ловушка — тест на пустом WordPress без плагинов и кэша. Результат не покажет предел тарифа, зато создаст ложное спокойствие.

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

И третье: оптимизация не бесконечна. Page cache и CDN откладывают апгрейд, но не отменяют его, если у вас 20% трафика авторизовано. Аудит плагинов и тяжёлых блоков даёт выигрыш, пока запросы не упрутся в железо.

Риски ошибки выбора

Самая частая ошибка — купить «безлимитный» shared и успокоиться. Лимит на CPU-секунды и concurrent connections в оферте есть всегда, просто он не в заголовке тарифа. Вторая — взять дешёвый VPS без настройки и получить тот же 503, только с другой стороны. Третья — тестировать главную страницу и не проверить корзину: падает обычно именно она.

Что подключить по этому материалу

WordPress имеет смысл вязать с техподдержкой и SEO-аудитом после запуска.

Сценарий внедрения: дорожная карта на первые недели

Сначала зафиксируйте базовую конфигурацию: тема, набор плагинов, включённый кэш (page cache, object cache), версия PHP и MySQL/MariaDB. Разверните копию сайта на тестовом домене у провайдера, который даёт trial или возврат в течение 7–30 дней. Прогоните нагрузку через k6 или Locust по 3 сценариям: анонимный трафик на главную и карточку, авторизованный трафик в админку и личный кабинет, одновременный краул 20–50 URL. Смотрите не только RPS, но и p95 TTFB, долю 5xx, потребление CPU/RAM по метрикам панели, число MySQL-соединений. Повторите тест с включённым и выключенным кэшем — так видно, где упирается хостинг. Если провайдер не даёт метрик и не разрешает нагрузочный тест — это уже ответ.

1. Нулевая неделя: baseline-метрики, карта ролей и ответственности, технические ограничения и SLA.
2. Неделя 1-2: запуск узкого пилота, контрольные точки, лог ошибок типовых сценариев.
3. Неделя 3-4: первое улучшение по KPI или честное признание, что нужно поменять сценарий/данные.
4. Неделя 5+: масштабирование на смежные процессы и фиксация регламентов, чтобы качество держалось без геройства команды.

Формат “один главный результат на одну неделю” сохраняет темп и экономит управленческое внимание.

Риски и как их снять заранее

• Запуск без baseline и недельной аналитики — самый дорогой вариант, потому что непонятно, что лечить.
• Смешивание многих задач одновременно — обычно увеличивает календарные сроки и бюджет сверх суммы задач по отдельности.
• Слабая интеграция с точками истины данных (CRM, биллинг, тикет-системы) даёт красивый интерфейс и плохой бизнес-эффект.

Что сделать дальше

Короткая диагностика под ваш процесс: обычно 3 дня для малого бизнеса и до 5 дней для проектов со сложной воронкой и несколькими стейджами.

Быстрый расчет эффекта: (количество заявок × текущая стоимость обработки заявки) − (то же после внедрения целевой модели) + (дополнительные продажи × средняя маржа). Число получится грубым и полезным: оно задаёт экономику решения даже без идеальных данных.

По запросу высылаем чеклист диагностики и шаблон weekly-отчёта по экспериментам: там видно, когда пора усиливать сценарий, а когда — остановиться.

• Запросить диагностику процесса: Открыть форму контактов PrimeCoder
• Получить план внедрения на 30 дней: Подключить AI Boost Team как внешний AI-офис с KPI

FAQ по теме статьи

Какие хостинги чаще всего падают под Gutenberg-нагрузкой?

Массовый shared-хостинг с лимитом на CPU-секунды и 1–2 PHP-воркерами на аккаунт, а также тарифы с «безлимитным» диском, но жёстким лимитом concurrent connections. VPS за 200–400 ₽/мес без настроенного PHP-FPM и object cache тоже упирается быстро. Стабильнее ведут себя managed WordPress-тарифы и VPS от 2 vCPU / 4 ГБ RAM с отдельным MySQL и Redis.

Как проверить хостинг до оплаты, если нет доступа к серверу?

Берите провайдера с trial 7–30 дней или гарантией возврата. Разворачивайте копию сайта, а не пустой WordPress. Гоняйте нагрузку через k6/Locust с внешней машины, фиксируйте p95 TTFB, 5xx и метрики панели. Если провайдер запрещает нагрузочные тесты в правилах — это ограничение само по себе риск.

Сколько RPS должен держать сайт на Gutenberg?

Ориентир для SMB: 20–50 RPS на кэшированных анонимных страницах и 3–10 RPS на динамических (корзина, кабинет, поиск) при p95 TTFB до 800 мс. Точная цифра зависит от темы и плагинов, поэтому важнее не абсолютный RPS, а запас: при пике x2–x3 сайт не должен отдавать 5xx.

Что важнее для Gutenberg — CPU, RAM или диск?

На первом месте CPU и число PHP-воркеров: рендер блоков и плагинов упирается в процессор. Дальше RAM под MySQL и Redis, иначе запросы уходят на диск. NVMe-диск помогает, но не спасёт, если CPU-лимит выбран на 100%.

Поможет ли object cache и CDN, если хостинг слабый?

Redis/Memcached и page cache снимают часть нагрузки, CDN закрывает статику и анонимные страницы. Но авторизованные пользователи и админка всё равно идут в PHP и MySQL, поэтому на слабом тарифе они останутся узким местом. Кэш продлевает жизнь хостингу, но не заменяет ресурсы.

Какие метрики смотреть в панели хостинга во время теста?

CPU usage и CPU throttling, свободную RAM, число активных PHP-воркеров и очередь запросов, MySQL connections и slow queries, I/O wait. Если в пике видите throttling или очередь — тариф не подходит, даже если сайт ещё отвечает.

Дальше по теме платформы: смежные материалы (Процессы и эксплуатация)

Статью лучше читать в связке — так быстрее собирается картина, как ответ складывается в работающую воронку, а не в изолированный совет.

• Внедрение AI в продажи за 30 дней
• AI-автоматизация поддержки и SLA
• Регламенты AI-отдела