Головна омана багатьох власників бізнесу (і, на жаль, деяких розробників) — це одержимість отриманням зеленої позначки «100/100» у синтетичному тесті Google PageSpeed Insights. Реальність така: користувач не бачить ваші бали, він відчуває реальну швидкість взаємодії.
У цій статті ми розберемо, чому «ідеальний» бал у тесті не гарантує задоволених клієнтів, і на яких метриках варто фокусуватись замість гонитви за цифрою на екрані.
Синтетика (Lab Data) проти Реальності (Field Data)
PageSpeed імітує завантаження сайту з певного сервера на умовному пристрої з умовною швидкістю мережі. Це Lab Data. Проте Google ранжує ваш сайт на основі CrUX (Chrome User Experience Report) — реальних даних про те, як ваш сайт вантажився у тисяч реальних людей на різних смартфонах і в різних умовах. Саме ці реальні показники формують Core Web Vitals.
Різниця буває разючою: сайт може показувати 95 балів у лабораторному тесті на потужному сервері Google, і водночас мати «погані» показники CrUX, бо значна частина вашої реальної аудиторії заходить з бюджетних Android-смартфонів через мобільний інтернет у метро. Тому перше, що варто перевірити — це не сам бал PageSpeed, а вкладку «Discover what your real users experience» у тому ж звіті.
Що насправді важливо оптимізувати?
1. LCP (Largest Contentful Paint)
Це час до появи найбільшого елемента на екрані (зазвичай це головне фото або банер у першому екрані). Якщо ваш LCP більший за 2.5 секунди — ви втрачаєте увагу клієнта. Як виправити: налаштуйте попереднє завантаження (preload) для головного зображення, використовуйте формати WebP/AVIF і переконайтеся, що воно не генерується через складний клієнтський JavaScript.
2. Відчувана швидкість (Perceived Performance)
Іноді технічно сайт вантажиться 4 секунди, але користувачу здається, що він працює миттєво. Це досягається завдяки правильному UX:
- Skeleton Loaders: замість порожнього білого екрана або крутилки показуйте сірі блоки-заглушки там, де скоро з'явиться контент.
- Optimistic UI: коли користувач натискає «Лайк» або «Додати в кошик», інтерфейс має миттєво показати успішну дію, а відправка даних на сервер має відбуватися у фоновому режимі.
- Прогресивне завантаження зображень: спочатку показуйте розмите зображення низької якості (placeholder), яке плавно заміняється на повну версію — так око користувача не бачить «пустоти».
3. Відкладення сторонніх скриптів
Часто ідеально швидкий сайт «вбивають» маркетологи, додаючи в Google Tag Manager 15 різних пікселів, чат-ботів, віджетів зворотного дзвінка та аналітики. Кожен такий скрипт блокує рендеринг. Налаштуйте їх завантаження за подією (наприклад, після першого скролу або кліку), щоб вони не заважали користувачеві побачити головний контент.
4. CLS (Cumulative Layout Shift) — тихий вбивця конверсії
Це метрика, яка вимірює, наскільки «стрибає» верстка під час завантаження. Класичний приклад: користувач хоче натиснути на кнопку, але в цю секунду над нею підвантажується банер, і кнопка зсувається вниз — клік потрапляє в інший елемент. Це не просто дратує, а й може призводити до випадкових небажаних дій (наприклад, підписки на розсилку замість закриття попапу). Рішення просте: завжди явно вказуйте розміри (width і height) для зображень, відео та рекламних блоків ще до їх завантаження, щоб браузер зарезервував місце заздалегідь.
Як правильно ставити цілі команді
Замість формулювання завдання розробнику як «зроби 100 балів у PageSpeed», сформулюйте його через реальні метрики користувача: «LCP на мобільних пристроях повинен бути менше 2.5 секунди для 75% реальних відвідувачів за даними CrUX за останні 28 днів». Це вимірюваний, реалістичний і, найголовніше, бізнесово корисний показник, який напряму корелює з утриманням клієнтів та позиціями в пошуку.