Core Web Vitals в 2026 году: почему тьюб-сайты и каталоги проваливают LCP, INP и CLS — и как это исправить

Большинство гайдов по производительности написаны под блоги и лендинги: одна большая картинка, заголовок, пара кнопок. Вам советуют сжать изображения и отложить JavaScript — и на этом всё. Ничего из этого не выживает при встрече с настоящим тьюб-сайтом или взрослым каталогом, где один шаблон рисует сетку из 60–200 превью, грузит плеер весом в 300 КБ, вставляет рекламные блоки от сети, которую вы не контролируете, и на входе накрывает всё это модалкой возрастного гейта.

Именно здесь Core Web Vitals и умирают. А на площадке, которая зарабатывает на тысячах показов, «неудовлетворительная» оценка — это не абстрактная SEO-проблема, а медленная утечка трафика и RPM одновременно. Это практический разбор, актуальный на 2026 год: почему такие сайты проваливают три метрики, которые Google реально измеряет, и как чинить каждую на уровне шаблона, чтобы фикс сразу распространялся на все страницы.

Что такое Core Web Vitals в 2026 году

Core Web Vitals — это три полевые метрики, которыми Google описывает реальный опыт загрузки и использования страницы. Largest Contentful Paint (LCP) измеряет, насколько быстро появляется самый крупный видимый элемент. Interaction to Next Paint (INP) измеряет отзывчивость страницы на клики, тапы и ввод. Cumulative Layout Shift (CLS) измеряет, насколько сильно прыгает вёрстка во время загрузки. Пороги «хорошо» в 2026 году не сдвинулись: LCP — не больше 2,5 секунды, INP — не больше 200 миллисекунд, CLS — не больше 0,1.

Хуже всего люди понимают то, как именно Google выставляет оценку. Он не запускает Lighthouse на быстром ноутбуке и не считывает число с экрана. Он берёт данные Chrome User Experience Report (CrUX) — обезличенную статистику реальных пользователей Chrome — и смотрит на 75-й перцентиль ваших визитов за скользящее 28-дневное окно. Страница проходит метрику только тогда, когда как минимум 75% реальных просмотров укладываются в порог «хорошо». Проще говоря, вашу оценку определяет самая медленная четверть трафика. Идеальный результат в Lighthouse не значит почти ничего, если треть аудитории сидит со среднего Android-смартфона на нестабильном мобильном интернете — а для тьюб-сайтов и каталогов такая аудитория не исключение, а большинство. Именно поэтому владельцы так удивляются, увидев в Search Console пометку «плохо» у сайта, который «у меня-то летает».

INP — та метрика, что застаёт врасплох. Она сменила First Input Delay (FID) ещё в марте 2024 года, и любой гайд, где всё ещё фигурирует FID, устарел. Для интерактивных страниц разница жёсткая: FID измерял задержку только первого взаимодействия. INP измеряет худшую задержку взаимодействия за весь визит. Каждый клик по фильтру, каждый тап по категории, каждое наведение на превью, которое дёргает JavaScript, каждый символ в строке поиска — всё это питает INP, и худший случай становится вашей оценкой. На странице с десятками интерактивных превью и панелью фильтров эту планку взять куда сложнее, чем когда-либо было с FID, — поэтому примерно два сайта из пяти до сих пор её не проходят.

Одно практическое следствие полевых данных — терпение. Поскольку CrUX работает по скользящему 28-дневному окну, фикс, который вы выкатили сегодня, полностью отразится в Search Console только примерно через месяц. Это не баг: вы всегда смотрите на месяц накопленного пользовательского опыта, а не на вчерашний деплой. Профессиональный подход — перестать сверлить взглядом Search Console в ожидании обновления и вместо этого поставить собственную линию раннего предупреждения примерно на 80% от каждого порога: LCP, выползший за 2,0 с, INP за 160 мс или CLS за 0,08 — это уже сигнал действовать, чтобы поймать регрессию до того, как она пересечёт официальную границу и тронет позиции.

Почему это вопрос дохода, а не только SEO

Стоит честно проговорить, что Core Web Vitals делают и чего не делают для ранжирования, — потому что именно здесь чаще всего сливают инженерное время. Page experience — реальный сигнал, но ведёт он себя как тайбрейк, а не как рычаг роста. Прохождение всех трёх метрик не спасёт тонкий контент и слабый ссылочный профиль, и никакая настройка INP не обгонит конкурента с лучшим контентом и более сильным авторитетом. Что прохождение делает — так это не даёт вам проиграть тайбрейк конкуренту, чей контент примерно не хуже вашего. На конкурентных запросах, где за одни и те же ключи бьётся десяток площадок, этот тайбрейк — уже не пустяк.

