Швидкість сайту та Core Web Vitals: повний гід

Що таке Core Web Vitals простими словами

Почнемо з головного. Core Web Vitals — це три метрики, якими Google вимірює реальну якість завантаження сторінки очима живої людини, а не робота. Вони відповідають на три прості запитання: чи швидко з'явився головний вміст, чи швидко сайт відреагував на вашу дію та чи не стрибала верстка під пальцем.

LCP — наскільки швидко видно головне

LCP (Largest Contentful Paint) — це момент, коли у видимій частині екрана відмалювався найбільший елемент: зазвичай це обкладинка, заголовок або велике зображення. Користувач вважає сторінку завантаженою саме тоді, коли побачив цей блок, а не коли дотягнувся останній скрипт у підвалі. Добрий орієнтир на 2026 рік — вкластися приблизно у 2,5 секунди на типовому мобільному з'єднанні.

INP — наскільки швидко сайт відповідає

INP (Interaction to Next Paint) прийшов на зміну старому FID і вимірює чуйність: ви натиснули кнопку, торкнулися меню, почали друкувати — і скільки мілісекунд минуло до видимої реакції інтерфейсу. Якщо після кліку пів секунди нічого не відбувається, мозок упевнений, що сайт завис. Комфортний діапазон — до 200 мілісекунд.

CLS — наскільки стабільна верстка

CLS (Cumulative Layout Shift) ловить найдратівливіший баг: ви цілитеся в кнопку, а згори дотягнулося зображення чи банер, усе поїхало вниз, і ви натиснули не туди. Це накопичувальний зсув верстки, і що ближче він до нуля, то охайніше відчувається сайт. Здорове значення — менше ніж 0,1.

Запам'ятайте просту формулу: LCP — про «побачив», INP — про «натиснув», CLS — про «не смикається». Усі три метрики Google збирає у справжніх користувачів Chrome і враховує в ранжуванні як частину сигналу про якість сторінки.

Чому швидкість впливає на SEO та конверсію

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

Швидкість і позиції в пошуку

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

Швидкість і гроші

На комерційних проєктах зв'язок між швидкістю завантаження сайту та доходом видно неозброєним оком. Пришвидшення першого екрана помітно піднімає конверсію кошика та форм заявок, знижує вартість залучення з реклами (за ті самі гроші ви не втрачаєте половину трафіку на завантаженні) і збільшує глибину перегляду. Ми неодноразово бачили це у клієнтських кейсах з розробки та оптимізації: технічна робота над швидкістю окупається швидше, ніж чергова рекламна кампанія.

Є й репутаційний шар. Гальмівний сайт підсвідомо зчитується як ненадійний: якщо тут усе лагає, чи можна довіряти оплату? Швидкість — це перше рукостискання з брендом, і воно має бути впевненим.

Як виміряти швидкість: лабораторія та поле

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

Лабораторні дані (lab)

Лабораторні вимірювання робить інструмент у контрольованих умовах: фіксований канал, заданий пристрій, чисте середовище. Це Lighthouse (вбудований у Chrome DevTools) і лабораторна частина PageSpeed Insights. Плюс лабораторії — відтворюваність: ви змінюєте код і одразу бачите, стало краще чи гірше. Мінус — це симуляція, а не живі люди.

Польові дані (field)

Польові дані — це метрики, зібрані у справжніх користувачів Chrome (набір CrUX). Саме їх Google враховує в ранжуванні. Вони показують, як сайт поводиться на реальних пристроях, мережах і в реальній географії. Польові цифри рахуються за 75-м перцентилем: важливо, щоб швидко було не «в середньому», а у трьох чвертей аудиторії.

Практичний порядок вимірювання

1. Проженіть ключові шаблони (головна, категорія, картка, форма) через PageSpeed Insights — окремо для мобільних і десктопа.
2. Дивіться насамперед на польові Core Web Vitals, якщо вони є; лабораторний бал використовуйте як інструмент налагодження.
3. Відкрийте вкладку Performance у DevTools і знайдіть, який саме елемент відповідає за LCP і які скрипти тримають потік.

Золоте правило: оптимізуйте за полем, налагоджуйте за лабораторією. Гонитва за гарною сотнею в Lighthouse без огляду на реальних користувачів — це робота заради скриншота, а не заради бізнесу.

LCP: за що відповідає і як покращити

LCP найчастіше і є те, що люди називають «сайт довго вантажиться». Покращити його — означає швидше показати головний елемент першого екрана. Розкладемо на складники.

З чого складається LCP

LCP складається з чотирьох частин: час відповіді сервера (TTFB), затримка на завантаження ресурсу, час самого завантаження ресурсу і час відмальовування. Гальмувати може будь-яка з них, тому лікування починається з діагностики, а не з вгадування.

Що справді пришвидшує LCP

