Чому сайт повільний: 5 причин та як їх виправити

⏱️ Час читання: ~10 хвилин | 📅 Опубліковано: 23 грудня 2025

Повільний сайт — це дірка в бюджеті

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

Клієнт натискає на вашу рекламу. Ви заплатили за цей клік. Сайт вантажиться секунду, дві, три... На четвертій він закриває вкладку. Гроші пішли, клієнт пішов, ви навіть не дізнались про це.

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

Хороша новина: це лікується. Але спочатку потрібен діагноз.

Діагностика: з чого почати

Перш ніж щось оптимізувати, потрібно виміряти. "Мені здається, що сайт повільний" — не діагноз. Потрібні конкретні цифри.

Інструменти для перевірки

Google PageSpeed Insights — безкоштовний і найважливіший. Показує оцінку від 0 до 100 для мобільної та десктопної версії окремо. Якщо бачите червону зону (0-49) — є серйозні проблеми. Оранжева (50-89) — можна покращити. Зелена (90-100) — все добре.

GTmetrix — детальніший звіт. Показує "водоспад" завантаження: що вантажиться, в якому порядку, скільки часу займає кожен елемент. Корисно для пошуку конкретних "вузьких місць".

WebPageTest — для глибокого аналізу. Дозволяє тестувати з різних локацій і пристроїв. Якщо ваша аудиторія в Європі, а сервер у США — тут ви це побачите.

Mobile vs Desktop: чому це важливо

Google використовує Mobile-First Indexing. Це означає, що для ранжування він дивиться на мобільну версію вашого сайту, навіть якщо користувач шукає з комп'ютера.

Наприклад: PageSpeed показує 85 балів для десктопу і 35 для мобільного. Власник сайту перевіряв тільки десктоп і думав, що все добре. А Google весь цей час бачив повільний мобільний сайт.

Завжди перевіряйте обидві версії. Якщо треба обирати пріоритет — мобільна важливіша.

І ще: не тестуйте сайт на своєму комп'ютері з швидким інтернетом. Chrome DevTools дозволяє симулювати повільне 3G — саме так бачать ваш сайт багато мобільних користувачів.

Core Web Vitals: три метрики, які хоче Google

У 2021 році Google запровадив Core Web Vitals як офіційний фактор ранжування. Це три конкретні метрики, які вимірюють реальний досвід користувача. Не абстрактну "швидкість", а конкретні речі.

LCP (Largest Contentful Paint)

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

Цільове значення: до 2.5 секунди — добре. 2.5-4 секунди — потребує покращення. Більше 4 секунд — погано.

Типова причина проблем: важке hero-зображення без оптимізації, повільний сервер, render-blocking ресурси.

INP (Interaction to Next Paint)

Що це: час від кліку/тапу користувача до візуальної реакції сайту. Замінив старий показник FID у березні 2024.

Цільове значення: до 200 мс — добре. 200-500 мс — потребує покращення. Більше 500 мс — погано.

Типова причина проблем: важкий JavaScript, особливо сторонні скрипти (аналітика, чат-боти, рекламні пікселі). Користувач натискає кнопку — і нічого не відбувається пів секунди.

CLS (Cumulative Layout Shift)

Що це: наскільки "стрибає" контент під час завантаження. Знаєте це відчуття, коли хочете натиснути кнопку, а вона раптом з'їжджає вниз через рекламу, що завантажилась?

Цільове значення: до 0.1 — добре. 0.1-0.25 — потребує покращення. Більше 0.25 — погано.

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

Причина #1: Важкі зображення

Найпоширеніша причина повільних сайтів. І найлегша для виправлення.

Типовий сценарій: дизайнер завантажив hero-зображення 4000×3000 пікселів, 5 МБ. На сайті воно відображається 1200×800. Ті 5 МБ все одно завантажуються повністю. Помножте на 10-15 зображень на сторінці — і отримаєте 50+ МБ, які користувач має завантажити.

Як виправити

Стисніть зображення. Інструменти на кшталт TinyPNG або Squoosh зменшують розмір на 60-80% без помітної втрати якості. Це безкоштовно і займає хвилину.