Но главная причина за это браться — деньги, которые с Google вообще не связаны. Скорость и стабильность двигают показатели, которые вы и так отслеживаете. Быстрые страницы — это меньше отказов и больше просмотренных роликов за сессию, а значит, больше рекламных показов на посетителя. Стабильная вёрстка — это реклама, которая действительно в зоне видимости в момент отрисовки, а значит, сохранённая viewability и связанные с ней ставки: рекламный блок, подгрузившийся с опозданием в две секунды на странице, которую пользователь уже проскроллил, — это показ, за который вы заплатили сдвигом вёрстки и не заработали ничего. Публично описанные кейсы по всему вебу раз за разом показывают одну картину: сайты, вдвое сократившие LCP, видят рост длительности сессии примерно на пятую часть, а сайты, улучшившие CLS, — измеримый прирост рекламного дохода. Точные цифры разнятся, но направление скучно предсказуемо — и на площадке с миллионами просмотров пара процентов складывается в реальные деньги.

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

Почему такие сайты проваливают проверку там, где общие советы не помогают

Провалы носят архитектурный характер и кучкуются в одних и тех же шести местах почти на каждом тьюб-сайте и каталоге.

Сетка превью — первый и худший виновник. Страница листинга рисует от 50 до 200 картинок, и если они отдаются без явных атрибутов ширины и высоты, браузер не знает, какой высоты будет каждая, пока не скачает её. По мере подгрузки всё, что ниже, дёргается вниз — классический всплеск CLS, помноженный на каждую картинку в сетке. В той же сетке обычно живёт и LCP: самый крупный видимый элемент тьюб-страницы — почти никогда не логотип и не заголовок, а первое превью, и если оно с ленивой загрузкой или отдаётся раздутым JPEG, LCP страдает.

Плеер — второй. JWPlayer, VideoJS и им подобные тащат JavaScript-бандлы в диапазоне 200–500 КБ, и если инициализировать плеер при загрузке страницы, этот бандл выполняется синхронно и блокирует главный поток на несколько сотен миллисекунд на среднем телефоне. Всё, что пользователь пытается сделать в это окно, — тап по превью, открытие фильтра — встаёт в очередь за ним. Это самый частый источник провалов INP свыше 500 мс.

Рекламные сети — третий, и они бьют сразу по двум метрикам. Блоки, которые асинхронно вставляют своё объявление уже после отрисовки страницы, толкают контент вниз при подгрузке (CLS), а сами рекламные скрипты крутят длинные задачи в главном потоке (INP). Этот код вы контролируете не полностью, поэтому чинить его — самое неприятное, но не безнадёжное.

Модалка возрастного гейта — четвёртый, и он почти уникален для этой ниши. Когда полноэкранный оверлей возрастной проверки вставляется через JavaScript после отрисовки, он сдвигает каждый видимый элемент под собой, и одна такая модалка в одиночку способна утащить CLS страницы из «хорошо» в «плохо». Шрифты — пятый тихий вредитель: загруженные не так, они добавляют блокирующий рендер запрос к LCP и вызывают видимую перекомпоновку текста (и удар по CLS), когда кастомный шрифт подменяет запасной. А под всем этим лежит шестой фактор — сама аудитория. Поскольку такие сайты сильно смещены в сторону мобильных пользователей на бюджетном железе, тот самый 75-й перцентиль, по которому оценивает Google, определяют ровно те устройства, которым тяжелее всего с большим JavaScript и крупными картинками.

Как чинить LCP: проблема сетки превью

Начните с выяснения, что вообще является вашим LCP-элементом, — полдела в том, чтобы чинить правильную вещь. Откройте Chrome DevTools, запишите загрузку во вкладке Performance и найдите маркер LCP на плёнке кадров; или прогоните страницу через PageSpeed Insights и прочитайте строку «Largest Contentful Paint element» в диагностике. На тьюб-странице это должно быть первое превью в сетке. Если инструмент показывает логотип, CSS-фон или элемент за пределами экрана — у вас структурная проблема ещё до любой оптимизации: фоновые CSS-картинки, в частности, нельзя эффективно предзагрузить, и браузер обнаруживает их поздно, так что если ваше главное превью задано через background-image, сначала переведите его в обычный инлайновый <img>.