• Швидка відповідь сервера. Тримайте TTFB низьким: кеш на боці сервера, адекватний хостинг, мінімум важких запитів до бази на генерацію першого екрана.
• Пріоритет головному ресурсу. LCP-зображення або шрифт заголовка варто завантажувати з високим пріоритетом (preload), а не в загальній черзі.
• Жодного лінивого завантаження для першого екрана. Класична помилка — повісити lazy-load на банер у самому верху. Ліниве завантаження лишаємо тому, що нижче згину.
• Легкий і правильно стиснутий LCP-елемент. Величезний PNG-герой на 2 МБ уб'є метрику навіть на швидкому сервері.

Окремо про render-blocking. Якщо перед показом першого екрана браузер змушений завантажити й виконати важкий CSS і JavaScript, LCP відкладається рівно на цей час. Тому критичний CSS виносять інлайном, а другорядні скрипти — вниз і у відкладене завантаження.

INP і CLS: чуйність і стабільність

Якщо LCP — про «побачив», то INP і CLS — про відчуття якості після завантаження. Їх часто недооцінюють, і дарма: саме вони формують відчуття, що сайт зроблено охайно.

Як покращити INP

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

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

Як прибрати зсуви верстки (CLS)

CLS лікується дисципліною верстки. Головні правила:

1. Завжди задавайте ширину й висоту (або aspect-ratio) зображенням і відео, щоб під них заздалегідь резервувалося місце.
2. Бронюйте місце під банери, віджети та рекламні блоки, а не дозволяйте їм розсовувати вміст під час появи.
3. Підключайте шрифти так, щоб підміна системного на кастомний не рухала текст (коректний font-display і запасні метрики).
4. Не вставляйте вміст над тим, що користувач уже бачить, — лише під ним.

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

Головні причини повільного сайту

Гарна новина: причин у повільних сайтів небагато, і вони на диво типові. У 9 випадках з 10 винен хтось із цього списку.

Важкі зображення

Абсолютний чемпіон за вагою сторінки. Фотографії у вихідній роздільній здатності, скриншоти в PNG на кілька мегабайтів, зображення, які в браузері стискаються до маленького розміру, але завантажуються цілком. Часто саме зображення виявляється LCP-елементом, тож подвійний удар.

Шрифти

Кілька накреслень у важких форматах, завантаження із зовнішнього домену, відсутність preload — і текст або блимає, або з'являється із затримкою, попутно рухаючи верстку.

Блокувальні CSS і JavaScript

Гігантські бандли, які треба завантажити й виконати до першого відмальовування. Особливо шкідливі важкі фреймворки там, де вистачило б пари рядків коду.

Сторонні скрипти

Чати, пікселі, десяток лічильників аналітики, віджети соцмереж, A/B-тести. Кожен окремо «легкий», але разом вони з'їдають головний потік і псують INP. Це найбільш недооцінена категорія.

Повільний хостинг і високий TTFB

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

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

Оптимізація зображень: формати та ліниве завантаження

Раз зображення — чемпіон за вагою, починати оптимізацію швидкості майже завжди варто з них. Тут найшвидший і найпомітніший виграш за мінімуму ризиків.

Сучасні формати

Переходьте на WebP, а де можливо — на AVIF. За зіставної якості вони важать помітно менше за класичні JPEG і PNG. Для іконок і простої графіки використовуйте SVG: він векторний, невагомий та ідеально чіткий на будь-якому екрані.

Правильний розмір і адаптивність

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

Ліниве завантаження — але з розумом

• Ставте loading="lazy" на зображення нижче першого екрана, щоб вони не заважали стартовому відмальовуванню.
• А от LCP-зображення першого екрана вантажте одразу і з пріоритетом — ліниве завантаження тут лише нашкодить.
• Завжди вказуйте розміри, щоб лінива підгрузка не спричиняла зсувів верстки (той самий CLS).

І не забувайте про стиснення. Проганяння через нормальний оптимізатор часто зрізає 40–70% ваги без видимої втрати якості. Для контентних сайтів це буквально безкоштовні секунди.

Шрифти, критичний CSS і зайвий JavaScript

Після зображень друга за значущістю зона — код, який браузер має обробити до показу сторінки. Тут ховається більша частина render-blocking проблем.

Шрифти

• Залиште мінімум накреслень — часто вистачає двох.
• Використовуйте woff2 і підвантажуйте шрифти зі свого домену.
• Робіть preload ключового шрифту першого екрана.
• Ставте font-display: swap, щоб текст був читабельним одразу, а не чекав завантаження шрифту.

Критичний CSS

Ідея проста: стилі, потрібні для першого екрана, вбудовуються інлайном прямо в HTML, а весь інший CSS вантажиться відкладено. Так браузер малює верх сторінки, не чекаючи всієї таблиці стилів. Плюс приберіть з проєкту мертві правила — за роки життя сайту їх накопичується дуже багато.

Менше JavaScript

