Увеличение скорости сайта WordPress

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

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

Работа проводилась поэтапно в августе — сентябре 2026 года.

Результат после оптимизации

Контрольные проверки были выполнены 8 сентября 2026 года.

Дополнительно в этих проверках:

• SEO — 100;
• Рекомендации — 100;
• агентный просмотр — 3/3.

То есть главная страница и проверенная внутренняя коммерческая страница попали в зелёную зону Lighthouse Performance.

Важно учитывать, что эти показатели относятся к лабораторным тестам Lighthouse в PageSpeed Insights.

На момент контрольной проверки сервис показывал «Нет данных» в блоке фактической производительности сайта. Поэтому результаты нельзя напрямую приравнивать к Core Web Vitals всех реальных посетителей.

С чего начали

На одном из ранних этапов лабораторный тест показывал:

Уже на этом этапе было понятно, что проблема не сводится только к выполнению JavaScript.

В конкретном лабораторном прогоне TBT составлял 0 мс, поэтому блокировка основного потока длинными задачами на этапе загрузки не была основной причиной низкой производительности.

При этом оставались другие узкие места:

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

На одном из промежуточных этапов критическая цепочка загрузки доходила примерно до 3 секунд.

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

Оптимизация LCP на первом экране

Одной из проблем первого экрана был декоративный фон формы .promoForm__bg.

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

Особенно мало пользы такой фон давал на мобильных устройствах.

Что изменили

Для мобильной версии тяжёлый декоративный фон убрали.

На небольших экранах форма стала использовать более простое оформление без загрузки дополнительного фонового изображения.

При этом пользователь по-прежнему видел:

• заголовок;
• форму;
• поля для контактов;
• кнопку отправки.

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

Сократили количество локальных шрифтов

Отдельно проанализировали шрифты темы.

На сайте использовалось несколько семейств и большое количество файлов разных форматов и начертаний. Часть из них фактически не требовалась для основных страниц.

Набор сократили до реально используемых вариантов, в том числе:

• Open Sans Regular;
• Open Sans Bold;
• Montserrat SemiBold;
• Montserrat Bold.

Шрифты оставили в формате WOFF2, а для их отображения использовали font-display: swap.

Одновременно пересмотрели preload.

Заранее загружаться должны только действительно важные ресурсы, а не вся библиотека шрифтов сайта.

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

Очистили CSS темы

За время доработок сайта в стилях постепенно накапливались:

• старые правила;
• повторяющиеся media queries;
• дубли;
• стили удалённых элементов;
• предыдущие варианты мобильной вёрстки;
• оформление отдельных экспериментов.

Поэтому одной минификации CSS было недостаточно.

Минификация делает запись компактнее, но не удаляет ненужную логику.

Основной файл стилей очищался вручную.

На одном из этапов его размер удалось уменьшить примерно:

115 123 → 94 940 байт

То есть приблизительно на 17,5%.

Отдельно сокращались стили карточек и других пользовательских компонентов.

Вынесли часть inline CSS в отдельные файлы

Некоторые доработки ранее находились непосредственно внутри HTML страницы.

Часть таких стилей была вынесена в отдельные CSS-файлы и стала подключаться только там, где соответствующий блок действительно используется.

Например, стили отдельных элементов главной страницы были перенесены во внешний файл вместо повторного присутствия в HTML.

Это позволило:

• уменьшить объём встроенных стилей;
• использовать браузерный кэш;
• не передавать одинаковый CSS при каждом открытии страницы;
• точнее контролировать подключение файлов по шаблонам;
• проще находить дублирующиеся правила.

Перестали подключать ресурсы «на всякий случай»

Одна из типичных проблем WordPress — глобальное подключение CSS и JavaScript.

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

На electric-24.ru отдельно проверялись зависимости:

• Contact Form 7;
• Fancybox;
• Owl Carousel;
• Muuri;
• jQuery;
• маска телефона;
• sticky header;
• WordPress i18n;
• скрипты темы;
• собственные плагины.