Полезно помнить, что LCP на самом деле складывается из четырёх отрезков времени: ответ сервера (time to first byte), задержка до того, как браузер вообще обнаружит картинку, время на её скачивание и время на отрисовку после скачивания. Оптимизируя LCP, вы бьёте по тому из четырёх, что оказался самым длинным, — и для тьюб-сайтов это почти всегда задержка обнаружения и ответ сервера.

Самый действенный одиночный фикс — не дать браузеру обнаружить LCP-картинку поздно. По умолчанию он находит этот <img> только после разбора HTML и CSS, а это лишние сотни миллисекунд. Предзагрузите её в <head> и пометьте высоким приоритетом, чтобы скачивание стартовало сразу, параллельно с HTML:

html

<link rel="preload" as="image"

href="/thumbnails/video-001.avif"

fetchpriority="high">

<img src="/thumbnails/video-001.avif"

width="320" height="180"

fetchpriority="high"

loading="eager"

decoding="async"

alt="Название видео">

<img src="/thumbnails/video-002.avif"

width="320" height="180"

loading="lazy"

decoding="async"

alt="Название видео">

Дальше — формат. Отдача превью в WebP срезает размер файла примерно на четверть-треть против JPEG при том же качестве; AVIF идёт дальше, часто более чем вдвое, и к 2026 году его поддержка в браузерах достаточно широка, чтобы отдавать его по умолчанию с запасным WebP или JPEG для отставших. Сочетайте формат с адаптивными размерами, чтобы телефон не качал превью десктопного размера: srcset с парой значений ширины позволяет каждому устройству забирать только нужное. На WordPress конвертацию при загрузке берут на себя плагины; на самописном стеке конвертируйте через Sharp или Pillow при загрузке либо трансформируйте на лету на границе CDN.

И есть сервер, от которого никакая работа с картинками не спасёт. Ответ сервера дольше 600 мс — почти гарантированный провал LCP, а шейред-хостинг регулярно сидит на 800 мс — 1,2 с. Переезд на нормально настроенный сервер с объектным кэшем (Redis или Memcached) и полноценным веб-сервером обычно опускает TTFB в диапазон 150–300 мс — и это улучшает LCP сильнее любой отдельной оптимизации картинок. А поскольку такие сайты обслуживают глобальный трафик, отдача превью обязана идти через CDN, чтобы посетитель за три континента от вас не ждал круговой путь до origin на каждую картинку.

Одна свежая хитрость для длинных сеток: CSS-свойство content-visibility: auto позволяет браузеру пропускать работу по отрисовке превью, которые далеко за экраном, пока пользователь не прокрутит к ним, — это срезает нагрузку на главный поток при рендере сетки из 200 картинок. Задайте пропущенным элементам contain-intrinsic-size, чтобы браузер всё же зарезервировал верное место и вы не обменяли выигрыш в LCP на проблему с CLS.

Как чинить INP: плееры, фильтры и налог на сторонние скрипты

INP — самая тяжёлая из трёх, потому что это не проблема размера файла, которую можно «сжать». Это проблема архитектуры JavaScript. Главный поток умеет делать только одно дело за раз, и каждая длинная задача на нём — это окно, в которое страница не может ответить пользователю. Чинить INP — значит находить эти длинные задачи и либо убирать их, либо дробить, либо уносить с критического момента.

Плеер — крупнейший рычаг. Фикс прост по сути: не инициализируйте плеер при загрузке страницы вообще. Покажите статичный постер с наложенной кнопкой play и подгружайте с инициализацией скрипт плеера только тогда, когда пользователь реально тапнет play. Для всех, кто листает без просмотра, — а на странице листинга это большинство — стоимость плеера полностью исчезает из их INP.

// Не вызывайте jwplayer(...).setup() при загрузке.

// Показываем постер + кнопку play, грузим по требованию:

document.querySelector('.play-btn').addEventListener('click', () => {

const s = document.createElement('script');

s.src = '/jwplayer.js';

s.onload = () => jwplayer('player').setup({ file: videoUrl });

document.head.appendChild(s);

}, { once: true });

