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

Спочатку ви зафіксуєте базові метрики в браузері: TTFB і поведінку завантаження сторінки за Network Waterfall (водоспадом запитів). Це допомагає розділити проблеми на два класи: затримки до видачі HTML (сервер/застосунок) і затримки після завантаження HTML (ресурси, сторонні скрипти, фронтенд-залежності). Додатково показано, як переперевірити TTFB через curl, щоб отримати більш «чистий» результат.

Далі — практичний профайлінг на рівні CMS (на прикладі WordPress): як за допомогою Query Monitor і вбудованого логування побачити важкі SQL-запити, ресурсоємні хуки/дії та повільні зовнішні HTTP-виклики, а також як зробити простий мікровимір часу обробки запиту. На виході у вас буде набір об’єктивних вимірювань і пріоритетний список дій (наприклад: прибрати/замінити конкретний плагін або хук, оптимізувати найважчий запит, скоротити зовнішні HTTP-інтеграції, увімкнути кешування, полегшити ресурси сторінки).

Вимір швидкості роботи сайту

Швидкість завантаження сайту — це не одне число. Практично розділяти її на два рівні:

• Час відповіді: як швидко сайт починає відповідати на запит (ключове — TTFB).
• Час “до готовності” для користувача: як швидко з’являється і стає придатною до роботи сторінка (зазвичай залежить від ресурсів: зображення, JS/CSS, шрифти, сторонні скрипти).

Нижче — пов’язаний процес: спочатку фіксуємо TTFB, потім за Network “водоспадом” розуміємо, що саме уповільнює завантаження після HTML.

TTFB: що це і навіщо вимірювати

TTFB (Time To First Byte) — час від відправлення запиту до моменту, коли отримано перший байт відповіді. Простіше: скільки часу минає до початку віддачі сторінки.

TTFB допомагає швидко локалізувати джерело затримки:

• TTFB високий → основний час іде до початку передавання відповіді: генерація сторінки в застосунку (PHP), виконання SQL-запитів, кеш не спрацював/скинутий, високе навантаження CPU, затримки по диску (iowait), очікування зовнішніх API/сервісів.
• TTFB низький, але сторінка завантажується довго → затримка виникає після отримання HTML: важкі зображення, багато JS/CSS, шрифти, сторонні віджети, велика кількість запитів до зовнішніх або сторонніх сервісів.

Вимір TTFB у браузері

Цей метод потрібен для швидкого первинного виміру в умовах, максимально наближених до реального користувача, особливо коли немає доступу до SSH або потрібно перевірити проблему з клієнтського боку. Він показує TTFB у контексті браузера (з урахуванням DNS/TLS/маршруту і поведінки кешу), тому допомагає відокремити затримки до видачі HTML (сервер/застосунок) від проблем, що виникають уже після отримання HTML (ресурси/скрипти/фронтенд-залежності).

1. Відкрийте сайт, який вас цікавить, у браузері. Ми рекомендуємо використовувати Google Chrome або Mozilla Firefox.
2. Натисніть F12 → Network.

3. Увімкніть Disable cache (якщо доступно) й оновіть сторінку (Ctrl+R).

4. Виберіть верхній запит типу Document (HTML сторінки).

5. Перейдіть у вкладку Timing і дивіться:

   • Waiting for server response (TTFB) — час до першого байта (аналог time_starttransfer у curl).

• Content Download — час завантаження вже сформованого HTML (аналог значення, що виводиться в curl time_total, але тільки для HTML, без ресурсів сторінки).

Вимір TTFB за допомогою curl

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

curl -o /dev/null -s \
  -H 'Cache-Control: no-cache' -H 'Pragma: no-cache' \
  -w 'TTFB: %{time_starttransfer}\nTotal: %{time_total}\n' \
  https://SITE_DOMAIN/

Що означає вивід:

• TTFB (time_starttransfer) — час до першого байта (коли відповідь почалася).
• Total (time_total) — повний час запиту (включно з отриманням усієї відповіді).

Детальний вимір швидкості сайту в браузері

Після того як HTML отримано, сторінка підвантажує ресурси (зображення, стилі, скрипти, шрифти, API-запити). Вкладка Network показує список запитів і часову шкалу, за якими видно, що саме займає час.

Для зняття виміру виконайте такі кроки:

1. Відкрийте ваш сайт у браузері.
2. Натисніть F12 → Network.

3. Позначте:

   • Disable cache, для виміру швидкості завантаження без впливу браузерного кешу;
   • за потреби Preserve log, щоб список завантажуваних ресурсів не очищався при кожному переході по сайту.

