Перейти к содержимому

Медленный WordPress: почему ваш сайт тормозит и как это исправить раз и навсегда

ai-generated-1776691469674.png

Время чтения: ~30 минут | Уровень: от новичка до разработчика | Актуально для: WordPress 5.x–6.x, WooCommerce, все хостинги

Почему скорость сайта — это не технический каприз, а деньги

Давайте начнём с цифр, которые неприятно осознавать, но необходимо знать.

По данным исследований Google за 2025 год, сайт, который загружается дольше 3 секунд, теряет 70% потенциальных посетителей — они просто уходят, не дождавшись. Каждые дополнительные 100 миллисекунд задержки снижают конверсию на 1%. Для интернет-магазина на WooCommerce с ежемесячным оборотом в 500 000 рублей это означает потери в 60 000 рублей в год только из-за того, что страница грузится на секунду дольше нормы.

Но это ещё не всё. С 2021 года Google использует Core Web Vitals — набор метрик скорости и удобства — как прямой фактор ранжирования. Медленный сайт буквально опускается в поисковой выдаче, уступая место более быстрым конкурентам. То есть вы одновременно теряете и трафик, и тех, кто всё-таки дошёл до сайта.

При этом сам WordPress как платформа в проблеме не виноват. Правильно настроенный WordPress сайт загружается за 0,5–1,5 секунды. Проблема — в том, как он установлен, настроен и обслуживается. Именно об этом данная статья.

Как понять, что ваш сайт действительно медленный

Прежде чем что-то оптимизировать, нужно измерить. «Мне кажется, сайт медленный» — не диагноз. Нужны конкретные числа.

Инструменты для измерения

Google PageSpeed Insights (pagespeed.web.dev) — самый важный инструмент, потому что именно он отражает то, как Google оценивает ваш сайт. Введите URL и получите оценку по шкале 0–100 отдельно для мобильных и десктопных устройств, а также детализацию по каждой метрике Core Web Vitals.

Что считается нормой:

  • Зелёная зона (90–100) — отлично, Google доволен

  • Жёлтая зона (50–89) — есть над чем работать

  • Красная зона (0–49) — серьёзная проблема, влияет на позиции

GTmetrix (gtmetrix.com) — более детальный анализ с водопадом загрузки ресурсов. Помогает увидеть, какой именно файл или запрос тормозит страницу, и сколько времени занимает каждый этап загрузки.

WebPageTest (webpagetest.org) — профессиональный инструмент. Позволяет тестировать с разных географических точек, на разных скоростях соединения и в разных браузерах. Незаменим, если ваша аудитория — в конкретном регионе.

Google Search Console — раздел «Core Web Vitals» показывает реальные данные от настоящих пользователей вашего сайта за последние 28 дней. Это важнее лабораторных тестов, потому что отражает живой опыт.

Ключевые метрики, на которые смотреть

LCP (Largest Contentful Paint) — время до появления самого крупного видимого элемента страницы (обычно это главное изображение или заголовок). Норма: до 2,5 секунды.

FID / INP (Interaction to Next Paint) — время отклика на первое взаимодействие пользователя (клик, нажатие). Норма: до 200 миллисекунд.

CLS (Cumulative Layout Shift) — насколько «прыгает» вёрстка при загрузке (элементы двигаются, пока подгружаются шрифты и изображения). Норма: менее 0.1.

TTFB (Time to First Byte) — время от запроса до получения первого байта ответа от сервера. Это прямой показатель скорости хостинга и серверной обработки. Норма: до 600 миллисекунд.

Запустите тест, зафиксируйте все цифры — это ваша точка отсчёта. После каждого этапа оптимизации тестируйте снова и сравнивайте.

Часть 1: Хостинг — фундамент всего

Любая оптимизация бессмысленна, если сайт стоит на медленном хостинге. Это как устанавливать гоночный двигатель в телегу — результат будет разочаровывающим.

Shared хостинг: почему он тормозит

