UK
Ігор НіколенкоВи відкриваєте свій сайт — він летить. Клієнт відкриває з телефона в маршрутці — і закриває, бо кнопка «Замовити» зʼявилася на четвертій секунді, а сторінка ще й підстрибнула під пальцем. Ви цього не бачите, бо у вас швидкий інтернет, потужний компʼютер і сайт давно в кеші. А Google бачить, бо міряє не у вас, а у реальних відвідувачів.
Core Web Vitals — це три числа, якими Google описує, як людина відчуває сторінку: чи швидко зʼявляється головне, чи швидко сайт реагує на дотик і чи не стрибає розмітка. Вони впливають на позиції у пошуку, але важливіше інше: вони напряму впливають на те, чи дійде людина до форми. Повільний сайт — це рекламний бюджет, з якого частину людей ви оплатили, а вони не дочекалися.
У цій статті я перекладу три метрики людською мовою, покажу, де подивитися свої справжні цифри, і розберу, що зазвичай гальмує сайт малого бізнесу і що з цього можна виправити без розробника.
Три метрики — три відчуття людини
Google свідомо обрав не «час завантаження сторінки», бо це число нічого не каже про досвід. Натомість — три моменти, які людина помічає тілом.
LCP, Largest Contentful Paint — коли на екрані зʼявився найбільший елемент: банер, заголовок, картинка товару. Це момент, коли людина розуміє «сторінка відкрилась». Google вважає добрим результат до 2,5 секунди.
INP, Interaction to Next Paint — скільки минає від дотику до реакції на екрані. Натиснули на меню — воно відкрилося одразу чи через паузу? Ця метрика замінила стару FID і суворіша за неї, бо дивиться на всі взаємодії за візит, а не лише на першу. Добре — до 200 мілісекунд.
CLS, Cumulative Layout Shift — наскільки сторінка «стрибає» під час завантаження. Класика: ви тягнетеся до кнопки, зверху довантажується банер, усе зсувається, і ви клацаєте не туди. Добре — до 0,1.
| Метрика | Що відчуває людина | Поріг «добре» | Найчастіша причина проблем |
|---|---|---|---|
| LCP | «Сторінка довго біла» | до 2,5 с | Важка картинка на першому екрані, повільний сервер, шрифти |
| INP | «Натискаю — і нічого» | до 200 мс | Багато скриптів: чати, пікселі, віджети, анімації |
| CLS | «Усе стрибає під пальцем» | до 0,1 | Картинки й банери без заданих розмірів, підвантажувані блоки |
Пороги — офіційні орієнтири Google, і рахуються вони за досвідом більшості відвідувачів, а не за найкращим чи середнім результатом. Тому «у мене відкривається швидко» — не аргумент.
Де подивитися свої справжні цифри
Є два типи вимірювань, і їх важливо не плутати.
Польові дані — те, що відчули реальні користувачі Chrome за останні тижні. Їх збирає Chrome User Experience Report, і саме вони впливають на пошук. Побачити їх можна у PageSpeed Insights у верхньому блоці «Що відчувають реальні користувачі» та у звіті «Основні показники вебсторінок» у Google Search Console. Якщо трафіку мало, польових даних може не бути — тоді орієнтуйтеся на лабораторні.
Лабораторні дані — результат одного прогону в контрольованих умовах, це нижня частина звіту PageSpeed Insights, побудована на Lighthouse. Вони корисні для діагностики: показують, які саме файли й скрипти займають час. Але «100 балів у лабораторії» не дорівнює швидкому сайту в полі, і навпаки.
Практичне правило: рішення ухвалюйте за польовими даними, причини шукайте в лабораторних. І перевіряйте мобільну вкладку — саме її Google бере за основу, і саме там проблеми найпомітніші.
Що зазвичай гальмує сайт малого бізнесу
За моїм досвідом, причини повторюються від проєкту до проєкту, і рідко серед них — «поганий код». Найчастіше це речі, які додавалися з добрими намірами.
Картинки. Фото з телефона на кілька мегабайт на першому екрані — найпоширеніша причина поганого LCP. Сюди ж — слайдери з десятком таких фото, які завантажуються всі одразу, хоча людина бачить один слайд.
Сторонні скрипти. Чат, кілька пікселів, віджет відгуків, карта, відео з автозапуском, калькулятор — кожен тягне свій код, і всі вони змагаються за процесор телефона. Це головний ворог INP. Особливо шкодять скрипти, які ставили «на пробу» і забули зняти.
Шрифти. Кілька гарнітур у кількох накресленнях, завантажені з зовнішнього сервісу, — і текст зʼявляється із затримкою або стрибає, коли шрифт нарешті приїхав.
Хостинг і відсутність кешу. Сервер, який генерує сторінку заново для кожного відвідувача і відповідає із затримкою, зсуває весь ланцюг завантаження. Це видно як довгий час до першого байта в лабораторному звіті.
Верстка без розмірів. Картинка чи банер без вказаних ширини й висоти — браузер не знає, скільки місця лишити, і зсуває контент, коли елемент нарешті завантажився. Це весь CLS.
Що виправити без розробника
Значну частину можна зробити самому в адмінці або з мінімальною допомогою.
- Стисніть картинки й переведіть у сучасні формати. WebP або AVIF замість JPEG і PNG дають ту саму якість у кілька разів меншим файлом. Багато платформ роблять це автоматично при завантаженні — перевірте, чи ваша вміє, і чи ввімкнено цю функцію.
- Відкладене завантаження для всього, що нижче першого екрана. Атрибут loading="lazy" на картинках і відео поза першим екраном — і браузер не витрачає ресурс на те, чого людина ще не бачить. А от головну картинку першого екрана, навпаки, треба завантажувати першою.
- Проведіть ревізію скриптів. Випишіть усе, що підключено: чати, пікселі, віджети. Для кожного — питання «чи це приносить заявки». Що не приносить — прибрати. Що лишається — по можливості перенести на серверну сторону: серверна передача конверсій знімає з браузера частину пікселів і одночасно повертає рекламі втрачені дані.
- Обмежте шрифти. Одна-дві гарнітури, два-три накреслення, з режимом показу тексту системним шрифтом, поки завантажується основний.
- Увімкніть кеш і CDN. Кешування сторінок на хостингу і мережа доставки контенту на кшталт Cloudflare для статичних файлів роблять сайт швидким для людини в іншому місті чи країні без зміни коду.
- Задайте розміри картинкам і блокам. Це часто налаштування теми або платформи; іноді — одна правка в шаблоні, яку варто попросити зробити один раз.
Після кожної зміни — перевірка у PageSpeed Insights у лабораторній частині одразу і в польовій через кілька тижнів. Індикатор має показувати факт: якщо польові дані не змінилися, значить, зміни не дійшли до реальних людей, і треба шукати далі.
Швидкість як частина воронки, а не як «технічне питання»
Найчастіша помилка — вважати швидкість справою розробника, яку можна відкласти. Насправді це перший крок воронки: людина ще не прочитала жодного слова, а вже вирішує, лишатися чи ні. Кожна сота відсотка бюджету, витрачена на тих, хто не дочекався, — це заявки, яких у вас не буде.
Тому я дивлюся на швидкість разом з усім іншим — з тим, як побудовані сторінки, чи рахуються заявки, чи не губляться вони у формі. Це один із розділів аудиту сайту й воронки: показати, на якому саме кроці ви втрачаєте людей, зокрема ще до того, як вони щось побачили. А коли сайт будується заново, простіше закласти швидкість в основу — сучасні формати картинок, кеш, мінімум скриптів у браузері, серверні конверсії — так, як це зроблено в NEO, і саме тому сайт за тиждень не означає «повільний сайт».
Коротко
- Core Web Vitals — три відчуття людини: коли зʼявилося головне (LCP), чи реагує сайт на дотик (INP), чи не стрибає розмітка (CLS).
- Офіційні орієнтири Google: LCP до 2,5 с, INP до 200 мс, CLS до 0,1, за досвідом більшості відвідувачів.
- Рішення — за польовими даними, діагностика — за лабораторними; дивіться мобільну вкладку.
- Найчастіші причини: важкі картинки, сторонні скрипти, шрифти, повільний хостинг без кешу, елементи без розмірів.
- Без розробника: стиснути картинки, відкласти завантаження, прибрати зайві скрипти, обмежити шрифти, увімкнути кеш і CDN.
- Серверна передача конверсій одночасно розвантажує браузер і повертає рекламі втрачені дані.
- Швидкість — перший крок воронки, а не окреме технічне питання.
Питання, які ставлять найчастіше
Чи справді швидкість впливає на позиції в Google?
Так, Core Web Vitals — один із сигналів ранжування, хоча й не головний. Сильніший ефект — поведінковий: люди частіше лишаються на швидкому сайті й частіше доходять до заявки.
Чому в PageSpeed Insights показники різні щоразу?
Лабораторний прогін залежить від навантаження на сервер і мережу в момент перевірки. Орієнтуйтеся на польові дані — вони усереднені за тижні.
Чи можна досягти «100 балів»?
Можна, але це не мета. Мета — «добре» за трьома метриками в польових даних для мобільних. Далі кожен бал коштує дорожче, ніж дає.
Сайт на конструкторі повільний через сам конструктор. Що робити?
Спочатку зробити те, що у ваших руках: картинки, скрипти, шрифти. Якщо після цього польові дані лишаються поганими, обмеження в платформі — і це аргумент для переїзду.