4. Оновіть сторінку за допомогою сполучення клавіш Ctrl+R. Також можна використати і сполучення Ctrl + F5.

Далі ми опишемо параметри, на які варто звернути увагу.

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

• Відсортуйте вміст вкладки Network за колонками Time (Час) і Size (Розмір):

  • Time — які запити займають найбільше часу.
  • Size — що завантажується найбільше за обсягом передаваних мережею даних.

• Зверніть увагу на типи:

  • Img — зображення.
  • JS/CSS — скрипти та стилі.
  • Font — шрифти.
  • XHR/Fetch — AJAX-запити.

Водоспад (Waterfall): де утворюються паузи

Водоспад у DevTools Network — це часова шкала завантаження ресурсів сторінки (HTML, CSS, JS, зображення, шрифти тощо), де кожен запит показано окремою смугою з етапами очікування, встановлення з’єднання та передавання даних. За ним видно, які запити стартують рано, які — пізно, скільки вони тривають і де з’являються «вікна простою», через які сторінка відчувається повільною.

Типові ознаки:

• Довгі смуги у великих ресурсів → велика вага файлу або повільна доставка.
• Багато ресурсів стартують лише після інших → залежність завантаження (блокування, пізнє підключення).
• Довга пауза до старту більшості запитів → підвантаження починається пізно (часто через важкий JS або блокувальні ресурси).

“Ланцюжки” і блокування

Ланцюжки — це ситуації, коли один ресурс не може почати завантаження або виконання, доки не завершиться інший, наприклад, скрипт, який підтягує наступний скрипт, або стилі, без яких браузер відкладає відмальовування. Блокування — приватний випадок таких залежностей: ресурси (частіше JS/CSS або сторонні віджети) затримують критичні етапи, через що контент з’являється пізніше, навіть якщо мережа і сервер працюють нормально.

Шукайте:

• Багато JS/CSS, які завантажуються до відмальовування → затримують появу контенту.
• Сторонні домени (аналітика, чат, віджети) → часто дають помітні затримки.
• Повторювані запити або багато дрібних файлів → зростають накладні витрати на завантаження контенту.

Аналіз продуктивності засобами CMS

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

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

Практична мета — знайти 1–3 ключові вузькі місця, які дають основну частку затримки і найчастіше напряму підвищують TTFB.

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

1. Виберіть 2–4 контрольні сторінки: головна, категорія/каталог, картка товару/запису, пошук, адмінка (якщо є скарги на адмінку).
2. Проведіть базові виміри: TTFB і поведінку завантаження за Network (ці кроки вже розібрані вище).
3. Вмикайте режими діагностики короткочасно і фіксуйте зміни по одному: одна зміна → один повторний вимір.

Загальні принципи аналізу для будь-якої CMS

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

1) SQL-запити до бази даних

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

• шукайте повільні запити (умовно: > 0.1–0.5 секунди)
• шукайте дублювані запити (класична проблема N+1)
• перевіряйте наявність індексів на часто використовуваних полях

2) Логіка застосунку (PHP/Python/інші мови)

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

• які модулі/розширення/плагіни активні
• які функції/обробники займають найбільше часу
• чи є цикли з великою кількістю ітерацій
• чи використовується кешування (page cache, object cache)

3) Зовнішні залежності

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

• HTTP-запити до сторонніх API (платежі, аналітика, інтеграції)
• підключення до зовнішніх сервісів (CDN, пошукові індекси)
• перевірки ліцензій, оновлень, статистики

Інструменти діагностики

Далі завдання просте: знайти джерело даних, яке покаже вам SQL/час/модулі/зовнішні запити.

Приклад аналізу сайту на базі CMS WordPress

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

Query Monitor: основний інструмент

Query Monitor — плагін, який додає панель діагностики й показує інформацію щодо поточного запиту прямо в адмінпанелі.

Насамперед перейдіть у вкладку плагінів.

Натисніть кнопку додавання плагінів.

У рядку пошуку введіть Query Monitor. Щойно пошук буде виконано, натисніть кнопку встановлення плагіна.

Спочатку відкрийте проблемну сторінку й перегляньте «три вітрини»:

• SQL-запити (Queries) — час, повторюваність, джерело (тема/плагін/функція)

• Hooks & Actions — які хуки займають найбільше часу і хто їх додав

• HTTP API calls — зовнішні запити та їхня тривалість

Далі важливо одразу перетворити перегляд на план:

1. Випишіть 1–3 найповільніші/найчастіші SQL-запити та їхнє джерело.
2. Випишіть 1–3 найдорожчі хуки або дії та хто їх додав.
3. Випишіть 1–3 найповільніші зовнішні HTTP-виклики і куди вони йдуть.
4. Зробіть одну зміну (плагін/налаштування/кеш) і повторіть вимір.

Діагностика без плагінів: вбудоване логування

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

У wp-config.php на час діагностики встановіть такі значення:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Після цього записи логу зберігатимуться в wp-content/debug.log. Цей файл зручно використовувати як «журнал фактів», особливо якщо ви додаєте точкові error_log() поруч із проблемними місцями.

Логування SQL-запитів вмикається окремо і лише на короткий час:

define('SAVEQUERIES', true);

Замініть поточний блок секції на розширений варіант нижче (готовий до вставки). Він пояснює де додати і як використовувати.

Точковий мікропрофайлінг у коді

Якщо потрібно швидко оцінити, скільки зайняла обробка запиту загалом (без деталізації за функціями), додайте мінімальні виміри часу і запишіть результат у лог. Це зручно для порівняння «до/після»: вимкнули плагін, увімкнули кеш, змінили налаштування → оновили сторінку → порівняли час у лозі.

Нижче розглянемо два практичні способи, де розмістити цей код: через MU-plugin (краще, бо не залежить від теми) і через functions.php активної теми (швидше в налаштуванні, але менш надійно під час оновлень/зміни теми).

Варіант A (рекомендується): MU-plugin (не залежить від теми)

1. Відкрийте каталог wp-content/.
2. Якщо папки mu-plugins немає — створіть wp-content/mu-plugins/.
3. Створіть файл, наприклад wp-content/mu-plugins/request-timer.php.
4. Вставте код нижче. MU-плагіни підключаються автоматично, активувати в адмінці не потрібно.

<?php
add_action('init', function () {
  // Логуємо тільки для адміністраторів, щоб не створювати зайве навантаження та обсяг логів
  if (!is_user_logged_in() || !current_user_can('manage_options')) {
    return;
  }
  $GLOBALS['t0'] = microtime(true);
}, 0);

add_action('shutdown', function () {
  if (!is_user_logged_in() || !current_user_can('manage_options')) {
    return;
  }

  $t = microtime(true) - ($GLOBALS['t0'] ?? microtime(true));
  error_log('WP request time: ' . $t . ' uri=' . ($_SERVER['REQUEST_URI'] ?? ''));
});
?>

Варіант B: functions.php Скрипти встановленої теми

Файл: wp-content/themes/<ваша-тема>/functions.php (вставляти в кінець файла). Мінус: під час зміни або оновлення теми правка може загубитися.

<?php
// some code...

add_action('init', function () {
  // Логуємо тільки для адміністраторів, щоб не створювати зайве навантаження та обсяг логів
  if (!is_user_logged_in() || !current_user_can('manage_options')) {
    return;
  }
  $GLOBALS['t0'] = microtime(true);
}, 0);

add_action('shutdown', function () {
  if (!is_user_logged_in() || !current_user_can('manage_options')) {
    return;
  }

  $t = microtime(true) - ($GLOBALS['t0'] ?? microtime(true));
  error_log('WP request time: ' . $t . ' uri=' . ($_SERVER['REQUEST_URI'] ?? ''));
});
?>

Як використовувати (процес)

1. Виберіть 2–4 контрольні сторінки (головна, категорія, картка, пошук, адмінка).
2. Відкрийте сторінку 2–3 рази, проведіть базові виміри, кілька разів завантаживши сторінку, що вимірюється, і отримавши середнє арифметичне на підставі записів про час її відкриття з логу.
3. Внесіть одну зміну (наприклад, вимкнули конкретний плагін).
4. Повторіть вимір на тих самих сторінках і порівняйте значення в лозі.

Цей вимір відображає час виконання PHP/WordPress-частини на сервері (приблизно те, що впливає на TTFB), але не включає завантаження ресурсів браузером.

Для перегляду результатів перевірте:

• Якщо ввімкнено WP_DEBUG_LOG — файл wp-content/debug.log.
• Інакше — error log PHP/веб-сервера (залежить від оточення).

Специфіка аналізу інших популярних CMS

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

Joomla

Вбудовані інструменти

Увімкнення: System → Global Configuration → System → Debug System: YES. Після цього Joomla може показувати SQL-запити, використання пам’яті й час виконання, а також список завантажених файлів/розширень.

