Как мы чуть не сожгли сервер, прикручивая стриминг ИИ к WordPress

«Просто прикрутите API от OpenAI, там делов на два часа», — сказал мне клиент в ноябре прошлого года. Ему нужен был умный чат-бот на сайте по продаже недвижимости. Не глупый автоответчик, а полноценный ассистент, который на лету генерирует ответы, подтягивая базу объектов. И главное требование: ответ должен печататься на экране в реальном времени, как в ChatGPT. Красивый, плавный стриминг текста.

Я покивал головой. Мы делали интеграции сотни раз. Но стриминг (Server-Sent Events) в связке с WordPress — это совсем другой зверь. В тот раз мы наступили на все возможные грабли, уронили сервер на презентации перед инвесторами и полностью переписали архитектуру. Вот реальный опыт разработчика, который вылез из этих окопов с рабочей технологией.

Почему стандартный подход убивает хостинг

Наш первый прототип мы собрали быстро. Взяли привычный admin-ajax.php, написали обработчик, воткнули curl-запрос к OpenAI. На локальном сервере все летало. Один пользователь, один запрос — красота. Текст плавно бежал по экрану.

Через неделю мы выкатили это на тестовый сервер клиента (4 ядра, 8 ГБ оперативной памяти) для закрытого показа. На презентацию зашло одновременно около 40 человек. Все они одновременно нажали кнопку «Подобрать квартиру» и начали строчить вопросы в чат. Спустя 15 секунд сервер лег намертво. База данных выдала ошибку подключения, а Nginx начал отдавать 504 Gateway Timeout.

Причина проста, но о ней редко думают веб-студии, собирающие сайты на готовых конструкторах. PHP по своей природе синхронен и блокирует потоки. Когда пользователь инициирует wordpress с потоковым ответом ai, PHP-воркер (FPM) открывает соединение с OpenAI и держит его открытым все то время, пока ИИ генерирует ответ. А это может длиться и 15, и 30 секунд.

Если у вас на сервере лимит в 50 PHP-воркеров, то ровно 50 одновременно общающихся пользователей полностью парализуют сайт. Пятьдесят первый пользователь даже главную страницу открыть не сможет — его запрос встанет в очередь и отвалится по таймауту. А если вы при этом дергаете стандартный admin-ajax.php, то при каждом чихе ИИ-генератора WordPress заново инициализирует все плагины, подключает базу данных и тратит драгоценные мегабайты памяти на каждый чанк текста.

Как заставить стриминг работать на WordPress и не разориться

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

Во-первых, забудьте про admin-ajax.php и даже про стандартный REST API WordPress для тяжелого стриминга. Мы написали кастомный PHP-обработчик, который инициализирует только ядро WordPress (без загрузки тяжелых плагинов вроде WooCommerce или Elementor) исключительно для проверки сессии пользователя. Это сократило время отклика системы с 400 миллисекунд до 15 миллисекунд на старте запроса.

Во-вторых, мы перевели работу на Server-Sent Events (SSE). Вместо того чтобы постоянно слать AJAX-запросы и спрашивать «Ну что, готово?», браузер открывает одно постоянное HTTP-соединение, и сервер сам порциями выплевывает токены по мере их генерации нейросетью. Но чтобы PHP-воркеры не висели в режиме ожидания, мы внедрили промежуточный микросервис-прокси на Node.js. Он забирает на себя всю грязную работу по удержанию сотен открытых соединений с пользователями, освобождая WordPress-сервер за доли секунды.

В-третьих, фронтенд. Если ваша тема перегружена визуальными редакторами, браузер пользователя начнет тормозить при попытке отрендерить быстро бегущий текст. Каждая новая буква заставляет браузер пересчитывать стили (делать reflow). Если у вас Elementor с его пятикратной вложенностью div-ов, интерфейс просто зависнет.

Почему шаблоны не подходят для ИИ-интеграций

После того проекта мы дали себе зарок: никогда не ставить ИИ-ассистентов на готовые темы. Это всегда превращается в кошмар поддержки. Готовый шаблон — это ком компромиссов. Там куча лишнего JS-кода, который конфликтует со скриптами стриминга.

Чтобы ИИ работал плавно, как на дорогих SaaS-платформах, необходима кастомная тема wordpress с нуля. Только так разработчик может контролировать критический путь рендеринга. Мы пишем легковесный JS-компонент, который общается с нашим SSE-сервером напрямую, минуя лишние прослойки. В итоге страница весит не 10 мегабайт, а 400 килобайт, и чат работает плавно даже на старых смартфонах.

ИИ на сайте — это не просто виджет в углу экрана. Это полноценный интерфейсный слой. Он должен знать контекст страницы, уметь перенаправлять пользователя на нужные товары, собирать лиды прямо внутри диалога и отправлять их в вашу CRM. Сделать такое на коленке с помощью готового плагина из репозитория WordPress невозможно. Любой шаг влево или вправо от стандартного функционала плагина — и вы упираетесь в стену.

Честный подход к разработке

Мы набили шишек на реальных нагрузках и поняли, как подружить старый добрый WordPress с современными асинхронными технологиями искусственного интеллекта. Мы не предлагаем вам установить готовый плагин, который отвалится при первом скачке трафика. Мы создаем архитектуру, которая выдержит реальных клиентов.

Если вам нужен надежный инструмент для бизнеса, а не просто игрушка для галочки, мы готовы разработать такое решение. Профессиональный, быстрый и масштабируемый сайт wordpress под заказ с чистой кодовой базой и глубокой интеграцией нейросетей — это то, что мы делаем каждый день. Загляните на страницу нашей услуги: Сайт на WordPress с кастомной темой и ИИ-интеграцией → https://guardlabs.online/agent-ready/. Мы обсудим вашу задачу, расскажем о подводных камнях именно вашего проекта и соберем решение, которое будет приносить лиды, а не головную боль.