Чому сайт на одному VPS завантажується швидше, ніж на іншому аналогічному?

ПартнериПоради

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

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

Принцип роботи гіпервізораVM

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

Різниця в швидкості завантаження сайту на двох однакових VPS найчастіше пояснюється не тарифом на папері, а реальним станом хост-ноди, типом віртуалізації, дисковою підсистемою та мережею. Навіть якщо в обох випадках написано 2 vCPU, 4 GB RAM, SSD, під капотом це можуть бути різні процесори, різні політики шерингу CPU, різні накопичувачі (SATA vs NVMe) і різна пропускна здатність мережі.

Що в принципі може гальмувати ваш сайт?

Для бізнесу важливо розділити це саме повільно відкривається сторінка на такі компоненти: час до першого байта (TTFB), швидкість віддачі статики (картинки/JS/CSS) і час виконання бекенду (PHP/Node/Python) разом із базою даних. На одному VPS у вас може бути блискавичний вебсервер, але повільні запити до БД через I/O — і в браузері це виглядає дуже повільно, особливо коли відкриваєш Network у Chrome. Інший VPS може мати кращий диск, але втрачати час на мережевих затримках або на конкуренції за CPU з сусідами по хосту, яких може бути десятки. Тому причину знайти не дуже легко. Йдемо далі.

CPU, оверсел і крадений час

У VPS процесор — це завжди спільний ресурс: провайдер розподіляє фізичні ядра між багатьма віртуальними машинами, і в пікові години ви можете отримувати менше реального CPU, ніж очікували. У Linux це часто видно через CPU steal time: у top він описаний як час, вкрадений у VM гіпервізором, тобто коли ваша VM була готова виконуватися, але процесор віддали іншому гостю. Таке пограбування зазвичай пов’язане з оверсабскрайбінгом (коли на ті самі фізичні ядра посадили забагато vCPU) і проявляється як непередбачувані стрибки часу відповіді навіть без змін у коді.​

Додатково впливає тип віртуалізації: контейнери зазвичай легші, бо працюють як процеси в одному ядрі, тоді як VM на гіпервізорі має власне ядро й додаткові шари керування ресурсами. Але важливий нюанс: контейнери не завжди швидші в усьому — у дослідженнях різниця може залежати від конкретного навантаження, а в окремих сценаріях контейнери можуть програвати на дискових операціях. Тобто аналогічний VPS у двох провайдерів може відрізнятися не тільки частотою CPU, а й самою моделлю ізоляції, що по-різному б’є по вашому профілю запитів.​

Диск і I/O: де найчастіше ховається причина гальмування?

Для більшості сайтів (CMS, магазини, каталоги, особисті кабінети) вузьким місцем стає не кількість ядер, а затримки диска під базою даних, кешами, логами та сесіями. Тут різниця між SSD та NVMe критична: SATA SSD технологічно впирається приблизно в ~550 MB/s, тоді як NVMe на PCIe 4.0 може давати 7,000 MB/s+ і значно нижчу затримку, що особливо важливо для випадкових (random) операцій БД. У реальних порівняннях це виглядає як різні порядки величин по IOPS і латентності між SATA та NVMe, тому один VPS оживає після міграції без жодних змін у коді — просто тому, що база перестає чекати диск.​

Окремий пласт — як саме організоване сховище у провайдера: RAID-рівень, контролер, чи це локальний NVMe, чи мережевий SSD, формат диска VM (наприклад, qcow2 проти raw) і загальна черга I/O на хості. Зовні ви бачите лише лейбл у тарифі, але всередині це може бути або низька латентність і стабільні IOPS, або красиві цифри без гарантій, які просідають у пікові години.

Мережа, маршрути і географія

Швидкість завантаження — це не лише сервер, а й шлях до користувача: дата-центр, аплінки, піринги, перевантажені маршрутизатори, а також фізична відстань. Два VPS з однаковою конфігурацією, але в різних локаціях, можуть мати різний RTT (ping), а отже — різний TTFB, особливо якщо у вас багато дрібних запитів (API, мікросервіси, зовнішні інтеграції). Навіть усередині віртуалізації мережа може бути реалізована по-різному (додаткові віртуальні свічі, різні драйвери), що додає мілісекунди — а на рівні UX вони швидко накопичуються.

Практичний чекліст для вибору та діагностики

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

• Виміряйте TTFB і повний час відповіді: curl -w "%{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total}\n" -o /dev/null -s https://... (дає розкладку, де саме губиться час).
• Подивіться конкуренцію за CPU: top/htop, звертайте увагу на %st (steal), бо це прямий індикатор того, що вашу VM відсувають у чергу на рівні хоста.​
• Перевірте диск: fio (random read/write), iostat -x (await, %util), ioping (латентність); для БД корисно окремо заміряти час типових запитів.
• Оцініть пам’ять і кеші: чи вистачає RAM під MySQL/PostgreSQL, чи не йде своп, чи налаштований opcache (для PHP), чи адекватні ліміти PHP-FPM/worker-пулів.
• Перевірте мережу: mtr/traceroute до ключових регіонів, швидкість порту (і чи є реальні ліміти), стабільність у пікові години.
• Попросіть у провайдера конкретику, а не маркетинг: тип накопичувача (SATA чи NVMe), чи є гарантія IOPS/throughput, політика оверселу CPU, чи виділені vCPU, чи є обмеження по “noisy neighbor”.

Якщо коротко, то найкраща стратегія — не просто переносити сайт як є, а спочатку відтворити “однаковий стенд” на двох VPS, прогнати однакове навантаження (хоча б 10–20 хвилин), і порівняти: steal time, disk latency/IOPS, TTFB та стабільність.