Як сервісній компанії не втрачати клієнтів через повільний сайт

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

Через це частину втрат складно побачити у CRM. Заявка не була створена, дзвінок не відбувся, менеджер не отримав повідомлення. У статистиці залишиться перехід, але причина відмови буде непомітною. Особливо оманливою буває перевірка з офісного комп’ютера: сторінка вже збережена в кеші браузера, інтернет стабільний, а власник бачить сайт зовсім не так, як новий відвідувач із мобільної мережі. На робочому комп’ютері кеш уже «прогрітий», а для клієнта це буде перше, холодне відкриття.

Де саме повільний сайт втрачає звернення

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

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

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

У Google Analytics 4 варто зіставити переходи на сторінки послуг із подіями форм і дзвінків. Записи сеансів у Microsoft Clarity або подібному сервісі покажуть, де користувачі зупиняються, повторно натискають кнопку чи залишають сторінку після довгого очікування. Так легше знайти місце, де трафік наче є, а до заявки люди не доходять.

Перевіряти потрібно не тільки бал PageSpeed

Високий бал у PageSpeed Insights ще не означає, що клієнтові зручно користуватися сайтом. І навпаки, невисока оцінка не завжди свідчить про критичну проблему. Бал — це підказка, а не діагноз. Потрібно дивитися, яка саме частина завантаження забирає час.

TTFB показує, скільки браузер чекає на першу відповідь сервера. Якщо показник стабільно високий на різних сторінках, причина може бути в серверних ресурсах, конфігурації PHP, базі даних або відсутності кешу. LCP стосується появи найбільшого видимого елемента — часто це головний банер, велика фотографія чи заголовний блок. INP допомагає оцінити, наскільки швидко сторінка реагує на натискання, введення даних та інші дії. CLS показує стрибки макета, коли кнопка або текст зміщується вже під пальцем користувача.

Тестуйте не одну, а щонайменше три сторінки: головну, популярну послугу та сторінку з формою або галереєю. Кожну перевіряйте кілька разів у мобільному режимі. Перший і повторний запуск можуть відрізнятися через кеш, а лабораторні результати — від реальної поведінки відвідувачів. У Chrome DevTools корисно відкрити вкладки Network і Console: перша покаже, які файли завантажуються найдовше, друга — помилки скриптів, через які форма або кнопка можуть працювати нестабільно.

Найчастіше гальмує не одна причина, а їхня комбінація

Сайт рідко стає повільним через один-єдиний файл. Затримки накопичуються. Сервер довго формує HTML, браузер завантажує великі зображення, чат чекає відповіді від стороннього сервісу, а CMS паралельно виконує зайві запити до бази даних. Тому стискання фотографій може дати помітне покращення, але не прибрати проблему повністю.

Щоб не шукати причину навмання, розкладіть проблему на три рівні. Перший — сервер: процесор, оперативна пам’ять, диск, PHP та база даних. Другий — CMS: тема, плагіни, кеш, фонові завдання й застарілі модулі. Третій — сама сторінка: зображення, шрифти, карти, відео, чати, аналітика та інші зовнішні скрипти.

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

У WordPress та інших CMS проблеми можуть створювати застарілі плагіни, важка тема, надмірна кількість запитів до бази даних або невдало налаштований кеш. Query Monitor допомагає побачити повільні запити й помилки, але на робочому сайті його не варто тримати активним без потреби. Для глибшої перевірки спеціаліст може переглянути журнали PHP, Nginx чи Apache, а також журнал повільних запитів MySQL — slow query log.

Серверну частину перевіряють у панелі хостингу або через системні інструменти. Командиtopчиhtopпоказують активні процеси,free -m— використання пам’яті,df -h— вільне місце,uptime— середнє навантаження. Окреме число load average без контексту нічого не доводить: його оцінюють разом із кількістю ядер, типом процесів і моментом виникнення проблеми.

