Поднимаем скорость загрузки сайта на wordpress — без дополнительных плагинов, только ручным способом.

Оптимизация

02.06.2026

Всех приветствую!

За свою многолетнюю практику я постоянно сталкиваюсь с тем, что рано или поздно любой сайт на wordpress начинает «тормозить». Чаще всего с такой деградацией производительности веб-сайта я сталкиваюсь в локально разработке. Добавляя для тестов новый плагин, новую тему, новую логику в код, всегда происходит «замусоривание» сайта. И он начинает работать все медленнее и медленнее. Но для локального стенда это не проблема — всегда можно удалить медленный локальный сайт и создать новый, свежий, чистый и быстрый.

Но что делать с живыми сайтами, которые расположены в интернете? Ведь они подвержены тем же проблемам: в процессе разработки веб сайта, на нем могут (и обязательно это происходит) оставаться активными не используемые плагины, может быть лишний код, которые не выполняет ничего полезного, внешняя структура сайта может превратиться в нагромождение решений разных разработчиков — все это ведет к снижению производительности.

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

Сегодня я хочу описать подробно о своем эксперименте по оптимизации своего сайта, а так же расскажу, как я это делал и к каким результатам пришел. Мой сайт — это «натянутая» когда-то готовая html+css верстка на wordpress. Моя цель — выжать максимум скорости из своего сайта. Работать буду над главной страницей. Итак, поехали.

Для начала хочу отметить, что бороться с ускорением веб сайта нужно в двух глобально отличающихся слоях:

Frontend — это внешняя часть сайта. Фронт ускорить можно убрав лишние JS-скрипты, лишние стили, оптимизировать изображения. Это самые «осязаемые» направления для оптимизации. Google page speed выдает очень подробный отчет по оптимизации именно внешней части сайта.
Backend — это «движок» сайта. Бэк ускорить можно оптимизируя исходный код сайта, применяя кеширование, отключая плагины. Эта часть оптимизации уже посложнее потому, что нужны специализированные инструменты анализа (я использую профилировщик XHProf), нужно иметь опыт в программировании, видеть «узкие» места, уметь переписать плагин/тему/участок кода на более производительный.

Начнем, друзья!

Ускоряем фронт

Итак, я сделал замеры своего сайта в известном сервисе от гугла, у меня получились следующие цифры:

Для мобильной версии оценка производительности в желтой зоне, 54 пункта (плохо)
Для настольной версии тоже в желтой зоне, 76 пунктов (плохо)

А так же я сделал замер в собственном браузере, два параметра: TTFB (время, за которое веб-сервер сгенерировал страницу и выдал ее браузеру) — 384 миллисекунды (не плохо), и время полной загрузки страницы — 6,13 секунд (ужасно)

Пришло время активных действий. Начинаем с самого легкого: исправляем друг за другом замечания PageSpeed.

Render-blocking requests

Сервис ругается на то, что «тяжелые» скрипты и стили на некоторое время блокируют показ страницы. В моем случае указаны style.css и jquery.js.

Это распространенные проблемы. style.css достается сайту вместе с купленной темой. Купленная тема потом урезается до необходимого функционала, а в стилях так и остается все, что там было. А замечание по jquery.js — это уже давно известный факт в сайтостроении. Эта библиотека слишком тяжелая для современного web, хоть и остается все еще очень удобной.

Очистку файла стилей от лишних правил я сделал с помощью npm-модуля purgecss. Модуль удаляет css-правила, селекторы которых не фигурируют в коде сайта. Purgecss мне уменьшил файл стилей почти в 6 раз — со 137 КБ до 24 КБ. Да, оно потеряло подключение шрифтов, но я это заметил при ручной проверке сайта и добавил недостающие правила в файл стилей. Результатом я доволен. И PageSpeed тоже.

По замечанию jquery есть несколько вариантов решения — либо убрать вообще эту библиотеку с сайта (максимально эффективно, но редко, когда это возможно, не сломав сайт), либо переместить загрузку этих скриптов в footer (эффективно, но на медленных хостингах и в футере библиотека будет блокировать отрисовку сайта), либо добавить атрибут defer для jquery-скриптов (это самый продвинуты и современный способ, суть в том, что браузер не будет больше ждать полной загрузки этих скриптов). Выбрать тот или иной вариант — это сугубо частная задача. Чаще всего можно прибегнуть ко второму варианту из-за его простоты. Я же выбираю последний вариант — добавлю атрибуты defer к скприптам. Сделаю это с помощью functions.php. Добавлю вот такой код в код своей темы:

function add_defer_to_scripts( $tag, $handle, $src ) {
    // Проверяем, что скрипт загружается в head (а не в подвале)
    if ( is_admin() ) {
        return $tag;
    }
    
    // Добавляем defer ко всем скриптам
    // (кроме тех, что уже имеют async, чтобы не дублировать)
    if ( strpos( $tag, 'async' ) === false && strpos( $tag, 'defer' ) === false ) {
        return str_replace( ' src', ' defer src', $tag );
    }
    
    return $tag;
}
add_filter( 'script_loader_tag', 'add_defer_to_scripts', 10, 3 );

Проверяю, делаю повторные замеры — да, индекс производительности вырос, замечаний по jquery больше в списке нет. Это маленькая победа!

Но сразу хочу сказать, что на множестве сайтов просто убрать jquery в футер, а тем более отложить его загрузку с помощью defer невозможно из-за особенностей темы — часто слайдеры/менюшки реализованы так, что требуется очень ранняя загрузка jquery. Такое я тоже видел в своей практике. Но не стоит отчаиваться, и на этот случай есть решение — надо брать и постепенно переделывать такие слайдеры/менюшки на более современные и оптимальные решения. Это все задача хоть и не простая, но реализуемая.

Итак, мы остановились на том, что уже оптимизировали загрузку стилей и jquery на сайте. В списке замечаний PageSpeed среди запросов, которые блокируют показ страницы у меня еще есть файл bootstrap.min.css — это стили, которые отвечают за основную разметку сайта. Его удалять нельзя. Но есть способ и его оптимизировать — я возьму из списка стилей только то, что отвечает за стилизацию каркаса, вынесу эти правила напрямую в inline-стили (не подключая файл, а объявляя правила непосредственно в шаблоне страницы). Но сделаю это потом, когда я перейду к более детальным и мелким точкам оптимизации. А для начала мне достаточно оптимизации того, что уже сделано. Идем дальше…

Font display

Следующий пункт в списке замечаний PageSpeed — это Font display. Суть этого замечания в том, что наш сайт делает дополнительные запросы, скачивая шрифты. И эти запросы тоже блокируют отображение сайта. Замечание очень похоже на предыдущее, и решать его тоже надо похожими способами — либо убирать эти запросы (если шрифт не используется), либо делать так, чтоб они загружались позже и не блокировали отображение страницы, либо внедрять их в inline, тем самым убираются лишние запросы. Но я сразу хочу предостеречь от способа все подряд внедрять в шаблон inline-ом — рано или поздно шаблон станет не читаемым для человека и очень «тяжелым». «Тяжелый» шаблон сайта оптимизировать гораздо сложнее, чем отдельные запросы.

Но есть другой способ решить это замечания по шрифтам — добавить в код подключения шрифта правило, чтоб отображался системный шрифт, пока грузится наш пользовательский шрифт. Надо добавить следующий стиль во все правила подключения @font-face

font-display: swap;

Я прошелся поиском по всем правилам @font-face, добавил везде стиль font-display: swap; и проблема была решена.

Но есть минус и у этого способа — это дизайн. Системный шрифт может сильно отличаться от нашего загружаемого пользовательского шрифта. И по-этому, в небольшой промежуток времени, пока сайт отображается с помощью системного шрифта, он может очень сильно отличаться от того, что задумал дизайнер. И в момент догрузки своего шрифта, все тексты могут настолько поменять свое начертание, что произойдет заметный сдвиг всего на сайте — текста, кнопок и т.п. Если такой эффект стал наблюдаться у вас, то вам не подходит способ с font-display: swap; и надо решать это замечание другими описанными способами.

Отдельных трудов составило убрать из замечаний fontawesome шрифт (это то, который мы подключаем для отображения на сайте всяких интересных иконок/стрелочек/галочек и прочего) — это была интересная история, которая тянет на отдельную статью. В одной из следующих статей обещаю поделиться этим интересным опытом.