На shared-хостинге ваш сайт делит ресурсы одного физического сервера с сотнями других сайтов. Если сосед запустил рассылку на миллион адресов — ваш TTFB вырастает с 200 до 2000 миллисекунд, и вы ничего не можете с этим сделать. Shared-хостинг подходит для личного блога с сотней посетителей в день. Для бизнес-сайта или магазина — нет.

На что смотреть при выборе хостинга

Для WordPress в 2025 году ключевые параметры такие:

Версия PHP: минимум PHP 8.1, лучше 8.2–8.3. На PHP 8.x скрипты выполняются на 20–30% быстрее, чем на 7.4.

OPcache: должен быть включён по умолчанию. OPcache кэширует скомпилированный PHP-код в памяти, что исключает повторную компиляцию при каждом запросе — ускорение в 3–5 раз.

MySQL 8.0+ или MariaDB 10.6+: новые версии работают быстрее с типичными запросами WordPress.

SSD NVMe накопители: в 5–10 раз быстрее обычных SSD для операций ввода-вывода.

Поддержка HTTP/2 или HTTP/3: позволяет браузеру загружать несколько ресурсов параллельно по одному соединению.

Серверный кэш (Redis или Memcached): принципиально важно. Без объектного кэша WordPress обращается к MySQL при каждом запросе — даже для одних и тех же данных.

VPS vs Managed WordPress Hosting

Если вы переросли shared-хостинг, следующий шаг — либо VPS (виртуальный выделенный сервер), либо managed WordPress hosting.

На VPS вы получаете полный контроль, но настройка LEMP-стека (Linux + Nginx + MySQL + PHP), Redis, SSL и автоматических обновлений — это несколько часов работы человека, понимающего Linux. Зато стоимость начинается от 500–800 рублей в месяц.

Managed WordPress hosting (Kinsta, WP Engine, Cloudways) берёт настройку на себя: Redis уже включён, Nginx уже настроен, CDN уже подключён. Цена выше — от 2000–5000 рублей в месяц — но вы получаете гарантированную производительность без необходимости самостоятельно разбираться с сервером.

Часть 2: Кэширование — самое важное, что вы можете сделать прямо сейчас

Кэширование — это сохранение уже готового результата, чтобы не генерировать его заново при каждом запросе. Без кэша каждый посетитель вашего сайта заставляет PHP выполнить десятки запросов к базе данных, обработать шаблон темы, подключить все плагины — и только потом отдать HTML. С кэшем — сервер просто отдаёт заранее сохранённый файл, что происходит в 10–50 раз быстрее.

Три уровня кэширования в WordPress

Уровень 1 — Page Cache (кэш страниц). Сохраняет готовый HTML каждой страницы. При следующем запросе сервер отдаёт файл напрямую, минуя PHP и MySQL полностью. Самый ощутимый прирост скорости.

Уровень 2 — Object Cache (кэш объектов). Сохраняет результаты запросов к базе данных в оперативной памяти (через Redis или Memcached). Когда PHP нужны данные, он берёт их из RAM, а не из MySQL — в 100 раз быстрее.

Уровень 3 — Browser Cache (кэш браузера). Говорит браузеру пользователя хранить статические файлы (изображения, CSS, JS) локально и не скачивать их при каждом визите. Ускоряет повторные посещения.

Лучшие кэш-плагины и их настройка

WP Rocket — платный, $59/год, но настраивается за 10 минут и покрывает все уровни кэширования «из коробки». Оптимален для тех, кто не хочет глубоко разбираться в теме. Включает минификацию CSS/JS, ленивую загрузку изображений, предзагрузку кэша и многое другое.

LiteSpeed Cache — бесплатный, но работает в полную силу только на хостингах с LiteSpeed Web Server. Если ваш хостинг использует LiteSpeed — это лучший бесплатный выбор без оговорок.

W3 Total Cache — бесплатный, очень гибкий, но требует понимания настроек. Неверная конфигурация может замедлить сайт или вызвать конфликты с WooCommerce.