Використовуйте сучасні формати. WebP важить на 25-35% менше за JPEG при тій самій якості. AVIF — ще менше, але підтримується не всіма браузерами. WordPress, Shopify та більшість сучасних CMS вміють автоматично конвертувати у WebP.

Вкажіть розміри. Завжди додавайте атрибути width і height до тегу <img>. Це запобігає "стрибкам" контенту (CLS) під час завантаження.

<!-- ❌ Погано -->
<img src="photo.jpg">
<!-- ✅ Добре -->
<img src="photo.webp" width="800" height="600" alt="Опис зображення">

Увімкніть lazy loading. Зображення, які знаходяться внизу сторінки, не потрібно завантажувати одразу. Атрибут loading="lazy" відкладає їх завантаження до моменту, коли користувач до них доскролить.

<img src="photo.webp" loading="lazy" width="800" height="600" alt="Опис">

Responsive images. Для різних екранів — різні розміри зображень. Навіщо мобільному телефону завантажувати картинку 2000 пікселів завширшки?

Найшвидший спосіб отримати результат — просто стисніть зображення на головній сторінці через TinyPNG. 10 хвилин роботи можуть прискорити сайт на 30-50%.

Причина #2: Роздутий код (CSS/JavaScript)

Сучасні сайти перевантажені кодом. Типова WordPress-тема тягне за собою 20+ CSS-файлів і стільки ж JavaScript. Більшість цього коду на конкретній сторінці не використовується.

Render-blocking ресурси

Це найпідступніша проблема. Браузер не почне відображати сторінку, поки не завантажить і не обробить CSS та JS, які знаходяться в <head>. Користувач бачить білий екран і чекає.

PageSpeed часто показує попередження "Eliminate render-blocking resources". Ось що з цим робити:

Для JavaScript: додайте атрибут defer або async. Це дозволяє браузеру завантажувати скрипт паралельно, не блокуючи рендеринг.

<!-- ❌ Блокує рендеринг -->
<script src="analytics.js"></script>
<!-- ✅ Не блокує -->
<script src="analytics.js" defer></script>

Для CSS: винесіть критичний CSS (стилі для першого екрану) інлайново в <head>, а решту завантажуйте асинхронно.

Мініфікація

Мініфікація — це видалення пробілів, коментарів та скорочення назв змінних у коді. Файл стає нечитабельним для людини, але браузеру байдуже. Розмір зменшується на 10-30%.

Більшість CMS мають плагіни для автоматичної мініфікації. Для WordPress — Autoptimize, WP Rocket, LiteSpeed Cache.

Unused CSS/JS

Chrome DevTools (вкладка Coverage) показує, скільки коду на сторінці реально використовується. Часто це 20-30% від завантаженого. Решта — мертвий вантаж.

Рішення залежить від ситуації:

• Видаліть плагіни/модулі, які не використовуєте
• Завантажуйте скрипти тільки на сторінках, де вони потрібні
• Для складних випадків — інструменти типу PurgeCSS

Але обережно: агресивна мініфікація та видалення "зайвого" коду може зламати сайт. Завжди тестуйте на staging-середовищі перед продакшеном.

Причина #3: Забагато HTTP-запитів

Кожен файл на сторінці — це окремий HTTP-запит до сервера. CSS, JavaScript, зображення, шрифти, іконки... На типовому сайті їх може бути 100+. Кожен запит має затримку, і вони накопичуються.

Third-party скрипти: тихі вбивці швидкості

Ось типовий набір на маркетинговому сайті:

• Google Analytics
• Google Tag Manager
• Facebook Pixel
• Hotjar або Clarity
• Intercom або інший чат-бот
• Рекламні скрипти

Кожен з цих скриптів тягне за собою ще скрипти. GTM може завантажувати десятки додаткових тегів. І всі вони виконуються в браузері користувача, з'їдаючи ресурси.

Результат: показник INP летить у червону зону. Користувач клікає — і сайт "думає" пів секунди, бо JavaScript зайнятий аналітикою.

Що робити:

• Проведіть аудит: скільки скриптів реально використовуєте? Той Hotjar, який поставили рік тому — хтось дивиться ті записи?
• Завантажуйте некритичні скрипти із затримкою (після завантаження сторінки)
• Використовуйте GTM з розумом — не все потрібно трекати

Шрифти

Google Fonts зручні, але кожен шрифт — це запит до зовнішнього сервера. А якщо ви підключили 3 шрифти по 4 накреслення кожен — це 12 запитів.

Рішення:

• Обмежтесь 1-2 шрифтами
• Завантажуйте тільки потрібні накреслення (400, 700, а не всі від 100 до 900)
• Хостіть шрифти локально замість Google Fonts
• Використовуйте font-display: swap щоб текст був видимий до завантаження шрифту

Об'єднання файлів

10 маленьких CSS-файлів краще об'єднати в один. Це зменшує кількість запитів. Але з HTTP/2 це вже не так критично — протокол дозволяє завантажувати багато файлів паралельно.

Причина #4: Відсутність кешування

Без кешування браузер завантажує всі файли заново при кожному візиті. Логотип сайту, CSS, JavaScript — все це вантажиться знову і знову, хоча воно не змінилось.

Браузерне кешування

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

Налаштовується через HTTP-заголовки Cache-Control та Expires. Для статичних файлів (CSS, JS, зображення) рекомендується кешувати на рік.

