Core Web Vitals: що полагодити без розробника

Ти відкриваєш Google Search Console, бачиш червону смужку, поруч - LCP, INP і CLS. Звіт ніби говорить мовою панелі керування космічним кораблем, хоча йдеться про звичайну сторінку з твоїми товарами, фото й кнопкою «Замовити». Рука тягнеться закрити вкладку з думкою: «Це точно до програміста». Але не все так складно. У цих трьох скороченнях є одна задача, яку часто не варто чіпати без технічної людини, і дві, де причина нерідко лежить у матеріалах, завантажених на сайт: у фото, банері, відео або блоці, для якого ніхто не залишив місця. Тому спершу варто зрозуміти, про яку незручність повідомляє звіт.

Швидкість потрібна не заради чарівного стрибка в пошуку, а щоб людина не чекала картинку, не натискала кнопку без реакції та не ловила текст, який раптом поїхав униз.

Largest Contentful Paint (LCP) - це час, за який на екрані з’являється найбільший помітний елемент сторінки. Найчастіше це велике фото товару, обкладинка, банер або великий заголовок. Google вважає хорошим LCP 2,5 секунди або менше.

Уяви сторінку кондитерської. Людина перейшла з реклами на сторінку торта, але спершу бачить порожню світлу площину, а головне фото торта з’являється із запізненням. Формально сайт уже почав завантажуватися, але для людини він ще не почався: вона прийшла саме за цим зображенням і ціною поруч із ним. Це проблема LCP. Interaction to Next Paint (INP) - це швидкість, з якою сторінка помітно відповідає на дію людини: натискання кнопки, відкриття меню, вибір варіанта товару, заповнення поля. Хороший INP - 200 мілісекунд або менше. Якщо натиснути «Додати в кошик», а інтерфейс зависає без жодної реакції, це не схоже на поламану кнопку, але відчувається саме так.

Коли сторінка рухається без твоєї згоди

Cumulative Layout Shift (CLS) - це показник візуальної стабільності: він підсумовує, яка частина уже видимого раптово зсувається і наскільки далеко вона їде. Це не секунди, а безрозмірна оцінка: 0,1 або менше - добре, понад 0,25 - погано. Наприклад, ти вже навів курсор або палець на кнопку, а над нею раптом з’явився банер, фото набрало висоту й кнопка поїхала вниз. Людина натискає не туди. У процесу в цей момент дивне хобі: він переставляє меблі, коли гості вже сіли. І йдеться не лише про перші секунди. Google міряє CLS протягом усього життя сторінки, а не тільки під час завантаження. Зсув, який стався протягом пів секунди після твого власного натискання, вважають очікуваним і не рахують; зсув, який стався сам собою - наприклад, коли ти прокручуєш нижче й туди догружається контент, - рахують.

Ці пороги Google перевіряє не за красивим середнім числом. Вони мають виконуватися щонайменше для 75% завантажень, окремо на мобільних пристроях і на комп’ютерах. Тому хороший результат на твоєму ноутбуці ще не означає, що сторінка добра для людей з телефоном і повільнішим з’єднанням.

Якщо в старому чек-листі ти бачиш FID, не витрачай час на його пошук. First Input Delay більше не входить до Core Web Vitals: 12 березня 2024 року його замінив INP. Тож у поточному звіті дивись саме на LCP, INP і CLS.

Коротка відповідь: сама по собі - ні. Google використовує Core Web Vitals у своїх системах ранжування, але прямо пояснює, що одного сигналу не існує. Хороші показники не гарантують верхніх позицій, а пошук прагне показати найрелевантніший матеріал навіть тоді, коли досвід користування сторінкою посередній. Це важливе уточнення, бо воно захищає тебе від двох невдалих рішень: чекати, що стиснення фото автоматично витягне сторінку вище за сильніші та корисніші відповіді, або махнути рукою на незручний сайт, бо текст і товар нібито достатньо хороші.

Швидкість - не заміна змісту, ціни, зрозумілої пропозиції чи довіри до бізнесу. Вона прибирає тертя між людиною та тим, за чим та прийшла. Якщо сторінка пояснює послугу, але перша картинка вантажиться надто довго, частина людей просто не дочекається пояснення. Якщо картка товару стрибає, людина може помилково натиснути на інший варіант. Це вже практична причина розібратися зі звітом, незалежно від обіцянок про місця в пошуку.

Роботу над швидкістю логічно тримати поруч із звичайними технічними доопрацюваннями сайту, а не перетворювати на окрему магічну послугу. І так само вона є частиною технічної сторони SEO, а не заміною роботи над тим, чи відповідає сторінка на запит людини.

