WordPress в 2026: на какой скорости сайт теряет заявки и что чинить первым — хостинг, кэш или плагины

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

Заявки теряются не на этапе «сайт упал», а в диапазоне, который никто не мониторит: 2,5–4 секунды загрузки на мобильных. Владелец видит «сайт работает» и не связывает просадку конверсии со скоростью. Первый рефлекс — купить новый хостинг или навесить кэш-плагин, хотя узкое место обычно в другом слое. Без замера по слоям любые правки — это перестановка вслепую.

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

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

• TTFB выше 600–800 мс — идите в хостинг, PHP и объектный кэш. Кэш-плагин здесь не при чём.
• TTFB в норме, а LCP 2,5–4 с — виноват фронтенд: картинки, шрифты, критический CSS. Хостинг менять бессмысленно.
• LCP в норме, а INP высокий — копайте JS и плагины. Ориентир: 20–30 активных плагинов — повод для аудита.

Сайт открывается за 4 секунды, выглядит рабочим и теряет заявки тихо, без ошибок в логах. Никаких 500-х, никаких падений. Человек на телефоне ждёт, потом закрывает вкладку. Вы платите за клик, а он уходит до того, как увидел форму.

Порог скорости, после которого заявки падают

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

Ориентиры по LCP на мобильных:

• до 2 с — конверсия держится стабильно, трогать нечего;
• 2,5–4 с — зона заметной просадки, здесь и теряются заявки;
• свыше 4–5 с — уходит значительная часть мобильного трафика.

Проблема в том, что 2,5–4 секунды — это не «сайт упал». Вы смотрите на него с ноутбука, всё открывается, форма на месте. Аналитику не открываете неделями. А потом сравниваете два периода и видите: трафик тот же, заявок меньше. И начинаете искать причину в рекламе, в оффере, в менеджерах. Хотя причина — в секундах.

Связать скорость и конверсию на своих данных можно. Разбейте страницы входа по скорости загрузки и посмотрите конверсию форм отдельно по каждой группе. Не по чужим кейсам — по своим. Если на страницах с LCP до 2 с конверсия в заявку выше, чем на страницах с LCP 3 с, — вы нашли узкое место. Без этого замера любые правки — перестановка вслепую.

Замер до правок: что и где смотреть

PageSpeed Insights даёт две картины: лабораторные данные (синтетический прогон) и полевые из CrUX (реальные визиты за последние недели). Лабораторные показывают потенциал, полевые — что происходит на самом деле. Смотрите оба, но решения принимайте по полевым.

Три метрики, за которые вы отвечаете:

• LCP — когда отрисовался главный элемент страницы. Высокий LCP при нормальном TTFB — вопрос к картинкам, шрифтам, критическому CSS.
• TTFB — сколько сервер думает до первого байта. Выше 600–800 мс — сигнал проблем на стороне сервера, а не фронтенда.
• INP — как страница реагирует на действия. Высокий INP — тяжёлый JS, плагины, скрипты аналитики.

Baseline по конверсии форм собирают за 2–4 недели. Меньше — статистика шумит, вы не отличите эффект от случайности. Зафиксируйте текущие цифры до любых правок: конверсия форм, LCP, TTFB, INP по каждой странице входа. Это ваша точка отсчёта. Без неё вы не докажете, что что-то улучшилось, и не поймёте, что сработало.

Отдельно проверьте страницы входа: главная, страница услуг, статьи из поиска. У них разная структура, разный вес, разные проблемы. Чинить всё сразу — значит не понять, что дало эффект.

Хостинг: когда узкое место в сервере

Признаки, что пора смотреть на хостинг:

• TTFB стабильно выше 600–800 мс на всех страницах;
• просадки в пиковые часы — утром или вечером сайт заметно тормозит;
• старая версия PHP, которую хостинг не обновляет;
• shared-хостинг с лимитами по CPU и памяти, которые вы упираетесь регулярно.

Shared-хостинг за 200 рублей в месяц работает, пока сайт маленький и трафик низкий. При 1–3 тыс визитов в месяц и активных плагинах вы начинаете конкурировать за ресурсы с соседями по серверу. Это не всегда видно в логах — просто сервер отвечает медленнее, чем мог бы.

Что чинить внутри хостинга, прежде чем менять:

1. Обновите PHP до актуальной версии. Старые версии медленнее и небезопасны.
2. Включите объектный кэш (Redis или Memcached), если хостинг поддерживает. Это ускоряет запросы к базе.
3. Проверьте, нет ли лишних запросов к базе на каждой загрузке — их видно через Query Monitor.

