Google написал, что сайт неэффективен на мобильных. Виноваты оказались счётчики
В Search Console у нашего сайта загорелось 102 неэффективных адреса на мобильных — и те же 102 зелёные на компьютере. Первая гипотеза про фоновую анимацию не подтвердилась замером. Виноваты оказались рекламные теги, а самой дорогой мелочью — вторая копия одной и той же библиотеки на 189 КБ. Разбор с цифрами и инструкция из шести шагов.
В Search Console у нашего собственного сайта загорелось: 102 адреса «неэффективны» на мобильных — и ровно те же 102 адреса зелёные на компьютере. Один сайт, одна вёрстка, разный вердикт. Мы полезли разбираться, первая же очевидная гипотеза оказалась неверной, а виновником оказалось то, что стоит почти на каждом сайте и что владелец обычно вообще не считает частью сайта. Ниже — весь разбор с замерами и инструкция, как проверить и починить своё.
Что именно измеряет Google
Метрика называется INP — Interaction to Next Paint. Google описывает её так:
«INP — метрика, которая оценивает общую отзывчивость страницы на действия пользователя, наблюдая за задержкой всех кликов, тапов и нажатий клавиш за время визита».
Пороги: хорошо — до 200 мс, требует улучшения — от 200 до 500 мс, плохо — больше 500 мс.
web.dev, документация по INPКлючевое, что стоит понять владельцу: INP меряет не скорость загрузки. Он меряет, сколько времени проходит от касания до того, как экран отреагировал. Страница может открыться за секунду и всё равно быть «неэффективной», если после открытия она занята собой и не успевает ответить на палец.
И вторая важная вещь: это полевая метрика. Google берёт её у реальных посетителей, а не из лабораторного теста. Поэтому в отчёте она обновляется с задержкой и по скользящему окну — мгновенного зелёного после правки не будет.
Почему мобильный красный, а компьютер зелёный
Ответ скучный и полностью объясняет расхождение: процессор телефона в четыре-восемь раз медленнее настольного. Один и тот же кусок работы, который на ноутбуке занимает 60 мс и остаётся незаметным, на телефоне растягивается до 300–500 мс — и человек уже видит, что кнопка «залипла». Вёрстка тут ни при чём: код один и тот же, разная только скорость его исполнения.
Первая гипотеза оказалась неверной
На нашей главной есть фоновая анимация, и подозрение легло на неё сразу — так же, как ляжет у большинства владельцев: «на сайте что-то шевелится, значит оно и тормозит». Вместо того чтобы её выключать и надеяться, мы замерили три варианта одного и того же экрана: как есть, с отключённой анимацией и с заблокированными сторонними тегами.
Мерили не «ощущение», а конкретную величину — блокирующее время главного потока: сумму того, на сколько длинные задачи превышают 50 мс. Пока идёт такая задача, браузер не может ответить на касание, и именно из этого складывается INP.
Результат снял вопрос. Отключение анимации не дало ничего — 1840 мс против 1782 мс исходных, разница в пределах погрешности, а формально даже хуже. Зато блокировка сторонних тегов срезала блокирующее время с 1782 до 378 мс. 79% времени, в течение которого страница не могла ответить на палец, создавали не наш код и не анимация.
Настоящий виновник
В <head> стояли четыре тега, и все четыре — стандартные, которые владелец ставит и забывает: счётчик аналитики, тег рекламной системы и два пикселя социальной сети. Все с атрибутом async, все «не блокирующие». Суммарно около 600 КБ стороннего JavaScript.
Дальше нашлось то, ради чего стоит читать этот раздел. Библиотека счётчика весом 189 КБ скачивалась и выполнялась дважды.
Причина обыденная. У нас два идентификатора — аналитика и реклама. Для каждого система выдаёт готовый сниппет со своей строкой подключения, и владелец честно вставляет оба. Но библиотека там одна и та же: она обслуживает все идентификаторы через отдельные вызовы конфигурации. Второй экземпляр не добавляет ничего — он просто ещё раз качается, ещё раз разбирается и ещё раз исполняется на том самом медленном мобильном процессоре.
Если у вас подключены аналитика и рекламный кабинет одной и той же системы — с высокой вероятностью у вас та же картина. Проверяется за минуту, способ ниже в шаге 3.
Почему «async» не спасает
Это второе место, где интуиция подводит. Атрибут async означает: «не задерживай разбор HTML, качай параллельно». Он честно делает свою работу — страница отрисовывается, не дожидаясь тега.
Но когда файл скачался, его всё равно надо исполнить, а исполняется он в том же единственном главном потоке, который отвечает на касания. async убирает блокировку разбора, но не убирает занятость потока — а INP меряет именно её. Отсюда типичная ситуация: страница показалась быстро, все счётчики «асинхронные», а метрика красная.
Ещё одна ловушка: одна отсрочка ничего не даёт
Напрашивающееся решение — отложить загрузку тегов до момента, когда браузер освободится. Мы так и сделали. И замерили.
Блокирующее время после одной только отсрочки составило 2101 мс против 2026 мс исходных — то есть стало чуть хуже. Логика простая: отсрочка сдвигает работу во времени, но не убирает её. Работа никуда не делась, она просто выполняется позже — иногда ровно тогда, когда человек уже начал тыкать в экран.
Сработало другое: устранение второй копии библиотеки. После него блокирующее время упало до 1775 мс, а вместе с ним подтянулось всё остальное — первая отрисовка с 1128 до 824 мс, ответ сервера с 669 до 335 мс.
Что делать со своим сайтом: шесть шагов
Ниже — порядок, в котором каждый шаг имеет смысл после предыдущего. К каждому — проверка, по которой видно, что вы его прошли.
Убедиться, что проблема ваша
Откройте в Search Console раздел с основными интернет-показателями и посмотрите на мобильную вкладку отдельно от компьютерной. Именно отдельно: расхождение «телефон красный, компьютер зелёный» — самый частый вид этой проблемы, и если смотреть только сводку, его легко не заметить.
Если мобильная вкладка зелёная — дальше можно не читать, у вас этой проблемы нет.
Измерить, а не гадать
Главная ошибка на этом шаге — начать выключать то, что кажется тяжёлым. Мы чуть не выключили анимацию, которая была ни при чём. Замерьте три варианта одной и той же страницы: как есть, без подозреваемого и без сторонних тегов.
Самый доступный способ — DevTools в Chrome: вкладка Performance, включить замедление процессора в 4 раза и эмуляцию мобильного, записать 10–15 секунд жизни страницы и посмотреть на длинные задачи. Они подсвечены и по каждой видно, какой файл её породил.
Проверить, не грузится ли одна библиотека дважды
Это самая дешёвая победа во всём списке. Откройте вкладку Network в DevTools, отфильтруйте по js и посмотрите на список: нет ли одинакового имени файла дважды, с разными параметрами в адресе.
Типовой случай — счётчик аналитики и рекламный тег одной системы: сниппеты разные, файл один. Оставьте одно подключение, а второй идентификатор настройте отдельным вызовом конфигурации. Ничего не потеряется: библиотека обслуживает оба.
<!-- было: два сниппета, одна и та же библиотека дважды -->
<script async src="…/tag.js?id=ID-1"></script>
<script async src="…/tag.js?id=ID-2"></script>
<!-- стало: библиотека одна, идентификаторов сколько нужно -->
<script async src="…/tag.js?id=ID-1"></script>
<script>
config('ID-1');
config('ID-2');
</script>
Отложить теги, не потеряв ни одного события
Только после шага 3 — потому что сама по себе отсрочка не помогает, мы это замерили. Но в связке она даёт освободить критические первые секунды.
Смысл приёма: вынести внешние файлы из <head> и подгружать их по первому из трёх событий — простой главного потока, таймаут в 3 секунды или первое касание экрана. Касание в списке обязательно: если человек уже взаимодействует со страницей, тег нужен немедленно, иначе вы потеряете как раз активную сессию.
События при этом не теряются, и это ключевая деталь. Крошечные заглушки-функции остаются в <head> и складывают все вызовы в очередь; когда библиотека наконец загрузится, она проиграет очередь целиком. Так эти сниппеты и задуманы — очередь предусмотрена их авторами.
Перепроверить и не ждать мгновенного зелёного
После выкладки повторите замер из шага 2 — вы должны увидеть падение блокирующего времени. А вот отчёт в Search Console позеленеет не сразу: он строится на данных реальных посетителей за скользящее окно и обновляется с задержкой в недели.
Это нормально и не повод откатывать правку или делать вторую поверх первой. Лабораторный замер говорит, что стало лучше — значит, поле подтвердит это позже.
Если не помогло — резерв
Когда сторонние теги приведены в порядок, а метрика всё ещё не в норме, дальше идут по убыванию отдачи: лишние счётчики, которые дублируют друг друга по назначению; неиспользуемый CSS (у нас на главной 92% правил не применяются); кэширование HTML, если страница отдаётся без кэша вовсе.
Отдельно стоит честно спросить: нужны ли вам все подключённые счётчики. Каждый из них — это чужой код, который выполняется на телефоне вашего посетителя, пока тот ждёт реакции на нажатие.
Чего делать не стоит
Коротко
«Неэффективно на мобильных при зелёном компьютере» почти всегда означает одно: страница занята исполнением чужого кода на медленном процессоре телефона. В нашем случае сторонние теги давали 79% блокирующего времени, а самой дорогой мелочью оказалась вторая копия одной и той же библиотеки на 189 КБ — она грузилась просто потому, что сниппет копируют по одному на каждый аккаунт.
Если делать одно действие прямо сейчас — откройте вкладку Network на своём сайте и посмотрите, не качается ли какой-нибудь файл счётчика дважды. Это проверка на минуту, и она бесплатна.
Сканирование покажет тяжёлые страницы, блокирующие скрипты и остальные технические находки — с разделением по серьёзности.
Частые вопросы
Что такое INP простыми словами?
Это время от касания экрана до момента, когда страница видимо отреагировала. Google считает хорошим показатель до 200 мс, плохим — больше 500 мс. Метрика оценивает отзывчивость, а не скорость загрузки: страница может открыться быстро и всё равно долго не отвечать на нажатия.
Почему сайт неэффективен на мобильных, но эффективен на компьютере?
Потому что процессор телефона в четыре-восемь раз медленнее настольного. Один и тот же скрипт, который на компьютере отрабатывает за 60 мс незаметно, на телефоне растягивается до 300–500 мс, и человек видит задержку. Код при этом один и тот же — разная только скорость исполнения.
Правда ли, что аналитика замедляет сайт?
В нашем замере сторонние теги давали 79% блокирующего времени главного потока: 1782 мс с ними против 378 мс без них. Это не повод убирать аналитику совсем, но это повод проверить, сколько у вас тегов, не дублируются ли они и когда именно они грузятся.
Помогает ли async у скрипта аналитики?
Частично. Атрибут async снимает блокировку разбора HTML, поэтому страница отрисовывается раньше. Но скачанный файл всё равно исполняется в главном потоке, а INP меряет занятость именно этого потока. Асинхронный скрипт может испортить метрику точно так же, как обычный.
Можно ли отложить загрузку счётчиков и не потерять конверсии?
Да, если оставить в head функции-заглушки, которые копят вызовы в очередь до загрузки библиотеки — так эти сниппеты и спроектированы. Обязательно включите первое касание экрана в число событий, по которым загрузка запускается, иначе можно потерять активную сессию. После выкладки проверьте, что события доходят.
Через сколько отчёт в Search Console станет зелёным после правки?
Не сразу. Показатель собирается у реальных посетителей за скользящее окно и обновляется с задержкой в недели. Ориентируйтесь на собственный лабораторный замер: если блокирующее время упало, поле подтвердит это позже.
Источники
Собственный замер PromoPilot, 28 августа 2026: эмуляция Pixel 5 с замедлением процессора в 4 раза, наблюдение за длинными задачами и откликом на касания на живом сайте.
web.dev, документация по метрике INP: определение, пороги «хорошо / требует улучшения / плохо», полевой характер измерения.
Google Search Console, отчёт «Основные интернет-показатели»: раздельные вкладки для мобильных и настольных устройств.
