Чому сайт працює повільно вранці: відповіді на питання про хостинг, які вас дратують

Ви прокидаєтесь, відкриваєте свій сайт з телефону - а він вантажиться так, ніби модем 2003 року вирішив нагадати про себе. Панель керування показує зелені індикатори, провайдер каже «все працює», а клієнти тим часом мовчки йдуть до конкурентів. Знайомо? Тоді ця стаття - для вас. Я зібрав питання, які люди реально задають у чатах підтримки, на форумах і в особистих повідомленнях - і дав на них чесні відповіді без корпоративного цукру.

Чому сайт гальмує зранку, якщо вночі все було чудово

Це одне з найпопулярніших питань, і відповідь на нього банальніша, ніж здається. Ранок - це час пікового навантаження. Люди прокидаються, відкривають браузери, перевіряють пошту, заходять на сайти. Якщо ви на shared-хостингу, уявіть комунальну кухню о восьмій ранку: всі одночасно хочуть зварити каву, а плита одна.

Але не завжди винен хостинг. Ось швидкий чек-лист для самодіагностики:

• Cron-завдання - можливо, ваші щоденні таски (бекапи, імпорт товарів, розсилки) запускаються рівно о 6:00-8:00 і з'їдають ресурси
• Кеш протух - якщо ваш кеш оновлюється щоночі, перший ранковий відвідувач отримує «холодну» сторінку
• БД перевантажена - нічні процеси (індексація, оптимізація таблиць) могли не завершитися до ранку
• CDN не налаштований - весь трафік б'є напряму в один сервер замість того, щоб розподілятися

Що робити? Перенесіть важкі cron-завдання на 3:00-4:00 ночі, додайте прогрів кешу перед піковими годинами, і подивіться на графіки навантаження в панелі. Часто проблема зникає за 10 хвилин налаштувань.

Скільки реально оперативної пам'яті потрібно моєму сайту

«128 МБ вистачить?» - питання, яке я чую щотижня. І щотижня відповідь одна: залежить. Але не в тому розпливчатому сенсі, коли консультант просто не хоче відповідати. Є конкретні орієнтири.

Головне правило: RAM повинна вміщувати вашу базу даних плюс кеш плюс запас 30%. Якщо база важить 800 МБ, а у вас 1 ГБ загалом - MySQL буде постійно скидати дані на диск, і сайт перетвориться на черепаху.

«Найдешевший спосіб прискорити будь-який сервер - додати RAM. Найдорожчий спосіб - ігнорувати, що її не вистачає.» - Brendan Gregg, автор книги «Systems Performance»

Мій хостинг-провайдер каже «проблема на вашому боці» - як перевірити

О, класика жанру. Сайт лежить, ви пишете в підтримку, а вам відповідають: «Сервер працює нормально, перевірте свій код». І ви стоїте на роздоріжжі - чи вірити, чи сваритися.

Ось алгоритм, який розставить все по місцях за 5-10 хвилин:

1. Перевірте статус сервера ззовні - використайте uptimerobot.com, ping.pe або host-tracker.com. Якщо сайт недоступний з різних точок світу - проблема точно не лише у вашому браузері.
2. Подивіться логи помилок - error_log у кореневій папці або в /var/log/. Шукайте записи з міткою часу, що збігається з падінням. PHP Fatal Error = ваш код. Connection refused = сервер.
3. Зробіть traceroute - команда traceroute ваш-домен.com покаже, де саме «ламається» маршрут. Якщо пакети губляться на хопах провайдера - це їхня проблема.
4. Запустіть простий PHP-файл - створіть test.php з одним рядком <?php echo 'OK'; ?>. Якщо він відкривається, а сайт ні - проблема у вашому коді. Якщо і він не відкривається - сервер не в порядку.
5. Перевірте ліміти - зайдіть у панель і подивіться використання CPU, RAM, inodes. Якщо щось на 100% - ви впираєтесь у обмеження тарифу.

Після цих п'яти кроків ви будете розмовляти з підтримкою мовою фактів. А факти - це те, що перетворює розмову з «у нас все працює» на «зараз розберемося».

Чи може хостинг впливати на позиції в Google