Взаимодействия с фильтрами и сортировкой на страницах каталога — следующий источник. Переключение категории или смена сортировки обычно дёргают один синхронный обработчик, который читает состояние, фильтрует набор данных, сносит старые DOM-узлы, строит новые и обновляет интерфейс — всё в одной длинной задаче, способной заблокировать поток на сотни миллисекунд. Фикс — уступить браузеру на полпути, чтобы он отрисовал промежуточный кадр (скажем, состояние загрузки) и остался отзывчивым, а не завис:

filterBtn.addEventListener('click', async (e) => {

updateState(e.target.value);

// Возвращаем управление браузеру, чтобы он отрисовал кадр до тяжёлой работы

await scheduler.yield(); // Chromium 115+

// Запасной вариант для старых движков: await new Promise(r => setTimeout(r, 0));

rerenderGrid(filteredResults);

});

API scheduler в 2026 году даёт больше, чем одну точку уступки: scheduler.postTask() позволяет ставить работу в очередь с явными приоритетами (user-blocking, user-visible, background), так что действительно несрочная работа — например, предзагрузка следующей партии превью — идёт с приоритетом, который никогда не конкурирует с тапом пользователя. По-настоящему откладываемую работу — аналитические маячки, некритичную настройку интерфейса — уносите в requestIdleCallback, который запускает её только когда главный поток свободен. А любой обработчик, срабатывающий часто (классика — автодополнение в поиске), нужно снабдить debounce, чтобы не гонять фильтр на каждое нажатие клавиши.

Категория, которую владельцы упускают чаще всего, — сторонние скрипты. Код рекламных сетей, партнёрские трекеры, виджеты чата и аналитика — всё это крутится на вашем главном потоке, и вместе они нередко становятся крупнейшим вкладом в INP на монетизируемом сайте именно потому, что это код, который вы не писали и не профилируете. Грузите каждый из них, что не нужен для первой отрисовки, с async или defer, прячьте всё что можно за первое взаимодействие пользователя и безжалостно ревизуйте, что вообще должно там быть. Виджет чата, который грузится на каждой странице категории, но не используется ни на одной, — это чистый налог на INP.

Наконец, когда INP плохой, а почему — непонятно, перестаньте гадать. У опенсорсной библиотеки web-vitals есть сборка с атрибуцией, которая показывает, какой именно элемент и какое взаимодействие дали ваш худший INP и сколько в нём пришлось на задержку ввода, обработку и отрисовку. Прикрутить её на день реального трафика — и вы найдёте конкретный виноватый обработчик быстрее, чем любым объёмом лабораторных тестов.

Как чинить CLS: превью, реклама, возрастной гейт и шрифты

CLS — самая исправимая из трёх, потому что почти весь он идёт из горстки хорошо понятных источников, а фиксы — это HTML и CSS, а не глубокий рефакторинг.

Явные размеры на каждой картинке — фундамент. Это самый действенный фикс CLS на насыщенной медиа странице, и он тривиален: дайте каждому <img> атрибуты width и height, чтобы браузер зарезервировал верное место до прихода картинки, и при загрузке ничего не сдвинулось. Подстрахуйтесь CSS-свойством aspect-ratio на контейнере для адаптивных раскладок:

html

<img src="thumb.avif" width="320" height="180"

alt="Название видео" loading="lazy" decoding="async">

<style>

.thumb-container { aspect-ratio: 16 / 9; width: 100%; overflow: hidden; }

</style>

Рекламные блоки — второй крупный источник, и принцип идентичен: зарезервировать место до прихода рекламы. Пустой <div>, в который через две секунды вставят баннер высотой 250 пикселей, толкает всё, что ниже, вниз на эти 250 пикселей — часто через несколько экранов контента. Дайте контейнеру минимальную высоту или соотношение сторон заранее, чтобы место было уже выделено к моменту прихода объявления:

html

<div id="ad-top" style="min-height:90px;width:728px;max-width:100%"></div>

<div class="ad-slot" style="aspect-ratio:728/90;width:100%;max-width:728px"></div>

Возрастной гейт требует отдельного подхода, потому что вставка полноэкранного оверлея после первой отрисовки — одно из худшего, что можно сделать с CLS. Есть два чистых способа. Первый — отрисовать HTML модалки в первоначальном ответе сервера, чтобы она была частью первой отрисовки, а затем просто прятать и показывать её через CSS: смена видимости у уже существующего DOM не считается сдвигом вёрстки. Второй, и самый простой, — сделать её оверлеем с position: fixed, который стоит над потоком документа и вообще не двигает контент под собой, когда бы он ни появился и ни исчез:

html

<div id="age-gate" role="dialog" aria-modal="true"

style="position:fixed;inset:0;z-index:9999;background:#000;

display:flex;align-items:center;justify-content:center;">

<div>

<p>Сайт содержит контент для взрослых.</p>

<button id="age-confirm">Мне есть 18 — Войти</button>

</div>

<script>

const gate = document.getElementById('age-gate');

if (sessionStorage.getItem('age-verified')) gate.remove();

document.getElementById('age-confirm').addEventListener('click', () => {

gate.remove(); // без сдвига — это был position:fixed

sessionStorage.setItem('age-verified', '1');

});

</script>

Шрифты — тихий четвёртый источник. Загрузка веб-шрифта через @import внутри CSS-файла добавляет блокирующую рендер цепочку запросов, что бьёт по LCP, а когда кастомный шрифт наконец подменяет запасной, текст перекомпоновывается и CLS растёт. Предзагрузите шрифт в <head> вместо импорта и используйте font-display: optional, чтобы браузер остался на запасном, если кастомный ещё не в кэше, — так подмены не будет вовсе. Для 2026 года сделайте ещё шаг: добавьте в правило @font-face дескрипторы size-adjust, ascent-override и descent-override, чтобы запасной шрифт занимал почти ровно столько же места, сколько кастомный, — тогда даже при подмене сдвигать будет нечего.

Бесконечная прокрутка тоже заслуживает упоминания, ведь на таких сайтах она частая: дозагрузка следующей партии результатов безопасна для CLS, пока вы добавляете контент ниже текущего вьюпорта и не перекомпоновываете то, что уже на экране. Резервируйте место под спиннер загрузки, вставляйте в заранее размеренные контейнеры и никогда не добавляйте контент выше позиции прокрутки пользователя.

Две техники 2026 года, которые почти все игнорируют

Помимо классических фиксов, две браузерные возможности тихо стали одними из крупнейших доступных выигрышей в 2026 году, и почти ни один тьюб-сайт или каталог их не использует.

Первая — кэш «назад/вперёд» (bfcache). Когда он работает, нажатие кнопки «назад» мгновенно восстанавливает предыдущую страницу из снимка в памяти: без сети, без повторного рендера, без сдвига вёрстки и с почти нулевыми LCP и INP на этой навигации. Для аудитории, которая много листает и постоянно скачет между страницей категории и отдельными роликами, bfcache — это разница между «шустро» и «вязко» на протяжении всей сессии. Загвоздка в том, что несколько частых паттернов тихо его отключают: обработчик события unload где угодно на странице, заголовок Cache-Control: no-store или некоторые всё ещё открытые соединения. В Chrome DevTools во вкладке Application есть тестер bfcache, который точно показывает, что его блокирует. Убрать эти блокировки — часто правка в одну строку, улучшающая опыт для огромной доли навигаций.

Вторая — Speculation Rules API, который позволяет сказать браузеру предзагрузить или даже полностью предрендерить страницы, куда пользователь, скорее всего, пойдёт дальше, — так что к моменту клика страница уже готова. На тьюб-сайте, где посетители кликают из листинга в ролик за роликом, предрендер наиболее вероятной следующей страницы делает эту навигацию мгновенной и фактически прячет время её загрузки. Достаточно консервативного правила «предрендерить при наведении или когда переход вероятен»:

html

<script type="speculationrules">

{

"prerender": [{

"where": { "href_matches": "/video/*" },

"eagerness": "moderate"

}]

}

</script>

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

Как понять, что фикс действительно сработал

Мониторинг — это сочетание трёх видов данных, потому что каждый отвечает на свой вопрос. Google Search Console показывает полевые данные — реальные цифры CrUX, по которым Google и оценивает, и ранжирует, — и это авторитетный сигнал «прошёл / не прошёл». Одна его особенность играет вам на руку: он группирует похожие URL (все страницы просмотра, все листинги категорий, все результаты поиска), а не отчитывается по каждому отдельно, — значит, фикс, применённый к шаблону, поднимает разом все URL, построенные на этом шаблоне. Чините сначала самые трафиковые шаблоны — и сдвинете крупнейшую группу наименьшими усилиями.

