Коротка відповідь
Повільний сайт майже завжди ламається в одному з двох місць, і їх треба розрізняти:
- Сервер довго думає. Браузер відправив запит і чекає першої відповіді. Вимірюється показником TTFB - часом до першого байта. Більше 600 мс - причина всередині: код сайту, база, версія PHP, вичерпані ліміти тарифу.
- Сторінка важка. Сервер відповів швидко, а сайт усе одно відкривається п'ять секунд, бо тягне 8 МБ картинок і три десятки скриптів. Тариф тут ні до чого - лікується на боці сайту.
Тому перше, що треба зробити, - не міняти хостинг, а поміряти TTFB. Це одна команда і півхвилини часу. Далі за списком нижче: 20 хвилин - і ви знаєте, кому адресувати проблему.
Хостинг винен рідше, ніж на нього думають, - але коли винен, це видно за конкретною цифрою, а не за відчуттями.
Хвилина 1-3. Виміряти, а не відчувати
«Сайт гальмує» - це не діагноз. Відкрийте PageSpeed Insights від Google, вставте адресу сторінки й дивіться на вкладку Мобільні: саме мобільний трафік зараз основний, і саме там усе повільніше.
Цифри, які мають значення:
- LCP - момент, коли з'явився найбільший видимий елемент (зазвичай перше фото чи заголовок). Норма - до 2,5 с;
- INP - наскільки швидко сторінка реагує на натискання. Норма - до 200 мс;
- CLS - чи стрибає верстка під час завантаження. Норма - до 0,1.
Загальний бал у кружечку - річ умовна, за ним не женіться: різницю між 75 і 95 відвідувач не помітить, а от між 30 і 75 - помітить одразу.
Перевіряйте не тільки головну. Гальмує зазвичай не вона, а сторінка товару, каталог із фільтрами чи кошик - там, де найбільше запитів до бази.
Хвилина 4-6. Розділити: сервер чи сторінка
Це головний крок усієї перевірки. Виконайте в терміналі одну команду (у Windows підійде PowerShell або той самий curl):
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://ваш-сайт.com/
Вона нічого не качає, а показує чотири числа в секундах. Ось як їх читати:
| Показник | Що це | Норма | Якщо більше |
|---|---|---|---|
| time_namelookup | пошук IP домену через DNS | до 0,05 с | проблема в DNS-провайдері домену, не в хостингу |
| time_connect | з'єднання з сервером плюс TLS | 0,05-0,15 с | далекий сервер або проблеми з мережею |
| time_starttransfer (TTFB) | сервер подумав і віддав перший байт | до 0,4 с | 0,4-0,8 с - є що чинити; понад 1 с - сайт або сервер у біді |
| time_total | увесь HTML отримано | близько до TTFB | велика різниця - HTML сам по собі надто важкий |
Запустіть команду 3-4 рази поспіль. Перший запуск завжди повільніший - це нормально, далі спрацьовує кеш. Якщо TTFB стабільно тримається під секунду, читайте наступний розділ. Якщо TTFB нормальний, а сайт «на око» повільний - вам у розділ про важку сторінку.
Хвилина 7-10. Якщо довго думає сервер
Чотири речі, які я перевіряю в цьому порядку, і три з них правляться в панелі без сторонньої допомоги.
Версія PHP
Найдешевше прискорення з усіх можливих. На моїх серверах стоїть PHP 8.3 з OPcache, але версію можна перемкнути для кожного домену окремо - і буває, що сайт роками сидить на 7.4, бо колись так поставили. Перехід із гілки 7.x на 8.x на типовому сайті скорочує час генерації сторінки помітно, і це безкоштовно. Єдина умова - перевірити сайт після перемикання: старий плагін чи тема можуть сипати помилками, тоді відкочуєте назад однією дією.
Ліміти ресурсів тарифу
У DirectAdmin є розділ зі статистикою використання: процесор, пам'ять, кількість одночасних процесів. Якщо ви бачите там регулярні впирання в стелю, сайт гальмує не «просто так» - його притримує планувальник. Так само говорять і листи про перевищення ліміту: що вони означають і що з цим робити, я розписав окремо в статті «Перевищено ліміт ресурсів»: що це означає і що робити.
База даних
Друга за частотою причина високого TTFB після відсутнього кешу. На сайті, якому кілька років, у базі накопичується мотлох: ревізії записів, логи плагінів, кинуті кошики, автозавантажувані опції. Сторінка робить 20-60 запитів до бази, і якщо база розпухла - кожен з них дорожчає.
Фонове навантаження
Класика: боти цілодобово перебирають паролі до адмінки, планувальник сайту виконує завдання на заходах відвідувачів, віджет підвантажує курси валют при кожному відкритті сторінки. Процесор витрачається не на відвідувачів, а на це. Якщо TTFB стрибає - то 0,3 с, то 3 с, - шукайте саме тут.
Хвилина 11-14. Якщо довго вантажиться сторінка
Сервер відповів за 0,2 с, а сайт відкривається шість секунд. Тоді відкривайте вкладку Мережа в інструментах розробника браузера (F12), перезавантажуйте сторінку й дивіться на підсумковий рядок: скільки запитів і скільки мегабайтів.
Орієнтир: до 2-3 МБ на сторінку і до 60-80 запитів - нормально. 8 МБ і 200 запитів - ось вам і шість секунд.
Що зазвичай стільки важить:
- Картинки в оригіналі. Найпоширеніша причина взагалі. Фото з телефона - це 4-6 МБ і 4000 пікселів по ширині, а виводиться воно у блоці 800 пікселів. Стиснення й формат WebP зменшують вагу в 5-10 разів без видимої втрати якості.
- Відсутнє відкладене завантаження. Якщо на сторінці 40 фотографій, браузер тягне всі 40 одразу, включно з тими, до яких відвідувач ніколи не долистає.
- Слайдер на першому екрані з п'ятьма важкими фото. Він гарантовано псує LCP, а користуються ним одиниці.
- Чужі скрипти. Онлайн-чат, піксель реклами, карта, віджет відгуків, три системи аналітики - кожен тягне запити до чужих серверів, на швидкість яких ви не впливаєте.
- Шрифти й відео-фон. Чотири накреслення по 200 КБ, які вантажаться раніше за текст, і ролик на 20 МБ у шапці, якого відвідувач із мобільного просто не дочекається.
Хвилина 15-17. Кеш - найдешевше прискорення з усіх
Якщо у вас сайт на CMS і на ньому досі немає кешування сторінок - усе інше можна не читати, почніть із цього. Без кешу кожен захід відвідувача - це запуск PHP, підтягування теми й усіх активних плагінів, десятки запитів до бази і лише потім готовий HTML. Із кешем сторінка віддається як звичайний файл.
Приріст від увімкненого кешу зазвичай більший, ніж від переходу на удвічі дорожчий тариф. Це не фігура мови: тариф додає ядро процесора, а кеш прибирає саму потребу в обчисленні.
Три рівні, які варто мати:
- Кеш сторінок - плагін або налаштування CMS. Головний ефект;
- Кеш браузера - щоб постійні відвідувачі не качали логотип і стилі щоразу заново;
- OPcache на сервері - кешує вже скомпільований PHP-код. У мене увімкнений за замовчуванням, від вас нічого не треба.
Одне застереження: кеш треба скидати після правок - половина звернень «я поміняв текст, а на сайті старий» саме про це.
Хвилина 18-19. Мережа: DNS, географія і Cloudflare
Якщо в команді з розділу вище найбільшим виявилось перше число - time_namelookup понад 0,2 с, - справа не в сайті, а в DNS-серверах, які обслуговують ваш домен. Це рівень реєстратора домену, і переїзд на швидші NS вирішує питання за годину.
Географія важить менше, ніж прийнято думати. Мої сервери стоять у Франції - для української аудиторії це 30-50 мс затримки, тобто величина, яку не відчути на тлі 300 мс генерації сторінки. Відчутна різниця починається, коли сервер стоїть за океаном.
Cloudflare перед сайтом входить у всі тарифи й уже працює. Він розвантажує канал і фільтрує сміттєвий трафік, але не робить швидшим повільний PHP: якщо сторінка генерується дві секунди, вона генеруватиметься дві секунди й за Cloudflare. Це інструмент проти навантаження, а не проти поганого коду.
Хвилина 20. Коли справа таки в тарифі
Буває і так. Ознаки, що ви впираєтесь саме в ресурси, а не в код: сайт помітно повільнішає на піках відвідуваності, у панелі видно постійне навантаження на процесор, з'являються помилки 503, приходять листи про ліміти. Ось чинні плани з ресурсами (ціни за річної оплати):
| Параметр | Старт | Оптимал | Бізнес | Pro |
|---|---|---|---|---|
| Ціна за рік, за місяць | 142 грн | 229 грн | 350 грн | 800 грн |
| Ціна помісячно | 479 грн | 599 грн | 759 грн | 1 119 грн |
| Ядра CPU | 1 | 2 | 3 | 4 |
| RAM | 2 GB | 3 GB | 4 GB | 8 GB |
| NVMe-диск | 10 GB | 20 GB | 30 GB | 100 GB |
| Швидкість підключення | 100 Mbit/s | 200 Mbit/s | 500 Mbit/s | 1 Gbit/s |
| Сайтів | 1 | 3 | 5 | 10 |
| Коли брати | візитка, лендінг | блог із трафіком, 2-3 сайти | магазин | студія, 10 проєктів |
Два уточнення до таблиці. Перше: диск у всіх планах NVMe, а не SATA SSD - на операціях із базою це відчутна різниця, бо база даних читає багато дрібних блоків, і саме там NVMe виграє найбільше. Друге: тариф підвищується без переїзду, сайт лишається на місці, змінюються тільки ліміти - тож починати з меншого плану безпечно. Порівняти всі плани з лімітами можна на сторінці тарифів.
Апгрейд не лікує відсутність кешу і 8 МБ картинок. Якщо TTFB у вас 0,2 с, а сторінка вантажиться шість секунд, старший тариф не змінить нічого - ви заплатите за ядра, які й так простоюють.
Що гальмує найчастіше: мій рейтинг
Те, що я реально бачу на серверах, у порядку спадання частоти:
- Немає кешування сторінок.
- Картинки залиті в оригіналі, без стиснення й без WebP.
- 20+ плагінів, половина з яких не використовується, але вантажиться на кожному заході.
- Стара версія PHP - 7.x там, де давно можна 8.3.
- База, яку жодного разу не чистили: ревізії, логи, автозавантажувані опції.
- Важкий конструктор сторінок, який генерує сотні кілобайтів CSS на просту сторінку.
- Чужі віджети: чат, карта, відгуки, три лічильники.
- Тариф, з якого сайт справді виріс.
Сім із восьми пунктів - це сайт, а не хостинг. Тому я й прошу спершу поміряти TTFB: із пунктами 1-7 проблема переїде на новий хостинг разом із сайтом.
Чек-лист на 20 хвилин
- Прогнати сторінку через PageSpeed Insights, вкладка «Мобільні», записати LCP.
- Перевірити не тільки головну, а й найважчу сторінку - каталог, товар, кошик.
- Поміряти TTFB командою curl, запустити 3-4 рази поспіль.
- TTFB понад 0,6 с - працюємо із сервером і кодом. Менше 0,4 с - працюємо зі сторінкою.
- Подивитись версію PHP у панелі. Якщо там 7.x - перемкнути на 8.3 і перевірити сайт.
- Відкрити статистику ресурсів у DirectAdmin: чи впирається акаунт у ліміти.
- Увімкнути кешування сторінок, якщо його немає. Це найбільший приріст за найменші зусилля.
- Відкрити F12 → «Мережа» і подивитись вагу сторінки. Понад 3 МБ - розбиратись із картинками.
- Прибрати з першого екрана слайдер і відео-фон, стиснути фото, увімкнути відкладене завантаження.
- Вимкнути плагіни й віджети, якими ніхто не користується.
- Поміряти повторно тим самим способом і порівняти з першою цифрою.
Останній пункт - обов'язковий. Без цифри «до» і «після» ви не знатимете, що саме допомогло, і за місяць повернетесь до тієї ж розмови.
Підсумок
Швидкість сайту - це не одна настройка, а два різні шари, які треба розділити перш ніж щось міняти. TTFB показує, чи винен сервер. Вага сторінки показує, чи винен сайт. Двадцять хвилин із секундоміром економлять місяці розмов «мабуть, це хостинг».
Якщо після перевірки виявилось, що сайт справді виріс із поточних ресурсів, - плани з ядрами й пам'яттю є на головній у блоці тарифів, а загальні критерії вибору я розібрав у статті «Як обрати хостинг для сайту у 2026». Якщо йдеться про лендінг і сумніваєтесь, чи потрібен йому окремий тариф, - є окремий розбір.
А якщо цифри отримали, але не розумієте, що вони означають саме у вашому випадку, - напишіть у підтримку в Telegram адресу сайту й ті чотири числа з curl. Подивлюсь і скажу, де саме втрачається час. Якщо потрібен запас на зростання - Оптимал із 2 ядрами і 3 GB RAM закриває більшість сайтів із реальним трафіком.