Чому швидкий сайт — це не тільки хостинг: 10 факторів продуктивності

Коли сторінка відкривається повільно, найпростіше звинуватити хостинг. Іноді причина справді на сервері: бракує процесорного часу, PHP-процеси стоять у черзі, диск перевантажений або проєкт вичерпує доступні ліміти. Але це лише одна ланка. Після відповіді сервера браузер ще має завантажити HTML, CSS, JavaScript, шрифти, зображення, аналітику та інші зовнішні компоненти.

На продуктивність одночасно впливають десять чинників: процесор і пам’ять, дискова підсистема, серверний код, CMS та її розширення, база даних, кешування, зображення, CSS і JavaScript, сторонні сервіси, а також DNS і мережевий маршрут. Нормальний TTFB не гарантує швидкого відображення першого екрана, а високий бал PageSpeed не означає, що сайт однаково добре працює для всіх користувачів. Щоб знайти причину, потрібно перевірити весь ланцюг: сервер, CMS, базу даних, мережу та браузер.

Як з’ясувати, де саме виникає затримка

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

Почніть із діаграми мережевих запитів waterfall у Chrome DevTools на вкладці Network. Перший документ показує, скільки браузер чекав на HTML. Далі видно, які CSS-файли, скрипти, шрифти й зображення завантажувалися найдовше. Для швидкої перевірки серверної відповіді можна використати:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}
Total: %{time_total}
" https://example.com/

TTFB показує час до першого байта, але не момент готовності сторінки. LCP відображає, коли з’явився найбільший елемент першого екрана, INP допомагає оцінити реакцію інтерфейсу, а CLS — зміщення блоків під час завантаження. На практиці сервер може віддати HTML досить швидко, а браузер ще кілька секунд чекатиме великий JavaScript-файл або зовнішній шрифт. Без waterfall тут легко оптимізувати не той рівень.

Симптом, імовірна причина та перша перевірка
Симптом	Імовірна причина	Перша перевірка
Довге очікування до появи HTML	Сервер, PHP або база даних	TTFB, PHP slow log, Query Monitor
HTML отримано, але сторінка ще порожня	Блокувальний CSS або JavaScript	Waterfall і вкладка Performance
Сайт повільний лише під навантаженням	CPU, PHP-FPM або MySQL	Графіки ресурсів і черга процесів
Проблема є лише в окремих регіонах	DNS, маршрут або географія сервера	WebPageTest, MTR, curl timing
Гальмують пошук і фільтри	Повільні SQL-запити	Slow query log і EXPLAIN
Перший перегляд повільний, повторний швидкий	Прогрів кешу або зовнішні ресурси	Заголовки кешу та waterfall

Коли потужніший сервер справді прискорює сайт

Потужніший сервер допомагає лише тоді, коли поточне середовище справді впирається в CPU, оперативну пам’ять, диск або встановлені ліміти. Це часто видно під час пікового трафіку, імпорту товарів, резервного копіювання, масового надсилання листів чи запуску cron-завдань. Якщо ресурс не перевантажений, його збільшення може майже не змінити час відповіді. Перша перевірка — графіки CPU, RAM, swap, disk I/O та черги PHP-FPM у момент сповільнення.

Завантаження процесора перевіряють через top або htop, пам’ять і swap — через free -m, загальний стан системи — через vmstat 1, а дискове очікування — через iostat -x 1. Високий iowait означає, що процеси чекають на диск. Активний swap за дефіциту RAM теж здатен різко погіршити відгук. Якщо всі воркери PHP-FPM зайняті, нові запити накопичуються навіть за помірного навантаження на CPU.

top
free -m
vmstat 1
iostat -x 1

У підтримці це часто виглядає так: власник просить додати пам’ять, але графіки показують вільну RAM, тоді як один PHP-процес довго виконує невдалий запит. Інша типова картина — резервне копіювання створює інтенсивне дискове навантаження, і сайт просідає лише в певний час. Додавати ресурси навмання немає сенсу: спочатку треба побачити, у що саме впирається сайт.

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

Як CMS, тема та плагіни затримують формування HTML

Кількість плагінів сама по собі не показує, наскільки вони сповільнюють WordPress. Один модуль може виконувати важкий SQL-запит, звертатися до зовнішнього API або запускати фонову перевірку на кожному перегляді, тоді як кілька простих розширень майже не впливають на TTFB. Перевірити це можна через Query Monitor або PHP slow log: вони покажуть, який компонент витрачає час на SQL, HTTP-звернення чи виконання PHP.

Підозру викликають сторінки, що довго генеруються навіть без помітного трафіку, повільна адмінпанель, регулярні запити до admin-ajax.php або різке погіршення після оновлення теми. Конструктори сторінок іноді створюють великий DOM, надлишковий CSS і складну серверну логіку. Деякі плагіни перевіряють ліцензію, статистику чи доступність стороннього сервісу ще до формування HTML.

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

Як розпізнати повільні запити до бази даних

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

Перша практична перевірка — slow query log. Він показує запити, які виконуються довше встановленого порога. Конструкція EXPLAIN SELECT ... допомагає побачити, чи використовується індекс і скільки рядків має переглянути MySQL. SHOW FULL PROCESSLIST корисний, коли запити накопичуються або блокують один одного.

SHOW FULL PROCESSLIST;
EXPLAIN SELECT ...;
SHOW TABLE STATUS;

У WordPress окремої уваги потребують автозавантажувані параметри, сесії, ревізії, тимчасові записи та журнали, що роками залишаються в таблицях. Проте кнопка «оптимізувати таблиці» не виправить невдалу структуру запиту. Якщо вибірка читає пів таблиці заради кількох рядків, додаткове ядро проблему не прибере. Результат перевіряють за тривалістю конкретного запиту та часом генерації сторінки до і після змін.

