Как вывести WordPress в зелёную зону Google PageSpeed без плагинов-комбайнов

Меня зовут Егор Воронов, я сооснователь FastUp.by и отвечаю в студии за разработку.

Когда речь заходит о выборе стека под новый проект, в сообществе часто слышен привычный вердикт: «WordPress — это устаревший тормозной комбайн, сайт на нем еле грузится. Для нормальной скорости нужно сразу собирать Headless CMS или переписывать всё на Next.js».

А если проект всё-таки делают на WordPress, решения обычно ищут в установке пяти сторонних плагинов оптимизации, которые обещают «ускорение в один клик». По факту в проект приезжает куча ненужного кода, а динамические блоки вроде счетчика корзины перестают обновляться.

Я перфекционист (хоть это иногда и мешает в продакшене), поэтому решил проверить эту догму на практике. Мы вывели собственный сайт в зеленую зону Google PageSpeed Insights (фундаментальный стандарт нашего SEO-продвижения) по всем категориям сразу, на мобильной и десктопной вкладке: производительность, специальные возможности, рекомендации, поисковая оптимизация. Плюс полный балл в новой категории «Агентный» — это про то, насколько сайт готов к чтению ИИ-агентами.

Отдельно про последний пункт. Сайт мы собирали так, чтобы его было удобно читать ИИ-поисковикам: подробная микроразметка, отдельная страница под каждый интент вместо одной страницы обо всем сразу, файл llms.txt.

Причем без переезда на Next.js, без сложного Headless-стека и без плагинов-комбайнов за 50/месяц. Оказалось, чтобы снять все возражения о «тормознутости WordPress», достаточно навести порядок в коде темы своими руками.

Сразу уточню, что означают эти цифры, а что нет. PageSpeed Insights показывает две разные вещи: лабораторный прогон Lighthouse на эмуляторе мобильного устройства и данные о реальных пользователях из отчета CrUX. Зеленые оценки по категориям — это про лабораторную часть. Она честно показывает, что на странице нет тяжелого мусора, но не заменяет наблюдения за живыми посетителями на их реальных телефонах и каналах связи.

Что нужно сделать, чтобы WordPress вышел в зеленую зону

Если коротко, весь список работ выглядит так, и ни один пункт не требует платного плагина:

1. Отказаться от веб-шрифтов в пользу системного стека — минус внешний запрос и нулевой сдвиг макета.
2. Вычистить дефолтный фронтенд WordPress: emoji-скрипты, стили Gutenberg, wp-embed, jQuery. Последний — только на фронте, в админке он должен остаться.
3. Отдавать CSS с высоким приоритетом и версионировать файл по filemtime(), чтобы повторные переходы шли из кэша браузера.
4. Отложить сторонние счетчики (Яндекс.Метрика, GTM) до первого действия пользователя, а не грузить их при открытии страницы.
5. Кэширование и сжатие отдать серверу (LiteSpeed, Nginx), а структуру скриптов и стилей держать руками в коде темы.
6. Проверить контраст цветов — в категории «Специальные возможности» это обычно единственная претензия.
7. Микроразметку вывести нативно, без SEO-плагина, если нужна связность данных для ИИ-поисковиков.

Дальше — по каждому пункту подробно: за счет чего собираются эти цифры, с какими граблями мы столкнулись и готовые сниппеты кода.

1. Системные шрифты: убираем лишнюю зависимость и CLS = 0

Первый шаг, который срезает проблемы со скоростью и сдвигами макета (CLS): отказ от сторонних веб-шрифтов (Google Fonts и файлов WOFF2).

Для своих проектов я использую исключительно системный стек шрифтов (font-sans в Tailwind: system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, sans-serif).

Почему это работает:

1. Шрифты уже загружены на устройстве пользователя. Браузеру не нужно делать DNS-запрос к стороннему хосту, устанавливать TLS-соединение и качать 50–100 КБ шрифтовых файлов.
2. Нулевой сдвиг макета (CLS = 0). Текст не «прыгает» при смене дефолтного системного шрифта на кастомный (так называемый FOIT/FOUT эффект).
3. Минус один источник отказа. Зачем тащить внешнюю зависимость там, где современные системные шрифты из коробки выглядят отлично?

2. Главная боль: «Запросы, блокирующие отрисовку»

Главный факап любого WordPress-сайта на тестах Mobile PageSpeed — пункт «Устраните ресурсы, блокирующие отображение». Именно там обычно висит самая крупная обещанная экономия из всего отчета.

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

Что мы сделали в коде темы fastup-v2:

Мы вынесли всю логику сайта в кастомную модульную тему и вычистили весь дефолтный фронтенд-мусор WordPress в файле inc/wp-cleanup.php.

<?php // 1. Полное отключение emoji remove_action('wp_head', 'print_emoji_detection_script', 7); remove_action('wp_print_styles', 'print_emoji_styles'); // 2. Отключение стилей Gutenberg и системных скриптов на фронтенде add_action('wp_enqueue_scripts', function() { if (is_admin()) return; wp_dequeue_script('wp-embed'); wp_dequeue_style('wp-block-library'); wp_dequeue_style('wp-block-library-theme'); wp_dequeue_style('global-styles'); wp_dequeue_style('classic-theme-styles'); }, 100); // 3. Отключение jQuery на фронтенде (если скрипты написаны на Vanilla JS) add_action('wp_default_scripts', function(&scripts) {
    if (!is_admin()) {
        scripts->remove('jquery');scripts->remove('jquery-core');
        scripts->remove('jquery-migrate'); } }, 9999);

Отдельно про jQuery, потому что это место, где легко сломать себе сайт. Если отключить его полностью, в админке что-нибудь обязательно слетит. Поэтому условие простое: если не админка — отключаем jQuery, в самой админке он остается жить. Заодно для производительности я скрыл верхнюю админ-панель, которая показывается залогиненному пользователю.

Минимизация задержки блокировки рендера CSS

Сайт сверстан на Tailwind CSS v4. Весь итоговый стилевой файл весит меньше 47 КБ (а с brotli-сжатием — около 8–10 КБ). Чтобы браузер скачивал его с наивысшим приоритетом сетевого стека, мы перехватываем тег в inc/enqueue-scripts.php:

<?php add_filter('style_loader_tag', function (html, handle,href, media) { if ('fastup-v2-style' ===handle) {
        return sprintf(
            '<link rel="preload" href="%s" as="style" fetchpriority="high">' . "n" . 
            '<link rel="stylesheet" id="%s-css" href="%s" media="%s" fetchpriority="high" />' . "n",
            esc_url(href), esc_attr(handle),
            esc_url(href), esc_attr(media)
        );
    }
    return $html;
}, 10, 4);

Preload я сюда добавил после замеров, а не на всякий случай: без него получалась та самая блокировка отрисовки — сначала уходит запрос, потом приходит ответ, и только потом браузер начинает что-то рисовать. Спекулятивный парсер браузера (Preload Scanner) начинает качать CSS мгновенно. При этом файл версионируется через filemtime(), благодаря чему повторные переходы между страницами отдаются из дискового кэша за 0 мс.

3. Аналитика (Яндекс.Метрика и GTM): как перестать терять баллы из-за чужих скриптов

Сторонние счетчики серьезно бьют по производительности. Скрипты не твои: ты не можешь назначить им правильные заголовки кэширования, не можешь поправить их код. А они еще и подгружают картинки без прописанных alt или неоптимизированные фреймы (например, карты Яндекса).

Дефолтное подключение Метрики и GTM блокирует поток процессора (TBT / Total Blocking Time) на мобильных устройствах на 300–500 мс.

Наше решение: грузить аналитику после первого действия пользователя

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

