Как улучшить LCP и INP на мобильной версии сайта: пошаговый разбор 5 технических причин

LCP и INP: что это такое и почему показатели часто проваливаются на мобильных

LCP (Largest Contentful Paint) — это метрика из набора Core Web Vitals, которая измеряет время до момента, когда самый крупный видимый элемент страницы полностью загружен на экране пользователя.

INP (Interaction to Next Paint) — вторая ключевая метрика, оценивающая скорость реакции интерфейса на взаимодействие пользователя: нажатие кнопки, клик по меню, ввод в форму. Чем ниже задержка — тем отзывчивее ощущается сайт.

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

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

Картина усложняется разрывом между лабораторными и полевыми данными. PageSpeed Insights в лабораторном режиме проверяет страницу в контролируемых условиях — фиксированная скорость соединения, конкретное устройство. Полевые данные (Chrome User Experience Report) собирают реальные измерения с реальных устройств реальных пользователей. Сайт может показывать хороший LCP в лаборатории и плохой — в поле, потому что аудитория сидит на бюджетных Android-смартфонах с нестабильным 4G. Работать нужно с обоими источниками: лаборатория показывает, что именно тормозит; поле — насколько это критично для вашей аудитории.

Проверьте скорость серверного ответа и оптимизируйте доставку данных

TTFB (время до первого байта) — первое, что нужно проверить, когда LCP не укладывается в рекомендуемые значения. Медленный ответ сервера напрямую откладывает момент начала загрузки любого ресурса на странице, включая главный LCP-элемент.

1. Измерьте TTFB через Lighthouse. Откройте Chrome DevTools → вкладка Lighthouse → выберите режим «Мобильные устройства» → запустите аудит. В разделе Diagnostics найдите метрику «Server response time». Lighthouse покажет фактическое время ответа сервера и сравнит его с рекомендуемым порогом. Запускайте тест несколько раз: одиночный прогон может попасть на кэшированный ответ и дать нереалистично низкий результат.
2. Проверьте данные реальных пользователей в Яндекс.Метрике. Откройте Метрику → Отчёты → Технологии → Скорость загрузки страниц. Здесь видно время загрузки по сегментам устройств. Отфильтруйте только мобильный трафик: если показатели на мобильных устройствах заметно хуже, чем на десктопе, — проблема, скорее всего, в серверной конфигурации или отсутствии CDN, а не в коде фронтенда.
3. Проверьте наличие CDN. Откройте DevTools → вкладка Network → обновите страницу → найдите запрос к основному HTML-документу → посмотрите заголовки ответа. Признак CDN — наличие заголовков вида X-Cache: HIT, CF-Cache-Status: HIT или аналогичных от вашего провайдера. Если таких заголовков нет — статические ресурсы (изображения, шрифты, скрипты) отдаются напрямую с хостинга, и пользователи в регионах получают их с задержкой.
4. Настройте кэширование на сервере. Проверьте заголовок Cache-Control в ответах сервера. Для статических ресурсов (CSS, JS, изображения) выставьте длительный срок кэширования. Для HTML-страниц — более короткий, чтобы контент оставался актуальным. Отсутствие кэширования означает, что каждый запрос мобильного пользователя генерирует нагрузку на сервер заново.

Сократите и оптимизируйте изображения и видео на мобильной версии сайта

Изображения — главный LCP-убийца на мобильных. Неоптимизированный hero-баннер в PNG на 3 МБ без указания размеров задерживает отрисовку самого крупного контента и одновременно ломает визуальную стабильность страницы. Решается в четыре шага.

1. Конвертируйте изображения в WebP или AVIF. Откройте Squoosh (squoosh.app) или настройте автоматическую конвертацию через плагин вашей CMS. WebP даёт заметно меньший вес по сравнению с PNG и JPEG при сопоставимом качестве; AVIF сжимает ещё сильнее, но поддержка браузерами шире у WebP. Для мобильной версии достаточно WebP с качеством в диапазоне 75–85 — визуально потери незаметны, вес падает в разы.
   Частая ошибка: конвертируют изображения, но оставляют оригинальные PNG в качестве fallback без тега <picture>. В итоге мобильный браузер загружает тяжёлый оригинал.
