Відвідувач не бачить ваших серверів і скриптів — він бачить порожній екран, який ніяк не завантажиться. Кожна зайва секунда очікування дає йому привід закрити вкладку й повернутися до пошуку, а Google враховує швидкість, коли вирішує, яку сторінку показати вище. Добра новина в тому, що причини повільного сайту давно відомі, їх легко виміряти й зазвичай можна виправити без переробки всього проєкту.
Коротко
- Швидкість впливає на те, чи дочекається людина сторінки, чи залишить заявку і наскільки високо сайт стоїть у пошуку Google.
- Найчастіше сайт гальмують важкі зображення, надлишок JavaScript, сторонні віджети, вбудовані відео й повільний хостинг.
- Більшість проблем розвʼязують сучасні формати зображень, відкладене завантаження, CDN, кешування й менше зайвих скриптів.
Чому швидкість — це питання продажів
Шлях до купівлі — це кілька кроків: відкрити сторінку, знайти товар, додати в кошик, оформити замовлення. Повільне завантаження додає паузу до кожного з них, і на кожній паузі частина людей іде. Скарг вони не пишуть — ви просто не отримуєте їхніх заявок.
Найбільше це відчувають мобільні відвідувачі. Слабший процесор і нестабільний звʼязок роблять сайт, який швидко відкривається на компʼютері в офісі, помітно повільнішим на смартфоні.
Є й менш помітний ефект — довіра. Сторінка, яка довго «думає», стрибає під час завантаження чи не реагує на натискання, виглядає ненадійною. Людина, яка вагається, чи довірити вам дані своєї картки, такий сигнал помічає одразу.
Як Google оцінює швидкість: Core Web Vitals
Google вимірює досвід відвідувачів трьома ключовими показниками, які називає Core Web Vitals, і враховує їх серед сигналів ранжування. Ось ці показники та пороги, які Google вважає добрими:
- LCP (Largest Contentful Paint) — за скільки зʼявляється найбільший видимий елемент першого екрана, зазвичай головне зображення чи заголовок. Добре — до 2,5 секунди.
- INP (Interaction to Next Paint) — як швидко сторінка реагує на натискання, введення тексту чи відкриття меню. Добре — до 200 мілісекунд.
- CLS (Cumulative Layout Shift) — наскільки «стрибає» вміст під час завантаження: наприклад, кнопка зсувається саме тієї миті, коли ви на неї натискаєте. Добре — до 0,1.
Google орієнтується на дані реальних відвідувачів: показник вважається добрим, якщо поріг досягнуто щонайменше в 75 % відвідувань. Швидкість не замінить корисного змісту, але коли схожих корисних сторінок багато, кращий досвід користувача може дати перевагу саме вашій.
Що найчастіше гальмує сайт
Перше місце майже завжди посідають зображення. Фото з камери чи фотостоку завантажують на сайт як є, на кілька мегабайтів, хоча на екрані воно займає лише кількасот пікселів. Телефон через це обробляє набагато більше даних, ніж потрібно.
Друге — JavaScript. Сайти часто підключають великі бібліотеки заради однієї анімації чи слайдера. Поки браузер завантажує й виконує цей код, сторінка не реагує на дії користувача, а це безпосередньо погіршує INP.
Третє — сторонні віджети й трекери: онлайн-чати, рекламні пікселі, аналітика, кнопки соцмереж. Кожен завантажує власні скрипти з чужих серверів, на швидкість яких ви не впливаєте. З роками їх стає дедалі більше, і навіщо потрібна частина з них, уже ніхто не памʼятає.
Ще дві типові причини — вбудовані відео й повільний хостинг. Плеєр YouTube чи Vimeo завантажує чималий обсяг коду ще до того, як хтось натисне «відтворити». А якщо сервер довго відповідає на перший запит, інші оптимізації компенсують цю затримку лише частково.
Як пришвидшити сайт
Для більшості сайтів працює той самий набір рішень:
- Сучасні формати зображень. WebP і AVIF за тієї ж якості зазвичай важать помітно менше, ніж JPEG чи PNG, а розмір картинки має відповідати екрану.
- Відкладене завантаження (lazy loading). Зображення нижче першого екрана завантажуються, лише коли користувач прокручує до них сторінку. Головне зображення першого екрана, навпаки, завантажується одразу.
- Мережа доставки контенту (Content Delivery Network, CDN). Копії файлів зберігаються на серверах у різних регіонах, і відвідувач отримує їх із найближчого.
- Кешування. Браузер і сервер зберігають готові файли й сторінки, щоб не створювати їх наново для кожного візиту.
- Менше JavaScript. Невикористані бібліотеки й віджети прибирають, а другорядні скрипти завантажують після основного вмісту.
- Відео за кліком (click-to-play). Замість плеєра сторінка показує легку заставку, а сам плеєр завантажується після натискання.
Якщо сервер і після цього відповідає повільно, проблема в хостингу або в серверному коді. Простий спільний хостинг підходить для сайту-візитки, але магазину з реальним трафіком зазвичай потрібно більше ресурсів.
Як виміряти швидкість
Почніть із безкоштовного інструмента Google PageSpeed Insights. Він показує два види даних. Лабораторні — це один тестовий запуск на змодельованому пристрої, який допомагає знайти причини. Дані реальних користувачів (field data) показують досвід ваших відвідувачів за останні тижні, і саме на них орієнтується Google.
Дані реальних користувачів зʼявляються, лише коли сайт має достатньо відвідувачів. Загальну картину дає звіт Core Web Vitals у Google Search Console: він групує сторінки за статусом окремо для мобільних і компʼютерів.
Оцінюйте результат за реальними даними, а не за одним тестом. Вони оновлюються із затримкою, тож ефект від виправлень видно не наступного дня, а через кілька тижнів.
Чек-лист
- Перевірте ключові сторінки в PageSpeed Insights окремо для мобільних і компʼютерів.
- Відкрийте звіт Core Web Vitals у Search Console й знайдіть сторінки з поганими показниками.
- Конвертуйте зображення у WebP або AVIF і зменште їх до реального розміру на екрані.
- Увімкніть відкладене завантаження для всього, що нижче першого екрана.
- Приберіть сторонні скрипти й віджети, якими вже ніхто не користується.
- Замініть вбудовані відео на заставки із запуском за кліком.
- Підключіть CDN і кешування, а якщо сервер відповідає повільно, перегляньте хостинг.
Як ми це робимо в IANKO
Ми закладаємо швидкість у проєкт ще на етапі дизайну, а не латаємо її після запуску. Дизайнери продумують перший екран, шрифти й зображення так, щоб сторінки залишалися легкими, технічний директор (CTO) відповідає за архітектуру й хостинг, а QA-інженери та тестувальники перевіряють сайт на реальних телефонах і з повільним інтернетом перед кожним релізом. Після запуску, на етапі «Робити краще», ми стежимо за реальними даними Core Web Vitals і виправляємо те, що заважає вашим відвідувачам.
Підсумок
Швидкий сайт не продає замість вас, але й не заважає продавати: людина бачить товар, а не порожній екран. Почніть із PageSpeed Insights і звіту в Search Console — вони покажуть, які сторінки гальмують і з чого почати.