Метрики оцінки продуктивності

JavaScriptJunior~4 хв читання

Продуктивність оцінюють не одним числом, а набором метрик, які покривають чотири рівні: завантаження сторінки в браузері, виконання JavaScript, роботу сервера та суб'єктивне відчуття швидкості. На співбесіді очікують, що ви назвете Core Web Vitals і поясните, чим вимірюється кожен рівень.

Теорія

TL;DR

Браузер: FCP, LCP, INP, CLS, TTFB, TBT. Три з них, LCP, INP і CLS, утворюють Core Web Vitals.
JavaScript: execution time, memory usage, паузи garbage collector, затримка event loop, FPS, час style, layout і paint.
Бекенд: latency, throughput (RPS), error rate, CPU, пам'ять, event loop delay, час запитів до бази, cache hit ratio.
UX: TTI, user timing marks, perceived performance.
Інтегральні індекси: Speed Index, Lighthouse Performance Score, Core Web Vitals Score.
Збирають усе це через Lighthouse, PageSpeed Insights, Performance API, web-vitals SDK, Chrome DevTools, Prometheus і Grafana.

Швидкий приклад

javascript

// Власні позначки часу через User Timing API
performance.mark('render-start');
renderList(items);
performance.mark('render-end');
performance.measure('render', 'render-start', 'render-end');

const [entry] = performance.getEntriesByName('render');
console.log(`render: ${entry.duration.toFixed(1)} ms`);

// Навігаційні метрики сторінки, зокрема TTFB
const [nav] = performance.getEntriesByType('navigation');
console.log('TTFB:', nav.responseStart - nav.requestStart, 'ms');

Метрики продуктивності фронтенду

Ці метрики оцінюють, наскільки швидко і плавно сторінка завантажується та реагує:

Метрика	Що вимірює	Хороше значення
FCP (First Contentful Paint)	Час до першого відмальованого контенту (текст, зображення)	< 1,8 с
LCP (Largest Contentful Paint)	Час до показу найбільшого елемента контенту (наприклад, банера, зображення)	< 2,5 с
FID (First Input Delay)	Затримка між першою дією користувача (клік, скрол) і реакцією сторінки	< 100 мс
INP (Interaction to Next Paint)	Наскільки швидко інтерфейс реагує на дії користувача (нова метрика, замінює FID)	< 200 мс
CLS (Cumulative Layout Shift)	Наскільки сильно зміщується контент під час завантаження	< 0,1
TTFB (Time To First Byte)	Час до отримання першого байта відповіді від сервера	< 0,6 с
TBT (Total Blocking Time)	Загальний час, коли основний потік (main thread) заблокований і не може реагувати	< 200 мс

Ці метрики збирають через:

Lighthouse, PageSpeed Insights;
Performance API (performance.getEntriesByType('navigation'));
Web Vitals SDK.

Метрики продуктивності JavaScript

Для оцінки швидкості виконання JS-коду та його ефективності:

Метрика	Що оцінює
Execution time	Час виконання ділянки коду (наприклад, через `console.time()` або `performance.now()`)
Memory usage	Споживання пам'яті (`performance.memory.usedJSHeapSize`)
Garbage collection time	Частота і тривалість пауз GC
Event loop lag / latency	Наскільки сильно блокується головний потік
FPS (Frames per second)	Частота оновлення інтерфейсу (має бути 60 FPS)
Recalculate Style / Layout / Paint time	Час, витрачений на відмальовування та перебудову DOM
Script parse/compile time	Час парсингу та компіляції JS-файлів

Інструменти:

Chrome DevTools, вкладка Performance;
React Profiler, Vue DevTools;
Lighthouse, розділ «Diagnostics».

Метрики продуктивності бекенду

Якщо йдеться про Node.js, NestJS, Express чи будь-який API-сервіс:

Метрика	Що показує
Response Time / Latency	Середній час відповіді сервера
Throughput (RPS)	Кількість запитів на секунду
Error rate	Частка неуспішних запитів (4xx/5xx)
CPU usage	Завантаженість процесора
Memory usage (RSS, heap)	Використання пам'яті
Event loop delay	Наскільки блокується event loop
DB query time	Середній час виконання SQL-запитів
Cache hit ratio	Ефективність кешування

Для вимірювання використовують:

Prometheus та Grafana;
New Relic, Datadog, Sentry Performance;
вбудований у Node.js performance API (perf_hooks).

Метрики користувацького досвіду та інтегральні індекси

Метрики UX показують не окремі мілісекунди, а те, наскільки комфортно працювати зі сторінкою:

Метрика	Що відображає
TTI (Time To Interactive)	Коли сторінка стає повністю інтерактивною
TBT + INP	Наскільки комфортно взаємодіяти
User timing marks	Власні точки через `performance.mark()` і `performance.measure()`
Perceived performance	Суб'єктивне відчуття швидкості через skeletons, lazy load, prefetch

Зверху над усім цим стоять складені індекси:

Метрика	Складена характеристика
Speed Index	Наскільки швидко весь контент візуально завантажується
Performance Score (Lighthouse)	Комплексна оцінка від 0 до 100
Core Web Vitals Score	Метрика Google для SEO та UX

Стисле резюме:

Для браузера, це FCP, LCP, INP, CLS, TBT. Для JS-коду, це execution time, memory, FPS, GC. Для сервера, це latency, RPS, CPU, DB time. Для UX, це TTI, Speed Index, user timings.

Типові помилки

Називати лише Lighthouse Score. Це похідне число; інтерв'юер чекає конкретні метрики, з яких воно складається.
Згадувати FID як актуальну метрику. З 2024 року INP замінив FID у складі Core Web Vitals, FID лишився історичним.
Орієнтуватися тільки на лабораторні дані. Lighthouse на потужному ноутбуці показує одне, реальні користувачі (RUM, field data) інше; потрібні обидва джерела.
Міряти середнє замість персентилів. Latency та INP оцінюють за p75 або p95, бо середнє ховає хвіст повільних сесій.
Плутати TTFB із часом завантаження. TTFB, це лише перший байт відповіді; сторінка може бути порожньою ще секунди після нього.
Довіряти performance.memory. Це нестандартна властивість, доступна переважно в Chromium і з огрубленими значеннями.
Оптимізувати без вимірювання. Спочатку профіль у DevTools, потім зміни, інакше час іде на ділянки, які нічого не вирішують.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.