Скорость сайта давно не стоит оценивать только по ощущению «открывается быстро» или по одному баллу в PageSpeed Insights. Google смотрит на страницу шире: через Core Web Vitals — ключевые показатели качества страницы, которые отражают реальный пользовательский опыт. Для SEO это важно, но без упрощений: хорошее быстродействие и page experience могут помочь сайту, однако сами по себе не заменяют релевантный контент, структуру и полезность страницы.

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

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

Скорость сайта, PageSpeed Insights и Core Web Vitals — иллюстрация к статье

Какие метрики важны сейчас

На момент обновления этой статьи Google ориентируется на три основные метрики Core Web Vitals :

  • LCP — Largest Contentful Paint, то есть время появления самого крупного видимого элемента в пределах первого экрана. Хорошим считается значение до 2,5 секунды.
  • INP — Interaction to Next Paint, то есть скорость реакции страницы на действие пользователя. Хороший уровень — до 200 мс.
  • CLS — Cumulative Layout Shift, то есть стабильность вёрстки во время загрузки. Хороший показатель — до 0,1.

Важная деталь: Google оценивает эти метрики не по одному визиту, а по 75-му перцентилю реальных посещений на мобильных и десктопных устройствах. Именно поэтому идеальная лабораторная проверка не гарантирует, что страница будет хорошо выглядеть в полевых данных. Если пользователи заходят из более медленных сетей, со старых смартфонов или видят более тяжёлый сценарий страницы, реальная картина может быть хуже.

С чего начинать проверку

Первая ошибка — смотреть только на общий балл в PageSpeed Insights . Сам по себе он почти ничего не объясняет. Намного полезнее смотреть сразу на два уровня данных:

  1. Полевые данные — реальное поведение страницы у пользователей. Если они доступны, PageSpeed Insights показывает их из Chrome UX Report.
  2. Лабораторные данные — контролируемый тест Lighthouse, который помогает локализовать проблему, но не является заменой реальному опыту.

Для рабочей диагностики обычно достаточно такой последовательности: сначала проверить URL в PageSpeed Insights, затем посмотреть отчёт Core Web Vitals в Google Search Console , а уже после этого разбирать конкретные причины в DevTools, Lighthouse или в рамках технического SEO-аудита сайта .

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

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

Что чаще всего портит LCP

LCP чаще всего ломается не из-за «медленного сайта в целом», а из-за конкретного крупного элемента на первом экране. У коммерческих страниц это обычно hero-image, большой баннер, заголовок с веб-шрифтом или главный контентный блок, который браузер находит слишком поздно.

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

Один из самых типичных промахов — когда главное изображение на первом экране загружается через lazy loading. Для LCP это плохая практика: страница откладывает загрузку именно того элемента, который должен появиться первым. Если большое изображение действительно является главным элементом страницы, его нужно загружать приоритетно, а не откладывать. Это прямо подчёркивается и в рекомендациях web.dev по LCP .

Что обычно помогает для LCP:

  • не lazy-load’ить главное изображение первого экрана;
  • отдавать его через обычный <img> , а не прятать за data-src или JavaScript;
  • сжимать изображения без потери смысла и отдавать современные форматы там, где это уместно;
  • не заставлять браузер открывать главный ресурс слишком поздно из-за тяжёлых CSS или JS;
  • при необходимости использовать preload для критического изображения или шрифта, если браузер находит их с задержкой.

Если сайт работает на старой теме, шаблоне или конструкторе, проблема часто глубже, чем просто картинка на странице. Иногда медленный LCP — это следствие того, как в целом построена страница ещё на этапе разработки сайта : тяжёлый первый экран, лишние библиотеки, фоновая картинка вместо нормального <img> , запутанный CSS или задержка из-за шрифтов.

Как улучшить INP

INP проседает тогда, когда страница медленно реагирует на действие пользователя: клик, тап, открытие меню, запуск фильтра, переключение вкладки, заполнение формы. В большинстве случаев проблема не в сервере, а в main thread браузера — основном потоке, который занят длинными JavaScript-задачами.

На практике слабый INP чаще всего связан с такими вещами:

  • тяжёлые JS-бандлы, которые долго парсятся и выполняются;
  • чрезмерное количество сторонних скриптов — чаты, трекеры, виджеты, A/B-сервисы, попапы;
  • сложные обработчики событий на кнопках, фильтрах, формах и меню;
  • большой DOM или частые перерасчёты вёрстки после взаимодействия пользователя;
  • долгие задачи, которые блокируют страницу на сотни миллисекунд.

Поэтому классический совет «подключите async и defer» сам по себе уже не решает проблему. Да, defer и async полезны для неблокирующих сценариев, но если на странице остаётся тяжёлый JavaScript, слабый INP никуда не исчезнет. Здесь приходится чистить лишние скрипты, разбивать длинные задачи, откладывать нефункциональные модули и проверять, что именно происходит после клика или тапа.