Ну а у нас на очереди замечание

Layout shift culprits

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

Network dependency tree

Это замечание говорит о том, что часть загружаемых данных (например, стилей) происходить медленно. В моем случае, подключаемые с помощью css шрифты делают загрузку всех остальных стилей медленно. Есть способ заставить браузер предварительно скачивать шрифты. Именно это я и сделаю — вынесу в шаблон, в раздел <head> подключение всех моих шрифтов с аргументом preload, например, вот так:

<link rel="preload" href="<?php echo get_template_directory_uri(); ?>/assets/fonts/Simple-Line-Icons.woff" as="font" type="font/woff" crossorigin>

Этот прием обеспечит предварительную загрузку подключаемых шрифтов. И правила в css, подключающие шрифты уже будут выполняться мгновенно, не блокируя все остальные стили.

Проверяю изменения с помощью нового замера PageSpeed — замечание Network dependency tree решено.

Improve image delivery

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

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

Перепроверяю индекс производительности — там больше нет замечаний по оптимизации изображений. Супер!

Конечно, для некоторых сайтов конвертации в webp будет недостаточно, или не приемлемо. В таких случаях можно озадачиться задачей «ленивой» загрузки изображений — это прием, когда изображение на страницу добавляется не сразу, а после того, как посетитель доскроллит страницу до того мета, где это изображение должно быть.

Reduce unused JavaScript

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

В этом блоке замечаний у меня указан скрипт jquery.js. Это еще один камень в огород этой библиотеки. Проанализировав, как подключается этот скрипт в моей теме, я обнаружил, что используется локальная версия jQuery, к тому же очень устаревшая. Я решил переделать подключение скриптов так, чтоб они использовали встроенный в wordpress jquery как зависимость. Во-первых в составе wordpress более свежая версия библиотеки, чем использовалась в моей теме, во-вторых в составе wordpress эта библиотека организована более профессионально, она разбита на разные файлы, и основное ядро библиотеки остается минимальным. Таким не хитрым приемом мне удалось убрать это замечание из отчета.

На этом моя борьба за скорость внешней части сайта почти закончилась. Я еще внес несколько исправлений в тему, которые убрали лишние перерисовки контента, сдвига блогов, а так же еще несколько иконок перенес из шрифтов в inline-svg. На всем этом решил подробно не останавливаться, т.к. такие приемы — это уже чисто индифидуальные под каждый сайт по разному надо делать.

В итоге по последним замерам Google Page Speed в результате моих работ получились такие показатели:

Для мобильной версии оценка производительности в желтой зоне, 99 пункта (отлично)
Для настольной версии тоже в желтой зоне, 100 пунктов (отлично)

А так же повторный замер в собственном браузере, два параметра: TTFB (время, за которое веб-сервер сгенерировал страницу и выдал ее браузеру) – около 500 миллисекунды (этот параметр не поменялся, т.к. на него можно повлиять путем оптимизации backend-части сайта), и время полной загрузки страницы – 2,03 секунд (отличный результат, ускорение в три раза)

На этом оптимизация Frontend-части сайта закончена. Далее я перейду к более технической оптимизации backend-части. Но об этом в следующей статье.

Заключение

Что я хочу сказать вместо заключения. Конечно же, все мои ручные правки можно было сделать путем установки нескольких плагинов, которые предназначены для оптимизации шрифтов, изображений js/css кода. Но я осознанно хотел продемонстрировать, что такая работу возможна и без установки новых плагинов. Потому что, я уверен, многие сталкивались с чувством, когда устанавливаешь один плагин для ускорения сайта, сайт в какой-то степени ускоряется, но вместе с тем больше замусоривается. И на дальнейшую оптимизацию мы ставим еще и еще плагины, и это превращается в бесконечный круговорот, в котором уже сложно разобраться — какой плагин за что отвечает, какой из них нужен или не нужен. И контроль над управлением сайтом теряется. Я продемонстрировал, что возможна оптимизация путем фактического улучшения или упрощения сайта. Да, это требует больше трудов, но результат того стоит — мы получаем чистый, понятный, подконтрольный сайт.

Продолжение следует.