Найчесніша оптимізація — не вантажити те, без чого можна обійтися. Перевірте, чи не тягнете ви важкий фреймворк заради пари ефектів. Відкладіть другорядні скрипти через defer і async, розбийте бандл на частини та підвантажуйте код за потреби. Окремо проведіть ревізію сторонніх віджетів: кожен чат, піксель і лічильник має виправдовувати своє місце в бюджеті продуктивності. Про те, як це поєднується з багатомовністю та не роздуває сторінку, ми писали в матеріалі про багатомовний сайт і SEO.

Кешування, CDN, HTTP/2 і хостинг

Фронтенд-оптимізація впирається у стелю, якщо фундамент — сервер і доставка — працює повільно. Ці речі дають приріст одразу на всіх сторінках.

Кешування

Працює на двох рівнях. Серверний кеш позбавляє від повторної важкої генерації сторінки і напряму знижує TTFB. Браузерний кеш (правильні заголовки Cache-Control для статики) означає, що під час повторних візитів зображення, шрифти та скрипти не завантажуються заново.

CDN

Мережа доставки контенту роздає статику із сервера, найближчого до користувача географічно. Що далі ваша аудиторія від вихідного сервера, то сильніший ефект: латентність падає, перший байт приходить швидше.

HTTP/2, HTTP/3 і стиснення

• Увімкніть сучасний протокол (HTTP/2 або HTTP/3) — він ефективніше вантажить десятки дрібних файлів паралельно.
• Увімкніть стиснення текстових ресурсів (Brotli або gzip) на сервері.
• Мініфікуйте HTML, CSS і JS, прибираючи пробіли й коментарі.

Хостинг і TTFB

Адекватний сервер — це не розкіш, а база. На навантаженому проєкті біржі фрилансу 24freelance ми впиралися саме в серверний шар: без кешу та оптимізації запитів перший байт повз, і жодна робота із зображеннями не давала цільових цифр, доки ми не привели до ладу бекенд.

Швидкість на мобільних пристроях

Важлива правда 2026 року: Google оцінює ваш сайт насамперед за мобільною версією, і більша частина трафіку приходить з телефонів. А телефон — це слабший процесор, менш стабільна мережа і менше терпіння в користувача.

Чому мобільні жорсткіші

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

Що робити

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

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

Моніторинг і регулярний контроль

Швидкість — це не разовий проєкт, а гігієна. Сайт живе: додається контент, приходять нові віджети й банери, оновлюється код — і продуктивність непомітно деградує. Без моніторингу ви дізнаєтеся про проблему від падіння продажів, а не зі звіту.

Як тримати руку на пульсі

• Регулярно перевіряйте польові Core Web Vitals у Google Search Console — там видно реальний тренд по вашій аудиторії.
• Налаштуйте автоматичні перевірки ключових шаблонів, щоб ловити регресії одразу після релізу, а не за місяць.
• Встановіть бюджет продуктивності — граничну вагу сторінки та кількість скриптів, які команда не має права перевищувати.
• Кожен новий сторонній скрипт проходьте як окреме рішення: що він дає бізнесу і скільки коштує за швидкістю.

Хто стежить

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

Головна думка: вимірюйте до і після кожної великої зміни. Цифра «стало швидше» має бути доведеною, а не відчутою.

Практичний чек-лист пришвидшення сайту

Зберемо все в один прикладний список. Ідіть по ньому згори донизу — пункти приблизно відсортовані за співвідношенням «ефект до зусиль». Не обов'язково робити все одразу, але пройтися по кожному пункту варто.

Замір і пріоритети

1. Виміряйте ключові шаблони в PageSpeed Insights (мобільні та десктоп) і запишіть поточні Core Web Vitals.
2. Знайдіть LCP-елемент кожного важливого шаблону і його головне гальмо.

Зображення

1. Переведіть зображення у WebP або AVIF, іконки — у SVG.
2. Віддавайте адаптивні розміри через srcset, не більші за контейнер.
3. Увімкніть ліниве завантаження нижче першого екрана; LCP-зображення вантажте з пріоритетом.
4. Пропишіть розміри зображень, щоб не було зсувів верстки.

Код і шрифти

1. Винесіть критичний CSS інлайном, решту вантажте відкладено.
2. Скоротіть накреслення шрифтів, додайте preload і font-display: swap.
3. Відкладіть скрипти через defer/async, приберіть невикористовуваний CSS і JS.
4. Проведіть ревізію сторонніх віджетів і видаліть зайве.

Сервер і доставка

1. Увімкніть серверний кеш і знизьте TTFB.
2. Налаштуйте браузерне кешування статики та стиснення Brotli/gzip.
3. Підключіть CDN і сучасний протокол HTTP/2 або HTTP/3.
4. Мініфікуйте HTML, CSS і JS.

Контроль

1. Перевірте результат на емуляції слабкого мобільного пристрою.
2. Налаштуйте моніторинг польових метрик і бюджет продуктивності.
3. Переміряйте до і після — зафіксуйте виграш у цифрах.

Пройдете цей чек-лист чесно — і отримаєте не просто гарний бал, а швидший, стабільніший і прибутковіший сайт. А це, зрештою, і є мета.

Часті запитання