Як перевірити швидкість сайту: TTFB, Core Web Vitals і способи прискорення

Повільний сайт не завжди виглядає повільним на комп’ютері власника. Сторінка може відкриватися швидко через локальний кеш, стабільний Wi-Fi та сучасний пристрій, але гальмувати на мобільному інтернеті, бюджетному смартфоні або під навантаженням. Тому перевірка повинна спиратися не на особисте враження й не на одну оцінку, а на кілька рівнів: відповідь сервера, передачу файлів, появу головного контенту, реакцію інтерфейсу та реальний досвід відвідувачів.

Почати можна з безкоштовного аудиту швидкості сайту. Інструмент BB STUDIO перевіряє DNS, з’єднання, TLS, TTFB, вагу HTML, стиснення, кешування та склад ресурсів. Це швидка серверна діагностика, яка допомагає відрізнити проблеми хостингу від важкої сторінки ще до глибокої роботи в браузері.

Швидкість — це не одна цифра

Фраза «сайт завантажився за три секунди» майже нічого не говорить без контексту. Користувач сприймає швидкість як послідовність подій:

1. браузер знаходить домен;

2. встановлює з’єднання та HTTPS;

3. очікує перший байт HTML;

4. отримує стилі, шрифти, скрипти й зображення;

5. показує найбільший видимий елемент;

6. дозволяє натискати кнопки без затримки;

7. зберігає стабільне розташування блоків.

Сторінка може мати швидкий сервер, але важке головне фото. Може швидко виглядати готовою, але зависати під час відкриття меню. Може відкритися за секунду, а потім зрушити кнопку через пізнє завантаження банера. Саме тому потрібна група показників.

Основні показники швидкості

Пороги Core Web Vitals оцінюють на 75-му процентилі реальних завантажень окремо для мобільних і десктопних пристроїв. Це важливо: один успішний тест на потужному ноутбуці не перекриває проблеми більшості мобільних користувачів.

Що таке TTFB

Time to First Byte — час від початку переходу до моменту, коли браузер отримав перший байт відповіді. У нього входять редиректи, запуск service worker за наявності, DNS, з’єднання, TLS та очікування відповіді сервера.

TTFB передує завантаженню основного контенту, тому повільна відповідь зсуває майже всі наступні події. Але TTFB не є Core Web Vital і не пояснює всю швидкість. Сайт зі швидким HTML може потім завантажити мегабайти JavaScript, а серверно згенерована сторінка з трохи вищим TTFB іноді показує контент швидше за клієнтський застосунок.

Як читати результат TTFB

• до 0,2 с — дуже швидка відповідь за сприятливих умов;

• 0,2–0,8 с — робочий діапазон, який оцінюють разом із географією та типом сайту;

• 0,8–1,8 с — потрібне дослідження причин;

• понад 1,8 с — серверна або мережева затримка вже серйозно обмежує завантаження.

Це не жорсткий рейтинг для кожного проєкту. Тестуйте кілька разів, із різних регіонів та окремо для закешованого й незакешованого стану.

Як провести коректну перевірку

1. Перевірте не лише головну

Головна сторінка часто оптимізована найкраще. Додайте до вибірки:

• популярну сторінку послуги;

• категорію інтернет-магазину;

• картку товару з галереєю та варіаціями;

• статтю блогу;

• сторінку контакту з картою;

• сторінку після входу, якщо є особистий кабінет.

2. Зробіть кілька запусків

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

3. Порівняйте мобільний і десктопний сценарій

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

4. Розділіть лабораторні та польові дані

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

5. Зафіксуйте стан до змін

Запишіть URL, дату, пристрій, регіон, показники й версію сторінки. Після оптимізації повторіть той самий сценарій. Інакше легко приписати покращення випадковій зміні мережі або кешу.

LCP: коли з’являється головний контент

Largest Contentful Paint найчастіше відповідає головному фото, банеру, великому заголовку або текстовому блоку у видимій області. Хороший LCP не означає, що завантажилося все; він означає, що користувач швидко побачив головний елемент.

LCP складається з кількох частин:

• TTFB;

• затримки до виявлення ресурсу;

• часу завантаження ресурсу;

• затримки від завершення завантаження до відображення.

Якщо головне зображення додається через JavaScript або CSS background, браузер може знайти його пізно. Для критичного зображення корисні правильний HTML, пріоритет завантаження, адаптивні джерела та відсутність lazy loading у першому екрані.

