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) - це показник візуальної стабільності: наскільки сторінка пересуває вже видимі елементи під час завантаження. Хороший CLS - 0,1 або менше. Наприклад, ти вже навів курсор або палець на кнопку, а над нею раптом з’явився банер, фото набрало висоту й кнопка поїхала вниз. Людина натискає не туди. У процесу в цей момент дивне хобі: він переставляє меблі, коли гості вже сіли.

Ці пороги 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, вона виглядатиме проблемною. Це не вирок усім сторінкам і не привід одразу міняти все. Це підказка, з якого типу незручності почати.

Разовий тест сторінки може показати іншу картину, і це нормально. Такий замір відбувається тут і зараз, за конкретних умов. Search Console дивиться на те, що відбувалося з реальними людьми протягом періоду. Один інструмент зручний, щоб перевірити зміну одразу після правки; інший показує, як сайт поводився в житті, а не лише в одному запуску.

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

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

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

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

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

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

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

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

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

Задай у редакторі ширину й висоту кожному зображенню та відео. Для карти чи відео обери фіксований контейнер або попроси залишити під нього місце до завантаження.

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

INP пов’язаний із тим, як сторінка обробляє дію людини. На нього часто впливає JavaScript - код, який запускає меню, фільтри, кошик, форми, попапи та інші взаємодії. Коли INP не вкладається в 200 мілісекунд, чесна відповідь зазвичай така: потрібен розробник, який подивиться, що саме блокує реакцію.

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

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

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