Швидкість сайту: 15 причин повільного завантаження і як їх усунути
Зображення, шрифти, скрипти, хостинг, blur-ефекти — розбираємо, що найчастіше гальмує сайти, і скільки мілісекунд повертає кожне виправлення.
Повільний сайт майже ніколи не має однієї причини. Він має п’ятнадцять дрібних, кожна з яких коштує 100–400 мс, і разом вони перетворюють двосекундне завантаження на семисекундне. Нижче — список винуватців у порядку шкоди: скільки мілісекунд забирає кожен, як його знайти й скільки часу займає виправлення. Починається все з вимірювання, бо оптимізувати навмання — найшвидший спосіб витратити тиждень і не зрушити нічого.
2.5s
межа «добре» для LCP на мобільному
200ms
межа «добре» для INP — швидкість відгуку
0.1
максимальний прийнятний CLS
60%
ваги середньої сторінки — зображення
Спочатку виміряти, потім чіпати
Головна помилка — дивитися на один бал у PageSpeed Insights і намагатися його підняти. Бал є синтетичною сумою, він стрибає між запусками на ±10 пунктів і нічого не каже про те, що бачать реальні люди. Дивитися треба на окремі метрики й на польові дані.
- 1Запустіть PageSpeed Insights для трьох різних типів сторінок — головної, сторінки послуги або товару, і найважчої сторінки з галереєю. Оптимізувати лише головну безглуздо: люди заходять із пошуку одразу вглиб.
- 2Розділіть лабораторні й польові дані. Верхній блок звіту — це реальні користувачі за останні 28 днів, нижній — симуляція на емульованому повільному пристрої. Пріоритет завжди у польових даних, бо це ваші клієнти, а не тестовий стенд.
- 3Відкрийте вкладку Network у браузері з обмеженням «Fast 3G» і подивіться, що вантажиться перші три секунди. Зазвичай там знаходиться щось, чого ви не очікували побачити взагалі.
- 4Зафіксуйте базові цифри до змін. Без точки відліку ви не доведете ані собі, ані клієнту, що виправлення спрацювало.
Зображення: причини 1–4, найбільший важіль
Якщо у вас є час лише на одну зміну, робіть цю. Зображення — це більшість ваги сторінки і майже завжди її LCP-елемент. Виправлення тут дають найбільший ефект на витрачену годину.
| Причина | Типова втрата | Що робити |
|---|---|---|
| 1. JPEG і PNG замість AVIF/WebP | 400–1200 мс | Конвертувати; AVIF дає −50–70% ваги без видимої втрати |
| 2. Одне зображення на всі екрани | 300–900 мс | Віддавати кілька розмірів через srcset, мобільному — вужчий файл |
3. Немає width і height | CLS 0.1–0.3 | Проставити розміри або aspect-ratio, щоб місце резервувалося |
4. loading="lazy" на першому екрані | 200–600 мс | Зняти lazy з LCP-зображення й додати йому fetchpriority="high" |
Найчастіша конкретна знахідка: банер на 2400 пікселів завширшки, знятий фотографом і залитий в адмінку без обробки, який показується на екрані шириною 390 пікселів. Це 1.8 МБ там, де вистачило б 90 КБ. Правильна розмітка виглядає так:
<img
src="/img/hero-800.webp"
srcset="/img/hero-400.webp 400w,
/img/hero-800.webp 800w,
/img/hero-1600.webp 1600w"
sizes="(max-width: 768px) 100vw, 800px"
width="800"
height="450"
fetchpriority="high"
alt="Команда за роботою"
/>Шрифти й CSS: причини 5–8
Шрифти підступні тим, що важать небагато, але блокують показ тексту. Користувач дивиться на порожній екран, поки завантажується файл на 80 КБ, — і це рахується як повільне завантаження, хоча HTML прийшов миттєво.
- 5. Три родини й вісім накреслень. Кожне накреслення — окремий файл на 20–60 КБ. Реально потрібні два: звичайний і жирний. Економія — 150–400 КБ і 200–500 мс.
- 6. `font-display: block` або відсутність значення. Текст лишається невидимим до 3 секунд.
swapпоказує системний шрифт одразу, а потім підміняє — сторінка стає читабельною на секунду раніше. - 7. Невикористаний CSS від теми чи UI-фреймворка. Типова тема віддає 200–400 КБ стилів, з яких сторінка використовує 15%. Прибирання невикористаного CSS звільняє 100–300 мс на рендер.
- 8. Важкі візуальні ефекти на мобільному.
backdrop-filter: blur(), багатошарові тіні й нескінченні анімації змушують браузер перемальовувати екран під час скролу. На бюджетному Android це не мілісекунди завантаження, а помітні ривки прокрутки, які користувач сприймає як «сайт гальмує».
<link rel="preload" as="font" type="font/woff2"
href="/fonts/inter-400.woff2" crossorigin>
<style>
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-400.woff2') format('woff2');
font-weight: 400;
font-display: swap;
}
</style>Скрипти й віджети: причини 9–12
Це найнеприємніша категорія, бо кожен окремий скрипт додав хтось із вагомої причини. Проблема виникає, коли їх вісім. JavaScript не просто вантажиться — він виконується, а поки виконується, сторінка не реагує на дотики.
| Що саме | Типова вага | Рішення |
|---|---|---|
| 9. Аналітика й рекламні пікселі | 80–250 КБ | Залишити необхідне, решту завантажувати відкладено |
| 10. Чат-віджет | 150–400 КБ | Вантажити після першої взаємодії або через 5 секунд |
| 11. Слайдери й анімаційні бібліотеки | 100–300 КБ | Замінити на CSS там, де потрібен простий ефект |
| 12. Дублікати бібліотек і застарілий jQuery | 90–200 КБ | Аудит залежностей, видалення того, що не викликається |
Практичне правило, яке ми застосовуємо на кожному проєкті: жоден сторонній скрипт не вантажиться до того, як користувач побачив контент. Чат з’являється через п’ять секунд або після скролу — конверсія від цього не падає, а INP покращується на 100–300 мс. Аналітику підключаємо після події завантаження, а не в <head> синхронно.
Кожен віджет на сайті має власника й причину. Проблема в тому, що причина була актуальна три роки тому, а віджет вантажиться досі.
Сервер і доставка: причини 13–15
Ця частина невидима в браузері, але задає стелю для всього іншого. Якщо сервер думає 900 мс перед першим байтом, жодна оптимізація зображень не витягне LCP у зелену зону.
- 13. Дешевий хостинг без кешу. Спільний тариф за $3 на місяць дає TTFB 600–1200 мс у години пік. Перехід на нормальний VPS або managed-хостинг із повносторінковим кешем зазвичай зрізає 400–800 мс — це найдешевше прискорення з усіх можливих.
- 14. Немає CDN. Якщо сервер у Німеччині, а половина відвідувачів — з іншого континенту, вони платять 150–300 мс лише за фізичну відстань. CDN для статики прибирає цю затримку майже повністю і коштує від нуля до кількох доларів на місяць.
- 15. Немає стиснення й кешуючих заголовків. Brotli або gzip зменшують HTML, CSS і JS на 60–80%. Заголовки
Cache-Controlдля статики означають, що повторний візит не завантажує нічого зайвого. Обидві налаштовуються за годину й діють на весь сайт одразу.
Порядок виправлень: від найбільшого ефекту до найменшого
- Стиснення й кешуючі заголовки на сервері — 1 година, ефект на всі сторінки
- Конвертація зображень у AVIF/WebP і
srcset— 3–6 годин - Зняти lazy-loading і додати
fetchpriorityдля LCP-зображення — 30 хвилин - Скоротити шрифти до двох накреслень і поставити
font-display: swap— 1 година - Відкласти чат, аналітику й пікселі — 2 години
- Прибрати важкі blur-ефекти й анімації на мобільному — 2–4 години
- Прибрати невикористаний CSS і зайві бібліотеки — 4–8 годин
- Змінити хостинг або підключити CDN — 1 день
Якщо після всього цього сайт усе одно повільний, проблема архітектурна: тема з конструктором сторінок або платформа, яка збирає сторінку з бази при кожному запиті. Тоді розмова вже не про оптимізацію, а про стек — ми порівнювали варіанти в матеріалі Next.js чи WordPress.
Часті питання про швидкість сайту
Яка нормальна швидкість завантаження сайту у 2026 році?
Орієнтуйтесь на Core Web Vitals: LCP до 2.5 секунди, INP до 200 мілісекунд, CLS до 0.1 — усе це на мобільному з’єднанні, а не на десктопі з оптоволокном. Ці пороги Google вважає межею «добре», і саме за ними оцінюється досвід реальних користувачів. Показник у 4 секунди на мобільному вже помітно б’є по конверсії.
Чи справді швидкість впливає на позиції в Google?
Так, але слабше, ніж прийнято думати: швидкість — один з багатьох сигналів і працює переважно як тайбрейкер між сторінками з приблизно однаковою релевантністю. Значно сильніший ефект непрямий — повільні сторінки втрачають користувачів до того, як ті побачать контент. Тому оптимізація швидкості майже завжди швидше окупається через конверсію, ніж через позиції.
Чому мій бал у PageSpeed Insights стрибає при кожному запуску?
Лабораторний тест виконується на віддаленому сервері з емуляцією повільного пристрою й мережі, тому результат природно коливається на ±10 пунктів. Орієнтуватися варто на польові дані у верхній частині звіту — вони зібрані з браузерів реальних відвідувачів за останні 28 днів. Якщо польових даних немає, сайт просто ще не має достатнього трафіку для їх формування.
Скільки коштує прискорити сайт?
Базовий пакет — стиснення, зображення, шрифти, відкладені скрипти — це зазвичай 8–16 годин роботи, тобто приблизно $200–500. Він дає найбільшу частину результату. Глибша оптимізація з переписуванням шаблонів або зміною платформи коштує від $1 000 і має сенс лише тоді, коли базові кроки вже вичерпані.
Чи допоможе плагін кешування вирішити проблему?
Частково: кеш прибирає час генерації сторінки на сервері й реально зрізає TTFB на кілька сотень мілісекунд. Але він не зменшує вагу зображень, не прибирає зайвий JavaScript і не впливає на INP, бо скрипти виконуються вже в браузері. Кеш — це перший крок, а не заміна оптимізації клієнтської частини.
Коротко
- Виміряйте до змін і дивіться на LCP, INP і CLS окремо, а не на загальний бал.
- Зображення дають найбільший виграш: сучасні формати,
srcset, розміри в атрибутах і жодного lazy-loading на першому екрані. - Сторонні скрипти б’ють по відгуку, а не по завантаженню — відкладайте чат, аналітику й пікселі до появи контенту.
- Blur-ефекти й нескінченні анімації ламають плавність скролу на бюджетних телефонах сильніше, ніж зайві 200 КБ.
- Стиснення, кешуючі заголовки й нормальний хостинг — година роботи, яка діє на весь сайт одразу.
Схожі матеріали
Core Web Vitals: LCP, INP і CLS простими словами
Три метрики, які Google використовує як сигнал ранжування. Пояснюємо кожну і показуємо, що ламає їх найчастіше.
Mobile-first дизайн: чому 70% трафіку вирішує все
Більшість ваших відвідувачів — з телефона. Але більшість сайтів досі проєктують на 27-дюймовому моніторі.
Next.js чи WordPress: що обрати для бізнес-сайту
Це не «сучасне проти застарілого». Це вибір між різними моделями витрат — розбираємо обидві.