03 / КОРОТКО
Какие Core Web Vitals нужно улучшать в 2026 году
04 / МЕТРИКИ
LCP, INP и CLS простыми словами
Источник: Google — Core Web Vitals.
05 / SEO
Core Web Vitals влияют на SEO, но это не кнопка «в топ»
Google подтверждает, что Core Web Vitals используются ranking systems как часть общей page experience. Но хорошая скорость сама по себе не делает нерелевантную страницу лидером выдачи.
Поэтому задача не «получить 100/100 любой ценой», а убрать задержки, которые реально мешают пользователю.
Источник: Google — Page Experience.
06 / ИЗМЕРЕНИЕ
Search Console, PageSpeed Insights и DevTools показывают разные стороны проблемы
Search Console
Field data по группам URL. Хорош для понимания масштаба проблемы.
PageSpeed Insights
Сочетает CrUX field data и Lighthouse lab diagnostics.
Chrome DevTools
Нужен, чтобы найти конкретный LCP element, long task или источник layout shift.
07 / LCP
LCP на Elementor чаще всего ломается в первом экране
На сайтах услуг LCP element часто оказывается hero image, большой heading или background image первого экрана.
- не загружать hero в 5000 px, если он показывается около 1600–1900 px;
- использовать WebP/AVIF там, где это оправдано;
- не lazy-load LCP image;
- дать критичному image высокий приоритет загрузки;
- сократить blocking CSS/JS;
- не строить первый экран из тяжёлого slider без необходимости;
- проверить TTFB и cache.
08 / ИЗОБРАЖЕНИЯ
Самая простая победа — перестать загружать изображения «на всякий случай огромными»
Если card thumbnail отображается шириной 500 px, нет причины отправлять пользователю исходник на 4000 px. Я смотрю не только file size, но и реальный display size, device DPR и format.
Особенно внимательно — featured images, hero backgrounds, project galleries и carousels.
09 / ШРИФТЫ
Web fonts могут одновременно ухудшать LCP и CLS
Проблемы начинаются, когда сайт загружает много начертаний, несколько font families, сторонние providers и не задаёт разумный fallback.
Для WordPress я предпочитаю локальные fonts, минимальный набор weights и предсказуемую font-loading strategy.
10 / INP
INP — это уже не про скорость загрузки, а про то, что происходит после клика
Страница может открыться быстро, но зависать при открытии menu, popup или filter. Причина — long JavaScript tasks, тяжёлые handlers, third-party scripts или большой объём работы main thread.
Third-party JS
Chats, maps и widgets не должны блокировать первый meaningful interaction без необходимости.
Plugins
Проверяем, не грузится ли frontend JS функции на страницах, где она не используется.
Animations
Scroll effects и interactions красивы, пока не начинают занимать main thread.
Custom JS
Длинную работу нужно разбивать, а не удерживать main thread одной задачей.
11 / CLS
CLS часто чинится проще всего — нужно заранее резервировать место
- задавайте width/height или aspect-ratio для изображений;
- не вставляйте сверху поздно появляющийся banner;
- резервируйте место под iframe, maps и embeds;
- контролируйте font swap;
- проверяйте sticky headers и notices;
- обращайте внимание на cookie bars и popup triggers.
12 / ELEMENTOR
Что я проверяю на WordPress + Elementor в первую очередь
DOM
Лишние nested containers и wrappers увеличивают объём страницы.
Carousels
Проверяем, загружаются ли изображения всех slides сразу и какой JS нужен компоненту.
Popups
Не нужно грузить тяжёлый popup ecosystem до того, как пользователь может его открыть.
Add-ons
Некоторые Elementor add-ons добавляют CSS/JS глобально. Смотрим реальную waterfall.
13 / CACHE
Кеш-плагин помогает, но не заменяет нормальную архитектуру
WP Rocket, LiteSpeed Cache и аналоги могут дать большой эффект: page cache, preload, delay JavaScript и optimization. Но если hero весит несколько мегабайт, carousel грузит двадцать фотографий, а add-ons добавляют JS на каждую страницу, одного переключателя недостаточно.
15 / ПЛАН
Как я бы оптимизировал медленный Elementor-сайт
- зафиксировать field data и проблемные группы URL;
- определить реальный LCP element;
- проверить server response и cache;
- разобрать images/fonts первого экрана;
- посмотреть waterfall CSS/JS;
- найти long tasks и third-party scripts;
- проверить layout shifts;
- убрать лишние global assets plugins/add-ons;
- повторить измерение после крупных изменений;
- проверить forms, menu, sliders и analytics.
Такая работа входит в техническую часть SEO-аудита и развития сайта.
16 / FAQ
Частые вопросы про Core Web Vitals, WordPress и Elementor
Что такое Core Web Vitals и зачем они нужны сайту?
Core Web Vitals — это набор метрик Google, которые помогают оценить реальный пользовательский опыт страницы. Сейчас основными показателями являются LCP, INP и CLS: скорость появления основного контента, отзывчивость интерфейса и визуальная стабильность страницы.
Для WordPress и Elementor эти показатели полезны не только ради SEO. Они помогают найти проблемы, которые человек действительно ощущает на сайте: медленный первый экран, задержку после нажатия кнопки, прыгающий контент, тяжёлые изображения или перегруженный JavaScript.
Какой LCP считается хорошим и что обычно ухудшает его на WordPress?
Хорошим считается LCP до 2,5 секунды. Метрика показывает, сколько времени пользователю приходится ждать появления самого крупного значимого элемента первого экрана — например hero-изображения, большого заголовка или другого заметного блока.
На WordPress и Elementor LCP чаще всего ухудшают слишком тяжёлые hero-изображения, медленный сервер, отсутствие кеширования, блокирующие CSS и JavaScript, неправильный lazy loading и большое количество ресурсов, которые браузер должен обработать до отображения первого экрана.
Какой INP считается хорошим и почему сайт может тормозить уже после загрузки?
Для хорошего пользовательского опыта INP должен быть не выше 200 мс. Эта метрика оценивает, насколько быстро страница визуально реагирует на действия пользователя: клики, нажатия клавиш и другие взаимодействия.
На Elementor высокий INP часто связан не с самой загрузкой страницы, а с работой JavaScript после неё. Проблему могут создавать popups, фильтры, меню, sliders, сложные animations, сторонние виджеты, карты, чаты и плагины, которые выполняют тяжёлые задачи в основном потоке браузера.
Какой CLS считается хорошим и из-за чего элементы страницы начинают прыгать?
Хорошим считается CLS не выше 0,1. Метрика измеряет неожиданные смещения элементов страницы во время загрузки. Например, пользователь собирается нажать кнопку, но изображение или баннер внезапно появляется выше и сдвигает интерфейс.
Частые причины CLS — изображения без заранее заданного размера или aspect-ratio, поздно загружающиеся шрифты, рекламные и cookie-блоки, iframe, карты, sticky-элементы и динамический контент, для которого браузер заранее не зарезервировал место.
Нужно ли получать 100 баллов в Google PageSpeed Insights для хорошего SEO?
Нет. Оценка 100/100 в Lighthouse или PageSpeed Insights не является обязательным условием для высоких позиций. Google прямо указывает, что Core Web Vitals являются только частью общей page experience, а идеальные результаты технических тестов сами по себе не гарантируют высокое ранжирование.
Рациональная цель — добиться хороших Core Web Vitals у реальных пользователей и убрать заметные проблемы сайта. Если для получения дополнительных двух баллов приходится ломать аналитику, формы, sliders или важный функционал, такая оптимизация уже не имеет практического смысла.
Почему PageSpeed Insights показывает одно, а Search Console — другое?
Потому что это разные типы данных. Lighthouse в PageSpeed Insights проводит лабораторный тест страницы в заданных условиях, а данные Chrome User Experience Report основаны на реальных посещениях пользователей Chrome. Поэтому лабораторный результат может быть хорошим, а реальные Core Web Vitals — хуже, или наоборот.
Search Console использует реальные данные и группирует похожие URL, поэтому изменения после оптимизации появляются не мгновенно. Новые пользовательские данные должны накопиться. Для диагностики проблемы удобнее Lighthouse и DevTools, а для оценки реального результата — Search Console и CrUX.
Elementor сам по себе делает WordPress-сайт медленным?
Нет. Elementor может участвовать в формировании тяжёлой страницы, но обычно скорость зависит от всей реализации: структуры containers, количества widgets, изображений, шрифтов, сторонних add-ons, JavaScript, анимаций, хостинга, темы и системы кеширования.
Один Elementor-сайт может иметь хорошие Core Web Vitals, а другой — серьёзные проблемы. Поэтому вместо универсального вывода «Elementor медленный» правильнее анализировать конкретную страницу: какой элемент является LCP, какие скрипты блокируют main thread, откуда появляется CLS и какие ресурсы реально загружаются пользователю.
Достаточно ли установить WP Rocket, чтобы исправить Core Web Vitals?
Нет. WP Rocket и другие плагины кеширования могут заметно улучшить загрузку сайта: включить page cache, preload, delay JavaScript и другие оптимизации. Но они не способны автоматически исправить любую архитектурную проблему.
Если первый экран загружает изображение на несколько мегабайт, Elementor add-on подключает тяжёлую библиотеку на всех страницах, а carousel сразу загружает двадцать фотографий, сначала нужно исправить сами причины. Кеш-плагин лучше использовать как часть оптимизации, а не как замену техническому аудиту.
Почему Core Web Vitals на мобильных устройствах хуже, чем на компьютере?
Мобильные пользователи работают на устройствах с разной производительностью процессора и качеством сети. Страница, которая быстро работает на мощном компьютере и хорошем Wi-Fi, может намного медленнее обрабатываться на среднем смартфоне через мобильную сеть.
Особенно заметно это для тяжёлого JavaScript, больших изображений, web fonts и сторонних сервисов. Поэтому при оптимизации WordPress-сайта важно проверять не только desktop Lighthouse, но и реальные mobile field data. Именно реальные пользователи лучше всего показывают, насколько быстро сайт работает вне условий разработчика.
Что изменилось в Core Web Vitals для SPA и динамических сайтов в 2026 году?
В Chrome 151 появились новые API для измерения Core Web Vitals при soft navigations — переходах внутри одностраничных приложений, когда URL и контент меняются без полной перезагрузки документа. С октября 2026 года Chrome также начал публиковать экспериментальные версии этих показателей в CrUX.
Для обычного многостраничного WordPress-сайта это пока не меняет основной подход к оптимизации. Но для headless WordPress, React, Next.js и других SPA-проектов становится важнее анализировать пользовательский опыт не только при первой загрузке, но и при последующих переходах внутри приложения.
