Тестування продуктивності фронтенду у 2026 році: Core Web Vitals, інструменти й чек-лист

Сайт може витримувати тисячу запитів на секунду й при цьому здаватися користувачу повільним. Головне зображення з'являється через п'ять секунд, кнопка «Купити» відгукується з помітною затримкою, а текст стрибає вниз, щойно над ним довантажився банер. Навантажувальне тестування такого не помітить, бо проблема не на сервері, а в браузері. Тут допомагає тестування продуктивності фронтенду.

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

Короткий вибір

Метрики: що саме вимірювати

Core Web Vitals

Google виділяє три ключові метрики. Сторінка вважається «хорошою», якщо 75 % відвідувань укладаються в поріг, окремо на мобільних і на десктопі.

INP замінив стару метрику FID 12 березня 2024 року. FID вимірював лише затримку першої взаємодії, а INP враховує всі взаємодії й увесь час до наступного кадру. Тому багато сайтів, які «проходили» за FID, за INP виявилися повільними.

Допоміжні метрики теж корисні для діагностики: TTFB (час до першого байта відповіді, добре до 0,8 с), FCP (перший відмальований вміст, добре до 1,8 с) і TBT (сумарний час блокування головного потоку в лабораторному тесті).

Лабораторні й польові дані

Це найважливіше розрізнення в тестуванні продуктивності.

• Лабораторні дані (lab, synthetic) — це прогін сторінки в контрольованих умовах: Lighthouse, WebPageTest, DevTools. Вони відтворювані, тому зручні для пошуку причин і порівняння «до й після». Але це одна сторінка, один пристрій і одна мережа, без реальних взаємодій. Тому INP лабораторія виміряти не може, замість нього дивляться на TBT.
• Польові дані (field, RUM) зібрані з реальних відвідувачів: Chrome UX Report (CrUX) або власний скрипт на кшталт web-vitals. Саме за ними Google оцінює Core Web Vitals, і саме вони показують, як сайт працює на старих телефонах, у метро й за межами міста.

Типова ситуація: Lighthouse на ноутбуці розробника показує 98 балів, а польовий LCP на мобільних — 4 секунди. Вірте польовим даним, а лабораторію використовуйте, щоб знайти й виправити причину.

Що змінилося у 2025–2026 роках

• Lighthouse 13 (жовтень 2025) прибрав старі аудити продуктивності й перейшов на «інсайти» — ті самі, що показує панель Performance у Chrome DevTools. Деякі звичні назви аудитів зникли, тож якщо ваш CI розбирає JSON-звіт Lighthouse, перевірте його після оновлення. Lighthouse 13 потребує Node.js 22.19 або новішого.
• LCP і INP тепер є не лише в Chrome. В межах Interop 2025 Firefox додав підтримку INP у версії 144 (жовтень 2025), а Safari 26.2 (грудень 2025) — LCP і INP. Тепер можна збирати ці метрики у своєму RUM і для користувачів iPhone. CLS поки працює лише в браузерах на Chromium, а CrUX, як і раніше, містить дані тільки з Chrome.
• CrUX Vis замінив CrUX Dashboard. Старий дашборд на Looker Studio Google закрив наприкінці 2025 року. Історію Core Web Vitals сайту тепер дивляться в CrUX Vis або через CrUX History API.
• DevTools показує живі метрики. Панель Performance одразу після відкриття показує локальні LCP, CLS і INP під час вашої роботи зі сторінкою й порівнює їх із польовими даними CrUX. Уповільнення процесора можна відкалібрувати під слабкий телефон.
• Long Animation Frames (LoAF). Цей API в Chrome показує, які саме скрипти зробили кадр довгим. Він набагато точніший за старі Long Tasks, і саме на ньому працює атрибуція INP у RUM-сервісах.
• Soft navigations. Для односторінкових застосунків (SPA) Chrome тестує API, що вимірює метрики при переходах без перезавантаження сторінки. Поки це експеримент, але за ним варто стежити, якщо у вас React, Vue чи Angular.

Покрокова перевірка сторінки

Ось процес, з якого варто починати, якщо вам доручили «перевірити швидкість».

1. Подивіться польові дані. Відкрийте сторінку в PageSpeed Insights. Якщо трафіку достатньо, угорі будуть реальні LCP, INP і CLS за 28 днів. Для домену в цілому й історії — Treo або CrUX Vis. Так ви знаєте, яка метрика справді проблемна і на яких пристроях.

2. Відтворіть у лабораторії. У Chrome DevTools увімкніть режим мобільного пристрою, уповільнення мережі (наприклад, «Slow 4G») і процесора (4–6× або відкалібрований пресет). Перевіряйте у вікні інкогніто без розширень.

