Как уменьшить CLS в WordPress
Если на странице при загрузке «прыгают» блоки, кнопки уезжают вниз, а текст перескакивает после появления баннера, шрифтов или изображений, у вас проблема с CLS — Cumulative Layout Shift. Для WordPress это особенно типично: тема подгружает шрифты, плагины вставляют баннеры и виджеты, изображения приходят без размеров, а сторонние скрипты дорисовывают интерфейс уже после первого рендера.
CLS влияет не только на оценку в PageSpeed Insights. Он напрямую портит пользовательский опыт: человек промахивается мимо кнопки, теряет контекст, хуже читает текст. Хорошая новость в том, что в WordPress почти всегда можно найти источник скачков и стабилизировать макет без полной переделки сайта.
Что именно вызывает CLS на WordPress-сайте
CLS появляется, когда браузер уже показал часть страницы, а потом один из элементов меняет размеры или вставляется в поток документа и сдвигает соседние блоки. В WordPress чаще всего это происходит из-за нескольких типовых причин.
- Изображения без заданных размеров. Если у картинки нет атрибутов
widthиheightили не зарезервировано место через CSS, браузер сначала рисует пустое место, а потом пересчитывает макет. - Шрифты, которые подменяют системный текст. Когда веб-шрифт загружается позже, текст может изменить ширину и высоту строк. Это особенно заметно на заголовках и кнопках.
- Блоки, которые вставляются JavaScript-ом после загрузки. Речь о попапах, уведомлениях о cookies, чатах, рекомендациях, рекламных вставках, счетчиках и виджетах.
- Слишком поздно подгружаемый CSS. Если критичные стили приходят не сразу, браузер сначала строит один вариант страницы, а потом перестраивает его после применения CSS.
- Содержимое из плагинов и темы, которое не резервирует место. Это может быть слайдер, блок отзывов, блок «похожие записи», форма подписки, блок авторов, встроенное видео.
- Асинхронные элементы в верхней части страницы. Верх экрана особенно чувствителен: любое добавление выше первого видимого блока сдвигает всё ниже.
Если CLS высокий только на мобильных, причина часто в том, что на маленьком экране блоки переносятся на новые строки, а шрифты и изображения меняют высоту карточек сильнее, чем на десктопе.
С чего начать диагностику
Сначала нужно понять, какой именно элемент сдвигает макет. В PageSpeed Insights и Lighthouse ищите раздел с причинами layout shift: там обычно показаны элементы, участвовавшие в сдвиге. Это не всегда финальный виновник, но хороший ориентир.
Дальше проверьте страницу вручную в Chrome DevTools. Откройте вкладку Performance, запишите загрузку страницы и посмотрите события layout shift. Так вы увидите, в какой момент и после какого ресурса появляется скачок. Если проблема проявляется только на конкретном шаблоне записи, странице товара или главной, сравнивайте именно этот шаблон, а не сайт в целом.
Для WordPress полезно отдельно проверить:
- какие элементы добавляет тема до и после загрузки;
- какие плагины вставляют блоки в верхнюю часть страницы;
- есть ли внешние скрипты, которые подгружают баннеры, чаты, рекламу или виджеты;
- не меняется ли высота шапки после загрузки меню, логотипа или sticky-header;
- не подменяются ли шрифты после первого рендера.
Как стабилизировать макет: что делать в первую очередь
Самый надёжный способ уменьшить CLS — заранее зарезервировать место под все элементы, которые могут появиться позже. Это относится к изображениям, видео, рекламным блокам, баннерам и любым динамическим вставкам.
1. У изображений должны быть известны размеры
В WordPress это обычно решается автоматически, если вы вставляете изображения через медиабиблиотеку и тема не ломает разметку. Но на практике проблемы возникают часто: картинка вставлена вручную, используется кастомный HTML, подключённый блок не передаёт размеры или тема выводит изображения без атрибутов.
Проверьте, что у изображений в контенте и в карточках есть width и height. Для адаптивной вёрстки это не мешает масштабированию: браузер использует эти атрибуты как соотношение сторон и заранее резервирует место.
Если изображение вставляется как фон через CSS, задайте контейнеру фиксированное соотношение сторон через aspect-ratio или хотя бы минимальную высоту. Иначе блок может сначала быть нулевой высоты, а потом внезапно вырасти.
2. Для шрифтов нужно уменьшить сдвиг текста
CLS часто растёт из-за веб-шрифтов. Когда браузер сначала показывает системный шрифт, а потом подменяет его на загруженный, меняются ширина слов, переносы строк и высота блоков. На заголовках и кнопках это особенно заметно.
Практически полезные меры:
- подключать только те начертания, которые реально используются;
- не тянуть лишние семейства и веса;
- использовать
font-display: swapили близкую стратегию, если это допустимо для дизайна; - по возможности хранить шрифты локально, а не зависеть от внешнего CDN;
- подбирать fallback-шрифты, близкие по метрикам к основному.
Если тема использует Google Fonts, проверьте, не загружаются ли они через несколько запросов и не блокируют ли рендер. Иногда проще перевести шрифты локально, чем пытаться выжать стабильность из внешнего подключения.
3. Не вставляйте новые блоки над уже показанным контентом
Частая ошибка в WordPress — добавить сверху страницы баннер, уведомление, форму подписки или рекламный блок, который появляется после загрузки скрипта. Если он вставляется в поток документа, весь контент ниже сдвигается.
Если такой блок нужен, лучше сразу зарезервировать под него место в макете. Например, задать фиксированную высоту для уведомления о cookies или разместить баннер в отдельной области, которая не меняет высоту после загрузки. Для всплывающих окон и sticky-элементов важно, чтобы они не толкали основной контент, а накладывались поверх него.
Для попапов и уведомлений это особенно актуально на мобильных: там даже небольшой блок сверху может вызвать заметный скачок.
Что проверить в теме и плагинах WordPress
Если базовые меры не помогли, источник CLS часто сидит в теме или одном из плагинов. Здесь уже нужно смотреть не на общую скорость сайта, а на конкретную разметку.
Шапка, меню и sticky-элементы
Шапка сайта должна иметь стабильную высоту до полной загрузки. Если логотип подгружается позже и меняет размер блока, или меню раскрывается только после выполнения JavaScript, верх страницы может «прыгать». Это часто бывает в темах с анимированной шапкой, sticky header и мобильным меню, которое сначала рендерится в одном состоянии, а потом перестраивается.
Проверьте, не меняет ли шапка высоту после загрузки шрифтов, логотипа и иконок. Если да, задайте ей фиксированную или минимальную высоту, а для логотипа — конкретные размеры.
Слайдеры, карусели и блоки «похожие записи»
Слайдеры и карусели — частый источник CLS, если они инициализируются после первого рендера. Пока скрипт не отработал, блок может быть слишком высоким, слишком низким или вообще без высоты. Аналогичная проблема бывает у блоков «похожие записи», которые подгружаются после основного контента.
Здесь помогает заранее задать высоту контейнера или использовать skeleton-обёртку с предсказуемыми размерами. Если плагин не позволяет это настроить, иногда проще заменить его на более предсказуемую реализацию.
Виджеты, чаты и внешние скрипты
Сторонние сервисы часто вставляют элементы без учёта макета сайта: чат, онлайн-консультант, рекламная сеть, виджет отзывов, кнопки соцсетей. Если они появляются в потоке документа, CLS почти неизбежен.
Лучше загружать такие элементы так, чтобы они не меняли высоту основного контента. Если сервис позволяет, размещайте виджет в фиксированном контейнере. Если нет — ограничивайте его влияние на макет через CSS и не ставьте его в верхнюю часть страницы.
Как уменьшить CLS на уровне WordPress и сервера
Иногда проблема не в одном конкретном блоке, а в том, что страница слишком долго собирается. Тогда браузер дольше живёт в промежуточном состоянии, и шанс увидеть скачок выше. Это уже зона темы, плагинов, кэша и сервера.
Что имеет смысл проверить:
- Кэширование страниц. Если HTML приходит медленно, браузер дольше ждёт стили, шрифты и изображения. Это не прямой источник CLS, но плохой TTFB усиливает видимые скачки.
- Оптимизация CSS и JS. Слишком агрессивная отложенная загрузка может ломать порядок отрисовки. Иногда CSS минифицируют и объединяют так, что критичные стили применяются поздно.
- Плагины, которые добавляют много фронтенд-логики. Чем больше скриптов на странице, тем выше риск поздней вставки элементов.
- Тяжёлые запросы к базе данных. Если блоки строятся динамически и долго, часть интерфейса появляется позже обычного.
- CDN и внешние ресурсы. Если шрифты, изображения или скрипты тянутся с медленного источника, браузер дольше ждёт финальную верстку.
Если вы используете инструменты технической оптимизации WordPress, вроде Clearfy Pro, их удобно применять для точечной чистки лишних фронтенд-элементов: убрать ненужные ресурсы из <head>, отключить лишние функции темы и сократить количество скриптов, которые могут вмешиваться в рендер. Но такие настройки не заменяют работу с самой вёрсткой: если блок не зарезервировал место, один плагин этого не исправит.
Особенности для блога, корпоративного сайта и WooCommerce
На обычном блоге CLS чаще всего создают изображения в статьях, шрифты, блоки подписки и рекомендации. На корпоративном сайте добавляются баннеры, формы заявки, чаты и анимации в шапке. В WooCommerce список шире: карточки товаров, галереи, бейджи, мини-корзина, уведомления о добавлении в корзину, блоки доставки и оплаты.
Для магазина особенно важно не ломать динамические элементы, которые должны обновляться. Нельзя просто «зажать» всё CSS-ом и отключить скрипты: корзина, вариативные товары и оформление заказа должны работать корректно. Здесь лучше стабилизировать именно размеры контейнеров, а не убирать функциональность.
Если CLS возникает на карточках товара, проверьте галерею, бейджи и блоки с ценой. Если скачок на странице оформления заказа, обычно виноваты уведомления, дополнительные поля и сторонние платёжные виджеты.
Как понять, что вы действительно исправили проблему
После изменений не ориентируйтесь только на общий балл PageSpeed. Он полезен как индикатор, но не показывает весь пользовательский сценарий. Проверяйте страницу в реальном браузере и на мобильном разрешении.
Смотрите на три вещи:
- не двигается ли основной контент после первой отрисовки;
- не меняется ли высота шапки, баннеров и карточек;
- не появляются ли новые скачки после подключения сторонних скриптов.
Если CLS уменьшился на одной странице, но остался на другой, значит проблема не глобальная, а шаблонная. В WordPress это нормально: главная, запись, архив и товар часто собираются по-разному, и оптимизировать их нужно отдельно.
Самый практичный подход такой: сначала найти элемент, который меняет макет, затем зарезервировать ему место, потом проверить, не создаёт ли новый сдвиг тема или плагин. В WordPress именно последовательность важнее, чем попытка «ускорить всё сразу».