PageSpeed Insights даёт лабораторные данные — синтетические, мгновенные и идеальные для отладки конкретной страницы до и после изменения, ведь не нужно ждать 28 дней, чтобы увидеть, сдвинул ли фикс стрелку в лаборатории. Используйте его для быстрых итераций, а вердикт доверяйте Search Console. А чтобы ловить проблемы раньше обоих инструментов, добавьте собственный мониторинг реальных пользователей: библиотека web-vitals измеряет LCP, INP и CLS в браузерах ваших реальных посетителей и позволяет слать эти цифры на ваш собственный эндпоинт аналитики, давая видимость регрессии в тот же день, а не с задержкой в месяц.

import { onLCP, onINP, onCLS } from 'web-vitals';

const send = (m) => navigator.sendBeacon('/rum',

JSON.stringify({ name: m.name, value: m.value, id: m.id }));

onLCP(send); onINP(send); onCLS(send);

Что бы вы ни делали, уважайте 28-дневное окно, прежде чем объявлять победу или поражение по официальным цифрам. Если группа страниц всё ещё застряла в «нужно улучшить» спустя более чем два полных цикла CrUX после деплоя фикса — это сигнал перепроверить конкретные URL из группы через PageSpeed Insights и поохотиться за тем, что фикс шаблона упустил. А если хочется наблюдать тренд, а не единичный снимок, история CrUX даёт увидеть, как перцентили группы страниц двигались неделя к неделе.

С чего начинать и на что не тратить время

Когда всё валится разом, порядок важен. Сначала чините ту метрику, что сидит в зоне «плохо», — это ваш живой риск для позиций. Затем беритесь за INP: он самый тяжёлый и самый часто проваливаемый, так что настоящая работа обычно там. Потом LCP, который сильнее всего влияет на отказы, а значит, и на коммерческие цифры. Потом CLS, самый исправимый и часто выпадающий сам собой из работы над размерами картинок и рекламными блоками, которую вы бы всё равно делали.

Не менее важно понимать, когда остановиться. Сигнал ранжирования у Google бинарный по каждой метрике — «хорошо» или «не хорошо», — так что CLS 0,02 и CLS 0,09 считаются абсолютно одинаково. Догонять зелёную метрику, делая её ещё зеленее, — это инженерное время, потраченное с нулевой пользой для позиций; вложите его в ту метрику, что всё ещё красная. И раз Search Console группирует по шаблонам, мыслите шаблонами, а не отдельными URL: одна правка шаблона страницы просмотра или листинга категории стоит больше сотни точечных правок отдельных страниц.

Замечание для немалой доли таких сайтов на WordPress, ведь одни и те же ошибки всплывают снова и снова. Уберите @import для Google Fonts из своего CSS и либо разместите шрифты у себя, либо грузите их через <link> с font-display: optional. Убедитесь, что шаблоны темы ставят width и height на каждый <img>, — большинство тем их опускают. Пустите превью через CDN, отложите каждый некритичный скрипт (аналитику, партнёрские трекеры, чат) и не подключайте плеер на страницах листинга, где ничего не проигрывается. Включите серверное объектное кэширование, чтобы обуздать TTFB, и зарезервируйте высоту у рекламных контейнеров до запуска рекламных скриптов. Ничего экзотического — это просто конкретные места, где стандартная взрослая тема на WordPress теряет производительность.

Чего Core Web Vitals для вас не сделают

Стоит закончить на реалистичной ноте, потому что главная ошибка владельцев — воспринимать Core Web Vitals как стратегию роста. Это не она. Прохождение всех трёх не поднимет сайт с тонким контентом, не компенсирует слабый или спамный ссылочный профиль и не обгонит по-настоящему лучшего конкурента. Page experience — это гигиенический минимум и тайбрейк: он не даёт терять позиции, которые вы бы иначе потеряли, и улучшает внутренние цифры, что двигают доход, но стоит он поверх контента и авторитета, а не вместо них.

Правильная модель мышления такова: Core Web Vitals в 2026 году — это дисциплина, а не трофей. Грузите меньше JavaScript, резервируйте место под всё, что подгружается с опозданием, отдавайте приоритет тому, что пользователь видит первым, и позвольте кэшу браузера и предрендеру делать работу, которая у них хорошо выходит. Делайте это стабильно на уровне шаблонов — и оценки подтянутся, а вместе с ними, что важнее, и трафик с рекламным доходом, которые тихо утекали, пока страница подтормаживала.