Повільний сайт — це не завжди білий екран. Іноді сторінка вже видима, але головне фото з’являється значно пізніше. Ви натискаєте меню, а воно реагує із затримкою. Або тягнетеся до кнопки, коли сторінка раптом зміщується через завантаження нового елемента.
Core Web Vitals вимірюють саме такі моменти: коли з’являється основний контент, як швидко сторінка реагує на дію та чи залишається макет на місці під час завантаження.
Ці показники корисні, але 100/100 не є бізнес-ціллю самою по собі. Відвідувач має швидко побачити пропозицію, відкрити меню та надіслати форму — звичайно, з телефона, а не лише на ідеальному тестовому пристрої.
PageSpeed і Core Web Vitals — це різні вимірювання
PageSpeed Insights показує оцінку Lighthouse від 0 до 100 і дані реальних користувачів, якщо їх достатньо. Lighthouse виконує лабораторний тест у змодельованих умовах: 90–100 — зелена зона, 50–89 — помаранчева, нижче 50 — червона.
Core Web Vitals використовують реальні відвідування Chrome за останні 28 днів, коли трафіку достатньо. У нової сторінки даних може не бути. Лабораторний тест допомагає знайти проблему, а польові дані показують досвід людей із різними телефонами та з’єднаннями.
У звіті варто запитати:
- це мобільний чи десктопний тест;
- це лабораторний запуск чи дані відвідувачів;
- яку саме URL виміряли;
- що помічає відвідувач на цій сторінці;
- що змінилося після виправлення?
Три Core Web Vitals без технічного словника
LCP: коли з’являється головний контент?
Largest Contentful Paint вимірює, скільки часу потрібно найбільшому видимому елементу — часто головному фото або заголовку. До 2,5 секунди вважається добре, понад 4 секунди — погано.
INP: наскільки швидко реагує сторінка?
Interaction to Next Paint вимірює реакцію на клік, дотик або натискання клавіші. Меню, яке відкривається після помітної паузи, або калькулятор із затримкою — це проблема INP. До 200 мс — добре, понад 500 мс — погано.
CLS: чи все залишається на місці?
Cumulative Layout Shift вимірює несподівані зміщення. Ви хочете натиснути кнопку, з’являється фото — і кнопка їде під пальцем. До 0,1 — добре, понад 0,25 — погано.
Google оцінює значення на 75-му перцентилі: приблизно три з чотирьох відвідувань мають залишатися в хорошому діапазоні. Актуальні межі описані на web.dev.
Що сповільнює сайт?
Зазвичай причина не в одному рядку коду. Сайт повільнішає, коли роками накопичуються шари: тема, конструктор, плагіни, чат, бронювання, рекламні пікселі та аналітика. Старі частини залишаються, бо ніхто не впевнений, чи вони ще потрібні.
Часті причини:
- фото й відео набагато більші, ніж потрібно для їхнього місця на екрані;
- сторінки зібрані з різних тем, конструкторів або наборів блоків;
- старі стилі й скрипти залишилися після редизайну;
- плагіни без зрозумілої задачі;
- аналітика та рекламні теги, результати яких ніхто не переглядає;
- забагато файлів шрифтів і варіантів накреслення;
- відео, карти, чати та віджети бронювання завантажуються одразу;
- нові функції додані без прибирання старого рішення.
WordPress або конструктор не роблять сайт повільним автоматично. Сучасний сайт теж може гальмувати через велике фонове відео та безліч зовнішніх сервісів. WebP або AVIF часто зменшують розмір фото, а адаптивні зображення не змушують телефон завантажувати десктопний файл.
Практичний приклад: WordPress зріс із 43 до 85 на мобільному
Один проєкт на WordPress починався з мобільної оцінки Lighthouse 43. Найбільший видимий елемент з’являвся через 9,6 секунди, Total Blocking Time становив 620 мс. Після оптимізації оцінка зросла до 85, перший видимий контент з’являвся за 1,5 замість 3,3 секунди, LCP змінився з 9,6 до 3,2 секунди, TBT — із 620 до 130 мс, CLS — із 0,059 до 0,002.
До оптимізації: мобільний тест Lighthouse з Performance 43. Попередній перегляд сайту анонімізовано.
Після оптимізації: мобільний тест Lighthouse з Performance 85. Попередній перегляд сайту анонімізовано.
Це знімки, зроблені в різний час, а не контрольований експеримент. Вони показують перебіг конкретного проєкту, а не гарантію для кожного сайту. Результати Lighthouse можуть змінюватися через середовище та версію тесту.
Чи потрібні 100 балів?
В OROS я використовую 80+ на мобільному та 90+ на десктопі як практичні орієнтири, а не офіційну норму Google чи гарантію. Важливіші питання такі:
- Чи швидко мобільний відвідувач бачить пропозицію?
- Чи реагують меню, кнопки, форми й калькулятори без помітної паузи?
- Чи не зміщується сторінка під час читання й натискань?
- Чи залишиться сайт зручним після додавання аналітики, контенту та потрібних функцій?
Оцінка 85 після старту з 43 може бути правильним моментом зупинитися. Останні бали на старому конструкторі іноді коштують стільки роботи, що простіше перебудувати сайт. Компактний статичний сайт може отримати 100, але навіть Lighthouse попереджає, що це надзвичайно складно і не очікується від кожного проєкту.
Коли можна оптимізувати наявний сайт?
Помаранчева або червона оцінка не означає автоматичну потребу в новому сайті. Спершу потрібно знайти джерело затримки: стиснути фото, прибрати непотрібні плагіни й скрипти, зменшити кількість шрифтів і відкладати відео до моменту, коли його захочуть переглянути.
Ремонт доречний, коли структура працює, команда може користуватися сайтом, а найбільші проблеми зрозумілі. Після кожної зміни перевіряйте форми, бронювання, аналітику та рекламні події. Висока оцінка швидкості нічого не варта, якщо заявки перестали надходити.
Коли розумніше перебудувати?
Нова збірка має сенс, коли роки правок, кілька конструкторів і крихкі залежності призводять до того, що одна зміна ламає іншу частину. Перенести корисний контент на чисту основу іноді дешевше, ніж нескінченно чистити стару.
Для сторінок послуг і лендингів, які не змінюються щодня, я часто використовую Astro. Він може заздалегідь зібрати статичні файли, тому браузер отримує просту основу. Astro не є чарівною кнопкою швидкості: велике відео, багато шрифтів і зовнішні скрипти все одно сповільнюють сайт, а добре налаштований WordPress може працювати дуже швидко.
Для рішення «ремонтувати чи перебудовувати» я спершу перевіряю причину затримок, контент і функції, які потрібно зберегти, потребу клієнта редагувати сторінки, можливість видалити старий код, майбутнє обслуговування та збереження форм, аналітики й URL.
Читайте WordPress, конструктор чи власна розробка: що підходить бізнесу?, якщо порівнюєте технічну основу.
Як самостійно перевірити швидкість сайту
Відкрийте важливі сторінки на звичайному телефоні, бажано також через мобільний інтернет. Перевірте меню, основну кнопку, форму, запис, оплату або калькулятор. Потім окремо запустіть мобільний і десктопний URL у PageSpeed Insights та подивіться, чи є дані реальних користувачів.
Не робіть висновок з одного запуску. Повторіть тест у схожих умовах і перевірте справжній шлях клієнта, а не лише головну. Після змін переконайтеся, що покращився не тільки бал, а й потрібні функції.
Що запитати розробника?
- На що зараз найдовше чекає відвідувач?
- Яке фото, шрифт або скрипт створює найбільшу затримку?
- Які зовнішні сервіси досі потрібні?
- Ми дивимося дані користувачів чи лабораторний тест?
- Чи можна виправити головні проблеми без перебудови?
- Що буде видалено і що перевіримо після цього?
- Чому рекомендується нова збірка?
- Як перевірятиметься мобільна версія після змін?
«Встановимо плагін швидкості» — це не діагноз. Розробник має знати причину, пояснити ризик і сказати, що реально зробити в межах поточного сайту.
Чи допомагає швидкий сайт у Google?
Google враховує Core Web Vitals та інші сигнали взаємодії зі сторінкою. Хороші показники не гарантують високої позиції: швидка сторінка зі слабким або нерелевантним контентом залишиться слабкою. Швидкість — це якісне обслуговування, а не трюк для миттєвого SEO-трафіку.
Спочатку дослідження, потім рішення про перебудову
Повільний сайт не потрібно автоматично замінювати. Почніть із мобільної версії, ключових сторінок, зображень, зовнішніх скриптів та обмежень поточної системи.
Опишіть сайт і проблему в калькуляторі сайту. Я поясню, що можна покращити в наявній версії та коли нова збірка справді виправдана. Якщо плануєте новий проєкт, прочитайте скільки коштує сайт у Нідерландах у 2026 році або скористайтеся калькулятором сайту.
Про автора
Daniel Orosz
Даніел створює сайти та цифрові системи в Керкраде. Він працює з вебтехнологіями понад 16 років і пояснює складні рішення простою мовою.
Більше про Даніела →