WP Super Cache — простой и надёжный, от Automattic. Хорош для начинающих, но ограничен по функциям.

Критически важно: что нельзя кэшировать в WooCommerce

Кэш-плагины и WooCommerce — потенциально конфликтная пара. Следующие страницы и условия обязательно должны быть исключены из кэша:

  • Страница корзины (/cart/)

  • Страница оформления заказа (/checkout/)

  • Страница личного кабинета (/my-account/)

  • Все страницы для авторизованных пользователей

  • URL с параметрами сессии WooCommerce

В WP Rocket это настраивается в разделе «Advanced Rules» → «Never Cache These Pages». Большинство плагинов автоматически определяют страницы WooCommerce, но всегда проверяйте вручную — положите товар в корзину и убедитесь, что количество товаров корректно отображается на другой странице.

Настройка Redis для объектного кэша

Если ваш хостинг поддерживает Redis — обязательно включите его. Это самое ощутимое улучшение серверной производительности после базового кэша страниц.

Для подключения Redis к WordPress установите плагин Redis Object Cache (автор Till Krüss, 100 000+ активных установок). После установки добавьте в wp-config.php:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_CACHE', true );

Затем в плагине нажмите «Enable Object Cache». Всё. Теперь WordPress берёт повторяющиеся данные из памяти, а не из MySQL.

Часть 3: Изображения — причина №1 медленных страниц

Неоптимизированные изображения — это причина медленной загрузки в большинстве случаев, с которыми мы сталкиваемся на практике. Типичная картина: сайт сделан на Elementor, каждая страница содержит 15–20 PNG-изображений по 1–3 МБ каждое, итого 30+ МБ на загрузку страницы. При скорости мобильного интернета 10 Мбит/с это 24 секунды только на изображения.

Правильные форматы изображений

WebP — современный формат от Google, который в среднем на 25–35% легче JPEG при том же визуальном качестве, и на 70–80% легче PNG. В 2025 году поддерживается всеми актуальными браузерами (Chrome, Firefox, Safari, Edge). Используйте его для всех фотографий и сложных изображений.

AVIF — ещё более современный формат, на 20% легче WebP. Поддержка браузерами пока не 100%, но для прогрессивной загрузки (с fallback на WebP) уже можно применять.

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

Автоматическая конвертация и сжатие

Не нужно вручную конвертировать каждое изображение. Плагины делают это автоматически:

ShortPixel — конвертирует в WebP/AVIF при загрузке, сжимает с настраиваемым уровнем качества. 100 изображений в месяц бесплатно, дальше платная модель от $4.99.

Imagify — от создателей WP Rocket, отлично интегрируется с ним. 20 МБ в месяц бесплатно.

Smush — популярный бесплатный вариант, но конвертация в WebP доступна только в Pro-версии.

Converter for Media — полностью бесплатный плагин с конвертацией в WebP. Простой и надёжный для большинства сайтов.

Ленивая загрузка (Lazy Load)

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

Начиная с WordPress 5.5, ленивая загрузка встроена в ядро — атрибут loading="lazy" автоматически добавляется к изображениям. Убедитесь, что ваши плагины оптимизации изображений не отключают эту функцию.

Важное исключение: изображение в первом экране (hero image, логотип, главный баннер) — то, что видно без прокрутки — должно иметь loading="eager" или вообще не иметь этого атрибута. Для него нужна прямо противоположная стратегия — предзагрузка через <link rel="preload">. Ленивая загрузка главного изображения — одна из самых частых причин плохого LCP.

Правильные размеры изображений

Загружать изображение 3000×2000 пикселей, чтобы показать его в блоке 600×400 пикселей — расточительство. Браузер скачает в 25 раз больше данных, чем нужно.

Перед загрузкой в WordPress меняйте размер изображений до максимального отображаемого. Для большинства блочных изображений это 1200–1600 пикселей по ширине. Для карточек товаров WooCommerce — 600–800 пикселей.