Для управления ресурсами использовались в том числе Autoptimize и Asset CleanUp, но не по принципу «включить все возможные настройки».

Для каждого ресурса сначала определяли:

1. действительно ли он нужен странице;
2. можно ли загружать его позже;
3. можно ли исключить зависимость полностью;
4. не перестанет ли после отключения работать интерфейс.

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

Уменьшили зависимость сайта от JavaScript

Часть элементов сайта исторически была завязана на JavaScript сильнее, чем требовалось.

Поэтому некоторые блоки постепенно переводились на более простую HTML/CSS-реализацию.

Работа затронула, в частности:

• FAQ;
• текстовые блоки;
• отдельные карточки;
• элементы отзывов и брендов.

Текст под H1 стал выводиться сервером WordPress, а не появляться только после выполнения клиентского скрипта.

Это уменьшает зависимость основного контента от JavaScript и делает его доступным уже в исходном HTML страницы.

Почему нельзя было просто отключить весь JavaScript

Во время оптимизации стало заметно, насколько некоторые элементы существующей темы зависели от отдельных скриптов.

После отключения части ресурсов могли перестать корректно работать:

• мобильное меню;
• модальные формы;
• всплывающие окна;
• кнопка прокрутки вверх.

Поэтому оптимизацию проводили постепенно.

Рабочая схема выглядела так:

отключение ресурса → проверка сайта → восстановление необходимой функциональности → повторный тест.

Если скрипт оказывался действительно нужен, его не удаляли только ради увеличения оценки Lighthouse.

Для коммерческого сайта работающая форма заявки важнее нескольких дополнительных баллов PageSpeed Insights.

Оптимизировали изображения

На сайте также обнаружились изображения, физический размер которых заметно превышал размер их отображения.

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

Кроме этого проверялись:

• WordPress thumbnails;
• изображения карточек;
• фотографии статей;
• размеры исходных файлов;
• качество после ресайза;
• соответствие размеров изображений реальному контейнеру.

Для крупных изображений страниц использовался рабочий размер около 842 × 632 px.

Задача заключалась не в максимальном сжатии любой ценой.

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

Убрали изображения там, где они не приносили пользы

Некоторые декоративные изображения были исключены полностью.

Если карточка могла нормально выполнять свою задачу за счёт:

• заголовка;
• текста;
• ссылки;
• кнопки,

то обязательная загрузка дополнительной фотографии не всегда была оправдана.

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

Настроили кэширование

Отдельно работали с повторной загрузкой ресурсов.

Использовались:

• страничное кэширование;
• браузерное кэширование;
• Autoptimize;
• оптимизация CSS;
• оптимизация HTML;
• отложенное выполнение части JavaScript.

При этом объединение всех CSS- и JS-файлов в один большой файл не использовалось как обязательная цель.

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

Пересмотрели сторонние скрипты

Отдельное внимание уделили ресурсам, которые сайт получает не только из своей темы.

В том числе проверялись:

• Яндекс.Метрика;
• формы;
• антиспам;
• капча;
• внешние библиотеки.

Для аналитики была реализована логика загрузки с учётом Cookie-согласия.

Также проверялось влияние антиспам-решений на формы и повторное открытие модальных окон.

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

Промежуточные результаты были разными

Оптимизация сайта не шла линейно.

На одном из промежуточных тестов десктоп показывал:

То есть LCP уже был хорошим, но в конкретном лабораторном прогоне вырос Total Blocking Time.

Это хороший пример того, почему нельзя оптимизировать сайт только по одной метрике.

Изменение порядка загрузки ресурсов может улучшить один показатель и одновременно ухудшить другой.

После этого работу продолжили.

Контрольный результат 8 сентября

После серии изменений сайт проверили повторно в PageSpeed Insights.

Главная — компьютер

Performance — 96

Дополнительно:

• специальные возможности — 93;
• рекомендации — 100;
• SEO — 100;
• агентный просмотр — 3/3.