Переход на VPS или managed-хостинг оправдан, когда TTFB остаётся высоким после этих шагов. Managed-хостинг для WordPress дороже shared, но снимает с вас администрирование сервера. VPS дешевле, но требует, чтобы кто-то его настраивал и обновлял. Если в штате нет технического специалиста — считайте стоимость не только сервера, но и времени на его поддержку.

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

Кэш: что он лечит и что маскирует

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

Три типа кэша, которые часто путают:

• Страничный кэш — сохраняет готовую HTML-страницу. Ускоряет повторные визиты анонимных пользователей.
• Объектный кэш — кэширует запросы к базе данных. Ускоряет генерацию страницы на сервере.
• Кэш браузера — сохраняет статику (картинки, CSS, JS) на устройстве пользователя. Ускоряет повторные загрузки.

Порядок такой: сначала бэкенд (TTFB, PHP, объектный кэш), потом страничный кэш, затем CDN. Если поставить кэш-плагин поверх медленного сервера, вы замаскируете проблему для части пользователей, но не решите её. Первый визит нового посетителя — а именно он и конвертируется — останется медленным.

CDN имеет смысл, когда основная аудитория географически удалена от сервера, или когда статика тяжёлая. Для SMB-сайта с аудиторией в одном регионе CDN может не дать заметного эффекта. Не тратьте на него бюджет, пока не разобрались с сервером и фронтендом.

Плагины и фронтенд: где уходят секунды

Дело не в количестве плагинов, а в том, что каждый активный добавляет запросы, скрипты и стили на каждой странице. Ориентир: 20–30 активных плагинов — повод для аудита. Не потому что «много», а потому что вы, скорее всего, не помните, зачем нужен каждый.

Что смотреть в первую очередь:

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

Изображения — отдельная история. Одна картинка на 3 МБ убивает LCP на мобильном. Сжимайте, переводите в WebP, ставьте lazy-loading для всего, что ниже первого экрана. Но не лениво грузите главное изображение — оно и есть LCP.

Шрифты: каждое начертание — отдельный файл. Если у вас три гарнитуры по пять начертаний, это 15 запросов. Оставьте одно-два начертания, подключите локально, не тяните с Google Fonts.

Критический CSS — стили для первого экрана — можно встроить прямо в HTML, а остальное грузить асинхронно. Это ускоряет первую отрисовку.

Отключайте плагины по одному и замеряйте после каждого. Не отключайте пачкой — не поймёте, что дало эффект. И держите бэкап перед экспериментами.

Если не уверены, какой плагин тормозит, посмотрите аудит производительности — он покажет вклад каждого расширения в LCP и INP.

Порядок действий: от замера к правкам

Диагностика по слоям, а не по привычке:

1. Замерьте LCP, TTFB, INP на мобильных через PageSpeed Insights и CrUX. Отдельно для каждой страницы входа.
2. Определите, где теряются секунды. TTFB выше 600–800 мс — сервер. LCP высокий при нормальном TTFB — фронтенд. INP высокий — JS и плагины.
3. Чините в порядке влияния: сначала TTFB (хостинг, PHP, объектный кэш), затем критический CSS и изображения, потом тяжёлые плагины.
4. Настройте страничный кэш и CDN, но только после того, как бэкенд перестал быть узким местом.
5. Зафиксируйте baseline в аналитике и перепроверяйте после каждого изменения.

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

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

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

Подход не сработает, если нет baseline и замеров до правок. Улучшения останутся недоказанными, а решения — вкусовыми. Вы будете спорить с подрядчиком, он будет показывать красивые скриншоты, а конверсия не изменится.

Также он не поможет, если узкое место вне сайта. Например, медленный ответ CRM или обработка заявок вручную. Если менеджер перезванивает через два дня, скорость сайта перестаёт быть ограничивающим фактором. Вы ускорите загрузку до 2 с, а заявки всё равно будут теряться — только уже на другом этапе.

И третье: если трафика мало. При 1–3 тыс визитов в месяц статистика по конверсии форм шумит. Вы можете ускорить сайт, но не увидеть эффекта в цифрах, потому что выборка слишком маленькая. В этом случае ориентируйтесь на технические метрики, а не на конверсию.

Что делать через 10 минут после чтения

Откройте PageSpeed Insights, вбейте адрес главной страницы, посмотрите на TTFB и LCP на мобильных. Запишите цифры. Повторите для страницы услуг и одной статьи из поиска.

Если TTFB выше 600–800 мс — начните с хостинга. Если TTFB в норме, а LCP высокий — смотрите картинки и шрифты. Если оба в норме, а INP высокий — аудит плагинов.

Зафиксируйте baseline: текущая конверсия форм за последние 2–4 недели. Без этой цифры вы не докажете, что что-то улучшилось.

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

FAQ

При какой скорости загрузки сайт реально начинает терять заявки?