<script>
(function() {
  var loaded = false;

  function loadAnalytics() {
    if (loaded) return;
    loaded = true;

    // 1. Google Tag Manager
    var g = document.createElement('script');
    g.async = true;
    g.src = 'https://www.googletagmanager.com/gtag/js?id=G-YOUR-ID';
    document.head.appendChild(g);

    window.dataLayer = window.dataLayer || [];
    function gtag(){ dataLayer.push(arguments); }
    window.gtag = gtag;
    gtag('js', new Date());
    gtag('config', 'G-YOUR-ID');

    // 2. Яндекс.Метрика
    (function(m, e, t, r, i, k, a) {
        m[i] = m[i] || function() { (m[i].a = m[i].a || []).push(arguments); };
        m[i].l = 1 * new Date();
        k = e.createElement(t); a = e.getElementsByTagName(t)[0];
        k.async = 1; k.src = r; a.parentNode.insertBefore(k, a);
    })(window, document, 'script', 'https://mc.yandex.ru/metrika/tag.js?id=YOUR_METRIKA_ID', 'ym');

    ym('YOUR_METRIKA_ID', 'init', {
        ssr: true, webvisor: true, clickmap: true, accurateTrackBounce: true, trackLinks: true
    });
  }

  // Резервный запуск через 3.5 секунды (если пользователь вообще не двигает экран)
  var timer = setTimeout(loadAnalytics, 3500);

  // Мгновенный запуск при первом физическом касании / движении мыши / скролле
  ['mousemove', 'touchstart', 'scroll', 'keydown'].forEach(function(ev) {
    window.addEventListener(ev, function() {
      clearTimeout(timer);
      loadAnalytics();
    }, { once: true, passive: true });
  });
})();
</script>

Результат:

• Пока страница отрисовывается и пользователь ещё ничего не сделал, аналитика не тратит ни 1 миллисекунды процессора. Показатель TBT = 0 мс.
• Живой посетитель при первом касании экрана мгновенно инициализирует скрипт: вебвизор, цели и клики фиксируются дальше как обычно.

Честно про цену этого приема. Посетитель, который открыл страницу и ушел, не сделав вообще ничего в течение 3.5 секунд, в статистику не попадет. Насколько это меняет картину по визитам и отказам, я не мерил: сравнения данных Метрики до и после у меня нет, я ориентировался на замеры PageSpeed и правил до тех пор, пока показатель не выходил из красной зоны в зеленую. Сами 3.5 секунды я тоже взял на глаз, а не подобрал по замеру. Если страница у вас грузится быстрее, резервный таймер можно ставить меньше или убирать совсем.

4. Почему готовые плагины оптимизации часто ломают сайт

Когда разработчики пытаются решить проблему скорости установкой плагинов вроде WP Rocket, Autoptimize или LSCache с включением галочек «Объединить CSS/JS», обычно начинается головная боль.

В чем проблема автоматических комбайнов:

1. Подгрузка лишнего кода. Плагин не знает специфики вашей темы и на всякий случай тянет полифилы и обертки, которые в большинстве случаев избыточны. Тут вообще стоит остановиться и подумать: если тебе нужна одна маленькая функция из целого комбайна, проще попросить нейронку написать под нее кусочек скрипта. Это быстрее, и в проект не приезжает куча функционала, который тебе не нужен.
2. Полностраничное кэширование ломает динамические блоки. Классический пример — счетчик товаров в корзине, который перестает обновляться. Я ловил это на двух разных проектах с корзиной, так что проблема массовая. Причина в том, что плагин кэширует страницу целиком, а не компонентами. То же самое происходит с авторизацией: пользователь залогинился, а аватарка и никнейм в шапке не поменялись, потому что отдается кэш.

На своем сайте я кэширую почти все, кроме кнопки авторизации — то есть выношу из кэша ровно тот кусок, который обязан быть живым.

Наш принцип: кэширование страниц и сжатие отдавать на уровень сервера (LiteSpeed / Nginx), а структуру скриптов и стилей контролировать руками в коде темы.

5. Accessibility и Best Practices: почти весь пласт закрывается одной правкой оттенка