Коротка відповідь - так. Довга відповідь - так, але не так, як ви думаєте.

Google прямо заявляє, що Core Web Vitals враховуються при ранжуванні. А три ключові метрики - LCP (найбільший елемент), FID/INP (інтерактивність) і CLS (стабільність верстки) - безпосередньо залежать від швидкості відповіді сервера. Показник Time to First Byte (TTFB) - це фундамент. Якщо сервер відповідає за 800 мс замість 200 мс, жоден кеш на фронтенді вас не врятує.

Що конкретно впливає з боку хостингу:

• Географія сервера - дата-центр у Франкфурті дасть TTFB 40-60 мс для Європи, а сервер у Сінгапурі - 250-400 мс
• Тип диска - NVMe SSD в 5-10 разів швидший за звичайний HDD при читанні бази даних
• Uptime - якщо сайт недоступний під час сканування Googlebot, сторінки випадають з індексу
• HTTP/2 і HTTP/3 - мультиплексування запитів скорочує час завантаження на 20-40%

Переїзд з повільного shared-хостингу на хороший VPS може дати приріст позицій на 5-15 місць для конкурентних запитів - не тому що Google «любить» VPS, а тому що метрики швидкості стають кращими. Я бачив це десятки разів на реальних проєктах.

Що робити, якщо email з хостингу потрапляє у спам

Ви налаштували корпоративну пошту на хостингу, відправляєте рахунок клієнту - а він каже «нічого не прийшло». Перевіряєте - лист лежить у папці Spam. Класика. І ось чому це відбувається.

На shared-хостингу ви ділите IP-адресу з десятками або сотнями інших сайтів. Якщо хоча б один з них розсилає спам, IP потрапляє у чорні списки. І ваші листи летять у смітник разом з ними. Це як жити в будинку, де один сусід влаштував нічний клуб - репутація адреси страждає у всіх.

Що перевірити і виправити:

1. SPF-запис - додайте в DNS запис типу TXT: v=spf1 include:ваш-хостинг.com ~all. Це говорить поштовим серверам, що ваш хостинг має право відправляти пошту від вашого домену.
2. DKIM-підпис - більшість панелей (cPanel, Plesk) генерують його автоматично. Перевірте, що він активний.
3. DMARC-політика - навіть базовий v=DMARC1; p=none; покращить доставку.
4. Перевірте IP у чорних списках - mxtoolbox.com/blacklists.aspx покаже, чи ваша адреса заблокована.
5. Розділіть транзакційну і маркетингову пошту - для масових розсилок використовуйте Mailgun, SendGrid або Postmark, а хостингову пошту - лише для особистого листування.

Якщо після всіх налаштувань листи все одно потрапляють у спам - час переходити на виділений IP або зовнішній поштовий сервіс. Це не капітуляція, це здоровий глузд.

Як зрозуміти, що ви переросли свій хостинг

Це питання, яке люди задають занадто пізно. Зазвичай - коли сайт вже впав під навантаженням, а клієнти вже пішли. Але є чіткі сигнали, які кричать «час переїжджати» задовго до катастрофи.

Сайт сповільнюється у передбачувані години. Щодня о 10:00 і 14:00 сторінки завантажуються вдвічі довше? Це не містика - це ваш тариф не справляється з регулярним навантаженням. Разові сплески - нормально. Щоденні - ні.

Ви постійно вичищаєте диск. Видаляєте старі бекапи, стискаєте логи, оптимізуєте зображення - і все одно місце закінчується через тиждень. Якщо ви витрачаєте на «прибирання» більше 30 хвилин на місяць - хостинг малий.

Підтримка радить оптимізувати код. Коли провайдер третій раз за місяць каже «оптимізуйте запити до БД» - це ввічливий спосіб сказати «ваш проєкт занадто великий для нашого тарифу».

Найнебезпечніший момент - коли все «ніби працює, але повільно». Бо у цей момент ви вже втрачаєте гроші, але ще не відчуваєте болю. За дослідженнями Google, затримка завантаження на 1 секунду знижує конверсію на 7%. Помножте це на ваш місячний оборот - і ви зрозумієте ціну «економії» на хостингу.

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