Швидкість сайту та Core Web Vitals: що перевіряти бізнесу

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

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

Три показники Core Web Vitals

За офіційною документацією Web Vitals, добрі орієнтири такі: LCP — не більше 2,5 секунди, INP — не більше 200 мілісекунд, CLS — не більше 0,1. Оцінювання проходження виконується на 75-му перцентилі відвідувань, окремо для мобільних і настільних пристроїв. Це пороги якості досвіду, а не гарантія продажів.

• LCP характеризує час появи найбільшого видимого елемента основного контенту.

• INP описує чутливість сторінки до взаємодій користувача протягом відвідування.

• CLS вимірює неочікувані зміщення макета.

Якщо повільно з’являється головне фото, починають із LCP і ланцюжка завантаження. Якщо натискання фільтра довго не дає видимого відгуку, аналізують взаємодію та зайнятість головного потоку браузера. Якщо блоки «стрибають», перевіряють розміри медіа, шрифти та контент, що додається пізніше.

Лабораторні та польові дані вирішують різні задачі

Лабораторний тест відтворює контрольовані умови й допомагає знайти причину. Польові дані відображають реальні пристрої, мережі та поведінку користувачів. У стандартному лабораторному запуску Lighthouse немає реальних взаємодій за весь візит, тому його показники не замінюють польовий INP. Обидва підходи потрібні для осмисленої перевірки.

Після виправлення лабораторний результат може змінитися одразу, а накопичувані польові дані — поступово. Якщо трафіку мало, частина звітів не матиме достатньої вибірки. Це не означає автоматично добрий або поганий стан. У такому разі варто додати власні вимірювання та чітко зазначати обмеження даних.

Почніть із важливих сторінок, а не лише з головної

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

Наприклад, Decibel поєднує каталог автозвуку й огляди. Для товарної сторінки важливі фото, характеристики та вибір; для матеріалу блогу — швидке читання й переходи до релевантного обладнання. Це різні сценарії перевірки, хоча вони належать одному сайту. Наведений кейс ілюструє структуру продукту, а не непідтверджені показники його швидкості.

Зображення: розмір файлу та місце у завантаженні

Спершу знайдіть, яке зображення справді формує перший екран. Йому потрібні відповідні розміри, формат і своєчасне завантаження. Не слід автоматично відкладати всі картинки: головне фото може виявитися саме тим ресурсом, який користувач чекає найдовше. Нижні галереї, навпаки, часто можна завантажувати пізніше.

Для різних екранів варто віддавати різні розміри. Велике оригінальне фото не повинно без потреби завантажуватися у маленьку картку. Водночас надмірне стиснення псує деталі товару. Потрібно перевіряти і вагу, і візуальну якість, особливо для тексту на упаковці або дрібних технічних елементів.

JavaScript, сторонні віджети та реакція інтерфейсу

Чат, аналітика, відео, рекламні скрипти й складні компоненти ділять ресурси браузера. Кожен інструмент може бути корисним окремо, але разом вони створюють затримки. Інвентаризація повинна показати власника скрипта, його призначення, момент завантаження та можливість відкласти роботу до потреби.

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

Вибір фреймворку впливає на доступні інструменти, проте не скасовує цієї роботи. У статті про Nuxt і Next.js пояснюємо, як розділяти серверну та клієнтську відповідальність і не оцінювати технологію лише за назвою.

Як прибрати неочікувані зміщення

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

Окремо тестуйте модальні вікна та блокування прокручування: зникнення смуги прокрутки іноді зміщує всю сторінку. Коректне виправлення має зберігати позицію, роботу клавіатури й можливість закрити вікно. Прибирати анімації без аналізу не завжди потрібно, але вони не повинні заважати основній дії.

Робочий план оптимізації

1. Зафіксувати вихідні виміри, пристрої та важливі маршрути.

2. Знайти найбільше обмеження для кожного сценарію.

3. Внести невеликий набір змін і перевірити функціональність.

4. Повторити виміри за зіставних умов.

5. Спостерігати польові дані й додати контроль, щоб проблема не повернулася.

Не змішуйте технічний ефект із бізнес-висновком. Покращення LCP є технічним результатом. Зміна конверсії потребує окремого аналізу трафіку, асортименту, реклами та сезону. Заздалегідь погоджений спосіб оцінки захищає від гучних, але непідтверджених обіцянок.

Поширені запитання

Чи потрібно прагнути 100 балів у кожному тесті?

Бал може бути зручним індикатором, але пріоритет — швидкий і стабільний користувацький сценарій. Витрати на останні бали слід порівнювати з реальним ефектом і функціональністю.

Чи допоможе лише заміна хостингу?

Якщо обмеження на сервері — може допомогти. Якщо проблема у важких зображеннях, JavaScript або зміщеннях верстки, потрібні зміни в інших частинах системи.

З чого почати власнику сайту?

Запишіть сторінки й дії, на які скаржаться користувачі. Технічний аудит сайту допоможе зіставити ці спостереження з вимірами, а матеріал про SEO та AI-пошук — включити швидкість у ширшу роботу над якістю сторінок.