Единственное, на что у меня ругался Lighthouse в этой категории, — контрастность цветов. Пласт типовой, он вылезает практически на любом сайте.

Так как верстка на Tailwind и все цвета я брал нативные из его палитры, чинилось это одной правкой. Основной небесно-голубой был sky-500. Я поменял его в CSS-инпуте на sky-700: цвет тот же самый, оттенок чуть темнее, контраст с фоном вырос до нормы. Дизайн визуально не поехал, а категория закрылась.

С Best Practices отдельной работы не было вообще: там все получилось автоматически.

6. Откуда у WordPress репутация «тормозного старья» и стоит ли переплачивать за Next.js?

Давайте честно: почему к WordPress в 2026 году у многих разработчиков и заказчиков предвзятое отношение?

1. Миллион кривых сайтов из 2010-х. На WP сделана огромная доля рунета. Из них куча древних проектов, собранных на Elementor, старом Gutenberg или верстках джуниоров десятилетней давности без следования современным стандартам. Люди видят эти сайты и переносят свой негативный опыт на сам движок.
2. «Сложная админка». Это я слышу от клиентов регулярно: в Тильде можно редактировать визуально, а в WordPress админка сложная. На самом деле она не сложная, она очень многофункциональная — а это разные вещи. Если зайти на конкретную страницу редактирования, там все максимально примитивно.
3. Иллюзия «легкости» конструкторов (Tilda). Заказчики уходят на Тильду, потому что там можно редактировать текст прямо на странице. Но по итогу получают визуальный конструктор с нулевым SEO-потенциалом, ограничением по функционалу и вечно растущей подпиской. Проходит полгода-год — и они всё равно приходят переделывать проект на WordPress. Мы разбирали это сравнение подробно в отдельной статье — WordPress или Тильда: что выбрать, и отдельно — что делать, если сайт на конструкторе уже тормозит.

Вот характерный разговор, буквально вчерашний. Клиент говорит: у нас сайт на конструкторе Битрикс24, конкуренция в нише низкая, и сайт, несмотря на то что он медленный, входит в топ-3. И добавляет: я знаю сайты на WordPress, которые работают гораздо медленнее.

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

WordPress vs Next.js: реальная экономика разработки

Сейчас модно кричать: «Вместо WordPress надо делать интернет-магазин на Next.js!».

Но давайте посчитаем деньги и время. Магазин или корпоративный сайт на Next.js с нуля, с собственной админкой — это кастомная разработка, и стоит она в разы дороже. Причина не в самом фреймворке: просто все, что в WordPress уже есть из коробки, тут пишется руками.

WordPress — это готовый, стабильный и обкатанный бэкенд. Да, он не самый элегантный, но он работает. Главная разница простая: сайт на конструкторе типа Тильды ограничен возможностями самой Тильды, а сайт на WordPress ограничен только навыками и фантазией вашего программиста.

Вместо того чтобы раздувать бюджет и тратить полгода на переезд на Next.js, достаточно провести базовый комплекс работ по чистке темы на WordPress. Это выйдет в разы быстрее, дешевле и выведет сайт в ту же зеленую зону. Мы так и делаем сайты клиентам — кастомная тема без конструкторов, разработка сайтов у нас устроена именно так.

7. Микроразметка Schema.org и нативный Sitemap (SEO & Agentic Web)

Сразу оговорка, чтобы не создавать ложную связь: балл 100 в категории SEO у Lighthouse набирается за другое — за наличие title и meta description, индексируемость, корректные ссылки, читаемый размер шрифта. Микроразметка там проходит по разделу ручных проверок и на балл не влияет вообще.

Schema.org мы делаем не ради этой сотни, а ради ИИ-поисковиков (ChatGPT, Perplexity, Google Gemini): им нужно понимать, что за организация стоит за сайтом и как связаны страницы. Как проверить, что нейросеть вообще видит ваш сайт, я разбирал отдельно.

