Що ми називаємо швидкістю сайту

Оцінка PageSpeed — зручний знімок, але це не вся швидкість. У лабораторії Lighthouse дивиться на фіксований сценарій: пристрій, мережа, кеш. У полі користувач приходить з іншим телефоном, іншою стільниковою мережею й іншим набором сторонніх скриптів. Тому поруч із балом завжди потрібні метрики, які описують відчуття сторінки.

TTFB — час до першого байта відповіді сервера. Високий TTFB тягне за собою все інше: навіть ідеальний фронтенд не врятує повільний API чи холодний PHP без кешу. FCP показує, коли з’явився перший осмислений піксель контенту. LCP — коли основний елемент в’юпорту став видимим; для картки товару це часто головне зображення. INP відображає затримку реакції на кліки й введення протягом візиту. CLS ловить «стрибки» верстки, через які людина промахується по кнопці «Купити».

Окремо стоїть розмір і вартість JavaScript: час розбору, гідратації та блокування головного потоку. Саме важкий клієнтський код частіше вбиває INP на мобільних, навіть коли LCP виглядає прийнятно у звіті.

Лабораторія і поле

Lighthouse і «ідеальний» прогін WebPageTest відповідають на питання: «чи ламаємо ми критичний шлях у контрольованих умовах?» Chrome UX Report і власний RUM відповідають на інше: «що реально отримують користувачі?» Різниця між Wi‑Fi на ноутбуці й 3G на бюджетному Android може перетворити «зелений» лабораторний LCP на «червоний» польовий. Якщо ви оптимізуєте лише під ноутбук розробника, ви оптимізуєте демо, а не продажі.

Чому середнє бреше

Уявіть: у 90% сесій LCP менший за 2,5 с, у 10% — понад 6 с. Середнє може виглядати «майже добре». Але саме повільний дециль часто — мобільні візити з реклами, регіони зі слабкою мережею, сторінки з важкими рекомендаціями. Ці 10% можуть нести непропорційну частку вартості кліка. Дивіться перцентилі (75-й і 90-й) і сегменти, а не лише середнє по сайту.

Що відбувається з користувачем, коли сайт повільний

Людина натискає «Купити» або переходить із пошуку на картку. Замість товару вона бачить порожній екран, спінер або кнопку, що зсунулась. Очікування саме по собі неприємне; на мобільному воно ще й конкурує зі сповіщеннями та сусідньою вкладкою конкурента.

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

Це не містика UX. Це фізика уваги: кожен зайвий крок очікування відбирає шанс дійти до наступного етапу воронки. Зв’язок швидкості з грошима починається тут, а не у звіті Lighthouse.

Що кажуть дослідження великих компаній

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

Google (Need for Mobile Speed, 2016). За агрегованими даними Google Analytics на вибірці мобільних сайтів близько 53% візитів з високою ймовірністю обриваються, якщо завантаження довше за три секунди; середнє завантаження багатьох мобільних сторінок на 3G тоді вимірювалось десятками секунд. Це кореляція по великих вибірках видавців і рекламних майданчиків, не ваш A/B-тест. Сенс для бізнесу: мобільне очікування — масова причина відмови, а не «нішева скарга перфекціоністів».

Amazon (за розповіддю Greg Linden). У контрольованих експериментах до початку 2000‑х сторінки штучно сповільнювали кроками по 100 мс і спостерігали помітне падіння виручки; у презентаціях часто фігурує порядок ~1% продажів на кожні +100 мс. Amazon не публікував формальний рецензований звіт; цитата йде з виступів і блогу інженера. Переносити «1% на 100 мс» на будь-який лендінг 2026 року як закон не можна — але ідея «мала затримка вимірювана в грошах на величезному трафіку» підтверджена культурою експериментів компанії.

Walmart (RUM, презентації ~2012–2013). За власними даними, конверсія падала зі зростанням середнього часу завантаження; у конвертуючих візитів середній час був нижчим (порядку 3,2 с проти ~6 с у неконвертуючих). У ключових слайдах: до +2% конверсії на кожну секунду покращення і до +1% інкрементальної виручки на 100 мс. Це спостереження на їхньому трафіку й їхньому визначенні часу завантаження, не універсальна еластичність.

Bing / Microsoft (експерименти зі сповільненням). У роботах про онлайн-експерименти штучне сповільнення сервера на 100 мс давало порядок ~0,6% покращення виручки при прискоренні (лінійна апроксимація на їхніх метриках). Важливо: змінювали затримку відповіді, а не «красу» інтерфейсу — це ближче до причинності, ніж простий зріз «швидкі vs повільні користувачі».

Pinterest. Перебудова сторінок під продуктивність дала порядку −40% до метрики очікування (Pinner Wait Time), +15% SEO-трафіку і +15% до конверсії в реєстрацію; ефект на залучення був мультиплікативним. Пізніше PWA для мобільного вебу скоротила час до інтерактивності з десятків секунд до одиниць і покращила залученість — знову зв’язок «прискорили критичний шлях → виросли продуктові метрики», а не лише «підняли бал».

