Три лучших способа повысить скорость сайта и оптимизировать Core Web Vitals в WordPress

Отключите ненужные блоки в теме. Любой готовый шаблон WordPress приходит с ворохом JS-обработчиков, шрифтов, анимаций. Это балласт. Если не используется – удалить. В functions.php уберите загрузку лишнего:


function remove_unwanted_assets() {
  wp_dequeue_style(\'elementor-icons\');
  wp_dequeue_script(\'some-theme-animation\');
}
add_action(\'wp_enqueue_scripts\', \'remove_unwanted_assets\', 100);


Это сразу снимает нагрузку с первой отрисовки. Время до интерактивности падает. CLS – в норме. Но это ещё не всё.

Асинхронная подгрузка шрифтов

Собираете все используемые гарнитуры. Переводите в woff2. Вставляете preload с атрибутом crossorigin. Далее – font-display: swap. Пример:


<link rel=\"preload\" href=\"/fonts/roboto.woff2\" as=\"font\" type=\"font/woff2\" crossorigin>


И добавьте в CSS:


@font-face {
  font-family: \'Roboto\';
  src: url(\'/fonts/roboto.woff2\') format(\'woff2\');
  font-display: swap;
}


Важно: удалите подключение Google Fonts через внешние CDN. Они тормозят рендеринг даже при DNS prefetch.

Кэш с умом. И на уровне сервера

LiteSpeed Cache – не просто очередной плагин. Он в связке с сервером. Обходит все WP Rocket. Автогенерация критического CSS, оптимизация ESI-блоков. Кэш заголовков, кэш запросов в базу, объектный кэш. Никакой Redis не нужен, всё внутри.

Внимание! Использование нескольких кэш-плагинов одновременно – гарантия конфликта. Работает один, остальные мешают.

Проверьте, что активирована функция QUIC.cloud CDN – сжатие изображений и передача через HTTP/3.

Заключение

Зашумлённый frontend, шрифты с внешнего CDN, и кэш, который живёт сам по себе – вот три якоря. Уберите их. Почувствуйте, как всё поехало. Быстро. Без рывков. Без провалов по LCP. Больше не нужно догадываться, где потери – всё под контролем.

Оптимизация загрузки изображений с помощью современных форматов и lazy loading

Замените JPEG и PNG на WebP или AVIF. Они сжимают без потерь качества: WebP экономит до 30% размера, AVIF – до 50% по сравнению с JPEG. Разница ощутима. Особенно на мобильных.

В WordPress поддержка WebP встроена с версии 5.8. Для AVIF используйте плагин Converter for Media или настройте конвертацию на уровне CDN. Cloudflare и BunnyCDN уже умеют.

Теперь ленивые загрузки. Добавьте атрибут loading=\"lazy\" ко всем изображениям. WordPress делает это автоматически начиная с 5.5, но это касается только тех, что вставлены через редактор Gutenberg. В шаблонах темы? Проверьте вручную.

Пример:

<img src=\"image.webp\" loading=\"lazy\" width=\"600\" height=\"400\" alt=\"Описание\">

Важно прописывать width и height – браузер зарезервирует место под картинку. Без этого происходит смещение контента. Cumulative Layout Shift растет. И всё летит к черту.

Для управления изображениями в WordPress лучше использовать wp_get_attachment_image() – она сама подставляет нужные размеры и атрибуты.

Вот так:

<?php echo wp_get_attachment_image( $image_id, \'large\', false, [\'loading\' => \'lazy\'] ); ?>

Важно помнить: lazy loading не работает для изображений, находящихся в верхней части страницы. Первое изображение всегда должно загружаться без задержки. Проверяйте через DevTools – смотрите загрузку по слоям, а не по интуиции.

Внимание! Никогда не используйте WebP для логотипов, иконок и графики с прозрачностью, если нет AVIF – в WebP нет поддержки CMYK, могут быть артефакты.

Отдельный ад: вставка изображений через кастомные поля без проверки. Многие темы используют get_field() (ACF). Убедитесь, что разработчик не вставляет <img> руками без loading и размеров. Это тонкая ловушка.

Для массового обновления старых изображений используйте Regenerate Thumbnails + Enable Media Replace + скрипт на сервере для пересоздания миниатюр в WebP. Не делайте это через панель – сломаете хостинг.

Помните! Использование современных форматов без ленивой загрузки – это всё равно что надеть гоночные шины на сломанный велосипед.

Логика простая. Меньше вес – быстрее отрисовка. Меньше запросов – стабильнее загрузка. Всё остальное – косметика.

Минимизация и асинхронная загрузка JavaScript для снижения времени до интерактивности

Внимание! Не используйте wp_enqueue_script без условий. Оборачивайте подключение в if ( is_page(\'checkout\') ) или аналогичные конструкции.

Минимизируйте JS через автопрефиксеры и агрегаторы, но не забывайте о конфликте между Autoptimize и кеширующими плагинами. Для WordPress безопаснее всего включать агрегацию только для несторонних скриптов, чтобы избежать дублирования.

Асинхронность – обязательна. Скрипты, не влияющие на above-the-fold, подключайте с атрибутом async или defer. Разница критична: async – параллельная загрузка и немедленное выполнение, defer – после парсинга DOM. Для аналитики и рекламных сетей – async. Для пользовательских и кастомных – defer.

<script src=\"example.js\" defer></script>
<script src=\"analytics.js\" async></script>

Замените инлайновые события на делегирование. Инлайновый JS в HTML (onclick, onload) тормозит рендер. Используйте делегирование через addEventListener в общем скрипте, загруженном с отложенным приоритетом.

Важно помнить: каждый лишний килобайт JS увеличивает TTI. Оптимизация начинается не с подключения, а с переосмысления архитектуры.

Разбивайте скрипты по страницам. Разработайте условные модули: админка – один пакет, лендинг – другой. Используйте wp_register_script и динамически регистрируйте нужное.

if ( is_front_page() ) {
wp_register_script( \'landing\', get_template_directory_uri() . \'/js/landing.js\', [], null, true );
wp_enqueue_script( \'landing\' );
}

Удалите всё, что не участвует в первичном взаимодействии. Lazy Load скриптов – не роскошь, а норма. Воспользуйтесь плагином Flying Scripts: настройте задержку для любых скриптов, не связанных с кликом или скроллом.

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

Настройка серверного кеширования и CDN для ускорения ответа сервера

Начните с включения Object Cache на сервере. Без него WordPress каждый раз делает одно и то же: загружает одни и те же данные из базы. Используйте Redis или Memcached. Убедитесь, что установлен и активирован плагин Redis Object Cache, а сервер поддерживает расширение phpredis.

Внимание! Без Object Cache нагрузка на базу данных возрастает в разы, особенно при большом трафике.

Проверьте, активирован ли кеш транзиентов. Для этого задайте хранение транзиентов в Redis, а не в базе. Пример настройки в wp-config.php:

define(\'WP_REDIS_DISABLED\', false);
define(\'WP_CACHE_KEY_SALT\', \'example.com:\');

Теперь CDN. Используйте Cloudflare, но не полагайтесь на него по умолчанию. Настройте Edge кеш на уровне запросов. Активируйте Page Rules или лучше – используй Cloudflare Workers с кастомной логикой. Например, обрабатывайте только GET-запросы и игнорируйте куки:

if (request.method === \"GET\" && !request.headers.get(\"cookie\")) {
// Serve from cache
}

CDN не должен проксировать админку и WP-Cron. Добавьте исключения:

• /wp-admin/*
• /wp-login.php
• ?doing_wp_cron

Следующий уровень – кеш HTML. Если вы используете WP Super Cache или LiteSpeed Cache, убедитесь, что включено кеширование для мобильных и что применяется кеш на первой загрузке. Не ждите второго запроса.

Важно помнить: кеш на сервере и CDN должны синхронизироваться. Если один показывает старое, а другой новое – пользователи получают хаос.

При использовании NGINX добавьте fastcgi-кеш. Пример конфигурации:

fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=WORDPRESS:100m;
fastcgi_cache_key \"$scheme$request_method$host$request_uri\";
fastcgi_cache_use_stale error timeout updating;

Проверьте заголовки: X-Cache, CF-Cache-Status. Нет «HIT»? Значит, кеш не работает. Лечите.

Сложность – в нюансах. Один плагин может сбрасывать весь кеш на каждое обновление поста. Найдите виновника. Отключайте все по очереди и смотрите на curl -I.

Решение есть. Но его нужно выжать. До последнего байта.

Удаление ненужных стилей и сокращение CSS для уменьшения Cumulative Layout Shift

Сначала вырежьте всё лишнее. Удалите неиспользуемые классы, особенно те, что приходят из библиотек вроде Bootstrap или Tailwind, если они используются частично. Сканируйте тему и плагины через purgecss или UnCSS, подключая только те селекторы, что реально присутствуют в DOM.

В WordPress проблема усугубляется плагинами. Почти каждый второй добавляет свои стили глобально, даже если нужен только на одной странице. Используйте wp_dequeue_style() и wp_deregister_style() внутри wp_enqueue_scripts с условием по is_page() или is_singular().

add_action( \'wp_enqueue_scripts\', \'remove_plugin_styles\', 100 );
function remove_plugin_styles() {
if ( ! is_page(\'kontakty\') ) {
wp_dequeue_style(\'contact-form-7\');
wp_deregister_style(\'contact-form-7\');
}
}

Минификация не обсуждается – обязательно. Используйте autoptimize или fast velocity minify, но отключите автослияние, если используете HTTP/2. Цель – сократить вес без потери контроля над порядком загрузки.

Структура CSS должна быть модульной. Вынесите критические стили в <head>, отложите остальное. Воспользуйтесь critical-css от wp-rocket или напишите вручную. Даже 100 мс задержки загрузки стилей шапки – это дергание интерфейса.

Важно: CLS растёт при любой перестановке элементов. Необработанные CSS-анимации, шрифты без резервных стилей, отложенные фреймы – всё это провоцирует скачки макета.

Шрифты – отдельная боль. Никогда не загружайте их без font-display: swap. Не применяйте нестандартный line-height к <h1> и <p> до загрузки webfont. Используйте system-ui или подгрузку через preload.

Иконки через шрифты? Удалите. Подключайте SVG напрямую или через <use> – это на 80% уменьшает влияние на рендеринг и убирает прыжки при генерации спрайта.

Внимание! Даже одно свойство padding без box-sizing: border-box способно выбить всю сетку, особенно в кастомных Gutenberg-блоках.

Минимум CSS, жёсткий контроль за последовательностью и обязательное тестирование через DevTools – только так.