Більшість відвідувачів не залишають повільну сторінку, бо ненавидять бренд. Вони йдуть, бо очікування відчувається як тертя, а тертя на першому екрані вбиває конверсію. Core Web Vitals - це спроба Google виміряти це тертя у спосіб, який можуть обговорювати і розробники, і власники сайтів.
Три метрики, перекладені
LCP, Largest Contentful Paint
Скільки часу потрібно, щоб з’явився основний контент сторінки. Для більшості сайтів це hero-зображення, головний заголовок або перше фото товару. Хороший LCP відчувається швидким; поганий LCP відчувається так, ніби сторінка все ще думає.
INP, Interaction to Next Paint
Наскільки чуйною відчувається сторінка, щойно ви намагаєтеся з нею взаємодіяти - натискаєте кнопку, розгортаєте меню, відкриваєте фільтри. Поганий INP відчувається так, ніби сторінка ігнорує вас на мить.
CLS, Cumulative Layout Shift
Наскільки контент стрибає, поки сторінка завантажується. Поганий CLS - це відчуття, коли тягнешся до кнопки й бачиш, як вона переміщується кудись інде, зазвичай бо реклама, зображення чи банер завантажилися пізно.
Чому ці метрики впливають на бізнес, а не лише на SEO
- Повільне перше відображення означає, що люди закривають вкладку до того, як з’явиться контент.
- Нечуйні взаємодії змушують форми, фільтри та оформлення замовлення відчуватися зламаними.
- Зсуви макета спричиняють хибні кліки, що створюють фрустрацію, повернення та звернення до підтримки.
- Google використовує ці метрики як сигнал ранжування, тож погана продуктивність також зменшує, як часто вас взагалі знаходять.
Вплив сукупний: невеликі проблеми продуктивності складаються між сесіями, а невеликі покращення теж накопичуються.
Що зазвичай дає найбільшу різницю
- Зображення. Коректно розміровані, сучасні формати (WebP/AVIF), ліниве завантаження нижче згину та з явними розмірами, щоб браузеру не доводилося вгадувати.
- Шрифти. Обмежте до тих, що ви справді використовуєте, самостійно хостьте, де можливо, та попередньо завантажуйте той, що рендерить текст hero.
- Сторонні скрипти. Аналітика, чат-віджети, A/B-інструменти та менеджери тегів часто є найбільшим джерелом повільного INP. Завантажуйте їх відкладено і лише на сторінках, де вони потрібні.
- Невикористаний JavaScript. Менше коду означає менше парсингу, менше виконання, менше енергії на слабких пристроях.
- Час відповіді сервера. Повільний бекенд ставить нижню межу для всього іншого. Кешування, оптимізація запитів та розумний рівень хостингу мають значення.
- Зарезервований простір. Використовуйте явні ширину/висоту або CSS aspect-ratio для зображень, реклами, iframe та банерів, щоб макет не зсувався пізніше.
Поширені помилки
- Вимірювання лише на власному швидкому ноутбуці. Користувачі на мобільних мережах та середніх пристроях. Використовуйте польові дані (моніторинг реальних користувачів) разом із лабораторними тестами.
- Гонитва за єдиним числом. Ідеальний бал Lighthouse за один прогін мало що означає; послідовні польові метрики впродовж тижнів - означають.
- Додавання інструментів для виправлення продуктивності. Більше скриптів рідко роблять сайт швидшим.
- Ставлення до продуктивності як до одноразової задачі. Без моніторингу вона регресує щоразу, коли команда додає новий віджет.
Розумна послідовність
- Отримайте базові польові дані для LCP, INP та CLS на ваших топ-5 сторінках.
- Спершу виправте hero-зображення та головний заголовок - вони непропорційно впливають на LCP.
- Проведіть аудит сторонніх скриптів; видаліть або відкладіть усе, що не є строго необхідним.
- Зарезервуйте простір для зображень, реклами та елементів, що завантажуються пізно.
- Моніторте безперервно та ставтеся до регресій як до багів.