Zalando та інші ритейлери. У галузевих зведеннях трапляється оцінка порядку +0,7% виручки при −100 мс; першоджерело часто слабше за Amazon/Walmart і потребує обережної цитати. Для AliExpress, Booking і Netflix у блогах гуляють схожі історії — перед презентацією бізнесу краще відкрити першоджерело команди, а не переказ агентства.

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

Переведення швидкості в гроші

Візьмемо спрощений інтернет-магазин: 1 000 000 відвідувачів на місяць, конверсія 2%, середній чек 2 000 ₴.

Замовлень: 1 000 000 × 0,02 = 20 000.
Виручка: 20 000 × 2 000 = 40 000 000 ₴.

Припустімо, погіршення швидкості знижує конверсію на 5% відносно поточної (не на п’ять процентних пунктів): нова конверсія 2% × 0,95 = 1,9%. Замовлень стає 19 000. Втрата — 1 000 замовлень або 2 000 000 ₴ потенційної виручки на місяць.

Це не твердження «сайт став на секунду повільнішим ⇒ −5%». Це переведення вашої гіпотези про Δ конверсії в гроші. Саме так варто розмовляти з бізнесом: «якщо швидкість з’їсть 5% конверсії при нашому трафіку й чеку, місяць коштує ось стільки».

Формула втрат і чому важливий прибуток

Базова виручка:

Revenue = Traffic × Conversion Rate × Average Order Value

Втрата виручки при зміні конверсії:

Lost Revenue = Traffic × ΔConversion × Average Order Value

де ΔConversion — абсолютна зміна частки замовлень (наприклад, з 0,020 до 0,019 → 0,001).

Прибуток:

Lost Profit = Lost Revenue × Gross Margin

Так розмова зміщується з «сайт втратив замовлення» до «повільний сайт потенційно зменшує прибуток на X ₴ на місяць». При маржі 30% втрата 2 млн виручки — це близько 600 000 прибутку. Саме цю суму порівнюють із вартістю спринту на кеш, CDN і урізання бандла.

Додатковий важіль — ціна десятих частки конверсії. При 500 000 відвідувачів і середньому чеку 1 500 ₴ кожні 0,1 п.п. конверсії (0,001 у частках) коштують 500 000 × 0,001 × 1 500 = 750 000 ₴ виручки. Менеджеру простіше думати: «покращення LCP на повільному сегменті може повернути частину цих грошей», ніж «LCP був 3,2 с».

SEO, реклама і повторні візити

Швидкість впливає не лише на миттєву конверсію. Метрики Core Web Vitals беруть участь у сигналах ранжування Google; інші пошуковики також враховують зручність сторінок, хоча точна формула закрита. Користувацькі сигнали (відмови, короткі сесії) можуть підсилювати ефект. Окремий міф: «прискорили головну — виросли всі позиції». Доведений мінімум: CWV і стабільний HTML допомагають не втрачати якість входу; решта — контент, посилання, інтент. Докладніше про шари видимості — у гайді SEO / AEO / GEO.

Реклама жорсткіша. Клік з Google Ads, інших рекламних мереж чи Meta вже оплачений. Повільна посадкова означає: гроші витрачені, а продаж не відбувся. Вартість залучення клієнта зростає не тому, що «реклама погана», а тому що воронка втрачає людей після кліка. Оптимізація LCP на лендінгу кампанії часто окупається швидше, ніж ще один креатив.

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

Воронка інтернет-магазину: швидкість на кожному кроці

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

Приклад схеми воронки (цифри демонстраційні):

Якщо повільний JS на картці ріже додавання в кошик, а важке оформлення замовлення ріже оплату, ви лагодите не «сайт», а конкретні розриви. Порівняйте дві картини:

Швидкий шлях (LCP за кроками): 2,0 → 1,8 → 1,7 → 1,9 с.
Повільний шлях: 5,5 → 6,2 → 7,1 → 8,0 с.

У другому випадку людина «платить» очікуванням на кожному кліку. Звідси правило: оптимізуйте швидкість воронки, а не лише головну для гарного скріншота Lighthouse.

Що зазвичай сповільнює сучасні сайти

Серверна частина. Повільні SQL, N+1, важкий PHP або Node без кешу, «холодний» API, неправильний CDN або його відсутність. TTFB вище секунди на ключових сторінках — червоний прапорець до суперечок про React.

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

Зображення. JPEG там, де потрібен WebP/AVIF; 3000 px ширини замість 600; немає лінивого завантаження і srcset. LCP часто = картинка товару: поки вона не оптимізована, фронтенд-мікрооптимізації дають мало.

Сторонні скрипти. Аналітика, чати, пікселі реклами, карти, віджети, A/B-платформи, рекомендації. Кожен «маленький» тег додає конкуренцію за головний потік. Без інвентаризації сторонніх скриптів ви лікуєте симптоми у своєму коді, поки чужий скрипт тримає INP.

