Perceived Performance: чому швидкий Frontend здається повільним

Бекенд відповідає за 200 мс. Lighthouse показує зелені цифри. DevTools не бачить жодних вузьких місць. А користувач все одно пише в підтримку: «сайт гальмує». Знайома ситуація? Це не баг у метриках — це розрив між об'єктивною швидкістю і сприйнятою. І саме другу користувач відчуває шкірою, а не в консолі розробника.

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

ЩО ТАКЕ PERCEIVED PERFORMANCE І ЧИМ ВОНА ВІДРІЗНЯЄТЬСЯ ВІД РЕАЛЬНОЇ

Різниця в тому, що людина не вимірює мілісекунди — вона оцінює досвід очікування. А цей досвід залежить не тільки від тривалості, а й від:

📌 наявності зворотного зв'язку — чи система показала, що взагалі щось відбувається, одразу після дії;

📌 передбачуваності — чи знає користувач, скільки ще чекати, чи це невідомість без кінця;

📌 зайнятості уваги — чи є що розглядати, поки триває завантаження, чи екран просто порожній;

📌 емоційного контексту дії — очікування після натискання «Оплатити» відчувається довшим, ніж таке саме очікування при гортанні стрічки.

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

ЧОМУ МОЗОК ОБДУРЮЄ НАС ЩОДО ЧАСУ

Сприйняття часу очікування — не лінійна функція. Кілька психологічних ефектів, які інженери фронтенду ігнорують на власний ризик:

• Порожній екран відчувається довшим, ніж екран з активністю. Дослідження в галузі UX (ще з часів експериментів у чергах авіакомпаній і ліфтів) показують: люди, яким нема на що дивитися під час очікування, суб'єктивно оцінюють паузу довшою на 30–50%, навіть якщо реальний час однаковий.
• Невизначеність гірша за очікуваний дискомфорт. Прогрес-бар, який рухається нерівномірно чи «застигає», дратує сильніше за повільний, але стабільний прогрес.
• Перша реакція системи важливіша за фінальний результат. Якщо додаток відреагував на клік за 100 мс (навіть просто підсвіткою кнопки), а сам результат прийшов через 3 секунди — сприйняття набагато краще, ніж тиша впродовж усіх трьох секунд.
• Ефект «раптового стрибка». Якщо контент з'являється миттєво і різко (макет «стрибає», текст зміщується), мозок реєструє це як хаос і оцінює сторінку як «глючну», навіть якщо формально вона завантажилася швидко.

Саме тому Core Web Vitals від Google — не випадковий набір метрик, а спроба формалізувати ці психологічні спостереження в цифри: LCP (наскільки швидко з'являється основний контент), INP (наскільки швидко система реагує на дію), CLS (наскільки стабільний макет під час завантаження).

ЯК ЗМУСИТИ ПОВІЛЬНИЙ FRONTEND ЗДАВАТИСЯ ШВИДКИМ

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

SKELETON SCREENS ЗАМІСТЬ СПІНЕРІВ

Замість крутилки на порожньому екрані — сірі плейсхолдери, що повторюють структуру майбутнього контенту (картки, лінії тексту, аватарки). LinkedIn, Facebook і YouTube масово перейшли на skeleton screens саме тому, що вони скорочують суб'єктивний час очікування: мозок сприймає структуру як «контент уже майже тут», а не «нічого не відбувається».

ОПТИМІСТИЧНІ UI-ОНОВЛЕННЯ (OPTIMISTIC UI)

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

ПРОГРЕСИВНЕ ЗАВАНТАЖЕННЯ КОНТЕНТУ

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

МИТТЄВА РЕАКЦІЯ НА ВВЕДЕННЯ

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

УПРАВЛІННЯ ОЧІКУВАННЯМ ЧЕРЕЗ ПРОГРЕС-БАРИ

Прогрес-бар, що трохи «підбріхує» на старті (швидко долітає до 80%, а потім сповільнюється до реального завершення), сприймається користувачем краще за технічно точний, але нерівномірний індикатор. Це прийом, яким свідомо користуються продукти на кшталт застосунків для сканування документів чи файлових менеджерів.

КОЛИ ІДЕАЛЬНО ОПТИМІЗОВАНИЙ FRONTEND ВСЕ ОДНО ЗДАЄТЬСЯ ПОВІЛЬНИМ

Буває і зворотна ситуація: команда вклала місяці в оптимізацію бандлів, lazy loading, кешування — а скарги на «гальмування» не зникають. Типові причини:

📌 Layout shift. Контент технічно завантажився швидко, але елементи сторінки «стрибають» під час довантаження реклами чи зображень без заданих розмірів — і користувач фізично не може клікнути туди, куди цілився.

📌 Порожній стан без пояснення. Дані вже прийшли за 300 мс, але поки рендериться складний компонент — екран білий. Користувач бачить паузу там, де насправді все ок.

📌 Довга затримка реакції на клік (поганий INP). Сторінка завантажилась швидко, але JS-потік заблокований важкими обчисленнями, і кнопка «не натискається» протягом секунди-двох після кліку — це відчувається як зависання, навіть якщо початкове завантаження було блискавичним.

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

ЯК ВИМІРЮВАТИ ТЕ, ЩО НЕ ЛИЖИТЬ У DEVTOOLS

Класичні метрики (Time to First Byte, повний Load) недостатньо описують досвід. Варто додатково відстежувати:

• First Contentful Paint (FCP) — коли користувач вперше бачить хоч щось на екрані.
• Largest Contentful Paint (LCP) — коли з'являється основний, «змістовний» блок сторінки.
• Interaction to Next Paint (INP) — наскільки швидко інтерфейс реагує на реальні дії користувача, а не тільки на завантаження.
• Cumulative Layout Shift (CLS) — наскільки стабільна верстка під час завантаження.
• Якісні дані: сесії з записом взаємодій (heatmaps, session replay), опитування NPS з відкритим питанням «що здалося повільним» — цифри рідко ловлять роздратування від смикання макета.

ВИСНОВОК: ШВИДКІСТЬ — ЦЕ ВІДЧУТТЯ, А НЕ ТІЛЬКИ ЧИСЛО

Perceived Performance — не альтернатива технічній оптимізації, а її необхідне доповнення. Можна виграти мілісекунди на бекенді й програти секунди сприйняття через порожній екран чи макет, що стрибає. І навпаки — правильно розставлені skeleton screens, оптимістичні оновлення й миттєва реакція на клік здатні зробити середньостатистичний за швидкістю додаток таким, що відчувається блискавичним.