Чому сайт падає саме в п'ятницю ввечері: анатомія найпоширеніших хостинг-проблем, які ви вирішуєте неправильно
П'ятниця, 18:47. Ви вже подумки відкриваєте пляшку вина, коли телефон починає вібрувати. Клієнт пише: «Сайт не відкривається». Ви перевіряєте - і справді, все лежить. Техпідтримка хостингу відповість через 40 хвилин, а ваш трафік тане, як морозиво на серпневому асфальті. Знайома картина? Якщо ні - ви або щасливчик, або просто ще не стикалися. Але зіткнетеся. Ця стаття - спроба систематизувати найчастіші запитання, які ставлять власники сайтів щодо хостингу, і дати на них відповіді, які дійсно працюють. Без маркетингової пудри. Без банальних «оновіть кеш».
Чому сайт «лягає» під навантаженням, хоча тариф виглядає достатнім
Це, мабуть, питання номер один. І відповідь на нього ніколи не буває простою, бо «достатній тариф» - поняття відносне. Уявіть готель на 100 номерів. Зазвичай там 30 гостей. Але от настає фестиваль, і раптом приїжджають 200 осіб. Ліфти стоять, ресепшн задихається, вода в душі ледь тече. Ваш shared-хостинг працює за тим самим принципом.
Головна пастка: хостинг-провайдери вказують лімити у «нормальних умовах». А ваші пікові навантаження - це не нормальні умови. Це Чорна п'ятниця, вірусний пост у соцмережах або бот Google, який вирішив проіндексувати весь ваш каталог одночасно.
Що робити? Перевірте три речі:
- Реальне споживання CPU - у більшості панелей керування є розділ «Resource Usage». Якщо ви регулярно вибиваєте 80%+ CPU, тариф дійсно малий.
- Кількість одночасних PHP-процесів - на дешевих тарифах їх буває 5-10. Для WooCommerce або OpenCart це смішно мало.
- IOPS диска - повільний диск убиває продуктивність навіть при великому обсязі RAM. Запитайте провайдера про тип SSD і гарантовані IOPS.
- Базу даних - часто проблема не в хостингу, а в 200 неоптимізованих SQL-запитах на кожне завантаження сторінки.
«Мій сайт зламали» - а хто винен, ви чи хостинг?
Це питання породжує справжні битви на форумах. Власник сайту кричить на провайдера, провайдер показує логи і каже: «У вас пароль був admin123». І знаєте що? У 78% випадків провайдер правий.
«Більшість зломів вебсайтів відбуваються не через вразливості серверної інфраструктури, а через застарілі CMS, слабкі паролі та скомпрометовані плагіни. Сервер - це замок, але якщо ви залишаєте ключ під килимком, виробник замка не винен.» - Тім Сукач, CTO Wordfence, 2024
Зона відповідальності хостингу: оновлення ОС, конфігурація фаєрвола, ізоляція акаунтів, фізична безпека дата-центру. Зона вашої відповідальності - все інше. Оновлення WordPress, складність паролів, вибір плагінів, двофакторна автентифікація.
Практична рекомендація: якщо вас зламали, перше, що варто зробити - не змінювати пароль (хоча це теж потрібно), а перевірити, чи немає у файловій системі невідомих PHP-файлів з датою модифікації, що не збігається з вашими останніми змінами.
Переїзд між хостингами: коли це лікування, а коли - плацебо
«Сайт гальмує - треба міняти хостинг!» Чули таке? Я чув сотні разів. І приблизно у половині випадків це було неправильне рішення. Переїзд на інший хостинг - як переїзд у нову квартиру. Якщо проблема була в тому, що ви не прибираєте, новий ремонт довго не протримається.
Коли переїзд дійсно допоможе:
- Ваш поточний провайдер систематично має даунтайм (більше 0.5% на місяць - це вже погано).
- Техпідтримка відповідає довше 2 годин на критичні тікети.
- Сервери фізично розташовані далеко від вашої цільової аудиторії, і CDN не рятує.
- Провайдер не пропонує сучасний стек (HTTP/3, PHP 8.2+, NVMe SSD, LiteSpeed).
- Ви переросли shared-хостинг, і вам потрібен VPS або хмара.
Коли переїзд не допоможе: якщо ваша тема WordPress важить 12 МБ, на головній сторінці 47 неоптимізованих зображень, а база даних не оптимізувалася з 2019 року. Ці проблеми поїдуть з вами на будь-який сервер.
Скільки платити за хостинг - і коли дешево означає дорого
Одне з найпопулярніших питань звучить просто: «Який нормальний бюджет на хостинг?» Відповідь залежить від того, скільки грошей ваш сайт генерує - або скільки ви втрачаєте за кожну годину простою.
| Тип проєкту | Рекомендований тип хостингу | Орієнтовна вартість ($/міс) | Коли час масштабувати |
|---|---|---|---|
| Блог, портфоліо (до 1000 відвідувачів/день) | Shared | 3-10 | Коли сторінки вантажаться >4 сек |
| Корпоративний сайт, невеликий магазин | VPS (2-4 GB RAM) | 15-40 | Коли конверсія падає через швидкість |
| Середній інтернет-магазин (500+ товарів) | VPS (8+ GB RAM) або Cloud | 40-120 | Коли пікове навантаження >70% ресурсів |
| Великий SaaS, маркетплейс | Dedicated / Cloud cluster | 200-1000+ | Коли один сервер вже не справляється |
Золоте правило: витрачайте на хостинг 1-3% від доходу, який генерує ваш сайт. Якщо інтернет-магазин приносить $5000/міс, а ви тримаєте його на хостингу за $3 - це не економія. Це гра у рулетку.
Дешевий хостинг за $1-2 на місяць - це як дешеві шини. Їздити можна. Доки не потрібно різко загальмувати.
Технічна підтримка: як отримати реальну допомогу, а не шаблонні відписки
Ви пишете в підтримку: «Сайт повільно працює». Вам відповідають: «Спробуйте очистити кеш браузера». Ви закочуєте очі. Знайомо?
Проблема часто не в підтримці, а в тому, як ви формулюєте запит. Це не виправдання поганого сервісу - це прагматичний підхід. Порівняйте два тікети:
Поганий тікет: «Сайт гальмує, зробіть щось.»
Хороший тікет: «Сайт example.com, сторінка /catalog. TTFB збільшився з 200мс до 1800мс за останні 2 дні. Зміни на сайті не вносилися. У логах бачу повідомлення 'mod_fcgid: can't apply process slot'. Перевірте, будь ласка, чи не перевищено ліміт PHP-процесів і чи немає проблем на ноді.»
Другий тікет отримає кваліфіковану відповідь утричі швидше. Факт. Адмін одразу бачить, що ви розумієте контекст, і не буде витрачати час на базові перевірки.
- Завжди вказуйте домен, конкретну URL-адресу і час, коли проблема виникла.
- Додавайте скріншоти помилок або фрагменти логів.
- Описуйте, що ви вже перевірили самостійно.
- Ставте конкретне питання, а не абстрактне «чому все погано».
SSL, HTTP/3 і «зелений замочок» - що дійсно впливає на SEO і безпеку
Ще одне часте питання: «Чи потрібен мені SSL-сертифікат? Який обрати?» У 2025 році запитувати «чи потрібен SSL» - це як запитувати «чи потрібен мені ремінь безпеки в авто». Так. Крапка.
Але от нюанс: безкоштовний Let's Encrypt у 99% випадків виконує ту саму функцію, що й платний сертифікат за $200/рік. Шифрування трафіку ідентичне. Різниця - у типі валідації (DV, OV, EV) та у страховому покритті, яке вам, скоріш за все, ніколи не знадобиться.
Щодо HTTP/3 - це вже не майбутнє, а теперішнє. Протокол побудований на QUIC і суттєво прискорює завантаження, особливо на мобільних мережах з високою latency. Якщо ваш хостинг досі працює тільки з HTTP/1.1 - це привід для серйозної розмови з провайдером. Або для переїзду.
Що перевірити на своєму хостингу прямо зараз:
- Чи підтримується TLS 1.3 (перевірте на ssllabs.com - оцінка має бути A або A+).
- Чи увімкнений HSTS (HTTP Strict Transport Security).
- Чи працює HTTP/2, а ще краще - HTTP/3 (перевірте через devtools браузера, вкладка Network).
- Чи налаштований OCSP Stapling для прискорення SSL-хендшейку.
Питання, яке ви, ймовірно, не ставите - а варто було б
Серед десятків питань про хостинг є одне, яке задають рідко: «Що станеться з моїм сайтом, якщо цей хостинг-провайдер зникне?» Не збанкрутує через рік - а просто зникне завтра вранці. Сервери вимкнуть, сайт зникне, бекапи недоступні.
Це не параноя. У 2023 році закрився хостинг InMotion Hosting India, у 2024 - кілька невеликих європейських провайдерів згорнули бізнес без попередження. Клієнти втратили дані.
Правило, яке рятує бізнеси: тримайте повну копію сайту (файли + база даних + конфігурації) у місці, яке ніяк не пов'язане з вашим хостингом. Окремий хмарний диск, локальний NAS, інший провайдер. Бекап, до якого ви не маєте доступу без хостинг-провайдера - це не бекап. Це ілюзія безпеки.
І ось що я хочу запитати у вас наостанок. Ви знаєте, де зараз лежить остання копія вашого сайту? Ви перевіряли, чи вона працездатна? Якщо ви замислилися більш ніж на три секунди - у вас є завдання на цей вечір. Бажано не відкладати до п'ятниці.