2. Проверьте и добавьте атрибуты width и height для каждого изображения. Браузер резервирует место под изображение до его загрузки только если знает размеры. Без этих атрибутов после загрузки картинки контент смещается — это прямой рост показателя визуальной стабильности (CLS). Согласно Основным сведениям о показателях Core Web Vitals — справка Google Search Central, значение CLS должно быть менее 0,1 для комфортного взаимодействия. Добавьте width="800" height="450" (или фактические размеры) в каждый тег <img>.
3. Подключите отложенную загрузку (lazy loading) для медиа за пределами первого экрана. Добавьте атрибут loading="lazy" ко всем изображениям и iframe с видео, которые пользователь не видит сразу. Это сокращает объём данных при первой загрузке страницы.
   Частая ошибка: loading="lazy" ставят на LCP-элемент — главный hero-баннер или первую карточку товара. Браузер откладывает его загрузку, и LCP проваливается. Атрибут loading="eager" (или его отсутствие) — только для изображений первого экрана; lazy — для всего остального.
4. Задайте адаптивные размеры через srcset и sizes. Мобильное устройство не должно загружать изображение шириной 1920 px для экрана 390 px. Пропишите несколько вариантов: srcset="image-400.webp 400w, image-800.webp 800w" и sizes="(max-width: 600px) 400px, 800px". Браузер выберет подходящий вариант сам.

Минимизируйте блокирующий JavaScript и сторонние скрипты

Блокирующий JavaScript задерживает отрисовку страницы до того, как браузер разберёт и выполнит скрипт. Для INP это прямая проблема: пока главный поток занят выполнением кода, он не реагирует на нажатия и касания пользователя. Для LCP — косвенная: если скрипт загружается синхронно в <head>, браузер откладывает построение DOM и рендеринг первого экрана.

1. Откройте Chrome DevTools → вкладка Performance → запишите сессию на мобильном эмуляторе. В треке «Main» найдите длинные жёлтые блоки — это задачи JavaScript, которые блокируют главный поток. Задачи длиннее нескольких десятков миллисекунд напрямую ухудшают INP. Конкретно смотрите, какой скрипт вызывает задачу: имя файла или домен стороннего сервиса будет в подсказке.
2. Проверьте атрибуты загрузки всех внешних скриптов в коде страницы. Скрипт без атрибута async или defer блокирует парсинг HTML. Добавьте defer для скриптов, которые не нужны до DOMContentLoaded (аналитика, чаты, виджеты), и async — для независимых скриптов без зависимостей от DOM. Inline-скрипты в <head> без крайней необходимости переносите в конец <body> или выносите в отдельный файл с defer.
   Частая ошибка: разработчик добавляет async скрипту, который зависит от jQuery или другой библиотеки. Если библиотека ещё не загружена — скрипт упадёт с ошибкой. Проверяйте зависимости перед сменой атрибута.
3. Запустите PageSpeed Insights для мобильной версии и откройте раздел «Устраните ресурсы, блокирующие рендеринг». Инструмент перечислит конкретные файлы JS и CSS, которые задерживают LCP. Для каждого файла решите: нужен ли он на первом экране? Если нет — отложите через defer или динамическую загрузку.
4. Проверьте сторонние скрипты отдельно. Откройте Chrome DevTools → вкладка Network → отфильтруйте запросы по типу «JS» → посмотрите колонку «Initiator» и домен. Чаты, виджеты обратного звонка, пиксели ретаргетинга и счётчики аналитики нередко добавляют суммарно несколько секунд к времени загрузки на медленных мобильных соединениях. Для каждого стороннего сервиса оцените: загружается ли он синхронно, блокирует ли главный поток, можно ли его отложить до первого взаимодействия пользователя (паттерн «загрузка по событию»).
   Частая ошибка: маркетолог подключает три-четыре виджета через тег в <head> без async. Каждый делает несколько сетевых запросов к внешним доменам — суммарная задержка накапливается, и LCP уходит за пределы рекомендованных значений.

Оптимизируйте стили и шрифты для мобильной версии сайта

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