3. Запишіть профіль у Performance. Перезавантажте сторінку із записом, а для INP натискайте реальні кнопки, відкривайте меню, вводьте текст у поля. Бокова панель Insights підкаже, що є LCP-елементом, які скрипти блокують потік, звідки зсуви.

4. Подивіться водоспад. У WebPageTest запустіть тест з потрібної локації на мобільному профілі. Водоспад і фільмстрип покажуть, коли саме почав вантажитися LCP-ресурс, які запити блокують рендеринг і скільки важать сторонні скрипти.

5. Перевірте повторне відвідування. Як сторінка працює з кешем? Чи повертається вона миттєво з кешу «назад/вперед» (bfcache)? У DevTools є окрема перевірка на вкладці Application.

6. Зафіксуйте результат. Мінімум три прогони, медіана, умови тестування, скриншоти. Так результат можна буде порівняти після виправлень.

Що перевіряти за кожною метрикою

LCP: головний вміст з'являється пізно

LCP складається з чотирьох частин: TTFB, затримка до початку завантаження ресурсу, час завантаження й затримка рендерингу. DevTools і DebugBear показують цю розбивку. Типові причини:

• повільна відповідь сервера (високий TTFB) — кешування, CDN, важкі запити до бази;
• головне зображення знаходиться пізно: воно в CSS-фоні, вставляється JavaScript-ом або має loading="lazy"; для LCP-зображення ледаче завантаження шкодить;
• немає підказок пріоритету: fetchpriority="high" на головному зображенні або <link rel="preload"> для критичних ресурсів;
• зображення завеликі або в старому форматі — перевірте в Squoosh, наскільки менше важитиме AVIF чи WebP; додайте srcset для різних екранів;
• блокувальні CSS і JavaScript у <head>, вебшрифти без font-display;
• рендеринг лише на клієнті: поки не завантажиться й не виконається весь JavaScript, на сторінці порожньо.

INP: сторінка повільно відгукується

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

• довгі задачі (понад 50 мс) у профілі: аналітика, чати, A/B-тести, рекламні скрипти, гідратація фреймворку;
• важкі обробники подій — сортування великого списку чи перерахунок усього стану на кожне натискання клавіші;
• зайві повторні рендери в React чи Vue — їх видно в React Developer Tools і Vue DevTools з підсвіткою рендерів;
• великий DOM: тисячі вузлів роблять кожне оновлення стилів і розкладки дорогим;
• відсутність візуального відгуку: навіть якщо операція довга, інтерфейс має одразу показати індикатор.

Тестуйте INP на реальних сценаріях: відкрити меню, додати товар у кошик, ввести текст у пошук, перемкнути фільтр. Найгірші значення зазвичай на слабких Android-телефонах, тому тест на справжньому недорогому смартфоні дасть більше, ніж будь-яка емуляція.

CLS: вміст стрибає

• зображення, відео й iframe без width і height або aspect-ratio;
• банери, згода на cookie, реклама чи вбудовані віджети, що вставляються над наявним вмістом;
• вебшрифти, що після завантаження змінюють розмір тексту;
• анімації через top і height замість transform.

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

JavaScript-бандли: вага має значення

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

• Bundlephobia — перед тим, як додати бібліотеку, подивіться, скільки вона важить, чи підтримує tree shaking і чи є легші альтернативи.
• webpack-bundle-analyzer і Statoscope — карта того, що потрапило в бандл. Типові знахідки: дві версії однієї бібліотеки, вся бібліотека дат замість однієї функції, адмінський код у публічному бандлі.
• Size Limit — бюджет розміру, що валить CI, якщо pull request робить бандл важчим за ліміт.
• Панель Coverage у Chrome DevTools показує, яка частина завантаженого JS і CSS не виконалася на сторінці, — кандидати на розбиття коду й ледаче завантаження.
• Yellow Lab Tools оцінює фронтенд загалом: складність DOM, дублікати CSS, проблемні конструкції JavaScript.

Окремо перевірте сторонні скрипти: аналітику, чати підтримки, пікселі реклами, віджети відгуків. Вони часто важать більше, ніж власний код сайту. Заблокуйте їх у DevTools (Network → Block request URL) і порівняйте метрики — так ви побачите їхню реальну ціну.

Продуктивність в автотестах і CI

Ручна перевірка знаходить проблеми, а CI не дає їм повернутися.

• Lighthouse CI проганяє Lighthouse кілька разів на кожну збірку й перевіряє правила: «LCP не гірше 2,5 с», «TBT не більше 200 мс», «JavaScript не більше 300 КБ». Через розкид результатів ставте пороги з запасом і використовуйте медіану кількох прогонів.
• Unlighthouse проходить Lighthouse по всіх сторінках сайту — зручно перед великим релізом чи міграцією.
• sitespeed.io — відкритий набір для регулярних синтетичних тестів із графіками в Grafana.
• Playwright і Puppeteer можуть зібрати трасу продуктивності чи Web Vitals прямо в наскрізному тесті ключового сценарію, наприклад оформлення замовлення.
• Size Limit контролює вагу JavaScript у кожному pull request.

