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, увімкнути вповільнення процесора вчетверо й емуляцію мобільного, записати 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 з уповільненням процесора вчетверо, спостереження за довгими задачами та відгуком на дотики на живому сайті.
web.dev, документація щодо метрики INP: визначення, пороги «добре / потребує покращення / погано», польовий характер вимірювання.
Google Search Console, звіт «Основні інтернет-показники»: окремі вкладки для мобільних і настільних пристроїв.
