Как ускорить WordPress: оптимизация Core Web Vitals шаг за шагом

Медленный WordPress почти всегда медленный не из-за самой платформы, а из-за хостинга, тяжёлой темы, десятков плагинов и неоптимизированных картинок. Хорошая новость в том, что причины можно найти и устранить. Ниже порядок действий, по которому мы ускоряем сайты, и подход к метрикам Core Web Vitals.

Три метрики, которые нужно понимать

Core Web Vitals описывают реальный опыт пользователя. Google рекомендует ориентироваться на следующие значения для 75-го процентиля посетителей, а подробности есть в материале web.dev о Core Web Vitals.

• LCP (Largest Contentful Paint): скорость появления главного элемента страницы. Хорошо: до 2,5 секунды.
• INP (Interaction to Next Paint): отзывчивость на клики и нажатия. Хорошо: до 200 миллисекунд.
• CLS (Cumulative Layout Shift): стабильность вёрстки, то есть насколько «прыгает» содержимое. Хорошо: до 0,1.

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

Сначала измерьте, потом оптимизируйте

Откройте PageSpeed Insights и посмотрите два блока: полевые данные реальных пользователей и лабораторный тест. Полевые данные важнее, потому что именно они отражают опыт людей. Затем найдите в отчёте самый большой источник потерь, а не пытайтесь выполнить все рекомендации подряд. Для диагностики на самом сайте полезны панель Network и вкладка Performance в браузере, а на WordPress ещё и плагин, показывающий запросы к базе и время работы хуков.

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

• TTFB (время до первого байта) на ключевых страницах;
• LCP, INP и CLS по полевым данным и по лабораторному тесту;
• общий вес страницы и число запросов;
• список установленных плагинов с отметкой, какие из них грузят скрипты на витрине.

Фундамент: хостинг, PHP и кэш

Если время ответа сервера (TTFB) велико, никакие оптимизации картинок не спасут LCP. Что стоит проверить в первую очередь:

• актуальная версия PHP, а не устаревшая 7.x;
• качественный хостинг или VPS с достаточными ресурсами вместо перегруженного общего тарифа;
• страничный кэш: отдача готового HTML вместо генерации страницы на каждый запрос;
• объектный кэш (Redis или Memcached) для динамичных сайтов и магазинов;
• CDN для статических файлов, если аудитория распределена по разным странам;
• сжатие Brotli или Gzip и современный протокол HTTP/2 или HTTP/3.

Ориентир для времени ответа сервера: по рекомендациям web.dev хороший TTFB составляет до 0,8 секунды. Если ваш сайт отвечает заметно дольше, начинайте с хостинга, кэша и запросов к базе данных, а не с оптимизации интерфейса.

Улучшаем LCP: картинки и критический путь

На большинстве страниц главный элемент — это изображение в первом экране. Его нужно отдать как можно раньше. Подробное руководство по этой метрике приведено в статье Optimize LCP. На практике работают такие шаги:

1. Конвертируйте изображения в WebP или AVIF и отдавайте размеры под реальный экран через srcset.
2. Для главного изображения не включайте ленивую загрузку, а задайте ему высокий приоритет (fetchpriority=high).
3. Для остальных изображений ниже первого экрана включите loading=lazy.
4. Подключите шрифты с font-display: swap и загружайте только нужные начертания.
5. Уберите CSS и JavaScript, блокирующие отрисовку, или отложите их загрузку.

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

Улучшаем INP и CLS: скрипты и стабильность

Плохой INP чаще всего создаёт избыточный JavaScript: счётчики, виджеты чатов, слайдеры, тяжёлые конструкторы страниц. Просмотрите, какие скрипты реально нужны. Подключайте их условно, только на нужных страницах, и откладывайте сторонние сервисы до взаимодействия пользователя. Рекомендации по метрике собраны в материале Optimize INP.

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

Отдельно оцените тему и конструктор страниц. Тяжёлые мультитемы загружают стили и скрипты для десятков функций, которыми вы не пользуетесь. Выбирайте лёгкую тему или блочную тему на редакторе Gutenberg, отключайте неиспользуемые виджеты и модули конструктора, а шаблоны страниц делайте простыми: вложенность блоков тоже замедляет отрисовку.

Чистка плагинов и базы данных

Удалите неиспользуемые плагины и темы, замените несколько плагинов одним специально написанным решением, если они закрывают одну задачу. Очистите ревизии записей, просроченные транзиенты и данные удалённых плагинов, проверьте автозагружаемые опции: именно они загружаются при каждом запросе. Для магазинов отдельная история с корзиной и каталогом, о ней рассказываем в материале про скорость и конверсию WooCommerce.

Обновляйте ядро WordPress, темы, плагины и версию PHP: новые версии нередко работают быстрее и закрывают уязвимости. Перед обновлением делайте резервную копию и проверяйте результат на тестовой копии сайта, особенно если у вас магазин или нестандартные плагины.

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

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

Как удержать результат

• замерить LCP, INP и CLS на главной, странице услуги и карточке товара;
• проверить, не появились ли новые скрипты в сетевой панели;
• сравнить вес страницы с прошлой версией;
• убедиться, что кэш очищается и работает для новых страниц.

Скорость деградирует незаметно: новый баннер, новый плагин, новая реклама. Заведите привычку замерять метрики после каждого значимого обновления, следите за отчётом Core Web Vitals в Search Console и задайте бюджет: например, не загружать на страницу больше определённого объёма скриптов. Если нужен аудит скорости вашего сайта и список исправлений с приоритетами, запросите расчёт, и мы покажем, где именно вы теряете секунды.

Поделиться:XLinkedInWhatsApp