Проведите технический SEO-аудит и устраните скрытые ошибки на сайте

Технический аудит в контексте Core Web Vitals — это не разовая проверка, а систематическая работа с тремя классами проблем: ошибки загрузки ресурсов, некорректные редиректы и нестабильность макета. Каждая из них влияет на разные метрики: 404 и цепочки редиректов тянут вниз LCP, а незакреплённые блоки — CLS, и устранить их помогает техническая оптимизация сайта.

1. Проверьте ошибки загрузки ресурсов через Screaming Frog. Откройте Screaming Frog → вкладка Response Codes → отфильтруйте по статусам 4xx и 5xx. Экспортируйте список и отдельно посмотрите колонку Content Type: изображения и скрипты с ошибкой загрузки блокируют или откладывают отрисовку LCP-элемента. Типичная ошибка: команды проверяют только HTML-страницы, но не ресурсы — JS, CSS, шрифты, изображения — хотя именно они чаще дают 404 на мобильной версии из-за неправильных относительных путей.
2. Найдите некорректные редиректы в Яндекс Вебмастере. Яндекс Вебмастер → Диагностика → Проблемы сайта. Здесь видны страницы с редиректными цепочками и временными редиректами (302) вместо постоянных (301). Цепочки из трёх и более редиректов задерживают начало загрузки страницы и тянут вниз LCP; найти их можно в Яндекс Вебмастере: Яндекс Вебмастер — диагностика и обход сайта → Диагностика → Проблемы сайта.
3. Измерьте CLS (визуальную стабильность) через PageSpeed Insights. Откройте PageSpeed Insights → введите URL мобильной версии → в разделе Diagnostics найдите «Avoid large layout shifts». Инструмент покажет конкретные элементы, которые сдвигаются при загрузке. Согласно Google Search Central — Core Web Vitals, основные сведения, для удобного взаимодействия CLS должен составлять менее 0,1. Типичные причины высокого CLS на мобильных: изображения без атрибутов width и height, баннеры, которые подгружаются после первичной отрисовки, и шрифты с FOUT-эффектом.
4. Устраните сдвиги макета. Для каждого изображения в <img> явно задайте width и height — браузер зарезервирует место до загрузки файла. Для рекламных и динамических блоков задайте минимальную высоту контейнера через CSS (min-height). Для шрифтов добавьте font-display: optional или swap в зависимости от критичности шрифта для первого экрана.

Инструменты и ресурсы для анализа и оптимизации LCP и INP

Для диагностики Core Web Vitals на мобильных нужны разные инструменты: одни показывают реальные данные пользователей, другие — лабораторные симуляции. Используй их в связке, а не по отдельности.

Яндекс Вебмастер → Диагностика → Качество сайта. Здесь видны проблемы, которые Яндекс зафиксировал при реальных обходах: медленные страницы, ошибки загрузки ресурсов, проблемы с мобильной адаптацией. Данные основаны на реальном трафике, поэтому именно с Вебмастера начинай диагностику — он показывает, что видит поисковик, а не симуляция браузера.

PageSpeed Insights совмещает два режима: лабораторные данные (Lighthouse под капотом) и полевые из Chrome User Experience Report. Согласно справке Google Search Central — Core Web Vitals и результаты поиска, для ранжирования учитываются именно полевые данные. Если лабораторный LCP хороший, а полевой — нет, проблема в реальных условиях сети и устройств пользователей, а не в коде как таковом.

Lighthouse в Chrome DevTools — для детального разбора причин. Запускай в режиме Mobile, в анонимном окне, чтобы расширения не искажали результат. Раздел «Opportunities» покажет конкретные файлы и элементы, которые тормозят LCP; раздел «Diagnostics» — задачи на главном потоке, которые влияют на INP. Частая ошибка: запускать Lighthouse на десктопе и переносить выводы на мобильную версию — данные расходятся существенно.

WebPageTest — когда нужен глубокий анализ водопада загрузки. Выбирай реальное мобильное устройство (не эмулятор) и регион, близкий к вашей аудитории. Инструмент строит детальный timeline: видно, какой ресурс блокирует отрисовку, где возникают сетевые задержки, на каком шаге браузер рисует LCP-элемент.