Оптимізація навмання — це коли сьогодні стискають картинки, завтра змінюють тариф, а післязавтра вже ніхто не пам’ятає, що саме допомогло.

Після кожної зміни повторюйте однаковий тест і записуйте TTFB, LCP, розмір сторінки, кількість запитів та працездатність форми. Одна зміна — один повторний тест. Інакше навіть успішне покращення важко відтворити, а побічну проблему легко пропустити.

Форма може зламатися, навіть коли сторінка вже відкрилася

Швидко показана сторінка ще не гарантує, що заявка дійде до менеджера. Ланцюжок довший: браузер надсилає дані, серверний обробник приймає їх, поштовий сервіс або CRM передає повідомлення, а менеджер отримує сповіщення. Збій можливий на кожному етапі.

Кнопка може не реагувати через помилку JavaScript. Сервер може повернути код 500, антиспам — 403 або 429, а лист — потрапити до спаму через відсутнє чи неправильне SMTP-налаштування. Іноді зовні все виглядає нормально: користувач бачить зелене повідомлення про успіх, але інтеграція з CRM або Telegram тимчасово не працює. Зелена кнопка ще не означає, що заявка дійшла.

Наскрізний тест проводять зі смартфона й комп’ютера. Надішліть заявку, перевірте повідомлення на сторінці, знайдіть запис у пошті або CRM та звірте час. Потім повторіть надсилання. Такий тест особливо потрібен після оновлення CMS, теми, плагіна форми, антиспаму або кешування.

Якщо заявка не проходить, відкрийте вкладки Console і Network у Chrome DevTools та подивіться, чи немає помилок JavaScript і який HTTP-код повернув запит. Далі перевіряють журнали PHP і вебсервера, журнал поштового надсилання та події CRM. Для технічної підтримки є велика різниця між повідомленням «сайт гальмує» і точним URL, часом помилки, кодом відповіді та коротким описом дії. Чим точніші дані, тим менше доводиться вгадувати.

У сезон сайт може працювати інакше, ніж у звичайний день

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

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

Перед кампанією варто пройти коротку підготовку:

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

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

Коли проблема справді в хостингу, а коли перенесення нічого не змінить

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

Перший тривожний сигнал — високий TTFB одразу на багатьох сторінках. Якщо разом із ним гальмує адміністративна панель CMS, з’являються помилки 502, 503 або 504, а в панелі видно регулярне перевищення CPU, RAM чи процесних лімітів, уже варто дивитися на сервер. До цієї ж групи належать затримки бази даних, нестача дискового простору та різке погіршення роботи під час зростання трафіку.

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

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

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

Практичний порядок дій: від симптому до виправлення

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

1. Назвіть конкретний симптом. Не «сайт повільний», а «сторінка монтажу кондиціонерів довго показує порожній екран» або «форма не реагує після натискання».
2. Повторіть проблему. Перевірте смартфон, комп’ютер, мобільну мережу, режим інкогніто й час, коли виникла затримка.
3. Зніміть базові показники. Подивіться TTFB, LCP, INP, розмір сторінки, кількість запитів і помилки у вкладці Console.
4. Пройдіть шлях заявки. Відкрийте послугу, натисніть номер, заповніть форму й переконайтеся, що повідомлення дійшло до менеджера.
5. Перегляньте ресурси та журнали. Перевірте CPU, RAM, диск, коди 5xx, помилки PHP і повторювані повільні запити.
6. Зробіть одну зміну. Наприклад, оптимізуйте головне зображення або тимчасово вимкніть проблемний віджет.
7. Повторіть той самий тест. Умови мають бути максимально схожими, інакше порівняння втратить сенс.
8. Зафіксуйте результат. Запишіть, що змінили й які показники отримали до та після.
9. Налаштуйте регулярну перевірку. Контролюйте доступність, форми, вільне місце та ключові сторінки перед рекламними кампаніями й сезонними піками.

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

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