Главная electric-24.ru — 96 Performance на компьютере. PageSpeed Insights, 8 сентября 2026 года.

Главная — мобильные устройства

Performance — 94

Дополнительно:

• специальные возможности — 97;
• рекомендации — 100;
• SEO — 100;
• агентный просмотр — 3/3.

Главная electric-24.ru — 94 Performance на мобильных устройствах. PageSpeed Insights, 8 сентября 2026 года.

Страница «Вызов электрика» — мобильные устройства

Performance — 95

Дополнительно:

• специальные возможности — 97;
• рекомендации — 100;
• SEO — 100;
• агентный просмотр — 3/3.

Особенно важно, что хороший результат получен не только на главной странице.

Внутренняя коммерческая страница с текстом, навигацией, формами и другими элементами также получила 95 баллов Performance в мобильном лабораторном тесте.

Эффект оптимизации проявился не только на главной странице, но и на проверенной внутренней коммерческой странице сайта.

Страница услуги «Вызов электрика» — 95 Performance на мобильных устройствах. PageSpeed Insights, 8 сентября 2026 года.

Что было сделано в рамках проекта

В итоге оптимизация затронула сразу несколько уровней WordPress-сайта:

1. Очищен основной CSS темы.
2. Удалены дублирующиеся и устаревшие правила.
3. Сокращено количество локальных шрифтов.
4. Оставлены необходимые файлы WOFF2.
5. Пересмотрена предварительная загрузка шрифтов.
6. Часть inline CSS вынесена в отдельные файлы.
7. Стили стали подключаться более адресно.
8. Проверены зависимости JavaScript.
9. Часть скриптов переведена на отложенное выполнение.
10. Некоторые блоки переведены на HTML/CSS без обязательного JavaScript.
11. Контент под H1 переведён на серверный вывод WordPress.
12. Оптимизированы изображения.
13. Скорректированы размеры WordPress thumbnails.
14. Убраны лишние декоративные изображения.
15. Облегчён первый экран мобильной версии.
16. Настроено кэширование.
17. Проверена загрузка аналитики.
18. Сокращено количество ненужных сторонних зависимостей.
19. После крупных изменений проверялась работоспособность форм, меню и модальных окон.

Почему мы не стали гнаться за 100 баллами

PageSpeed Insights показывает удобную оценку от 0 до 100, но сама цифра не должна становиться единственной целью оптимизации.

Можно искусственно облегчить страницу:

• удалить форму;
• отключить аналитику;
• убрать изображения;
• отказаться от интерактивных элементов;
• удалить часть коммерческих блоков.

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

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

Контрольные результаты 94–96 Performance для полноценного WordPress-сайта с формами, коммерческими блоками, мобильным меню и аналитикой в данном случае показательнее, чем искусственные 100 баллов на максимально упрощённой странице.

Итог

После последовательной оптимизации WordPress-сайта electric-24.ru контрольные лабораторные проверки PageSpeed Insights от 8 сентября 2026 года показали:

• 96 Performance — главная страница, компьютер;
• 94 Performance — главная страница, мобильные устройства;
• 95 Performance — внутренняя страница «Вызов электрика», мобильные устройства.

При этом на проверенных страницах сохранились основные элементы сайта:

• формы обратной связи;
• мобильное меню;
• всплывающие окна;
• страницы услуг;
• аналитика;
• коммерческие блоки;
• основной дизайн.

Вместо одной «магической» настройки использовалась последовательная схема:

замер → поиск причины → изменение → проверка функциональности → повторный замер.

Именно такой подход позволил ускорить сайт, не превращая оптимизацию PageSpeed Insights в самоцель.

КОНСУЛЬТАЦИЯ

Низкая скорость у сайта?

Пришлите адрес ресурса.

Ваш сайт Факс

Ваше имя

Телефон, e-mail или Telegram

Кратко опишите задачу

Обсудить

Согласен(на) с политикой обработки персональных данных