Онлайн-чат в WordPress: четыре способа и цена каждого

Типичная постановка, с которой приходят владельцы магазинов: WooCommerce на WordPress 6.x, два оператора в поддержке, чат поставили первым плагином из каталога с четырьмя звёздами. Через неделю — жалобы на тормоза в часы акции, а на мобильном круглая кнопка чата села поверх кнопки оформления заказа. Очевидное решение «поискать плагин получше» здесь не работает: вопрос не в качестве плагина, а в том, где физически живёт чат и когда браузер грузит его скрипт. Эти два решения определяют и нагрузку на хостинг, и скорость страницы, и то, кому достанутся персональные данные посетителей.

Условия примера

Чтобы разговор был предметным, зафиксируем вводные, на которые дальше будем опираться:

• WordPress 6.x, WooCommerce, PHP 8.1+, страницы кешируются плагином кеша или на уровне Nginx;
• shared-хостинг или недорогой VPS: лимит одновременных PHP-процессов известен и невелик — на базовых тарифах это обычно единицы, точное число смотрите в панели хостинга;
• до 50 посетителей онлайн в пике, два оператора, обращения приходят неравномерно;
• цель — отвечать на вопросы о наличии и доставке, не уронив скорость карточки товара.

Никаких замеров «до и после» я не придумываю: ниже будет сказано, что и чем мерить на своём сайте, потому что вес виджетов у вендоров меняется от релиза к релизу.

Четыре способа поставить чат

Чат внутри WordPress: сообщения в своей базе

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

Цена вопроса — архитектурная. PHP не умеет держать постоянное соединение дёшево, поэтому такие плагины опрашивают сервер: либо коротким AJAX-опросом раз в несколько секунд, либо long polling.

Long polling — приём, когда браузер отправляет запрос и держит соединение открытым, пока сервер не ответит новым сообщением или не истечёт таймаут. Для PHP это означает занятый процесс на всё время ожидания.

Посчитайте на наших вводных: 40 посетителей онлайн, опрос раз в 5 секунд — это 8 запросов в секунду к admin-ajax.php, и каждый из них поднимает ядро WordPress со всеми активными плагинами целиком. Запросы к admin-ajax.php и /wp-json/ кеш страниц не обслуживает — они всегда идут в PHP. При лимите в несколько воркеров очередь выстраивается мгновенно, и первым страдает не чат, а обычные страницы: посетитель видит долгий ответ или 503.

Отдельная засада — Heartbeat API ядра, который сам по себе шлёт периодические запросы. Если плагин чата к нему прицеплен, интервал можно разрядить:

// Реже опрашивать сервер там, где секунды не критичны. WordPress 6.x
add_filter( 'heartbeat_settings', function ( $settings ) {
	$settings['interval'] = 60; // в секундах
	return $settings;
} );

Допустимый диапазон значений ядро ограничивает — актуальные границы смотрите в описании фильтра heartbeat_settings в справочнике разработчика, а не подбирайте наугад.

SaaS-виджет одной строкой скрипта

Jivo, Carrot quest, Chatra, Tawk.to, Crisp и подобные сервисы дают фрагмент JavaScript. Вся переписка живёт на их инфраструктуре, ваш PHP не участвует вообще: нагрузки на хостинг нет, и это главный аргумент на наших вводных.

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

INP (Interaction to Next Paint) — метрика отзывчивости из Core Web Vitals, с марта 2024 заменившая FID. Тяжёлый сторонний виджет портит именно её.

Второй платёж — персональные данные: имя, телефон, IP, поведение посетителя уходят на серверы вендора. Для российского сайта это вопрос к 152-ФЗ и к вашей политике обработки данных, и решать его нужно с юристом, а не в настройках плагина.

Кнопка в мессенджер

Вместо чата — ссылка в WhatsApp, Telegram или Max. Ноль серверной нагрузки, ноль сторонних скриптов, если делать кнопку руками: обычная ссылка и немного CSS. Диалог продолжается в привычном посетителю приложении, и оператор не обязан сидеть в админке.

Чем платите: нет истории обращений на стороне сайта, нет распределения по операторам, нет автоприглашений. Переход в приложение — лишний шаг, часть посетителей на нём отваливается. И плагины «кнопка мессенджера» из каталога часто приносят с собой целый фреймворк ради одной иконки — проверяйте, что реально грузится.

Свой Chatwoot рядом с сайтом

Открытый Chatwoot ставится на отдельный сервер, а на сайт подключается его виджет. Вы получаете SaaS-удобство и свои данные одновременно.

Цена честная и заметная: это не «папка рядом с WordPress», а отдельный сервис на Rails с PostgreSQL, Redis и фоновыми воркерами, со своим доменом, TLS, бэкапами и обновлениями. Требования к памяти и порядок развёртывания берите в официальной документации проекта, а не из статей — они меняются между мажорными версиями. Имя метода инициализации виджета и путь к SDK тоже сверяйте с документацией вашей версии.