Сразу оговорюсь про плагины, чтобы не выглядело красивее, чем есть. SEO-плагин у меня стоит — Rank Math, и он живет на сайте ровно ради одного: удобно проставлять title и description, там для этого нормальный интерфейс с сепаратором. Вся функциональная часть вынесена в отдельные файлы темы и плагина не касается: карта сайта — свой файл, сжатие изображений — свой, отключение лишнего — свой, микроразметка — свой. Вывод схемы у самого Rank Math выключен, иначе на странице оказалось бы два конфликтующих графа.

Что лежит в этих файлах:

1. Единый JSON-LD граф (inc/schema-org.php): выводится нативно через PHP. Включает сущности Organization, ProfessionalService с юридическими реквизитами, WebPage, BreadcrumbList и Article.
2. Нативный Sitemap (inc/sitemap.php): транзиентный генератор XML-карты сайта, собранный на нативных rewrite_rules WordPress. Карточка сбрасывается в кэш только при сохранении постов.

8. Серверный отклик TTFB: как drop-in кэш сократил время ответа с 7–10 с до ~0.8 с

Когда мы запускали сайт на shared-хостинге hoster.by, выяснилось, что популярный litespeed-cache не дает нужного эффекта: сайт работает под связкой Nginx и Apache, а не веб-сервера LiteSpeed, поэтому встроенный edge-кэш плагина оказался нерабочим, а «холодный» отклик страницы доходил до 7–10 секунд (замер curl -w '%{time_starttransfer}').

Устанавливать тяжелые плагины-комбайны с десятками настроек не хотелось. Поэтому мы написали собственное компактное решение — fastup-page-cache (суммарно 420 строк кода в двух файлах).

Как устроен механизм кэширования:

1. Drop-in advanced-cache.php (125 строк): файл копируется в директорию wp-content/advanced-cache.php и подключается ядром WordPress на самом раннем этапе загрузки при включенной константе define('WP_CACHE', true) в wp-config.php. PHP стартует, проверяет наличие закэшированного HTML-файла на диске и, если он не старше TTL (24 часа), отдает его клиенту с заголовком X-FastUp-Cache: HIT, полностью пропуская ресурсоемкую инициализацию темы, плагинов и запросов к MySQL.
2. Основной плагин fastup-page-cache.php (295 строк): управляет файлом drop-in, регистрирует хуки сброса кэша и добавляет кнопку очистки в админ-бар.
3. Надежная инвалидация: кэш автоматически сбрасывается при сохранении или удалении постов (save_post), редактировании таксономий, меню, настроек темы и обновлении метаполей ACF (хуки updated_post_meta / added_post_meta), что исключает показ устаревшей информации.

Результат: время до первого байта (TTFB) упало с 7–10 секунд до стабильных ~0.8 секунды, зафиксированных при прямых замерах через curl.

Итог

В сообществе принято считать: «Если у тебя WordPress — твой сайт обречен быть медленным». Как говорится, пускай говорят.

По факту весь интернет по-прежнему держится на PHP. Чтобы получить 100 баллов в Google PageSpeed на WordPress, не нужно изобретать велосипед, писать сложную Headless CMS или выкидывать сотни часов на Next.js.

Достаточно соблюдать банальную дисциплину разработки: убрать тяжелые визуальные билдеры, использовать системные шрифты, изолировать аналитику и доверять кэширование серверу.

Скорость при этом — только фундамент. Быстрый сайт сам по себе не приводит клиентов, он лишь перестает их терять: дальше нужна работа с содержанием и поисковой выдачей. Как мы считаем стоимость этой работы и почему первый месяц дороже остальных, я разбирал в статье про цены на SEO-продвижение в Беларуси.

Если ваш сайт на WordPress тормозит, а плагины оптимизации проблему не решили, напишите нам — посмотрим, что именно его держит, и скажем, чинится ли это чисткой темы или там нужна переделка (подробнее о том, почему нельзя латать старый legacy-код, читайте в отдельной статье).

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