Вы зашли в Google PageSpeed Insights, увидели заветную зелёную зону и спокойно закрыли вкладку? Вынужден вас расстроить: ваш сайт всё ещё может жёстко тормозить у реальных клиентов, а поисковики — методично пессимизировать его в выдаче.
Я столкнулся с этим на собственном сайте smogu.by. Робот показывал отличную скорость. Но когда я открыл Google Search Console и посмотрел на реальные данные с телефонов живых пользователей — картина была совсем другой. 22 страницы помечены как «медленные». Позиции в поиске начали падать.
В этом материале — подробный разбор того, что именно ломало скорость, как мы это чинили шаг за шагом, и какой результат получили в итоге. Без воды, с реальными цифрами.
Читайте в этой статье
В чём разница между тестом PageSpeed и реальностью: почему сайт тормозит у клиентов
Большинство владельцев сайтов совершают одну и ту же ошибку: они ориентируются на синтетический тест PageSpeed Insights и считают что всё в порядке. На самом деле Google собирает два принципиально разных типа данных.
Синтетический тест (лабораторные данные) — робот проверяет сайт со своего мощного сервера с идеальным подключением к интернету. Условия идеальные, нагрузки нет, кэш чистый.
Core Web Vitals (полевые данные) — это реальный опыт живых людей. Google фиксирует как ваш сайт загружается на смартфонах обычных пользователей которые едут в минском метро через плохой 4G, или открывают сайт на бюджетном Android-телефоне.
Если сайт перегружен тяжёлыми скриптами, картинками или криво настроенным кэшем — вы получите красивую зелёную зону для робота, но реальный график в Google Search Console превратится в кошмар.
Именно это и произошло на smogu.by.
Главный виновник — метрика LCP (Largest Contentful Paint): время загрузки самого большого видимого элемента страницы. Она превышала критические 2,5 секунды. Google мгновенно пометил 22 страницы как «медленные» и начал снижать их позиции в выдаче.
Важно понять: у нас сложная конфигурация. Тема Astra Pro, онлайн-школа, хостинг Hoster.by на сервере LiteSpeed, плагин LiteSpeed Cache, несколько плагинов аналитики и метрики, плюс сторонние виджеты. Каждый элемент этой связки может стать источником проблемы. Именно поэтому мы пошли по пути глубокой ручной оптимизации — а не «установить плагин в один клик».
4 критические ошибки WordPress которые убивали скорость — и как мы их исправили
Ошибка №1: слепая генерация UCSS — и почему мы её отключили
UCSS (Unique CSS) — это функция при которой плагин кэширования генерирует уникальные CSS-стили для каждой страницы через облачный сервис. Звучит умно. На практике — в момент генерации сайт у реального пользователя на долю секунды отображается без дизайна. Голый текст без стилей. Верстка «прыгает».
Результат — метрика CLS (Cumulative Layout Shift) улетает в красную зону. CLS измеряет насколько элементы страницы смещаются при загрузке. Норма: до 0.1. У нас было значительно выше.
Для лёгкой темы Astra Pro эта функция оказалась полностью избыточной. Astra уже оптимизирована под скорость и генерирует минимальный CSS. Мы отключили UCSS в настройках LiteSpeed Cache — и первый источник нестабильности исчез.
Где отключить: LiteSpeed Cache → Page Optimization → CSS Settings → Generate UCSS → Off
Ошибка №2: JavaScript блокировал процессор — и сломал мобильное меню Astra
Скрипты аналитики, Яндекс.Метрика, пиксели соцсетей и чаты поддержки при первом открытии страницы намертво блокируют процессор телефона. Пока они загружаются — страница стоит. Пользователь видит контент но не может ни на что нажать. Эту задержку Google измеряет как INP (Interaction to Next Paint).
Решение — настроить жёсткую задержку тяжёлого JS-кода до первого действия пользователя. То есть скрипты грузятся не при открытии страницы, а когда пользователь впервые кликнул или прокрутил.
Важный нюанс который стоил нам времени: после включения задержки JS на сайте перестало нормально открываться мобильное меню темы Astra. Пользователю приходилось кликать по иконке меню 2–3 раза. Это критический UX-баг который мы поймали не сразу.
Причина: скрипты самой темы Astra и библиотека jQuery тоже попали в список откладываемых. Без них меню не инициализировалось при первом касании.
Решение: нашли конкретные скрипты темы и внесли их в список исключений из задержки в настройках LiteSpeed Cache. После этого меню снова заработало мгновенно с первого касания.
Где настроить: LiteSpeed Cache → Page Optimization → JS Settings → JS Defer → включить → добавить в исключения: jquery.min.js, astra-theme.js и другие критические скрипты темы.
Ошибка №3: Google Fonts грузились с чужих серверов
Стандартное подключение шрифтов через Google Fonts — это запрос к внешнему серверу при каждой загрузке страницы. Для пользователя в Беларуси это добавляет 200–400мс задержки. Плюс — шрифты подгружаются с задержкой и текст сначала отображается в системном шрифте, потом «прыгает» в нужный. Это снова CLS.
Astra Pro имеет встроенную функцию которая скачивает Google Fonts на ваш хостинг и включает режим font-display: swap. Текст отображается сразу в правильном шрифте без задержки и прыжков.
Где включить: Astra Pro → Консоль → Настройки → Производительность → Включить
Очистить локальные файлы шрифтов. Это заставляет тему Astra заново скачать чистые файлы шрифтов на хостинг.
После включения шрифты кешируются на вашем сервере Hoster.by и грузятся вместе с остальными файлами сайта — без внешних запросов.
Ошибка №4: CLS 0.377 из-за одного блока Spectra — и как иконка ломала всё
Это была самая неочевидная проблема. После того как мы исправили первые три ошибки — скорость загрузки стала отличной. Но метрика CLS застряла на значении 0.377 — глубокая красная зона при норме до 0.1.
Google PageSpeed чётко указал на виновника: конкретный блок на странице.
Виновником оказался блок Infobox из плагина Spectra на посадочной странице курса. У блока была иконка расположенная над заголовком. Из-за отложенной загрузки иконка появлялась с задержкой в 200–300мс и буквально толкала весь текст ниже вниз. Пользователь видел как заголовок и описание скачут на несколько пикселей сразу после загрузки страницы.
Google это фиксировал как CLS и наказывал страницу в выдаче.
Решение: зашли в редактор страницы в блок Spectra Infobox, убрали иконку над заголовком и зафиксировали структуру блока через явные отступы. Иконка теперь нет — и она не влияет на сдвиг верстки при загрузке.
Изменение было минорным с точки зрения дизайна. Но эффект — кардинальным.
Опасность для онлайн-школ: как оптимизация ломает LMS и WooCommerce
Самая большая ошибка новичков — «включить всё» в плагине кэширования. Если у вас простой блог, это может сработать. Но если на сайте развернута система онлайн-обучения (например, Tutor LMS) или интернет-магазин, слепая оптимизация превратит сайт в руины.
После включения задержки JavaScript мы столкнулись с критической проблемой: на странице каталога курсов полностью пропала сортировка, а кнопки переключения страниц (пагинация) стали «мертвыми». Плагин кэша просто усыпил скрипты, управляющие личным кабинетом студентов.
Как мы это решили:
- Изоляция скриптов: Мы нашли технические маркеры платформы обучения и принудительно внесли их в список исключений (
tutor,tutor-lms,/plugins/tutor/). Теперь база онлайн-школы загружается мгновенно, и интерактивные элементы работают без задержек. - Запрет на кэширование личных кабинетов: Страницы профилей студентов, уроков и корзины мы полностью исключили из кэширования. Это застраховало сайт от опасного бага, когда один студент из-за кэша сервера может увидеть личные данные или прогресс обучения другого пользователя.
Ловушка сочных картинок: оптимизация графики без потери аппетита
Эта проблема особенно близка малому бизнесу в сфере b2c — кондитерам, ресторанам, шоурумам. Чтобы продавать бенто-торты или одежду, вам нужны сочные, детализированные фотографии в высоком разрешении. Но каждая такая картинка с телефона весит по 5–10 Мегабайт. Если загрузить их на WordPress «как есть», сайт моментально умрет под их тяжестью.
Просто включить Lazy Load (отложенную загрузку) недостаточно, ведь, как мы выяснили, роботы поисковиков всё равно зафиксируют плохой показатель LCP на первом экране.
Правильный алгоритм работы с коммерческой графикой:
- Принудительная конвертация: Все изображения на сервере должны автоматически пережиматься в современные веб-форматы WebP или AVIF. Это уменьшает вес картинок на 70–80% без видимой потери качества. Тортики остаются аппетитными, но загружаются в 5 раз быстрее.
- Резервирование пикселей: Чтобы картинки при загрузке не толкали текст вниз и не портили метрику CLS, в коде каждой карточки товара или отзыва должны быть жестко прописаны размеры (
widthиheight). Мы внедрили автоматическое прописывание недостающих размеров на уровне сервера, полностью стабилизировав макет.
Результат: FCP 1.2с и LCP 1.6с на сложной странице с курсом
После точечной ручной настройки и устранения всех четырёх конфликтов мы загнали сложную посадочную страницу курса с кучей картинок, тарифов, видео и отзывов в абсолютный технологический топ.
Итоговые показатели для мобильных устройств:
| Метрика | До оптимизации | После оптимизации | Норма Google |
|---|---|---|---|
| LCP | >2.5 сек (красная зона) | 1.6 сек | до 2.5 сек |
| FCP | ~2.0 сек | 1.2 сек | до 1.8 сек |
| CLS | 0.377 (красная зона) | <0.1 | до 0.1 |
| INP | высокий | минимальный | до 200мс |
Сайт открывается на любом смартфоне мгновенно. Время блокировки процессора минимально. Кнопки и формы заказа работают без задержек с первого касания. 22 страницы которые Google помечал как «медленные» — вернулись в зелёную зону.
Почему это важно для бизнеса: не просто технические баллы
Скорость сайта — это не про красивые цифры в PageSpeed. Это про деньги.
Исследования Google показывают: при увеличении времени загрузки страницы с 1 до 3 секунд вероятность ухода пользователя вырастает на 32%. При загрузке 5 секунд — на 90%.
Для посадочной страницы курса это означает прямую потерю потенциальных студентов. Человек кликнул на рекламу или нашёл сайт в поиске — и ждёт 3–4 секунды пока страница загрузится. Половина уже ушла.
Плюс прямое влияние на SEO: Google официально использует Core Web Vitals как фактор ранжирования с 2021 года. Сайт который тормозит — получает пессимизацию в выдаче вне зависимости от качества контента.
После оптимизации мы зафиксировали:
- Снижение показателя отказов на мобильных устройствах
- Возврат позиций страниц которые были пессимизированы
- Увеличение времени на странице — люди перестали уходить пока грузится контент
Чек-лист: что проверить на вашем WordPress прямо сейчас
…
Прежде чем трогать настройки — сделайте диагностику. Вот быстрый план:
Общее время: 1 час
Шаг 1.
Откройте Google Search Console → раздел «Core Web Vitals» → посмотрите отдельно мобильные и десктопные данные. Именно здесь реальная картина, а не синтетический тест.
Шаг 2.
Откройте PageSpeed Insights и проверьте конкретную страницу. В разделе «Диагностика» будет указан конкретный виновник если есть проблема с CLS — как в нашем случае с блоком Spectra.
Шаг 3.
Проверьте раздел «Полевые данные» в PageSpeed — там те же данные что и в Search Console. Если там красные или жёлтые показатели при зелёных лабораторных — у вас та же история что и была у нас.
Шаг 4.
Убедитесь что шрифты Google Fonts загружаются локально, а не с серверов Google. Это легко проверить через DevTools → Network → отфильтровать по fonts.googleapis.com.
Шаг 5.
Проверьте нет ли у вас конфликта между плагином кэширования и скриптами темы. Если после включения оптимизации JS что-то перестало работать на сайте — почти наверняка виновата задержка скриптов темы.
Важное предупреждение: не настраивайте плагины кэширования наугад
Это главный вывод из нашего опыта.
Настройки LiteSpeed Cache, WP Rocket или W3 Total Cache — это не «включил и забыл». Каждая конфигурация уникальна: тема, хостинг, плагины, тип контента — всё влияет на то какие настройки сработают, а какие сломают сайт.
Один неверный шаг может:
- Полностью сломать мобильное меню (как у нас с Astra)
- Отключить формы заказа или кнопки оплаты
- Сломать слайдеры и интерактивные элементы
- Привести к «белому экрану» для части пользователей
Именно поэтому мы делали всё итеративно: включили одну настройку → проверили на мобильном → зафиксировали результат → перешли к следующей.
Если вы хотите получить такой же результат на своём сайте — без риска что-то сломать — читайте наше полное руководство по разработке и настройке сайта на WordPress.
И помните: оптимизация скорости — это часть SEO-стратегии, а не отдельная техническая задача. О том когда SEO начинает давать результаты после технической оптимизации — читайте в отдельной статье.
Хотите такую же скорость для своего сайта?
Если ваш сайт на WordPress долго открывается, картинки или текст прыгают при загрузке, а клиенты уходят к конкурентам — не пытайтесь настраивать плагины наугад. Один неверный шаг может полностью сломать верстку или формы заказа.
Только на этой неделе я возьму 3 сайта на бесплатный экспресс-аудит скорости.
Я лично проверю ваш ресурс по методике Core Web Vitals, найду скрытые технические тормоза и составлю пошаговый план вывода вашего сайта в зелёную зону поисковиков.
Написать в Telegram с пометкой «Аудит скорости» — и ссылкой на ваш сайт. Успейте занять место пока оно свободно.
Часто задаваемые вопросы «Ускорение WordPress»
Что такое Core Web Vitals и почему они влияют на позиции в Google?
Core Web Vitals — это три метрики реального опыта пользователей которые Google использует как фактор ранжирования с 2021 года. LCP (время загрузки главного элемента) должен быть до 2.5 секунды, INP (отклик на действие пользователя) до 200мс, CLS (стабильность верстки при загрузке) до 0.1. Если хотя бы одна метрика в красной зоне — Google снижает позиции страницы в поиске независимо от качества контента.
Почему PageSpeed Insights показывает зелёную зону, но сайт всё равно тормозит у пользователей?
PageSpeed показывает синтетический тест с идеального сервера Google. Это лабораторные данные в идеальных условиях. Core Web Vitals в Google Search Console — это реальные данные с телефонов ваших пользователей через мобильный интернет. Разница может быть кардинальной. Всегда проверяйте вкладку «Полевые данные» в PageSpeed и отчёт Core Web Vitals в Search Console — только там настоящая картина.
Безопасно ли откладывать JavaScript на WordPress?
Зависит от настройки. Откладывать тяжёлые сторонние скрипты (аналитика, пиксели соцсетей, чаты поддержки) — безопасно и нужно. Откладывать скрипты темы (jQuery, основные JS-файлы Astra и других тем) — опасно, это ломает интерактивные элементы. Решение: добавить критические скрипты темы в список исключений плагина кэширования. Всегда проверяйте мобильное меню и формы после включения задержки JS.
Какой плагин кэширования лучше для WordPress в 2026 году?
Зависит от хостинга. Если хостинг работает на LiteSpeed (например Hoster.by) — LiteSpeed Cache даёт лучший результат, так как работает на уровне сервера а не только PHP. На Apache и Nginx хорошие результаты показывают WP Rocket и W3 Total Cache. Важно: любой плагин кэширования требует ручной настройки под конкретную тему и конфигурацию — универсальных настроек «в один клик» не существует.
Что такое CLS и как исправить прыжки верстки на WordPress?
CLS (Cumulative Layout Shift) — метрика сдвигов верстки при загрузке страницы. Норма: до 0.1. Частые причины на WordPress: изображения без указанных размеров width и height, отложенная загрузка иконок и шрифтов, блоки плагинов (Spectra, Elementor) с динамическими элементами. Диагностика: PageSpeed Insights → раздел «Диагностика» → там будет указан конкретный элемент который вызывает сдвиг. Решение для каждого случая своё — нужно смотреть конкретный элемент.
Сколько времени занимает оптимизация WordPress под Core Web Vitals?
Диагностика и базовая настройка — 2–4 часа при наличии опыта. Поиск и устранение нестандартных конфликтов (как у нас с блоком Spectra) — может занять дополнительно 1–3 часа. Результат в Google Search Console появляется через 28 дней — именно столько Google собирает данные для обновления отчёта Core Web Vitals.
Все цифры и скриншоты в статье — из реальной работы над сайтом smogu.by. Конфигурация: Hoster.by, LiteSpeed сервер, WordPress 6.x, тема Astra Pro, плагин LiteSpeed Cache.
Автор: Станислав Белко — Smogu.by | Telegram | Instagram @belkostanislau