Що кешування прискорює, а що залишає повільним

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

Page cache зберігає готовий HTML. FastCGI cache робить це на рівні вебсервера. Object cache через Redis або Memcached зменшує кількість повторних звернень до бази даних. OPcache зберігає скомпільований PHP-код, а браузерний кеш відповідає за повторне використання CSS, JavaScript, шрифтів і зображень. Це різні рівні, тому встановлення одного кеш-плагіна не означає, що всі вони працюють.

Порівняйте перший і повторний запит, а також заголовки Cache-Control, Age, X-Cache або CF-Cache-Status. Для цього достатньо curl -I https://example.com/. Паралельно переконайтеся, що кошик, кабінет, форми та персоналізовані сторінки виключені з кешування. У зверненнях часто видно дві крайнощі: кеш або не спрацьовує, або зберігає те, що має залишатися індивідуальним.

Чому швидкий TTFB не рятує важкий фронтенд

Низький TTFB не гарантує швидкого відображення сторінки, якщо браузер завантажує великі зображення або довго виконує JavaScript. Проблема особливо помітна на смартфонах і повільних мережах. HTML уже отримано, але перший екран ще порожній, головний банер з’являється із запізненням, а кнопки не реагують через зайнятий main thread.

У DevTools відсортуйте ресурси за Size і Duration. Часто найбільшим файлом виявляється фотографія, завантажена в оригінальній роздільній здатності. Для контентних зображень доречні WebP або AVIF, правильні width і height, а також адаптивні варіанти. Водночас головне LCP-зображення не варто бездумно відкладати через lazy loading: для нього іноді потрібен вищий пріоритет через fetchpriority.

CSS може блокувати рендеринг, а великий JavaScript — надовго займати головний потік. Вкладки Coverage і Performance показують невикористані стилі, тривалі завдання та витрати на виконання скриптів. Атрибути defer і async корисні не для кожного файла: спочатку перевірте залежності й порядок запуску. Сервер уже все віддав, а браузер ще розгрібає фронтенд — таку проблему додаванням RAM не лікують.

Як сторонні сервіси додають неконтрольовану затримку

У waterfall іноді видно дивну картину: власний HTML і зображення вже завантажилися, а сторінка все ще чекає чат, шрифт або систему аналітики. Підключили зовнішній скрипт — додали ще один сервер, DNS і мережевий маршрут, які не контролюєте. Навіть швидкий VPS не скоротить очікування, якщо сторонній домен повільно відповідає або недоступний.

Затримка зовнішнього ресурсу розкладається на DNS lookup, встановлення з’єднання, TLS та очікування відповіді. У DevTools можна відфільтрувати запити за доменом або тимчасово заблокувати підозрілий ресурс через Request Blocking. Якщо без нього сторінка стає відчутно швидшою, причина знайдена.

Не обов’язково видаляти всю аналітику чи функціональні віджети. Частину скриптів можна завантажувати відкладено, шрифти — розміщувати локально, для відео та карт — використовувати легкі фасади, а для потрібних доменів — preconnect. Практичний критерій простий: користь стороннього компонента має виправдовувати додану ним затримку.

Чому сайт працює по-різному в різних регіонах

У власника все працює швидко, а користувачі з іншої країни скаржаться на затримку. У такій ситуації потрібно перевіряти не лише сервер, а й DNS, маршрут, географію та встановлення TLS-з’єднання. Відповідь «у мене відкривається швидко» ще нічого не доводить. Порівнюйте DNS time, connect time, TLS time і TTFB з кількох локацій.

Браузер спочатку визначає IP-адресу, потім встановлює TCP-з’єднання і погоджує TLS. Довгий ланцюжок CNAME, повільний DNS, віддалений дата-центр, невдалий маршрут провайдера або пакетні втрати додають затримку ще до отримання першого байта. Розділити ці етапи допоможе команда:

curl -o /dev/null -s -w "DNS: %{time_namelookup}
Connect: %{time_connect}
TLS: %{time_appconnect}
TTFB: %{time_starttransfer}
" https://example.com/

Маршрут перевіряють через traceroute, tracert або mtr, а швидкість із різних регіонів — через WebPageTest. CDN може скоротити шлях до статичних ресурсів, але не завжди прискорює динамічну генерацію. Також перевірте, чи отримує користувач cache hit на найближчому вузлі, а не щоразу звертається до origin-сервера.

Як оптимізувати сайт за вимірюваннями

Не змінюйте все одразу. Одна правка — одне контрольне вимірювання в тих самих умовах. Коли одночасно встановлюють плагін кешування, змінюють налаштування CDN, стискають зображення та переносять сайт, уже неможливо зрозуміти, що допомогло, а що створило нову проблему.

Зафіксуйте сторінку, пристрій, регіон, стан авторизації та кешу.
Виміряйте TTFB, LCP, вагу сторінки, кількість запитів і тривалі завдання JavaScript.
Перевірте CPU, RAM, swap, disk I/O, ліміти та чергу PHP-FPM.
Знайдіть повільні PHP-операції й SQL-запити через slow logs, Query Monitor та EXPLAIN.
Перевірте page cache, object cache, зображення, CSS, JavaScript і сторонні домени.
Внесіть одну зміну, повторіть тест у тих самих умовах і запишіть результат.

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

Найкращий результат зазвичай дає не один «чарівний» крок, а кілька виправлень у правильній послідовності. Хостинг залишається фундаментом продуктивності, проте реальна швидкість залежить від усього ланцюга — DNS, сервера, PHP, бази даних, кешу, фронтенду та браузера користувача.

Веб-інтеграція сторонніх систем