INP: чи реагує сторінка на натискання

Interaction to Next Paint оцінює затримку кліків, дотиків і натискань клавіш протягом усього візиту. Високий INP часто з’являється, коли головний потік зайнятий довгим JavaScript-завданням: браузер отримав дію, але не може швидко показати результат.

Типові джерела:

• великий bundle без розділення;

• кілька слайдерів та анімацій на одній сторінці;

• важкі фільтри товарів;

• повторне побудування великого DOM;

• сторонні чати, віджети, пікселі й трекери;

• обробники, які виконують зайві синхронні обчислення.

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

CLS: чому сторінка «стрибає»

Cumulative Layout Shift вимірює неочікувані зсуви. Найчастіші причини:

• у зображення чи iframe немає width і height;

• банер з’являється над уже показаним контентом;

• шрифт змінює розміри тексту після завантаження;

• блок рекомендацій вставляється без зарезервованого місця;

• cookie-повідомлення пересуває всю сторінку;

• анімація змінює геометричні властивості замість transform.

Резервуйте місце через розміри або aspect-ratio, завантажуйте шрифти з продуманим fallback і не вставляйте новий контент над поточною позицією без дії користувача.

Зображення: найчастіший резерв швидкості

На багатьох сайтах саме зображення становлять найбільшу частину трафіку. Проблема не вирішується одним стисненням. Потрібно перевірити формат, фактичні розміри, srcset, lazy loading, пріоритет першого екрана та прозорість.

Для діагностики використовуйте аудит зображень: він допоможе знайти відсутні alt, надмірну вагу, невідповідні формати й проблеми відкладеного завантаження. Окремі файли можна безкоштовно обробити через конвертер зображень у WebP, де зміна відбувається локально в браузері.

Практичний порядок:

1. обріжте фото до потрібного співвідношення;

2. створіть ширини для різних екранів;

3. оберіть WebP або AVIF для фото, SVG — для векторної графіки;

4. підберіть якість без помітних артефактів;

5. налаштуйте srcset і sizes;

6. не використовуйте lazy loading для LCP-зображення;

7. задайте width, height або aspect-ratio.

Кешування і стиснення

Кеш працює на кількох рівнях. Браузер зберігає статичні файли, сервер може зберігати готову HTML-відповідь, CDN — копію ближче до користувача, а об’єктний кеш — результати запитів до бази.

Не встановлюйте один довгий термін для всього. Версіоновані CSS, JS і зображення можуть кешуватися довго, а HTML і персоналізовані дані потребують обережнішої політики. Після оновлення файл повинен отримувати нову адресу або хеш, інакше відвідувач може бачити стару версію.

Gzip або Brotli зменшують текстові ресурси: HTML, CSS, JavaScript, JSON і SVG. Уже стиснені JPEG, WebP чи відео майже не виграють від повторного gzip. Перевіряйте Content-Encoding і Cache-Control у відповіді, а не лише налаштування плагіна.

Хостинг, база даних і серверний код

Коли TTFB високий, починайте з бекенду. Причиною може бути перевантажений тариф, далекий дата-центр, повільний диск, стара версія PHP, важкий запит, зовнішній API або відсутність page cache.

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

Для динамічних сайтів корисно перевірити:

• повільні SQL-запити;

• autoload-дані й розмір опцій;

• cron-завдання;

• API, які блокують формування HTML;

• кеш сторінок та об’єктів;

• черги фонових задач;

• журнали помилок і пікове навантаження.

CSS, JavaScript і шрифти

Критичні стилі потрібні для першого екрана, решта може завантажуватися пізніше. Але автоматичне об’єднання всіх CSS-файлів інколи створює один великий ресурс і ламає порядок правил. Оптимізацію перевіряють візуально на різних шаблонах.

Для JavaScript:

• додавайте defer до скриптів, які не повинні блокувати HTML;

• завантажуйте віджети після згоди або взаємодії;

• розділяйте код за сторінками й функціями;

• прибирайте невикористані бібліотеки;

• уникайте дублювання jQuery, слайдерів і аналітики;

• перевіряйте довгі задачі в Performance-профілі.

Для шрифтів використовуйте лише потрібні набори й накреслення, сучасний формат WOFF2, preload тільки для справді критичного файлу та font-display. Надмірний preload може конкурувати з головним зображенням і погіршити LCP.

WordPress і WooCommerce