Как уменьшить CLS

CLS — это про скачки вёрстки. Именно из-за него кнопка может «уехать» вниз в момент, когда пользователь уже тянется к ней, а текст внезапно смещается после загрузки баннера, iframe или шрифта. Для контентного и коммерческого сайта это не мелочь, а реальная проблема пользовательского опыта.

Самые частые причины плохого CLS хорошо известны:

  • изображения без заранее заданных размеров;
  • рекламные блоки, embeds и iframe без зарезервированного места;
  • динамически вставленный контент над уже видимой частью страницы;
  • веб-шрифты, которые меняют размер или ширину текста после загрузки.

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

Отдельно стоит проверить, не блокируются ли CSS, JS или изображения в robots.txt . Такие ошибки не всегда становятся главной причиной просадки метрик, но могут ломать корректное отображение страницы и её анализ поисковыми системами.

Что ещё реально влияет на быстродействие

Есть несколько вещей, которые не сводятся к одной метрике, но стабильно влияют на реальную скорость сайта:

  1. Критические ресурсы над первым экраном. Если страница не может быстро отрисовать первый экран из-за большого CSS, тяжёлых шрифтов или запутанной цепочки ресурсов, LCP почти всегда страдает.
  2. Неиспользуемые CSS и JS. Старые темы, CMS-плагины и универсальные шаблоны часто тянут код, который не нужен конкретной странице, но всё равно блокирует или усложняет рендеринг.
  3. Кэширование и сжатие. Долгий cache lifetime для статических файлов, Brotli или Gzip, а также корректные заголовки кэша не исправят плохую архитектуру, но часто дают заметный выигрыш.
  4. Сервер и TTFB. Медленный ответ сервера тоже вредит, особенно если он задерживает отдачу HTML. Но в современных проектах TTFB — это лишь часть картины, а не единственный источник проблемы.
  5. CDN. CDN полезен, если у сайта широкая география трафика или тяжёлые статические ресурсы. Но CDN не уберёт долгие JS-задачи, не стабилизирует CLS и не сделает легче перегруженный первый экран.
  6. Сторонние сервисы. Именно они часто «съедают» и LCP, и INP, и CLS одновременно: чаты, виджеты, пиксели, сторонние формы, видеовставки, рекомендательные блоки.

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

Анализ производительности страницы: LCP, INP, CLS и технические причины просадки

Что часто делают неправильно

В статьях о скорости сайта до сих пор часто повторяют советы, которые звучат правильно, но в реальной работе мало что дают. Вот что стоит сразу убрать из мышления:

  • не сводить всю оптимизацию к одному баллу в PageSpeed Insights;
  • не писать, что скорость сама по себе гарантирует высокие позиции в Google;
  • не lazy-load’ить LCP-изображения только потому, что «так советуют для всех картинок»;
  • не лечить INP только атрибутами async и defer , если страница перегружена JavaScript;
  • не игнорировать CLS, потому что визуальные скачки часто бьют по UX сильнее, чем несколько десятых секунды в лабораторном тесте;
  • не надеяться, что CDN или кэш автоматически решат проблемы тяжёлого шаблона, плохого DOM и сторонних виджетов.

Как выглядит нормальный рабочий план

Если отбросить красивые презентации и смотреть на реальный процесс, то он обычно выглядит так:

  1. Проверить полевые данные и понять, какая метрика проседает — LCP, INP или CLS.
  2. Найти конкретный элемент или сценарий, который портит метрику.
  3. Отдельно проверить мобильную версию, потому что именно там проблемы часто проявляются сильнее.
  4. Почистить первый экран, JavaScript, сторонние скрипты, шрифты, баннеры и нестабильные блоки.
  5. Повторно сверить результат в PageSpeed Insights, Search Console и при необходимости в собственном RUM-мониторинге.

Такой подход почти всегда эффективнее, чем бесконечно «добивать балл» и гоняться за мелкими аудитами, которые не имеют реального влияния на пользовательский опыт. Если нужно отдельно посмотреть на технические подходы к улучшению метрик, полезно сверить их и с практическими рекомендациями web.dev по Core Web Vitals .

Вывод

Улучшение скорости сайта сегодня — это уже не история про абстрактное «сделать страницу легче». Это работа с конкретными метриками Core Web Vitals и конкретными техническими причинами, из-за которых пользователь видит медленный первый экран, ощущает задержку после клика или сталкивается со скачками вёрстки.

Для LCP нужно быстрее показать главный элемент страницы. Для INP — разгрузить JavaScript и main thread. Для CLS — стабилизировать макет ещё до загрузки всех блоков. И только потом имеют смысл кэш, CDN, сжатие, мелкие аудиты и косметические правки.

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