Зайдите в wp-admin → Настройки → Медиафайлы и проверьте, какие размеры WordPress создаёт автоматически. Лишние размеры (которые ни одна тема не использует) только засоряют сервер.

Часть 4: Минификация и загрузка CSS/JS

Каждая страница WordPress обычно загружает десятки CSS и JavaScript файлов. Каждый файл — это отдельный HTTP-запрос. Каждый запрос — это задержка. А некоторые скрипты ещё и блокируют рендеринг страницы, заставляя браузер ждать их полной загрузки, прежде чем показать пользователю хоть что-то.

Что такое «блокирующие ресурсы»

Когда браузер встречает в HTML тег <script src="script.js"> без атрибутов async или defer, он останавливает парсинг HTML, скачивает скрипт, выполняет его — и только потом продолжает отображение страницы. На практике это означает: пользователь видит белый экран, пока грузятся скрипты.

Признак проблемы в PageSpeed Insights: предупреждение «Eliminate render-blocking resources» с перечнем конкретных файлов.

Минификация

Минификация — это удаление из CSS и JavaScript всего лишнего: пробелов, переносов строк, комментариев, избыточных символов. Файл style.css весом 200 КБ после минификации может весить 140 КБ — это 30% экономии без потери функциональности.

Большинство кэш-плагинов (WP Rocket, LiteSpeed Cache, W3 Total Cache) умеют минифицировать CSS и JS автоматически. Включите эту функцию и проверьте, что сайт работает корректно — в редких случаях минификация ломает скрипты, написанные с ошибками в синтаксисе.

Объединение файлов (Concatenation)

Объединение нескольких CSS/JS файлов в один снижает количество HTTP-запросов. В эпоху HTTP/1.1 это было критически важно. С HTTP/2 и HTTP/3 браузер может загружать десятки файлов параллельно по одному соединению, поэтому объединение стало менее обязательным — но всё равно полезным.

Осторожно с WooCommerce: объединение скриптов чекаута с остальными скриптами сайта часто ломает корзину. Исключайте страницы WooCommerce из объединения или тестируйте очень внимательно.

Условная загрузка скриптов

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

Добавьте в functions.php вашей child-темы:

// Подключать скрипты WooCommerce только на нужных страницах
add_action( 'wp_enqueue_scripts', 'dequeue_woocommerce_scripts', 99 );
function dequeue_woocommerce_scripts() {
    if ( ! is_woocommerce() && ! is_cart() && ! is_checkout() ) {
        wp_dequeue_style( 'woocommerce-general' );
        wp_dequeue_style( 'woocommerce-layout' );
        wp_dequeue_style( 'woocommerce-smallscreen' );
    }
}

Аналогично поступайте с любым плагином, который грузит скрипты «на всякий случай» на каждой странице.

Часть 5: База данных — скрытый тормоз

WordPress активно работает с базой данных. Каждая загрузка страницы — это десятки SQL-запросов: получить контент записи, получить настройки, проверить пользователя, получить виджеты, получить меню. Раздутая или неоптимизированная база данных делает каждый из этих запросов медленнее.

Что раздувает базу данных

Ревизии записей. По умолчанию WordPress сохраняет каждую версию каждого поста. Статья, которую редактировали 50 раз, создаёт 50 записей в таблице wp_posts. На сайте с тысячами записей — это миллионы строк только ревизий.

Ограничьте количество ревизий в wp-config.php:

define( 'WP_POST_REVISIONS', 5 ); // Хранить максимум 5 ревизий

Или полностью отключите:

define( 'WP_POST_REVISIONS', false );

Мусор в wp_options (autoload). Каждый плагин при установке записывает свои настройки в таблицу wp_options с флагом autoload=yes. Это означает, что данные загружаются в память при каждом запросе к сайту — даже если плагин деактивирован. Со временем накапливаются тысячи строк, загружаемых без нужды.

Проверьте объём autoload-данных:

SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload='yes';

Если результат больше 1 МБ — это проблема. Используйте плагин WP-Optimize или WP-Sweep для очистки orphaned autoload-данных.

Транзиенты (Transients). WordPress хранит временные кэш-данные в таблице wp_options. Без Redis они накапливаются и не всегда корректно удаляются. Регулярная очистка устаревших транзиентов уменьшает размер таблицы.

Таблицы WooCommerce. На активном магазине таблицы wp_woocommerce_sessions (незавершённые сессии покупателей) и wp_wc_order_stats могут расти до десятков гигабайт. Настройте очистку в WooCommerce → Настройки → Дополнительно → WooCommerce.com:

Для очистки сессий через WP-CLI:

wp wc cleanup --session-expiration=48 --dry-run

Уберите --dry-run после проверки, чтобы применить очистку.

Оптимизация и восстановление таблиц

Регулярная оптимизация таблиц (аналог дефрагментации диска) возвращает свободное пространство после удалений:

OPTIMIZE TABLE wp_posts, wp_options, wp_postmeta;

Или через WP-CLI:

wp db optimize

Плагин WP-Optimize делает это автоматически по расписанию — настройте еженедельную очистку и забудьте.

Часть 6: CDN и серверные настройки

CDN: зачем и как выбрать

CDN (Content Delivery Network) — это глобальная сеть серверов, хранящих копии статических файлов вашего сайта (изображения, CSS, JS, видео). Когда пользователь из Новосибирска открывает ваш сайт, размещённый на сервере в Москве, его браузер загружает изображения с ближайшего CDN-сервера — например, в Екатеринбурге. Это снижает задержку в несколько раз.

Cloudflare (бесплатный тариф покрывает 95% потребностей малого и среднего бизнеса) — самый популярный выбор. Помимо CDN, бесплатно предоставляет WAF (защита от атак), Argo Smart Routing, автоматическое сжатие Brotli и бесплатный SSL.

Настройка Cloudflare с WordPress занимает 15 минут: смените nameservers домена на Cloudflare и установите плагин Cloudflare для WordPress — он автоматически настраивает совместимость и очищает кэш CDN при публикации новых материалов.

Важно для WooCommerce: в Cloudflare → Caching → Configuration выставьте «Cache Level: Standard» и обязательно добавьте Page Rules для исключения страниц checkout, cart, my-account из кэширования.

Включите Gzip/Brotli сжатие

Сжатие текстовых ресурсов (HTML, CSS, JS) снижает их размер на 60–80% при передаче. Это должно быть включено на уровне сервера.

Проверить, включено ли сжатие, можно на checkgzipcompression.com — введите URL вашего сайта и получите мгновенный ответ.

Для включения через .htaccess (Apache):

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

На Nginx это настраивается в конфиге сервера — обратитесь в техподдержку хостинга или добавьте в конфигурацию:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1000;

HTTP/2 и Browser Cache

Убедитесь, что ваш сервер поддерживает HTTP/2 — это легко проверить через инструмент http2.pro или в вкладке Network DevTools браузера (посмотрите столбец Protocol, должно быть h2).

Настройте заголовки кэширования браузера для статических файлов через .htaccess:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Часть 7: Плагины — аудит и зачистка

На типичном WordPress-сайте мы видим 25–40 активных плагинов. Из них реально используются 10–15. Остальные — «установлю и посмотрю», «может, пригодится», «не помню зачем». Каждый лишний плагин добавляет запросы к базе данных, PHP-код при инициализации, потенциально CSS и JS на фронтенде.

Как провести аудит плагинов

Установите плагин Query Monitor. Он покажет в реальном времени, сколько запросов к базе данных делает каждый плагин на текущей странице и сколько времени каждый занимает. Увидели плагин, который делает 50+ запросов на странице блога — это кандидат на замену.

Задайте себе про каждый плагин три вопроса:

Первое — активно ли используется эта функция прямо сейчас? Если нет — деактивировать и удалить.