Чат — это не функция сайта, а третья сторона в вашем критическом пути рендеринга. Решайте не «какой плагин поставить», а «где он живёт и когда грузится».

Сравнение в одной таблице

Как подключать виджет: не настройками плагина, а шестью строками

Любой из трёх внешних вариантов сводится к одной задаче: вставить скрипт туда, где он нужен, и тогда, когда он не мешает. Плагины-обёртки обычно грузят виджет на всех страницах без разбора. Поэтому вставку лучше держать у себя — в mu-plugins: файлы из этой папки подключаются автоматически и выживают смену темы, в отличие от кода в functions.php.

<?php
/**
 * Plugin Name: Chat Widget Loader
 * Файл: wp-content/mu-plugins/chat-widget-loader.php
 * Проверено на WordPress 6.7, PHP 8.2
 */

add_action( 'wp_footer', function () {

	// На шаге оплаты чат перекрывает кнопку и отвлекает
	if ( function_exists( 'is_checkout' ) && is_checkout() ) {
		return;
	}

	if ( is_feed() ) {
		return;
	}
	?>
	<script>
	(function () {
		var widgetRequested = false;

		function loadChatWidget() {
			if ( widgetRequested ) return;
			widgetRequested = true;

			var widgetScript = document.createElement('script');
			// Точный URL скрипта берите в кабинете своего сервиса
			widgetScript.src = 'https://example-chat.invalid/YOUR_WIDGET_ID.js';
			widgetScript.async = true;
			document.head.appendChild(widgetScript);
		}

		// Грузим после первого действия посетителя
		['scroll', 'mousemove', 'touchstart', 'keydown'].forEach(function (eventName) {
			window.addEventListener(eventName, loadChatWidget, { once: true, passive: true });
		});

		// Страховка для тех, кто читает молча
		setTimeout(loadChatWidget, 12000);
	})();
	</script>
	<?php
}, 100 );

Что здесь важно: виджет не участвует в первой отрисовке и не попадает в начальную загрузку, а условие на is_checkout() убирает его с самой чувствительной страницы магазина. Если ваш сервис отдаёт обычный файл скрипта, а не inline-фрагмент, подключайте его штатно через wp_enqueue_script — с WordPress 6.3 функция принимает стратегию загрузки defer или async в массиве аргументов.

Когда чат уже стоит плагином и тащит скрипты на каждую страницу, снимите лишнее по handle:

add_action( 'wp_enqueue_scripts', function () {
	if ( is_front_page() || is_product() ) {
		return; // здесь чат нужен
	}
	wp_dequeue_script( 'handle-skripta-plagina' );
}, 999 );

Узнать настоящий handle можно, выведя очередь: global $wp_scripts; print_r( $wp_scripts->queue ); на тестовой странице.

Когда что выбирать

Критерий простой — нагрузка и требования к данным, а не длина списка функций:

1. До десятка обращений в день, один человек отвечает с телефона — кнопка в мессенджер. Всё остальное будет дороже и медленнее без выигрыша.
2. Поток обращений, два и больше операторов, shared-хостинг — SaaS-виджет с отложенной загрузкой. Серверная часть чата не должна делить PHP-процессы с вашим магазином.
3. Данные нельзя отдавать наружу — Chatwoot на своём сервере. Готовьтесь администрировать ещё один сервис.
4. Плагин с чатом в базе WordPress — только для сайтов с небольшим трафиком на своём VPS, где вы контролируете число воркеров и видите метрики PHP-FPM.

Что ломается на практике

• Кеш и nonce. Если плагин печатает в HTML nonce или идентификатор сессии, кеш страниц заморозит его и раздаст всем. Симптом — чат не отправляет сообщения или ошибка проверки у части посетителей. Такие фрагменты нужно отдавать отдельным запросом, а не из кешированной страницы.
• Дубли виджета. Скрипт вставлен и плагином, и в Google Tag Manager, и в шаблон темы. Два чата на странице конфликтуют за хранилище и перекрывают друг друга. Проверяйте: один источник вставки, остальные выключены.
• Перекрытие кнопок на мобильном. Классика WooCommerce: круглая кнопка в правом нижнем углу садится на «Добавить в корзину» в липкой панели. Смотрите на реальном телефоне, а не в эмуляторе ширины.
• Цена отложенной загрузки. Автоприглашения и открытие чата по ссылке в первые секунды не сработают — виджета ещё нет в DOM. Если проактивные приглашения приносят заявки, ставьте таймаут короче и смиритесь с просадкой метрик.
• Баннер согласия. Сторонний виджет ставит свои cookie. Если у вас есть consent-баннер, загрузка чата должна зависеть от согласия, иначе баннер становится декорацией.

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

Сначала измерьте, чего стоит виджет именно у вас: в DevTools на вкладке Network отфильтруйте запросы по домену сервиса и посмотрите суммарный вес и число соединений, затем прогоните страницу в PageSpeed Insights с виджетом и без. Смотрите на INP и LCP на мобильном — там разница заметнее всего.

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