Пам'ятайте про шум: на спільних CI-машинах результати можуть коливатися на 10–20 %. Краще стабільні бюджети на розмір і кількість ресурсів плюс м'які пороги для таймінгів, ніж тест, що «червоніє» щодня без причини.

Моніторинг реальних користувачів (RUM)

Лабораторія не покаже, що користувачі з Android у Харкові бачать LCP 5 секунд, а на iPhone в Києві все гаразд. Для цього потрібен RUM — збір метрик із браузерів реальних відвідувачів.

• Безкоштовний старт: бібліотека web-vitals зі збіркою attribution надсилає LCP, INP і CLS разом із причинами у вашу аналітику чи на власний бекенд.
• Готові сервіси: DebugBear, RUMvision, Request Metrics, SpeedCurve показують розбивку за сторінками, пристроями й країнами та атрибуцію INP до конкретних скриптів.
• Якщо вже є APM: Sentry, Datadog і New Relic мають модулі моніторингу фронтенду, і зручно бачити фронтенд і бекенд в одному місці.
• Хмарний хостинг: Vercel має вбудований модуль Speed Insights для сайтів, що на ньому розміщені.

Тестувальнику RUM корисний як джерело пріоритетів: ви бачите, які сторінки й сценарії найповільніші у реальності, і тестуєте насамперед їх.

Як звітувати про проблеми продуктивності

Баг-репорт «сайт повільний» нічого не дає розробнику. Хороший звіт містить:

• сторінку й сценарій: URL, дії (наприклад, «натиснути "Фільтри" на мобільному»);
• метрику й значення: «INP 640 мс при відкритті фільтрів», «LCP 4,2 с на мобільному профілі»;
• умови: пристрій або емуляція, уповільнення CPU й мережі, браузер і версія, кеш холодний чи теплий;
• кількість прогонів і медіану, щоб відрізнити проблему від шуму;
• докази: файл профілю з DevTools (його можна зберегти й прикріпити), посилання на тест WebPageTest, скриншот водоспаду;
• причину, якщо її видно: «LCP-зображення має loading="lazy"», «довга задача 380 мс у скрипті чату»;
• польові дані, якщо вони є: «у CrUX 75-й перцентиль INP на мобільних — 450 мс».

План навчання на місяць

Для практики підійде будь-який власний сайт чи навчальний проєкт. Корисно також брати в роботу реальні сайти зі звичної вам галузі й порівнювати їх у CrUX.

АІ в тестуванні продуктивності

АІ-асистенти добре пояснюють профілі й водоспади, якщо дати їм контекст: опишіть або вставте фрагмент трасування, звіт Lighthouse у JSON чи список довгих задач, і попросіть знайти найімовірніші причини. Chrome DevTools має вбудовану АІ-допомогу, яка відповідає на запитання про записаний профіль продуктивності.

Але перевіряйте поради: АІ може запропонувати загальні «оптимізації», які нічого не дадуть на вашій сторінці, або не врахувати, що LCP-зображення взагалі вставляє скрипт. Будь-яку гіпотезу підтверджуйте вимірюванням до й після. Добірки АІ-інструментів для розробників ви знайдете в підкатегорії Веб-розробка.

Про інші види тестування читайте в статтях «Навантажувальне тестування», «Тестування мобільних застосунків», «Тестування доступності» та «Інструменти для мануального тестування». Усі інструменти з цієї статті є в підкатегоріях Тестування і Веб-розробка.

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

Чим тестування продуктивності фронтенду відрізняється від навантажувального?

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

Чи треба добиватися 100 балів у Lighthouse?

Ні. Оцінка Lighthouse — це лабораторний орієнтир. Важливіше, щоб польові Core Web Vitals були в зеленій зоні для 75 % користувачів.

Чому PageSpeed Insights показує різні результати при кожному запуску?

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

Чому немає польових даних для моєї сторінки?

CrUX показує лише сторінки й сайти з достатньою кількістю відвідувань у Chrome. Для нових чи нішевих сайтів збирайте власний RUM через web-vitals.

Як виміряти INP, якщо в Lighthouse його немає?

У лабораторії записуйте взаємодії в панелі Performance у DevTools (вона показує INP наживо) і дивіться на TBT як на непрямий показник. Справжній INP дадуть лише польові дані.

Не знаєте, з чого почати?

Запитайте Елю: вона підбере інструменти для тестування швидкості під ваш проєкт і рівень.

Дата перевірки фактів: 4 листопада 2026 року. Умови сервісів і можливості браузерів можуть змінюватися, тож перевіряйте їх на офіційних сайтах.