У Google Search Console відкрий звіт Core Web Vitals. Він показує дані реальних відвідувачів із Chrome User Experience Report, або CrUX, за останні 28 днів. У ньому URL потрапляють до груп Good, Needs improvement або Poor. Для LCP це відповідно до 2,5 секунди, до 4 секунд і понад 4 секунди; для INP - до 200 мілісекунд, до 500 мілісекунд і понад 500 мілісекунд; для CLS - до 0,1, до 0,25 і понад 0,25.

Важлива деталь: групі сторінок призначають найгірший зі статусів. Якщо в однієї групи нормальний LCP, але поганий CLS, вона виглядатиме проблемною. Це не вирок усім сторінкам і не привід одразу міняти все. Це підказка, з якого типу незручності почати. Ще дві деталі економлять час. Група з’являється лише тоді, коли має мінімальний обсяг даних одразу для LCP і CLS; якщо їх замало, Search Console може показати натомість origin-групу - усі URL у межах одного протоколу, хоста й порту разом. А напис «No data available» - це не хороша оцінка: він означає, що реальних відвідувань поки замало, а не що сторінки швидкі.

Разовий тест сторінки може показати іншу картину, і це нормально. Такий замір відбувається тут і зараз, за конкретних умов. Search Console дивиться на те, що відбувалося з реальними людьми протягом періоду. Один інструмент зручний, щоб перевірити зміну одразу після правки; інший показує, як сайт поводився в житті, а не лише в одному запуску. Корисно знати, що PageSpeed Insights показує обидва зрізи одразу: угорі - дані реальних відвідувачів Chrome, нижче - лабораторний замір, зроблений тут і тепер. Перевір, який із двох ти читаєш і чи це дані саме твого URL, а не всього сайту: якщо в окремої сторінки трафіку замало, інструмент показує дані origin. Є ще одна чесна причина розбіжності: лабораторний запуск зазвичай завантажує сторінку й на цьому спиняється, тож не бачить зсувів, які стаються пізніше, коли людина прокручує.

Не намагайся довести, який із них «правильний». Краще сформулюй просте питання: чи бачу я у Search Console проблему в реальних відвідуваннях, і чи можу я відтворити її на сторінці? Якщо LCP поганий, відкрий сторінку з телефона через мобільний інтернет і подивися, що саме людина чекає найдовше. Якщо CLS поганий, кілька разів завантаж сторінку та простеж, чи рухається кнопка, ціна, форма або текст.

LCP не завжди означає, що сервер або код катастрофічно повільні. Він складається з кількох частин: часу до першої відповіді сайту, затримки перед початком завантаження потрібного ресурсу, самого завантаження та відмальовування елемента. Без розробника ти не зобов’язаний розкладати ці частини по технічних полицях. Тобі достатньо перевірити найочевидніше: що стоїть на першому екрані і скільки зайвої ваги воно несе.

Якщо головний екран має велике зображення, не завантажуй туди найбільший файл, який трапився в папці. Підготуй версію під реальний розмір у дизайні, стисни її та, якщо твоя система керування сайтом це підтримує, використай сучасний формат WebP або AVIF. Суть не в назві формату: людина не має завантажувати зайві дані, яких на її екрані навіть не видно. Стискати варто, але не обіцяй собі, що це зрушить число на кожній сторінці. З чотирьох частин вище легший файл скорочує лише одну - саме завантаження. Якщо зображення лишається схованим, доки не відпрацює скрипт, і все з’являється одночасно, зекономлений час просто переходить у відмальовування елемента, а LCP лишається на місці. Тож ситуація «файл легший у кілька разів, а звіт не рухається» - це не твоя помилка, а ознака того, що причина, яка лишилась, технічна.

Що має з’явитися першим

Головну картинку першого екрана не варто відкладати через lazy-load: браузер чекає з її завантаженням, хоча саме її людина прийшла побачити відразу.

Візьмімо умовну майстерню меблів і випишімо припущення, щоб міркування можна було перевірити. Припустімо, що Search Console позначає мобільну групу сторінок проєктів як Poor за LCP; що на першому екрані стоїть одне фото кухні, яке власник завантажив прямо з камери, приблизно на чотири мегабайти; що на телефоні це фото показується завширшки близько 800 пікселів; і що сайт працює на системі керування, медіатека якої дає доступ до файлу, його формату й перемикача lazy-load, але не глибше. Рішення за цих припущень: не перебудовувати сайт і не купувати плагін. Замінити саме цей файл версією, підготовленою під розмір, у якому його реально показують, зберегти у WebP або AVIF, якщо система це вміє, лишити оригінал в архіві й вимкнути lazy-load лише для цього зображення. Далі - чекати: звіт говорить двадцятьма вісьмома днями реальних відвідувань, тож вирок наступного ранку нічого не означає. Три речі змінили б це рішення. Якщо найбільшим елементом першого екрана виявиться заголовок або інший блок - фото від початку було не тією ціллю. Якщо новий файл вантажиться швидко, а група через кілька тижнів усе одно лишається Poor - причина радше у відповіді сервера або скриптах, які стримують відмальовування. А якщо редактор не дає доступу до формату, стиснення чи lazy-load - чесний наступний крок це описана задача для розробника, а не ще одна спроба в медіатеці. Для фото нижче на сторінці відкладене завантаження може бути доречним, але не для першої великої картинки.

