Оптимизация скриптов js в wordpress

Избыток JavaScript в WordPress увеличивает время до первого взаимодействия (TTI) в среднем на 1.5–3 секунды, что ведет к потере до 20% конверсии на мобильных устройствах. Оптимизация JS — это не просто включение «минификации», а хирургическое удаление лишнего кода и управление приоритетами загрузки.

Аудит JS: поиск «мусорных» скриптов

Типичный сайт на WordPress с 10-15 плагинами грузит от 40 до 80 JS-файлов, из которых до 30% не используются на конкретной странице. Например, скрипты формы Contact Form 7 или слайдера Revolution Slider часто подгружаются даже на простых текстовых страницах, добавляя по 50–150 КБ лишнего веса.

Для очистки использую метод дерегистрации через functions.php: wp_dequeue_script(). В одном из кейсов удаление неиспользуемых скриптов WooCommerce с информационных страниц сократило размер JS-пакета на 210 КБ и ускорило LCP на 0.4 сек.

Вывод эксперта: Начинайте не с кэширования, а с жесткой фильтрации. Если скрипт не работает на данной странице — он не должен быть в DOM.

Стратегии загрузки: Defer против Async

Разница между Defer и Async критична для рендеринга. Async загружает скрипт в фоне, но исполняет его сразу после загрузки, что может заблокировать отрисовку. Defer откладывает исполнение до полного парсинга HTML. Переход на Defer для всех второстепенных скриптов (метрики, чаты) обычно снижает показатель Total Blocking Time (TBT) на 300–700 мс.

Кейс: перенос тяжелого JS-бандла темы в футер с атрибутом defer на сайте-каталоге сократил время отрисовки первого экрана (FCP) с 2.1 сек до 1.4 сек.

Вывод эксперта: Используйте Async только для независимых внешних сервисов (Google Ads), для всего остального — строго Defer.

Минификация и объединение: скрытые риски

Объединение (Concatenation) всех JS-файлов в один большой бандл было актуально при HTTP/1.1. В эпоху HTTP/2 и HTTP/3 это контрпродуктивно: один огромный файл блокирует кэширование отдельных модулей. Если вы измените одну строку в одном скрипте, пользователю придется перекачивать весь бандл объемом 500 КБ вместо одного файла на 10 КБ.

Минификация (удаление пробелов и комментариев) дает реальный прирост в 5–10% от объема файла. В связке с Gzip или Brot compresses (сжатие на сервере) это сокращает передаваемый объем данных в 3–4 раза.

Вывод эксперта: Откажитесь от объединения файлов в пользу минификации и HTTP/2. Это сохраняет гранулярность кэша и ускоряет повторные визиты.

Борьба с Render-Blocking JS и сторонним кодом

Сторонние скрипты (Facebook Pixel, Google Tag Manager, Яндекс.Метрика) — главные «пожиратели» ресурсов. Загрузка одного тяжелого внешнего скрипта может добавить до 1 секунды к TTI. Решение — отложенная загрузка (Lazy Load JS) по событию первого скролла или клика пользователя.

Пример: внедрение задержки загрузки чата поддержки на 3 секунды после загрузки страницы позволило поднять оценку PageSpeed Insights с 65 до 92 баллов для мобильной версии без потери функциональности.

Вывод эксперта: Любой скрипт, который не влияет на первый экран, должен грузиться с задержкой. Это единственный способ добиться «зеленой зоны» в Core Web Vitals.

Вывод

Оптимизация JS в WordPress начинается с удаления лишнего (wp_dequeue_script), переходит к правильному методу загрузки (Defer) и завершается отложенным исполнением тяжелых внешних сервисов. Избегайте объединения файлов в один бандл при использовании HTTP/2. Начните с анализа через Chrome DevTools (вкладка Coverage), чтобы увидеть процент неиспользуемого кода, и удалите его — это даст самый заметный прирост скорости без затрат на дорогой софт.