# Приклад для Nginx
location ~* \.(css|js|jpg|jpeg|png|gif|ico|webp|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Серверне кешування

Динамічні сторінки (PHP, Python, Node.js) генеруються на кожен запит. Сервер виконує код, робить запити до бази даних, збирає HTML. Це займає час.

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

Інструменти:

• OPcache — кешує скомпільований PHP-код. Має бути увімкнений на будь-якому PHP-сервері.
• Redis / Memcached — кешують результати запитів до бази даних і об'єкти.
• Varnish — HTTP-кеш перед веб-сервером. Може прискорити сайт у рази.
• Плагіни — WP Super Cache, W3 Total Cache, LiteSpeed Cache для WordPress.

Page Cache

Для більшості контентних сайтів (блоги, каталоги, landing pages) повне кешування сторінок — найефективніший метод. Сторінка генерується один раз, а потім віддається як статичний HTML.

Але пам'ятайте: кешування не підходить для сторінок з персоналізованим контентом (кошик, особистий кабінет). Там потрібен інший підхід — кешування фрагментів або AJAX-завантаження динамічних частин.

Причина #5: Повільний сервер

Можна ідеально оптимізувати frontend, але якщо сервер відповідає 2 секунди — сайт все одно буде повільним.

TTFB (Time To First Byte)

Час від запиту до першого байта відповіді. Показує, наскільки швидко реагує сервер. Ідеально — до 200 мс. Якщо більше 600 мс — є проблема.

Високий TTFB може означати:

• Перевантажений або слабкий сервер
• Повільна база даних
• Неоптимізований backend-код
• Сервер географічно далеко від користувачів

Gzip / Brotli стиснення

Текстові файли (HTML, CSS, JS, JSON) можна стискати перед відправкою. Gzip зменшує розмір на 70-80%. Brotli — ще ефективніший для тексту.

Перевірте, чи увімкнено стиснення. У Chrome DevTools (Network → вибрати файл → Headers) шукайте Content-Encoding: gzip або br.

# Увімкнення Gzip в Nginx
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 1000;

Версія PHP

Різниця в продуктивності між версіями PHP — драматична. PHP 8.3 може бути вдвічі швидший за PHP 7.4 на тому самому коді.

База даних

Повільні запити до бази — часта причина високого TTFB. Особливо на сайтах з великою кількістю контенту або складними фільтрами.

Базові кроки:

• Увімкніть slow query log, щоб знайти проблемні запити
• Додайте індекси на поля, по яких відбувається пошук
• Оптимізуйте таблиці (OPTIMIZE TABLE для MySQL)
• Налаштуйте буфери MySQL (innodb_buffer_pool_size)

Хостинг

Дешевий shared-хостинг або VPS — це сотні сайтів на одному сервері. Якщо сусідній сайт/клієнт "з'їдає" ресурси — страждають усі.

Виділений сервер надає гарантовані ресурси. Різниця в швидкості може бути 2-3 рази.

CDN: коли він справді потрібен

CDN (Content Delivery Network) — це мережа серверів по всьому світу, які зберігають копії вашого контенту. Користувач отримує файли з найближчого сервера, а не з вашого основного.

Коли CDN допоможе

• Географічно розподілена аудиторія. Сервер у Нідерландах, а половина користувачів — в Азії? Затримка буде відчутною.
• Багато статичного контенту. Зображення, CSS, JS — все це CDN роздає ефективніше.
• Піки трафіку. CDN може взяти на себе 60-80% навантаження, захищаючи основний сервер.
• DDoS-захист. Більшість CDN (особливо Cloudflare) фільтрують шкідливий трафік.

Коли CDN не потрібен

• Локальний бізнес. Якщо всі користувачі в одній країні, а сервер там само — CDN не дасть помітного приросту швидкості.
• Динамічний контент. CDN кешує статику. Для персоналізованих сторінок він менш ефективний.
• Малий трафік. Накладні витрати на налаштування можуть не окупитись.

З нашого досвіду: якщо ваша аудиторія в одній країні, а сервер поруч — CDN дасть 10-15% приросту за рахунок кешування статики. Справжній ефект (50%+) відчувають проєкти з глобальною аудиторією. Але навіть для локальних сайтів CDN корисний як захист від DDoS та додатковий рівень кешування.

Чекліст: 15 пунктів для перевірки

Швидка самодіагностика. Пройдіться по списку і відмітьте, що вже зроблено:

🖼️ Зображення

• ☐ Зображення стиснуті (TinyPNG, Squoosh)
• ☐ Використовується WebP замість JPEG/PNG
• ☐ Вказані width і height для всіх <img>
• ☐ Lazy loading для зображень нижче першого екрану

💻 Код

• ☐ CSS/JS мініфіковані
• ☐ Критичний CSS інлайново в <head>
• ☐ JavaScript з атрибутом defer або async
• ☐ Видалені невикористовувані плагіни/скрипти

🌐 Сервер

• ☐ Gzip або Brotli стиснення увімкнено
• ☐ PHP версії 8.2+ (рекомендовано 8.3/8.4)
• ☐ OPcache увімкнено
• ☐ Браузерне кешування налаштовано (Cache-Control)

📊 Моніторинг

• ☐ TTFB менше 600 мс
• ☐ Core Web Vitals у зеленій зоні
• ☐ Регулярна перевірка через PageSpeed (щомісяця)

Якщо більше 5 пунктів не виконано — є значний потенціал для покращення.

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

Яка швидкість завантаження вважається нормальною?

Google рекомендує LCP до 2.5 секунди. На практиці: якщо сторінка повністю завантажується за 3 секунди — це добре. За 1-2 секунди — відмінно. Більше 5 секунд — проблема, яку користувачі відчувають.

Чи достатньо встановити плагін кешування?

Це хороший перший крок, але не панацея. Плагін кешування допоможе з серверним навантаженням, але не виправить важкі зображення, render-blocking скрипти або повільну базу даних. Потрібен комплексний підхід.

Сайт швидкий на комп'ютері, але повільний на телефоні. Чому?

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

Чи впливає швидкість на SEO?

Так, напряму. Core Web Vitals — офіційний фактор ранжування Google з 2021 року. Повільні сайти отримують нижчі позиції. Крім того, повільний сайт має вищий bounce rate, що теж негативно впливає на SEO.

Як часто потрібно перевіряти швидкість?

Рекомендуємо щомісяця через PageSpeed Insights. Обов'язково — після оновлень CMS, встановлення нових плагінів або змін на сайті. Швидкість може деградувати поступово, і регулярний моніторинг допомагає це помітити вчасно.

Shared хостинг vs VPS: наскільки велика різниця у швидкості?

Залежить від конкретних провайдерів, але в середньому VPS швидший у 2-3 рази. Головна перевага — гарантовані ресурси. На shared хостингу ваш сайт конкурує з сотнями інших за CPU та RAM.