Якщо доступу до формату, стиснення чи lazy-load у тебе немає, не вгадуй налаштування в коді. Занотуй сторінку, назву головного зображення й те, що воно є найбільшим елементом першого екрана. Для розробника це вже нормальна постановка задачі, а не тривожне «щось червоне в Google».

CLS часто видно без спеціальних знань. Відкрий сторінку та не прокручуй її відразу. Подивися, чи виникають із запізненням блоки, через які їде все, що вже було на екрані. Особливо перевір великі фото, відео, вбудовані карти, форми, віджети та банери.

Google називає поширеними причинами стрибків зображення без указаних розмірів, рекламу, вставки й iframe без розмірів, динамічно доданий контент і вебшрифти. Iframe - це вбудоване в сторінку вікно іншого сервісу, наприклад карти, відео або форми. Для читача немає різниці, що саме зрушило кнопку; важливо, що сторінка не зарезервувала для цього місце заздалегідь.

Задай у редакторі ширину й висоту кожному зображенню та відео. Якщо таких полів немає, ту саму роботу роблять у стилях через співвідношення сторін, а для блока, висота якого наперед невідома - віджета відгуків, рекламного місця, вбудованої форми - працює зарезервована мінімальна висота. Для карти чи відео обери фіксований контейнер або попроси залишити під нього місце до завантаження. Одне застереження про зарезервоване місце: воно не має схлопуватися, коли нічого не приїхало. Заглушка, що зникає, бо реклами чи відгуку не повернулося, дає рівно такий самий стрибок, як і контент, що з’явився.

Другий умовний приклад: на сторінці послуги є форма запису, а над нею з’являється віджет відгуків. Спершу форма стоїть високо, потім віджет догружається й відсуває кнопку. Власник не мусить переписувати віджет. Він може вимкнути його на цій сторінці, перенести нижче або попросити розробника зарезервувати для нього сталу висоту. Якщо система пропонує вказати пропорції або розмір блоку, не залишай поля порожніми. Тут перші два варіанти - рішення в редакторі, третій - технічна задача.

INP пов’язаний із тим, як сторінка обробляє дію людини. Google розкладає кожну взаємодію на три частини: затримку до того, як код, що обробляє твоє натискання, взагалі почне виконуватися; час роботи цього коду; і затримку до моменту, коли браузер може показати результат на екрані. JavaScript - код, який запускає меню, фільтри, кошик, форми й попапи - зазвичай проявляється в одній із цих частин, а під час завантаження великий скрипт може стримувати реакцію просто тому, що браузер ще розбирає й компілює його. Одну річ ти можеш зробити без розробника, і це не обхідний маневр: подивися, скільки всього ти попросив сторінку нести. Чат, віджет відгуків, рекламні й аналітичні теги, слайдер, яким ніхто не користується - кожен приносить свій код. Прибрати те, що сторінці не потрібне, - редакторське рішення. Далі чесна відповідь звучить так: щоб знайти, яка з трьох частин повільна, потрібна людина, яка вміє читати профіль продуктивності.

Ти все одно можеш добре підготувати задачу. Випиши конкретну дію: «на мобільному в картці товару після вибору розміру кнопка довго не змінюється» або «меню після натискання відкривається з паузою». Додай URL, пристрій і час, коли ти це побачив. Не називай причину, якщо не знаєш її. Твоя цінність тут у точному описі моменту, а не у спробі самостійно лікувати JavaScript через випадковий плагін.

Не став плагін кешування лише тому, що в тебе червона смужка. Він може бути корисним у певній конфігурації, але не зменшить вагу фото, яке ти завантажив у надмірному розмірі, і не пояснить, чому сторінка відгукується із затримкою. Спершу назви проблему її іменем: LCP, CLS або INP. Лише після цього вирішуй, чи можна змінити файл або блок у редакторі, чи потрібна технічна робота.

Перший крок один: відкрий у Search Console звіт Core Web Vitals, запиши найгіршу з трьох метрик окремо для мобільних і комп’ютерів та знайди одну сторінку з цієї групи. Далі дивись не на червоний колір, а на те, що людина реально чекає, натискає або втрачає з поля зору.