Як виміряти вплив швидкості на своєму сайті

Крок 1. Зберіть базу: трафік, конверсія, середній чек, виручка, відмови, польові Core Web Vitals (не лише Lighthouse).

Крок 2. Розділіть сесії за швидкістю, наприклад за LCP: < 2,5 с / 2,5–4 с / > 4 с. Порівняйте конверсію і виручку на відвідувача за групами.

Крок 3. Дивіться поле: RUM, Analytics / інші лічильники, Chrome UX Report, серверні логи TTFB. Лабораторія — для налагодження регресу в CI.

Крок 4. Шукайте кореляцію обережно. Таблиця на кшталт «повільний LCP → нижча конверсія» — корисний сигнал, але кореляція ≠ причинність: повільні сесії можуть бути ботами, слабкими пристроями або важкими сторінками каталогу з іншою семантикою попиту.

Таку таблицю на своїх даних варто показати бізнесу як гіпотезу, а не як доведений закон. Доказ — експеримент.

A/B-тест швидкості і пастка однієї метрики

Сильний дизайн: варіант A — поточний сайт, варіант B — прискорений (або штучно сповільнений для оцінки еластичності). Однакові трафік, аудиторія, період, ціни й рекламні кампанії; змінюється технічна реалізація. Міряйте конверсію, частку додавань у кошик, частку тих, хто дійшов до оплати, виручку на відвідувача, середній чек, відмови — не лише LCP.

Штучне сповільнення (як у Amazon/Bing) часто чистіше для оцінки «скільки коштує 100 мс», ніж великий рефакторинг, у якому заодно змінили UX. Прискорювальний реліз зато ближчий до реальної роботи команди.

Пастка однієї метрики: LCP покращили з 4,2 до 2,1 с, а конверсія й виручка не зрушили. Технічний успіх є, бізнес-ефект не доведений — можливо, вузьке місце було в доставці, ціні чи формі оплати. Зворотний випадок: LCP майже не змінився, але сценарій «додати в кошик» став відчутно швидшим завдяки INP — і замовлення виросли. Дивіться зв’язку метрик шляху, а не один зелений кружок у звіті.

Демонстраційний (не польовий) приклад для розмови із замовником:

При 200 000 візитах і чеку 1 200 ₴ приріст конверсії на 0,25 п.п. — це 200 000 × 0,0025 × 1 200 = 600 000 ₴ виручки. Позначте в презентації: які рядки з RUM, які — ілюстрація.

Економіка оптимізації і бюджет продуктивності

Нехай оптимізація коштує 120 000 ₴, а після неї стабільно з’являється +120 000 ₴ додаткового прибутку на місяць. Термін окупності:

Payback = Investment / Monthly Incremental Profit = 1 місяць

Окупність за перший місяць:

ROI = (Incremental Profit − Investment) / Investment

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

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

Мета «PageSpeed 100» погана сама по собі: сто балів не гарантують продажі, хороший UX і збіг із полем. Правильна мета — мінімізувати час до потрібної дії користувача на всьому шляху покупки.

Пріоритет робіт зазвичай такий: сервер і TTFB → критичний шлях відмалювання (HTML/CSS/шрифти) → зображення LCP → JavaScript → сторонні скрипти → CDN і кеш на краю. Зв’язок UX і грошей у переговорах із замовником також розібрано в огляді окупності UX.

Чекліст для власника сайту

• Вимірюється польовий LCP (не лише Lighthouse)
• Вимірюються INP і CLS
• Вимірюється TTFB на ключових URL
• Є RUM або принаймні CrUX + аналітика
• Відомі конверсія, середній чек і маржа
• Конверсія дивиться в сегментах за швидкістю
• Для спірних релізів планується A/B або тест зі сповільненням
• Задано бюджет продуктивності й власник регресів
• Платний трафік перевіряється на швидкість посадкових
• Швидкість воронки (картка → кошик → оплата) важливіша за «бали головної»

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

Далі за темою

• JavaScript: 8 оптимізацій продуктивності — що міряти і що різати в клієнтському коді.
• 10 фактів про окупність UX — цифри для розмови із замовником про тертя.
• SEO, AEO, GEO у 2026 — де CWV стоять серед шарів видимості.
• Чому я пішов з Next.js на Astro — практичний кейс ваги JS на маркетинговому сайті.
• Еволюція веб-архітектури — контекст, звідки береться важкий клієнт.

Висновок

Повільний сайт — це не «поганий Lighthouse». Це менше переглянутих товарів, менше кошиків, менше замовлень, вища вартість залученого кліка і менше прибутку. Оптимізацію швидкості має сенс оцінювати в грошах: через свою воронку, свої перцентилі й свою гіпотезу Δ конверсії — з калькулятором вище і чесним тестом, а не з чужим мемом про «+1 секунда».

Ланцюжок, який варто повісити над дошкою команди:

Performance → UX → поведінка → конверсія → замовлення → виручка → прибуток