WordPress тормозит по умолчанию: каждый запрос к странице запускает PHP, который собирает HTML из базы данных, применяет активные плагины и только потом отдаёт результат браузеру. Большинство WordPress-сайтов показывают PageSpeed в диапазоне 30-60 - не из-за плохого контента, а из-за архитектуры, которая не оптимизирована для скорости. Оптимизировать WordPress реально, но есть потолок, после которого только смена стека даёт значимый прирост.
В проектах по поддержке и миграции сайтов мы регулярно видим одну картину: компания поставила кэш-плагин, сжала изображения, перешла на более быстрый хостинг - PageSpeed вырос с 38 до 55, и дальше не двигается. Причина в том, что узкое место находится глубже: в количестве активных плагинов, в том, как страничный конструктор генерирует CSS, в блокирующих скриптах сторонних виджетов. Эти проблемы не решаются точечными настройками.
Важный контекст: с марта 2024 года Google заменил метрику FID на INP (Interaction to Next Paint) - время отклика на взаимодействие пользователя. Большинство старых гайдов по оптимизации WordPress настраивают под FID, который уже не учитывается в Core Web Vitals. Если ваши усилия по оптимизации не дают результата - возможно, вы оптимизируете не ту метрику. В этой статье разберём реальные причины тормозов WordPress, что можно исправить без смены стека, и когда оптимизации перестают работать.
Основные причины медленного WordPress
WordPress - гибкая платформа, и именно эта гибкость создаёт проблемы со скоростью. Каждая добавленная функциональность чаще всего реализуется через плагин, который добавляет собственные скрипты, стили и запросы к базе данных.
Plugin bloat - главная причина. Среднестатистический WordPress-сайт работает с 20-40 активными плагинами. Каждый плагин подгружает свои JS и CSS файлы на каждую страницу, даже если на этой конкретной странице он не нужен. Сайт с 47 плагинами может загружать 2-3 МБ скриптов только из-за плагинов.
PHP-рендеринг на каждый запрос - структурная проблема WordPress. Даже с кэшем: кэш инвалидируется при публикации нового материала, и следующий пользователь ждёт полного цикла PHP. На высоком трафике это заметно в поле (CrUX data), а не только в лаборатории Lighthouse.
Неоптимизированные изображения - одна из самых распространённых причин плохого LCP. Редакторы загружают PNG размером 3-5 МБ, WordPress масштабирует их, но не конвертирует в WebP и не добавляет атрибут loading="lazy" автоматически без плагина.
Shared hosting - большинство небольших WordPress-сайтов живут на виртуальном хостинге, где ресурсы делятся между сотнями соседних сайтов. При пиковой нагрузке соседей ваш сайт замедляется независимо от оптимизации.
Блокирующие скрипты - JS по умолчанию блокирует рендеринг. Google Tag Manager, виджет чата, счётчик аналитики - каждый такой скрипт без атрибута defer или async задерживает момент, когда пользователь видит страницу.
Страничные конструкторы (Elementor, Divi, WPBakery) генерируют раздутый HTML и подгружают десятки файлов CSS и JS. Elementor добавляет в среднем 400-700 КБ к весу страницы. Это архитектурная проблема: её нельзя решить кэш-плагином.
Как измерить скорость правильно
PageSpeed Insights показывает два типа данных: лабораторные (Lighthouse) и полевые (CrUX). Лабораторные данные - это результат тестирования в управляемой среде с имитированным 4G. Полевые данные - реальные показатели от реальных пользователей вашего сайта за последние 28 дней.
Гугл ранжирует сайты по полевым данным (CrUX), а не по лабораторным. Это означает: можно получить 85 в Lighthouse и при этом иметь плохие полевые Core Web Vitals - и именно плохие полевые данные будут влиять на позиции. Проверяйте оба раздела в PageSpeed Insights: если лабораторный балл высокий, а полевые данные красные - проблема в том, как ваша реальная аудитория нагружает сайт (мобильные устройства, медленный интернет, география).
Минимальные пороговые значения Core Web Vitals для оценки “хорошо”: LCP (Largest Contentful Paint) - до 2,5 секунды; CLS (Cumulative Layout Shift) - до 0,1; INP (Interaction to Next Paint) - до 200 мс. Если хотя бы один показатель в красной зоне - это приоритет перед любой другой оптимизацией.
Что можно исправить не меняя стек
Есть набор улучшений, которые дают реальный прирост на большинстве WordPress-сайтов. Рассмотрим их по приоритету.
Изображения
Изображения - самый быстрый способ улучшить LCP при минимальных усилиях. Конвертируйте все изображения в WebP: он в среднем на 25-35% легче JPEG при сравнимом качестве. Плагин Imagify, ShortPixel или встроенный в WordPress 6.1+ конвертер справятся с этим задачей.
Добавьте loading="lazy" для всех изображений, которые не находятся в первом экране. Самое важное - preload для LCP-изображения: изображение-герой должно загружаться с приоритетом, а не ждать парсинга HTML. Добавьте в <head> тег <link rel="preload" as="image"> с путём к главному изображению страницы.
Задайте явные атрибуты width и height для всех изображений - это устраняет CLS, который возникает, когда браузер не знает размер изображения до загрузки и перекладывает элементы страницы.
Скрипты
Defer non-critical JS - скрипты аналитики, виджеты, ремаркетинговые пиксели не нужны для первого рендеринга страницы. Добавьте атрибут defer или загружайте их через плагин типа Flying Scripts, который откладывает загрузку до взаимодействия пользователя.
Проведите аудит плагинов: деактивируйте все, которые вы не можете объяснить за 5 секунд. Инструмент Query Monitor покажет, сколько запросов к базе данных делает каждый плагин и сколько времени это занимает.
Аудит сторонних скриптов - отдельная задача. Google Tag Manager, Intercom, Drift, HotJar - каждый такой инструмент добавляет 50-200 мс к INP. Перенесите сторонние скрипты в GTM и настройте их загрузку только на тех страницах, где они нужны.
Хостинг и кэш
Managed WordPress hosting (Kinsta, WP Engine, Cloudways) даёт реальное преимущество перед shared hosting: изолированные ресурсы, встроенный Redis для object cache, оптимизированный стек PHP-FPM + Nginx. Переезд с дешёвого shared хостинга на managed нередко даёт 15-25 баллов PageSpeed без каких-либо других изменений.
Object cache через Redis или Memcached кэширует результаты сложных запросов к базе данных. Это особенно важно для сайтов с большим количеством динамического контента: WooCommerce, membership-сайты, сложные фильтры.
CDN (Cloudflare, BunnyCDN) ускоряет доставку статических файлов и снижает задержку для пользователей в других регионах. Cloudflare в бесплатном плане уже даёт заметное улучшение TTFB для международной аудитории.
Когда оптимизации WordPress не хватает
Есть сигналы, которые говорят о том, что проблема структурная, а не настроечная. Вы столкнулись с потолком WordPress-оптимизации, если:
- На сайте более 30 активных плагинов, и их количество продиктовано бизнес-потребностями (не мусор, а нужная функциональность)
- PageSpeed остаётся ниже 60 после применения всех стандартных оптимизаций: кэш, WebP, CDN, managed hosting
- Сайт собран на Elementor или Divi - конструктор генерирует раздутый CSS/HTML, который нельзя устранить без пересборки страниц
- LCP больше 4 секунд на мобильных устройствах в полевых данных (не в лаборатории)
- INP выше 400 мс из-за тяжёлого JS от конструктора или виджетов
В этих случаях дальнейшие усилия по оптимизации дают убывающую отдачу. Каждый следующий процентный пункт PageSpeed стоит непропорционально много времени - и при этом не устраняет фундаментальную архитектурную проблему: PHP-рендеринг на каждый запрос.
Альтернатива - переезд на Headless
Headless-архитектура разделяет контент (CMS) и его отображение (фронтенд). Вместо того чтобы WordPress собирал HTML при каждом запросе, фронтенд (Astro, Next.js) компилирует все страницы в статический HTML при деплое. Пользователь получает готовый файл с CDN - без PHP, без базы данных, без плагинов в цепочке.
Результат по Core Web Vitals принципиально другой:
- LCP с 4,8 с -> 1,1 с (статический HTML с CDN отдаётся в десятки раз быстрее PHP-ответа)
- PageSpeed с 42 -> 94
- INP практически обнуляется: нет тяжёлого JS от Elementor, нет блокирующих скриптов
Содержимое по-прежнему управляется через удобный интерфейс - Sanity, Contentful или тот же WordPress в headless-режиме (как источник данных без фронтенда). Редактор работает в знакомой среде, разработчик получает полный контроль над производительностью.
Подробнее о том, как устроен переезд на современный стек и что конкретно происходит с URL-структурой, редиректами и SEO при миграции - в отдельном материале.
Реальный кейс: с 38 до 91 за 6 недель
Клиент из сферы B2B SaaS пришёл с WordPress-сайтом, который набирал 38 баллов в PageSpeed на мобильных устройствах. На сайте было 47 активных плагинов, главная страница собрана в Elementor, хостинг - стандартный shared план.
После применения стандартных оптимизаций (WebP, кэш, CDN, defer для скриптов) PageSpeed вырос до 54. Дальнейшее улучшение без смены архитектуры было невозможным: Elementor генерировал 680 КБ CSS и блокировал рендеринг.
Pринятое решение - миграция на Astro + Sanity в качестве headless CMS. Контент из WordPress перенесён через API, URL-структура сохранена, настроены 301-редиректы. После запуска:
- PageSpeed Mobile: 38 -> 91
- LCP: 4,9 с -> 1,2 с
- CLS: 0,24 -> 0,02
- Bounce rate: -28% за первые 4 недели после запуска
- Время загрузки страницы товара (медиана): 3,8 с -> 0,9 с
Сроки миграции: 6 недель с момента аудита до запуска. Сайт поддерживается командой контента в Sanity без участия разработчика для рутинных обновлений.
Если вам нужна долгосрочная поддержка сайта после миграции - Exceltic.dev берёт на себя мониторинг Core Web Vitals, обновление зависимостей и точечные доработки фронтенда.
Часто задаваемые вопросы
Почему WordPress медленный даже с кэш-плагином?
Кэш-плагин решает только одну проблему: исключает повторный PHP-рендеринг для одинаковых страниц. Но он не уменьшает количество JS и CSS файлов от плагинов, не оптимизирует изображения, не устраняет блокирующие скрипты и не влияет на INP. Кроме того, кэш инвалидируется каждый раз при обновлении контента - и следующий посетитель снова ждёт полного PHP-цикла. Для сайтов с частыми обновлениями (новости, e-commerce с динамическими ценами) эффект кэша минимален.
Сколько плагинов - это уже много для WordPress?
Чёткой границы нет: важнее не количество, а качество и характер плагинов. 15 хорошо написанных плагинов могут нагружать сайт меньше, чем 7 плохих. Практическое правило: если у вас больше 30 активных плагинов, вероятность конфликтов и избыточной нагрузки на JS/CSS резко растёт. Проверьте каждый плагин: подгружает ли он JS/CSS на страницах, где они не нужны? Это можно увидеть в DevTools -> Network при проверке конкретной страницы.
Влияет ли скорость сайта на позиции в Google?
Да, но не напрямую через Lighthouse-балл. Google использует полевые данные Core Web Vitals (из CrUX - реальные показатели ваших пользователей) как один из факторов ранжирования в рамках Page Experience. Если LCP, CLS или INP в «красной» зоне по полевым данным в PageSpeed Insights - это сигнал, который учитывается. Лабораторный балл PageSpeed (число справа) не является прямым сигналом ранжирования - важны именно полевые метрики.
Стоит ли переезжать с WordPress на Headless ради скорости?
Это оправдано, если PageSpeed остаётся ниже 60 после применения всех стандартных оптимизаций, сайт построен на Elementor или другом тяжёлом конструкторе, или если вы видите отток пользователей из-за медленной загрузки на мобильных. Headless-переезд - это проектная работа (4-8 недель в зависимости от объёма), но результат кардинально другой: PageSpeed 85-95, LCP ниже 1,5 с, полная независимость от PHP-стека. Если сайт относительно простой и не страдает от конструктора - часто достаточно managed hosting + кэш + WebP, и переезд избыточен.
Если у вас WordPress с PageSpeed ниже 55 и стандартные оптимизации уже применены - опишите ситуацию команде Exceltic.dev. Проведём аудит, покажем где конкретно теряется скорость, и оценим: нужна ли миграция или достаточно точечных исправлений.