Ускорение WordPress в 2026: Core Web Vitals...

О чём статья и зачем это всё

WordPress в 2026 году всё ещё способен быть быстрым, но только если перестать “лечить” сайт очередным плагином “Speed Booster 9000”.

Цель: привести сайт к предсказуемым метрикам Core Web Vitals:

LCP — насколько быстро появляется главный контент (обычно hero-блок/картинка/заголовок).
INP — насколько быстро сайт отвечает на клики/ввод (главный фронтовый “больной” показатель).
CLS — насколько “прыгает” верстка при загрузке.

Будем идти как инженеры: сначала измеряем → затем делаем узкие правки → фиксируем регрессии.

1) Сначала измеряем, потом “оптимизируем”

Если ты не зафиксировал baseline — ты не ускоряешь, ты надеешься.

Инструменты (минимум)

Lighthouse (лабораторные цифры, удобно сравнивать “до/после”).
PageSpeed Insights (подтягивает полевые данные, если они есть).
WebPageTest (waterfall, очень полезно для LCP/TTFB/third-party).
Chrome DevTools → Performance (ловить long tasks и причины плохого INP).

Какие страницы мерить (обязательно)

Не надо тестить только главную. Выбирай шаблоны, а не “странички”:

Главная
Категория / архив
Пост / статья
Карточка товара (Woo) / карточка услуги
Корзина, оформление (если e-commerce)
Страница с формой/калькулятором (если есть)

Фиксируем baseline (табличка)

Сделай табличку (хоть в Markdown, хоть в Notion):

Шаблон	URL	TTFB	LCP	INP	CLS	Вес страницы	Запросов	Примечания
Home	/
Post	/blog/…
Product	/product/…

Пример заполнения:

TTFB: время ответа сервера (целевой показатель < 200ms)
LCP: время загрузки главного контента (целевой показатель < 2.5s)
INP: время отклика на взаимодействие (целевой показатель < 200ms)
CLS: стабильность вёрстки (целевой показатель < 0.1)

Правило: любое изменение — повторяем замер в тех же условиях.

2) Быстрые победы за 30–60 минут (без “переписать тему”)

Это то, что часто даёт результат сразу.

2.1 Включи page cache (если его нет)

Если сайт не кэшируется страницами — ты каждый раз “рендеришь” WP заново. Это дорого.

Варианты:

Серверный fastcgi_cache (Nginx) — самый честный по скорости.
Плагинный page cache — быстрее внедрить, но иногда хуже контроль.

Сразу правило: не кэшировать корзину/чекаут/личный кабинет, и страницы, зависящие от cookies.

2.2 Поправь hero (LCP) — это почти всегда причина “почему медленно”

У hero-картинки должны быть:
- нормальные размеры (не 4000px шириной ради блока 1200px),
- современный формат (WebP/AVIF),
- корректный srcset/sizes (иначе мобилка грузит “как для кинотеатра”),
- никакого lazy на LCP-элементе.

2.3 Убери/отложи “маркетинговый зоопарк”

Чаты, виджеты, трекеры, A/B, попапы — они убивают INP и иногда LCP. Сейчас это главный “тихий киллер” производительности.

3) Серверный слой: TTFB и предсказуемость

Если TTFB плавает как рыба в пакете — LCP ты не стабилизируешь.

3.1 Минимальный адекватный стек

Nginx (reverse proxy)
PHP-FPM (под нагрузку)
OPcache (включён и настроен)
Redis (опционально, но часто очень полезно)
MariaDB/MySQL с нормальными параметрами и логами

3.2 PHP-FPM: базовая настройка, чтобы не было “502 как стиль жизни”

Смотри конфиг пула (путь зависит от дистрибутива), обычно:

Debian/Ubuntu: /etc/php/8.x/fpm/pool.d/www.conf
CentOS/RHEL: /etc/php-fpm.d/www.conf

Пример расчёта параметров:

Если у тебя 2GB RAM: pm.max_children = 10-15 (каждый процесс ~150MB)
Если у тебя 4GB RAM: pm.max_children = 20-25
Если у тебя 8GB RAM: pm.max_children = 40-50

Пример здравых параметров (адаптируй под RAM/CPU):

; /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

request_terminate_timeout = 60s

Логика:

pm.max_children = сколько PHP-процессов одновременно. Ставь по памяти: один процесс WP под нагрузкой может быть 80–200MB (и это не шутка).
pm.max_requests помогает “сбрасывать” утечки.

3.3 OPcache: must-have, но “включить” — недостаточно

Файл: /etc/php/8.x/fpm/conf.d/10-opcache.ini (или аналог)

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Если прод и деплоишь атомарно (релизы/ссылки), можно делать агрессивнее (меньше проверок), но тогда инвалидацию решай осознанно.