На що звернути увагу

• кількість і «важкість» модулів на сторінці (особливо якщо модулів багато в шаблоні)
• кешування (System → Global Configuration → System → Cache)
• стиснення та параметри кешу сторінок

Drupal

Інструменти розробника

Найчастіше використовують Devel module (query log, memory usage, execution time). Для детальної панелі — Webprofiler (частина Devel).

На що звернути увагу

• Views і їхнє кешування (часте джерело важких запитів)
• кількість активних модулів
• Twig і кеш компіляції шаблонів

OpenCart

Як підійти до діагностики

Якщо є developer/debug розширення — використовуйте його (пошук у marketplace за словами debug/profiler). Якщо розширень немає, починайте з логів помилок і точкових вимірів навколо проблемних місць.

На що звернути увагу

• кількість модулів/розширень на сторінці
• запити до товарів/категорій (часто N+1)
• сторонні модулі оплати/доставки (зовнішні HTTP-запити)

MODX, PrestaShop та інші

Для інших CMS майже завжди працює однаковий алгоритм:

1. знайдіть в офіційній документації розділи debugging / performance
2. перевірте маркетплейс/каталог модулів на наявність профайлерів
3. увімкніть логування на рівні CMS і короткочасно зберіть дані по 2–4 проблемних сторінках

Вище ми розібрали, як перевести суб’єктивне «сайт повільний» у вимірювані факти: зафіксувати TTFB (у браузері та через curl) і за Network waterfall зрозуміти, де саме формується затримка — до видачі HTML чи після. Якщо TTFB підвищений, наступний крок — підтвердити причини на стороні застосунку/CMS (SQL, хуки/модулі, зовнішні HTTP-виклики) і отримати список конкретних кандидатів на оптимізацію. Нижче — універсальна послідовність дій, яка допомагає не розпорошуватися й швидко дійти до пріоритетних змін.

Універсальний чек-лист для діагностики

Чек-лист допомагає пройти діагностику послідовно: від вимірювань до причин, щоб швидко виділити конкретні вузькі місця та пріоритетні дії.

Крок 1: Базові вимірювання

Спочатку зафіксуйте клієнтські метрики:

• виміряйте TTFB за допомогою браузера або curl
• перевірте послідовність завантаження ресурсів після отримання HTML (Network waterfall)

Крок 2: Увімкніть debug-режим CMS

Далі увімкніть діагностику на стороні CMS/застосунку:

• активуйте вбудований debug/developer mode або підключіть профайлер
• зберіть дані на заздалегідь вибраних контрольних сторінках

Крок 3: Сформуйте список основних джерел затримки

Переведіть проблему в конкретні кандидати:

• 3 найповільніші SQL-запити
• 3 найбільш ресурсоємні модулі/компоненти/плагіни
• зовнішні HTTP-запити (якщо є) із зазначенням тривалості

Крок 4: Перевірте кешування та причини промахів

Важливо оцінити не лише наявність кешу, а й умови, за яких він не застосовується:

• чи активний page cache
• чи активний object cache і query cache, якщо це підтримується CMS
• чи немає факторів, які призводять до частих промахів або скидань (динамічні блоки, авторизація, часті оновлення, відмінні cookie/заголовки)

Крок 5: Пріоритизація та перевірка ефекту

• починайте зі зміни з максимальним очікуваним ефектом
• після кожної зміни повторюйте вимір і порівнюйте з базовою лінією

Висновок

Тепер у вас є відтворювана база вимірювань: TTFB (через DevTools і curl) і розуміння, де формується затримка — до видачі HTML (логіка застосунку, SQL, кешування, зовнішні HTTP-виклики) чи після (ресурси сторінки, шрифти, сторонні скрипти, кількість запитів). Це переводить суб’єктивне «повільно» в конкретні показники, які можна покращувати крок за кроком і перевіряти цифрами.

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

• Оптимізація продуктивності на послугах Хостингу — якщо потрібно сфокусуватися на налаштуваннях CMS, кешуванні, скороченні «важких» плагінів/модулів та оптимізації ресурсів сторінки.
• Оптимізація на послугах VPS/VDS, Dedicated — якщо ви готові заглибитися в налаштування серверного оточення (web-server, PHP-FPM, OPcache), контроль фонових задач і системний моніторинг.
• Оптимізація бази даних — якщо за результатами діагностики основний час іде в SQL: повільні запити, повторювані вибірки, індекси та блокування.

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