Ориентир: до 2 секунд на мобильных конверсия держится стабильно. 2,5–4 секунды — зона заметной просадки. Свыше 4–5 секунд теряется значительная часть мобильного трафика. Но точный порог для вашего сайта зависит от аудитории и типа заявок. Замерьте свою конверсию на страницах с разной скоростью.

Что чинить первым — хостинг, кэш или плагины?

Порядок задаёт замер, а не привычка. Если TTFB выше 600–800 мс — начинайте с хостинга, версии PHP и объектного кэша. Если TTFB в норме, а LCP высокий — с изображений, шрифтов и критического CSS. Если LCP в норме, а INP высокий — с плагинов и JS.

Кэш-плагин решит проблему скорости?

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

Сколько плагинов — это уже много?

Дело не в количестве, а в том, что каждый активный плагин добавляет запросы, скрипты и стили на каждой странице. Ориентир: 20–30 активных плагинов — повод для аудита. Проверьте, какие из них грузятся на всех страницах, хотя нужны на одной.

Как понять, что хостинг — узкое место, а не плагины?

Посмотрите на TTFB. Если он выше 600–800 мс на всех страницах, включая простые, — проблема на стороне сервера. Если TTFB в норме, а тормозят только отдельные страницы — скорее всего, дело в плагинах или контенте на этих страницах.

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

Шаг 1: замерьте реальные метрики — LCP, TTFB, INP на мобильных через PageSpeed Insights и CrUX, отдельно для страниц входа (главная, услуги, статьи из поиска). Шаг 2: определите, где теряются секунды: TTFB выше 600–800 мс — вопрос к хостингу и бэкенду; LCP высокий при нормальном TTFB — к фронтенду, картинкам, шрифтам; INP высокий — к JS и плагинам. Шаг 3: чините в порядке влияния — сначала TTFB (хостинг, PHP-версия, объектный кэш), затем критический CSS и изображения, потом тяжёлые плагины. Шаг 4: настройте страничный кэш и CDN, но только после того, как бэкенд перестал быть узким местом. Шаг 5: зафиксируйте baseline в аналитике и перепроверяйте после каждого изменения — иначе не поймёте, что сработало.

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

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

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

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

Отдельно для разработки: фиксируйте производительность, безопасность и индексируемость страниц как часть DoD деплоя, а не постфактум.

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

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

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

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

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

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

При какой скорости загрузки сайт реально начинает терять заявки?

Ориентир: до 2 секунд на мобильных конверсия держится стабильно; 2,5–4 секунды — зона заметной просадки; свыше 4–5 секунд теряется значительная часть мобильного трафика ещё до отрисовки контента. Точный порог для вашего сайта определяется замером: сравните конверсию страниц входа с разной скоростью за один период.

Что чинить первым — хостинг, кэш или плагины?

Порядок задаёт замер, а не привычка. Если TTFB выше 600–800 мс — начинайте с хостинга, версии PHP и объектного кэша. Если TTFB в норме, а LCP высокий — с изображений, шрифтов и критического CSS. Если тормозит отклик на действия пользователя (INP) — с JS и плагинов. Кэш-плагин усиливает уже здоровый бэкенд, но не лечит медленный сервер.

Кэш-плагин решит проблему скорости?

Частично. Страничный кэш ускоряет повторные и анонимные загрузки, но не помогает на первом визите, при авторизации, в корзине и на динамических страницах. Если TTFB высокий из-за слабого хостинга или тяжёлых запросов, кэш замаскирует симптом на части трафика и оставит проблему на остальной.

Сколько плагинов — это уже много?

Дело не в количестве, а в том, что каждый активный плагин добавляет запросы, скрипты и стили на каждой странице. Ориентир: 20–30 активных плагинов — повод провести аудит и отключить неиспользуемые. Проверяйте не число, а вклад в LCP и INP через профилирование и отключение по одному.

Как понять, что стало лучше, а не «показалось»?

Зафиксируйте baseline: LCP, TTFB, INP по ключевым страницам и конверсию форм за 2–4 недели до правок. После каждого изменения замеряйте те же метрики в тех же условиях (мобильный профиль, тот же регион). Без baseline любые улучшения — субъективная оценка.

Нужен ли CDN для сайта на WordPress в РФ?

CDN помогает, если аудитория географически распределена или статика тяжёлая. Для локальной аудитории в одном регионе выигрыш может быть меньше, чем от оптимизации изображений и TTFB. Решение принимайте по замеру: сравните скорость отдачи статики с CDN и без него на реальных сессиях.

Дальше по теме платформы: смежные материалы (Разработка и запуск продукта)

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

• Сколько стоит сайт под ключ в Москве
• Как выбрать подрядчика по AI и автоматизации
• Внедрение AI в продажи за 30 дней