4) Кэш: 3 уровня, которые путают почти всех

4.1 Page cache (самый жирный профит)

Это кэш HTML, чтобы не гонять WP на каждый запрос.

Вариант A: Nginx `fastcgi_cache` (рекомендую)

Ниже примерный набросок. В проде обязательно оттюнь под свою схему cookies/URL.

# /etc/nginx/conf.d/wp-cache.conf

fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=2g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

map $http_cookie $skip_cache {
  default 0;
  ~*wordpress_logged_in 1;
  ~*comment_author 1;
  ~*woocommerce_items_in_cart 1;
  ~*wp_woocommerce_session_ 1;
}

map $request_uri $skip_cache_uri {
  default 0;
  ~*^/wp-admin/ 1;
  ~*^/wp-login.php 1;
  ~*^/cart 1;
  ~*^/checkout 1;
  ~*^/my-account 1;
}

server {
  # ...
  set $no_cache 0;
  if ($skip_cache = 1) { set $no_cache 1; }
  if ($skip_cache_uri = 1) { set $no_cache 1; }

  location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    fastcgi_cache WORDPRESS;
    fastcgi_cache_bypass $no_cache;
    fastcgi_no_cache $no_cache;

    fastcgi_cache_valid 200 301 302 10m;
    add_header X-Cache $upstream_cache_status always;
  }
}

Смысл:

Гости получают HTML из кэша.
Авторизованные/корзина/чекаут — мимо.

Вариант B: Плагин кэширования

Если нет доступа к Nginx или хочется быстро:

WP Rocket / LiteSpeed Cache (если LS) / W3TC / Cache Enabler — вариантов много. Главное: проверяй, что реально отдаётся статика, а не “кэш включен в настройках”.

4.2 Object cache (Redis/Memcached)

Это не “ускоритель всего”, это ускоритель повторяющихся запросов к базе/объектам.

Когда заметно помогает:

WooCommerce
Сайты с большим количеством опций, мета, сложными запросами
Высокая посещаемость

Самый типовой путь:

поднять Redis,
поставить плагин Redis Object Cache,
включить object cache,
посмотреть, что hit rate нормальный.

4.3 OPCache (кэш байткода PHP)

Если OPcache выключен — ты реально компилируешь PHP каждый запрос. В 2026 это выглядит как “зачем ты так с собой”.

5) База данных и запросы: меньше боли — больше эффекта

5.1 Сначала найди, что реально тормозит

Подключи:

Query Monitor (на время диагностики)
MySQL/MariaDB slow query log (на сервере)

Включение slow log (очень грубо, идея)

В my.cnf (путь зависит от системы):

slow_query_log=1
long_query_time=0.5
slow_query_log_file=/var/log/mysql/slow.log

Дальше анализируй: какие запросы долгие, какие повторяются, кто их вызывает (плагин/тема).

5.2 Типовые “минные поля” WP

autoload опции раздуты (ты грузишь половину сайта в память при каждом хите).
транзиенты растут как дрожжи.
ревизии и мусор.
отсутствие индексов на кастомных таблицах (если делали “как получится”).

Минимальная гигиена:

чистка ревизий/транзиентов (аккуратно, не на проде “с плеча”).
аудит wp_options на autoload.

6) Тема и фронт: лечим LCP/CLS/INP без шаманства

6.1 LCP: главный кадр

Что чаще всего делает LCP плохим:

“герой” — огромная картинка,
рендер-блокирующие CSS,
шрифты, которые блокируют рендер,
TTFB (сервер не успевает).

Практика:

hero-картинку: правильный размер + WebP/AVIF + preload.
критические стили — минимизировать, остальное грузить позже (если используешь решения вроде “critical CSS”, делай осознанно).

6.2 CLS: прыгающая вёрстка

CLS обычно ломают:

изображения без размеров,
вставки баннеров/виджетов “позже”,
webfonts без нормальных фоллбеков.

Фиксы:

всегда резервируй место под медиа (ширина/высота/соотношение).
под виджеты — контейнер фиксированной высоты + скелетон (хоть простой).
шрифты — font-display: swap; и в идеале preload критичных.

Пример резервирования места под изображение:

<!-- Плохо: CLS будет прыгать -->
<img src="image.jpg" alt="..." />

<!-- Хорошо: место зарезервировано -->
<div style="aspect-ratio: 16/9; background: #f0f0f0;">
  <img src="image.jpg" alt="..." width="1200" height="675" loading="lazy" />
</div>

<!-- Или через CSS -->
.image-wrapper { aspect-ratio: 16 / 9; width: 100%; }

Пример скелетона для виджета:

<div
  class="widget-skeleton"
  style="height: 300px; background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%); background-size: 200% 100%; animation: loading 1.5s infinite;"
>
  <!-- Виджет загрузится сюда -->
</div>

6.3 INP: сайт должен отвечать на клики, а не “подумать”

INP в WP чаще всего портят:

тяжёлые темы/конструкторы,
слайдеры/анимации,
third-party скрипты,
куча обработчиков событий и long tasks.

Как чинить по шагам:

В DevTools → Performance запиши профиль при клике по меню/кнопке.
Найди long task (обычно 100–500+ ms).
Определи источник: файл темы/плагина/виджета.
Убери лишнее или отложи:
- defer/delay для неважных скриптов,
- загрузка по взаимодействию (клик/скролл),
- отключение скрипта на страницах, где он не нужен.

Если “всё на Elementor и жить хотим красиво” — жить можно, но INP будет дороже в починке. Тут или дисциплина, или боль.

7) Медиа: WebP/AVIF, lazy, CDN — по-взрослому

7.1 Форматы

WebP — стабильная база.
AVIF — часто лучше по размеру, но тяжелее по энкодингу (генерировать на сервере аккуратно).

7.2 Lazy loading: где можно, где нельзя

Нельзя делать lazy для элемента, который является LCP (обычно hero).
Можно для всего, что ниже первого экрана.

Пример правильного использования:

<!-- Hero - НЕ lazy, это LCP элемент -->
<img src="hero.webp" loading="eager" fetchpriority="high" alt="..." />

<!-- Изображения ниже fold - можно lazy -->
<img src="content-1.webp" loading="lazy" alt="..." />
<img src="content-2.webp" loading="lazy" alt="..." />

<!-- Или через нативный lazy (браузер сам решит) -->
<img src="content-3.webp" loading="lazy" alt="..." />

7.3 CDN

CDN оправдан, если:

много трафика,
много тяжелых медиа,
география широкая,
сервер “на коленке” и ты не хочешь его раздувать.

8) Плагин-диета: как выжить без “ещё одного оптимизатора”

Правило простое: каждый плагин должен платить аренду.

8.1 Как понять, кто жирный

открой DevTools → Network,
смотри, кто добавляет CSS/JS,
проверь, грузится ли это на всех страницах.

Типовой ад:

плагин формы грузит свои скрипты даже на странице “О компании”.
плагин галереи тянет 300KB JS ради одного блока.

8.2 Нормальная стратегия

отключать ассеты на ненужных страницах (через настройки плагина или специализированные инструменты),
не ставить “комбайны”, которые делают всё и конфликтуют со всем,
лучше один качественный кеш/оптимизатор, чем три “ускорителя”, которые дерутся за одно и то же.

9) Third-party скрипты: маркетинг любит тормоза, но это лечится

Тут компромисс, не война.

Что делать:

загружать по взаимодействию (первый клик/скролл),
откладывать чаты до 10–15 секунд или до просмотра 2–3 страниц,
резать дубликаты аналитики (да, такое бывает).

Если у тебя 6 счётчиков, 2 пикселя, чат, виджет “мы перезвоним” и ещё “тепловая карта” — INP будет не просто плохим, он будет оскорблённым.

10) Контроль качества: чтобы не деградировать через неделю

Самая частая проблема: “мы ускорили” → поставили новый плагин → вернулись в болото.

10.1 Мини-регрессия

Список контрольных URL (шаблоны) + замер после каждого релиза.

10.2 Мониторинг

Минимум:

uptime,
TTFB,
размер страницы,
количество запросов.

Если хочешь совсем по-взрослому:

RUM (полевые метрики от реальных пользователей) — но это отдельная тема.

Итоговый чек-лист (коротко)

Сервер

PHP-FPM настроен под нагрузку
OPcache включён и адекватно настроен
TTFB стабилен

Кэш

Page cache работает для гостей
Исключения настроены (admin/cart/checkout/account)
Object cache (Redis) включён там, где нужен

Медиа

LCP-элемент не lazy
WebP/AVIF, нормальные размеры, srcset/sizes
Ненужные тяжелые медиа убраны/заменены

Тема/фронт

CLS не прыгает (резервирование размеров)
INP контролируем (нет long tasks из “мусорного” JS)

Плагины/third-party

Плагинов минимум, ассеты точечно
Чаты/виджеты/метрики отложены и дисциплинированы

Что делать прямо сегодня (план на 2–3 часа)

Замерь baseline на 5–7 ключевых шаблонах (таблица).
Почини LCP (hero без lazy + форматы + размер).
Включи page cache (Nginx или плагин).
Сними Performance профиль и найди причину плохого INP.
Отложи third-party и выкинь лишнее.
Повтори замер, зафиксируй улучшения.

Requirements