Второе — можно ли заменить этот плагин нативными функциями WordPress или кодом в functions.php? Многие плагины делают одно простое действие, которое реализуется 5 строками кода.

Третье — когда последнее обновление? Плагин без обновлений более 2 лет — потенциальная угроза совместимости и безопасности.

Типичные «тяжёлые» плагины, которые стоит заменить

Jetpack — комбайн, делающий всё сразу: статистику, CDN для изображений, защиту от спама, формы, слайдеры. Весит много, влияет на TTFB. Если вам нужна только статистика — замените на Google Analytics или Plausible. Если нужна только защита от спама — Akismet работает отдельно и значительно легче.

Revolution Slider / Slider — красивые слайдеры стоят дорого в плане производительности. Вопрос: действительно ли слайдер необходим? Исследования показывают, что конверсия у статичного hero-изображения зачастую выше, чем у слайдера. Если слайдер нужен — подключайте его скрипты только на тех страницах, где он используется.

Несколько форм-плагинов одновременно — Contact Form 7 и Gravity Forms и WPForms на одном сайте. Выберите один.

Два SEO-плагина — такое бывает после переезда или смены разработчика. Yoast и Rank Math одновременно — конфликт настроек и двойная нагрузка.

Часть 8: Специфика WooCommerce — Cart Fragments и AJAX

WooCommerce имеет специфическую проблему производительности, которая многих застаёт врасплох: по умолчанию на каждой загрузке любой страницы сайта делается AJAX-запрос для обновления данных корзины (cart fragments). Даже если посетитель читает статью в блоге и никогда ничего не добавлял в корзину — запрос всё равно идёт.

Это означает, что ни одна страница WooCommerce-сайта не может быть полностью обслужена из кэша без дополнительной настройки. AJAX-запрос всегда генерирует серверную нагрузку.

Решение 1: Отключить cart fragments для незарегистрированных пользователей

Если ваш магазин не предполагает «persist cart» (сохранение корзины между сессиями) для гостей, вы можете отключить фрагменты для не залогиненных:

add_action( 'wp_enqueue_scripts', 'disable_cart_fragments_for_guests', 11 );
function disable_cart_fragments_for_guests() {
    if ( ! is_user_logged_in() ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}

Решение 2: Перенести запрос на момент взаимодействия

Современный подход — не делать AJAX-запрос при загрузке страницы, а только когда пользователь реально взаимодействует с корзиной (добавляет товар, переходит на страницу корзины). Плагины WP Rocket и LiteSpeed Cache автоматически решают эту задачу через собственную реализацию фрагментов корзины.

WooCommerce и страница магазина

Страница архива товаров (/shop/) — часто самая тяжёлая страница сайта. При 500+ товарах и сложных фильтрах время генерации может превышать 5 секунд. Несколько советов:

Используйте пагинацию (не бесконечную прокрутку) с разумным количеством товаров на странице — 12–24. Бесконечная прокрутка при 200+ товарах означает загрузку всех данных в один DOM.

Для сложных фильтров с большим каталогом рассмотрите плагин FacetWP или SearchWP — они строят собственные индексы для быстрого поиска вместо тяжёлых JOIN-запросов WooCommerce.

Часть 9: Мобильная производительность

Более 60% трафика в 2025 году приходит с мобильных устройств. Google использует mobile-first индексацию — то есть именно мобильную версию сайта проверяет при ранжировании. При этом мобильные оценки в PageSpeed Insights почти всегда хуже десктопных — соединение медленнее, процессор слабее.

Специфика мобильной оптимизации

Viewport meta tag — убедитесь, что в <head> есть:

<meta name="viewport" content="width=device-width, initial-scale=1">

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

Адаптивные изображения. WordPress автоматически генерирует несколько размеров изображений и использует атрибут srcset, чтобы браузер загружал изображение, подходящее именно для его разрешения экрана. Убедитесь, что ваша тема и плагины изображений не перегружают это поведение.

Touch targets. Кнопки и ссылки должны быть достаточно крупными для нажатия пальцем — минимум 44×44 пикселя по рекомендациям Google. Слишком мелкие кнопки — это не только неудобство, но и сигнал о плохом UX для алгоритмов ранжирования.

Избегайте всплывающих окон на мобильных. Google штрафует сайты, показывающие агрессивные попапы, перекрывающие контент на мобильных устройствах.

Пошаговый план оптимизации: с чего начать прямо сейчас

Если вы дочитали до этого места и у вас кружится голова от количества задач — не переживайте. Вот приоритизированный план действий. Начните с первых пунктов — они дадут 80% результата при минимальных усилиях.

Приоритет 1 (делаем в первую очередь, дают максимальный эффект):

  • Запустите PageSpeed Insights и зафиксируйте текущие показатели

  • Установите кэш-плагин (WP Rocket, LiteSpeed Cache или WP Super Cache)

  • Установите плагин оптимизации изображений и конвертируйте в WebP

  • Включите ленивую загрузку изображений

Приоритет 2 (делаем после первого блока):

  • Очистите базу данных от ревизий и мусора через WP-Optimize

  • Проведите аудит плагинов и удалите лишние

  • Убедитесь, что OPcache включён на хостинге

  • Настройте Cloudflare (бесплатный тариф)

Приоритет 3 (для серьёзной оптимизации):

  • Подключите Redis Object Cache

  • Настройте условную загрузку скриптов

  • Рассмотрите переход на VPS или managed WordPress hosting

  • Настройте реальный cron вместо wp-cron

Приоритет 4 (для продвинутых):

  • Переведите WooCommerce на Elasticsearch/SearchWP для поиска

  • Настройте CDN для медиафайлов

  • Реализуйте preload для критических ресурсов

  • Перейдите на HTTP/3

После каждого блока — снова запускайте PageSpeed Insights и сравнивайте с исходными показателями.

Что делать, если оптимизация не помогает

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

TTFB остаётся высоким (> 1 сек) после включения кэша — скорее всего, проблема на уровне сервера: слабый хостинг, медленный MySQL, отсутствие OPcache. Пора менять хостинг.

Один конкретный плагин генерирует сотни запросов к БД — плохо написанный код, нет кэширования внутри плагина. Ищите альтернативу или нанимайте разработчика для оптимизации.

CLS высокий (> 0.1) — элементы скачут при загрузке. Убедитесь, что у всех изображений указаны атрибуты width и height, веб-шрифты загружаются с font-display: swap, рекламные блоки резервируют место в вёрстке.

LCP плохой, но изображения оптимизированы — возможно, LCP-элемент — это не изображение, а текстовый блок, загрузка которого блокируется скриптом или шрифтом. Проверьте в DevTools, что именно является LCP-элементом.

Не хотите разбираться с этим сами? Мы возьмёмся за работу

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

Если у вас нет на это времени, желания или экспертизы — команда GuruPractice готова взять всё это на себя.

Мы работаем со скоростью WordPress и WooCommerce регулярно: знаем, какие настройки дают 80% результата за минимальное время, какие кэш-плагины конфликтуют с конкретными шлюзами, и как поднять PageSpeed с 30 до 85+ баллов без замены хостинга и переписывания темы с нуля.

Что входит в нашу работу по оптимизации скорости:

  • Полный аудит текущего состояния с отчётом в PageSpeed Insights, GTmetrix и WebPageTest

  • Настройка кэширования под вашу конкретную конфигурацию (с учётом WooCommerce, если он есть)

  • Оптимизация и конвертация всех изображений в WebP

  • Очистка и оптимизация базы данных

  • Аудит плагинов с рекомендациями по замене

  • Настройка CDN и серверного сжатия

  • Итоговое сравнение показателей «до» и «после» — прозрачно и наглядно

→ Обратитесь к нам на gurupractice.ru — опишите задачу, и мы ответим в течение нескольких часов.