PR-CY удобен как быстрая точка входа: сервис агрегирует технические ошибки и даёт рекомендации в одном отчёте без ручной настройки. Используй его для первичного скрининга перед тем, как уходить в детальный аудит через Lighthouse или WebPageTest.

Готовый чек-лист по оптимизации LCP и INP на мобильной версии сайта

1. Проверьте время ответа сервера и подключите CDN. Откройте PageSpeed Insights → введите мобильный URL → найдите раздел «Сократите время ответа сервера (TTFB)». Если показатель выходит за рекомендованные значения — начните с настройки серверного кэширования и переноса статики (изображения, CSS, JS) на CDN-узлы ближе к пользователю. Для российской аудитории выбирайте CDN с точками присутствия в Москве и Санкт-Петербурге. Частая ошибка: CDN подключают для изображений, но забывают про шрифты и иконочные спрайты — они тоже тянут LCP.
2. Сожмите изображения, переведите их в современные форматы и включите отложенную загрузку. Для LCP-изображения (обычно это главный баннер или первый экран) — никакого loading="lazy": браузер должен загрузить его немедленно. Для всего остального — loading="lazy" обязателен. Конвертируйте JPEG/PNG в WebP или AVIF: современные форматы дают заметное сокращение размера при сопоставимом визуальном качестве. Проверьте результат через PageSpeed Insights → раздел «Используйте изображения в современных форматах». Частая ошибка: разработчики добавляют loading="lazy" на LCP-элемент — это прямо задерживает отрисовку первого экрана.
3. Минимизируйте блокирующий JavaScript и сторонние скрипты. Переносите некритичные скрипты в конец <body> или добавляйте атрибуты defer/async. Сторонние скрипты — пиксели, виджеты, чат-боты — загружайте через async или откладывайте до первого взаимодействия пользователя. Откройте Chrome DevTools → вкладка Performance → найдите Long Tasks на главном потоке: задачи длиннее рекомендованного порога блокируют реакцию на касания и напрямую ухудшают INP. Частая ошибка: аналитические скрипты подключают синхронно в <head> — это задерживает и LCP, и INP одновременно.
4. Встройте критические стили и оптимизируйте подключение шрифтов. Выделите CSS, необходимый для отрисовки первого экрана, и поместите его inline в <head> — браузер не будет ждать загрузки внешнего файла. Остальные стили загружайте асинхронно через media="print" onload="this.media='all'". Для шрифтов: добавьте <link rel="preload"> на основной шрифт и используйте font-display: swap — текст появится сразу, а шрифт подменится по готовности. Частая ошибка: font-display: swap добавляют, но забывают про preload — шрифт всё равно загружается поздно и вызывает сдвиг макета.
5. Проведите технический SEO-аудит и устраните ошибки, влияющие на CLS. Запустите Screaming Frog → вкладка Response Codes → отфильтруйте 4xx и 5xx: ошибочные ресурсы (шрифты, скрипты, изображения) тянут LCP вверх, так как браузер ждёт ответа. Для CLS — проверьте, что все изображения и видео имеют явно заданные атрибуты width и height: без них браузер не резервирует место под элемент и сдвигает макет при загрузке. Проверьте результат в Яндекс Вебмастер → раздел «Качество сайта» → ошибки мобильной версии. Частая ошибка: аудит проводят один раз после запуска — CLS-проблемы появляются при каждом обновлении шаблона или добавлении новых блоков.

Заключение

Пять технических причин, разобранных в статье, покрывают большинство реальных кейсов: медленный сервер и отсутствие CDN, тяжёлые изображения без lazy load и современных форматов, блокирующие стили и шрифты, неоптимизированный JavaScript, скрытые ошибки в редиректах и макете. Устраните их последовательно — и LCP с INP придут в норму без переписывания всего фронтенда.

Раз в квартал открывайте PageSpeed Insights и Яндекс Вебмастер → «Качество сайта» и сверяйте показатели. Это занимает час, но позволяет поймать деградацию до того, как она скажется на позициях.