У WordPress не існує одного «найшвидшого» набору плагінів. Результат залежить від теми, конструктора, хостингу, каталогу й інтеграцій. Типовий план:

1. створити резервну копію та тестове середовище;

2. знайти повільні запити й важкі плагіни;

3. налаштувати page cache та object cache;

4. оптимізувати зображення і шрифти;

5. прибрати непотрібні модулі конструктора;

6. відкласти чати, карти та маркетингові скрипти;

7. перевірити кошик, checkout, кабінет і мультимовність після кешування.

Сторінки кошика, оформлення й особистого кабінету зазвичай не можна кешувати як звичайну статику. Для товарів важливі галерея, варіації, фільтри, пошук і синхронізація залишків — тестуйте не лише головну.

Лабораторні й реальні дані

Лабораторна оцінка відповідає на питання «що відбувається в заданому сценарії зараз». Польові дані відповідають на питання «що відчували реальні користувачі протягом періоду». Вони можуть відрізнятися через:

• географію та провайдерів;

• моделі пристроїв;

• кеш;

• авторизацію;

• різні сторінки;

• поведінку користувачів;

• сезонне навантаження;

• недостатню кількість польових даних для конкретної URL.

Не намагайтеся отримати 100 балів ціною функціональності. Google прямо пояснює, що хороша сторінкова взаємодія складається з багатьох аспектів, а ідеальний результат одного тесту не гарантує високої позиції. Для SEO-просування сайту швидкість є технічною основою, але релевантність, контент, структура та авторитет залишаються критичними.

Пріоритети виправлення

Список рекомендацій може містити десятки пунктів. Сортуйте їх за впливом, охопленням, ризиком і вартістю.

Перший пріоритет

• серверні помилки й дуже високий TTFB;

• LCP-зображення на кілька мегабайт;

• відсутність стиснення текстових ресурсів;

• блокуючі скрипти на всіх сторінках;

• серйозні зсуви кнопок і форм;

• зависання меню, фільтрів або checkout.

Другий пріоритет

• неправильна кеш-політика;

• зайві шрифти й накреслення;

• сторонні віджети без відкладення;

• невикористаний CSS і JavaScript;

• неоптимальні сторінки категорій і товарів.

Низький пріоритет

• невеликі покращення, які не впливають на користувацький шлях;

• косметичне підвищення лабораторної оцінки без зміни польових даних;

• складна переробка заради кількох кілобайтів на рідкісній сторінці.

Як швидкість впливає на бізнес

Швидкість не продає сама по собі, але прибирає тертя. Її вплив варто перевіряти через:

• частку виходів із посадкових сторінок;

• завершення форм і checkout;

• конверсію мобільних користувачів;

• дохід на сеанс;

• помилки взаємодії;

• органічні входи й сканування;

• звернення до підтримки через технічні проблеми.

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

Коли потрібна технічна допомога

Самостійно можна стиснути фото або вимкнути зайвий віджет. Але кешування checkout, оптимізація бази, зміна сервера, робота з критичним CSS і поділ JavaScript потребують тестового середовища й плану відкату.

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

Чекліст після оптимізації

• повторені тести ключових типів сторінок;

• порівняні холодний і теплий кеш;

• перевірені мобільний та десктопний сценарії;

• немає помилок у формах, кошику, оплаті та кабінеті;

• ресурси отримують коректні Cache-Control і Content-Encoding;

• LCP-елемент завантажується пріоритетно;

• зображення мають правильні формати, розміри й srcset;

• сторонні скрипти не блокують перший екран;

• шрифти не спричиняють невидимий текст і зсуви;

• Search Console і реальна аналітика відстежуються після релізу;

• існує резервна копія та можливість відкату.

Вартість оптимізації

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

Якщо проблема пов’язана з фундаментом і розглядається нова платформа, орієнтири вартості пояснює матеріал скільки коштує сайт у 2026 році. Для точного плану потрібні URL, доступ до аналітики, стек, хостинг, список інтеграцій і результати профілювання.

Висновок

Правильна перевірка швидкості починається з діагностики, а не з випадкового встановлення плагіна. Спочатку визначте, де виникає затримка: мережа, сервер, HTML, зображення, блокуючий код чи взаємодія. Потім перевірте ключові сторінки, поєднайте лабораторні та польові дані, розставте пріоритети й виміряйте бізнес-результат після змін.

Якщо потрібен технічний аудит і безпечний план оптимізації, зверніться до BB STUDIO.