У вас гарний сайт: добрі тексти, привабливий дизайн, зрозуміла навігація. Але заявок менше, ніж ви очікували. Одна з причин, яку часто не помічають: сторінка завантажується надто повільно — особливо на смартфоні. Звучить банально, але це один із найкраще досліджених зв’язків в онлайн-маркетингу.
Цифри: що показують дослідження, а що ні
- Google (2016): у дослідженні «The Need for Mobile Speed», яке охопило понад 10 000 мобільних сайтів, 53 % мобільних відвідувань переривалися, якщо сторінка завантажувалася довше ніж три секунди. Цифра стара й походить з епохи 3G, але тенденція актуальна й досі: кому доводиться чекати, той іде.
- Deloitte (2020): дослідження «Milliseconds Make Millions», проведене на замовлення Google на даних 37 сайтів брендів, показало: коли мобільна сторінка ставала швидшою на 0,1 секунди, конверсії в роздрібній торгівлі зростали в середньому на 8,4 %, а в туристичних компаній — на 10,1 %.
- Ранжування в Google: Core Web Vitals входять в оцінку зручності сторінки (page experience), яку враховують системи ранжування Google. Релевантність і якість вмісту важать більше, але коли кілька сторінок приблизно однаково корисні, вирішальним може стати якраз хороший користувацький досвід.
Важливо для розуміння: це середні значення, здебільшого великих брендів. Наскільки швидкість вплине саме на ваш бізнес, залежить від галузі, цільової аудиторії та вихідної ситуації. Гарантій тут немає. Але одне зрозуміло: повільна сторінка шкодить двічі. Відвідувачі йдуть ще до того, як побачать вашу пропозицію, а в пошуку такій сторінці складніше.
Що взагалі означає «швидко»?
Google вимірює користувацький досвід під час завантаження за допомогою Core Web Vitals — трьох показників із чіткими пороговими значеннями. Оцінюється 75-й процентиль: щонайменше три з чотирьох переглядів сторінки мають вкладатися в поріг.
| Метрика | Що означає | Добре | Варто покращити | Погано |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Коли стає видимим найбільший елемент вмісту? | ≤ 2,5 с | 2,5–4 с | > 4 с |
| INP (Interaction to Next Paint) | Як швидко сторінка реагує на кліки й введення даних? | ≤ 200 мс | 200–500 мс | > 500 мс |
| CLS (Cumulative Layout Shift) | Наскільки сильно «стрибає» макет під час завантаження? | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Як безкоштовно виміряти швидкість свого сайту
- PageSpeed Insights від Google: угорі показує польові дані реальних користувачів Chrome (якщо у вашого сайту достатньо відвідувачів), а нижче — лабораторну оцінку від 0 до 100 з конкретними порадами щодо покращення.
- Google Search Console: звіт «Core Web Vitals» показує, які групи сторінок не вкладаються в порогові значення.
- GTmetrix: детальна каскадна діаграма (waterfall), яка показує, скільки завантажується кожен файл.
- Chrome DevTools (F12): на вкладці Network видно кожен завантажений файл і його розмір, а на вкладці «Lighthouse» можна запустити вимірювання самостійно.
Для лабораторної оцінки діє власна кольорова шкала Google: 90–100 — добре (зелений), 50–89 — варто покращити (помаранчевий), менше 50 — погано (червоний). Завжди вимірюйте також мобільну версію і робіть це кілька разів, бо окремі вимірювання коливаються. Зрештою вирішальними є польові дані, адже вони показують, що бачать реальні відвідувачі.
Найпоширеніші причини повільних сайтів
Гальма майже завжди ті самі — і більшість із них можна усунути без повного перезапуску сайту.
1. Надто великі зображення
Класика. Фото просто з камери чи смартфона легко важить кілька мегабайтів. На сайті для більшості зображень вистачає значно менше ніж 200 КБ, якщо віддавати їх у сучасному форматі, як-от WebP або AVIF, і в тому розмірі, у якому їх справді показують. Інструменти: Squoosh, TinyPNG або автоматична оптимізація у вашій системі, наприклад компонент зображень у Next.js. Зображення нижче на сторінці можна довантажувати через lazy loading (відкладене завантаження), а от велике зображення на самому верху — ні, інакше погіршиться LCP.
2. Забагато зовнішніх скриптів
Кожен трекер, кожен віджет чату, кожна вбудована карта завантажує додатковий JavaScript. Це забирає пропускну здатність і процесорний час; на старіших смартфонах насамперед страждає швидкість реакції (INP). Регулярно перевіряйте, які скрипти вам справді потрібні. Дещо можна завантажувати лише після кліку, наприклад карту чи відео, — а трекінг і так має запускатися тільки після згоди відвідувача.
3. Немає CDN (Content Delivery Network)
У межах Німеччини відстань до сервера додає лише кілька мілісекунд. Проте CDN однаково варто мати: мережа віддає зображення, скрипти й шрифти з найближчого вузла, гасить пікові навантаження й помітно допомагає, якщо ваш сервер розташований далеко. Серед постачальників — Cloudflare (з безкоштовним стартовим тарифом), AWS CloudFront або мережа вашого хостера. Якщо постачальник працює поза ЄС, до чекліста слід додати й захист даних.
4. Застарілі протоколи передавання даних
HTTP/2 і HTTP/3 передають багато файлів паралельно й швидше, ніж старий HTTP/1.1. Майже всі сучасні хостери підтримують щонайменше HTTP/2. Чи використовує його ваш сайт, видно в Chrome DevTools на вкладці Network у стовпці «Protocol» (значення «h2» або «h3»).
5. Ресурси, що блокують рендеринг
Ідеться про файли CSS і JavaScript, які мають повністю завантажитися, перш ніж браузер узагалі щось покаже. Рішення: спершу завантажувати CSS, потрібний для першого екрана, а решту — згодом; підключати JavaScript з атрибутами «defer» або «async»; обмежити кількість шрифтів і їхніх накреслень.
6. Повільний сервер
Дешевий віртуальний хостинг (shared hosting), відсутність кешування чи WordPress із десятками плагінів призводять до того, що вже перша відповідь сервера триває довго. Цей час називається Time to First Byte (TTFB). Як приблизний орієнтир Google називає щонайбільше 0,8 секунди. Якщо ваш показник значно вищий, кешування, кращий тариф або прибирання плагінів часто дають більше, ніж будь-яка оптимізація зображень.
Як ми працюємо у Vagabov Agency
У наших вебпроєктах швидкодія — частина планування, а не доповнення, яке прикручують наприкінці. У проєктах на Next.js стандартно передбачено:
- автоматичну оптимізацію зображень через компонент зображень Next.js — у сучасних форматах і потрібних розмірах,
- lazy loading для всього, що нижче видимої області,
- статичну генерацію скрізь, де це можливо,
- доставку через CDN,
- вимірювання в Lighthouse і PageSpeed Insights перед запуском і після значних змін.
Базове технічне SEO разом з оптимізацією швидкості завантаження входить у кожен наш пакет сайту, а не йде окремою доплатою.
Що це означає для вашої компанії?
Скільки додаткових заявок принесе швидший сайт, ніхто не може чесно передбачити — і ми теж. Але ви можете виміряти це самі:
- Зафіксуйте вихідні значення: щонайменше чотири тижні записуйте Core Web Vitals ваших найважливіших сторінок і коефіцієнт конверсії, тобто кількість заявок, бронювань чи покупок на 100 відвідувань.
- Усуньте найбільше гальмо: почніть із того, що PageSpeed Insights показує як найбільший потенціал для економії, — найчастіше це зображення або скрипти.
- Порівняйте: подивіться на такий самий за тривалістю період після змін. Зважайте на сезонність і на те, що без згоди відвідувачів ваша статистика фіксує не всі відвідування.
- Продовжити чи зупинитися: якщо ваші показники вже в зеленій зоні, кожна наступна мілісекунда дає дедалі менше. Тоді вигідніше працювати над вмістом і пропозицією.
Як за кілька хвилин перевірити, чи ваш сайт швидший за сайти конкурентів, ми показуємо в статті про порівняння швидкості з конкурентами (німецькою). Технічні подробиці — у статті про технічне SEO та Core Web Vitals у Next.js (німецькою).
Висновок: швидкодія — не технічна дрібниця, а бізнес
Швидкий сайт — не приємний бонус. Швидкість завантаження — один із тих важелів, які найпряміше впливають на користувацький досвід, видимість і кількість заявок. І її можна виміряти до та після того, як ви інвестуєте.
Якщо хочете дізнатися, що гальмує ваш сайт, просто візьміть свої показники PageSpeed на безкоштовну першу консультацію. Там ми обговоримо, які заходи справді варті зусиль у вашому випадку.
