Швидкість сайту: як перевірити за 10 хвилин і що з цього справді впливає

Швидкість сайту перевіряють двома безкоштовними інструментами Google: PageSpeed Insights показує окрему сторінку, звіт Core Web Vitals у Search Console показує весь сайт. Дивитись треба на дані реальних користувачів на мобільному: LCP до 2,5 секунди, INP до 200 мілісекунд і CLS до 0,1. Якщо всі три зелені, швидкість не ваша проблема, навіть коли загальний бал PageSpeed жовтий.

Справді впливає одне: чи проходять ці три показники поріг Google. На мобільному найчастіше не проходить LCP, а серед причин повільності найчастіші три: важкі зображення, сторонні скрипти і повільний сервер. На позиції швидкість впливає, але релевантність сторінки важливіша, тому бал заради балу не окупається. Інші статті про технічну базу і пошук зібрані в темі «Сайт і SEO».

Чим міряти і які цифри нормальні

Міряти треба в PageSpeed Insights і Search Console, а нормою вважати пороги Google для Core Web Vitals. Core Web Vitals це три показники досвіду реальних відвідувачів: LCP (як швидко зʼявився найбільший елемент першого екрана), INP (як швидко сторінка реагує на натискання) і CLS (наскільки зсувається верстка). З 12 березня 2024 року INP замінив FID, тож інструкції з FID застаріли.

Сторінка проходить оцінку, коли всі три показники зелені для 75 % відвідувань, окремо для мобільних і для десктопу. Перевірка за 10 хвилин:

1. PageSpeed Insights, головна, мобільна вкладка (3 хв). Верхній блок це дані реальних користувачів Chrome за останні 28 днів і вердикт Core Web Vitals Assessment. Нижче бал від 0 до 100: це результат одного завантаження на симульованому телефоні середнього рівня, він потрібен для пошуку причин.
2. Те саме для головної сторінки послуги чи товару (2 хв). Внутрішні сторінки часто завантажуються інакше, ніж головна: інший шаблон, інші зображення і віджети.
3. Звіт Core Web Vitals у Search Console, мобільні (3 хв). Скільки адрес у статусах «погано» і «потрібно покращити» і через який показник. Звіт групує схожі сторінки, тож видно, проблема в одному шаблоні чи всюди. Як читати інші звіти, розібрано в статті про Search Console.
4. Ваш телефон на мобільному інтернеті, не на Wi-Fi (2 хв). Що зʼявляється останнім, що стрибає, чи одразу відкривається меню.

Якщо PageSpeed пише, що даних реальних користувачів недостатньо, для малого сайту це нормально: сторінка має набрати достатньо візитів у Chrome. Тоді звіт у Search Console, найімовірніше, теж буде порожнім, і лишаються лабораторний тест та ваш телефон.

Три речі, які гальмують найчастіше

Найчастіше гальмують зображення, сторонні скрипти і сервер. На це вказують дані Web Almanac 2025 від HTTP Archive: на мобільному гарний LCP мають 62 % сайтів проти 77 % для INP і 81 % для CLS, а елементом LCP у 76 % мобільних сторінок є зображення.

Важкі зображення. На медіанній мобільній головній сторінці зображення важать 911 КБ, тоді як Search Console радить тримати всю сторінку разом з усіма ресурсами до 500 КБ. Окрема пастка: 16–17 % сторінок вмикають відкладене завантаження (lazy loading) для головного зображення, хоча Google прямо радить ніколи так не робити, бо це завжди затримує LCP. Базова перевірка LCP і що робити з важкими фото розписані в пункті 3 технічного аудиту сайту за годину, тут не повторюю.

Сторонні скрипти. Чат-віджети, пікселі, вбудовані відео і стрічки Instagram, конструктори форм. Сторонні ресурси є щонайменше на 90 % сторінок. Поки браузер завантажує і виконує скрипт, головний потік зайнятий, і сторінка пізніше реагує на натискання (INP), а вбудований блок без заданого розміру зсуває верстку (CLS). Google окремо радить не тримати одну функцію від двох постачальників, наприклад два менеджери тегів чи дві системи аналітики.

Повільний сервер і перевантажена платформа. TTFB це час до першого байта відповіді сервера, орієнтир Google до 0,8 секунди. За тим самим Web Almanac, гарний TTFB мають лише 44 % мобільних сайтів. На WordPress на нього впливають кількість і якість плагінів та тема, а спільний хостинг, за словами Google, зазвичай повільніший.

Що можна виправити без розробника

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

• Зображення до завантаження на сайт. Зменште кожне фото до ширини, в якій його показують, і збережіть у WebP або AVIF: за документацією Google ці формати стискають краще за JPEG і PNG. На першому екрані краще одне фото, ніж слайдер із пʼяти.
• Ревізія сервісів. Відкрийте список підключених віджетів і кодів (у налаштуваннях конструктора чи в Google Tag Manager) і приберіть те, чим не користувались три місяці: старий піксель, другий лічильник, чат без звернень.
• Вбудовані відео і стрічки соцмереж. Замініть їх картинкою з посиланням на YouTube чи Instagram.
• Налаштування платформи. Якщо конструктор чи CMS має опції стиснення зображень, кешування чи відкладеного завантаження скриптів, увімкніть їх і перевірте сторінку ще раз.

Умовний приклад бюджету ваги. Орієнтир Search Console: до 500 КБ на сторінку з усіма ресурсами. Шрифти, стилі і скрипти простого лендингу умовно беремо за 250 КБ, на зображення лишається 250 КБ. Головному фото віддаємо 100 КБ, чотирьом іншим по 35–40 КБ (150 КБ поділити на 4). Навіть одне фото з телефона на 3–4 МБ у цей бюджет не вміщується: його треба зменшити в 30–40 разів, щоб вийти на 100 КБ.

Що дає правильне завантаження головного зображення на реальних сайтах, показує кейс платформи інтернет-магазинів Nuvemshop, опублікований на web.dev у 2026 році. Проблема там була не у вазі фото: розробники платформи серед інших змін прибрали відкладене завантаження із зображень першого екрана і дали їм пріоритет, і за рік частка магазинів із гарним LCP зросла з 57 % до 96 %. Конверсія мобільних відвідувачів з органічного пошуку Google в оплачене замовлення в тих самих бразильських магазинах у січні 2026 року була на 8,9 % вищою, ніж у січні 2025-го; це порівняння двох періодів, а не A/B-тест.

Після змін запустіть PageSpeed ще раз. Лабораторний бал зміниться одразу, а дані реальних користувачів оновлюються поступово, бо охоплюють 28 днів.

Коли швидкість не є вашою проблемою

Швидкість не ваша проблема, коли три показники реальних користувачів уже зелені. Google прямо пише, що гарний результат у звіті Core Web Vitals не гарантує топ, а гонитва за ідеальним балом заради SEO може бути не найкращим використанням часу. У Lighthouse підйом балу з 99 до 100 потребує приблизно такого самого покращення показників, як із 90 до 94.

Звʼязок із грошима при цьому реальний: у кейсі, опублікованому Google, Vodafone в A/B-тесті лендингу покращила LCP на 31 % і отримала на 8 % більше продажів. Але це великий сайт із платним трафіком. На сайті з кількома заявками на тиждень різницю у 8 % не видно, тому спершу виключіть інші причини.

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

Конверсія низька однаково на мобільному і десктопі? Тоді швидкість навряд чи винна, і причину шукають у трафіку чи пропозиції, як у розборі конверсії сайту в 1 %.

Сама перевірка за 10 хвилин погано працює для сайтів із кількома десятками візитів на тиждень: даних реальних користувачів, найімовірніше, немає, а лабораторний бал коливається від запуску до запуску навіть без змін на сайті (серед причин Google називає мережу, обладнання, на якому йде тест, рекламу й A/B-тести на сторінці). Тут швидкість оцінюють грубо, «повільно чи ні на телефоні», і переходять до трафіку. Якщо незрозуміло, що саме гальмує продажі, це розбираємо на консультації для бізнесу.

Що передати розробнику

Розробнику передають не «пришвидшіть сайт», а сторінку, показник із цифрою, ціль і спосіб приймання. Шаблон задачі з умовними значеннями:

До старту попросіть оцінку в годинах і перелік змін: стиснення і пріоритет головного зображення, відкладене завантаження сторонніх скриптів, перевірка TTFB і кешування. Ціль формулюйте через Core Web Vitals, а не через бал PageSpeed.

Часті помилки

Ганятися за 100 балами. Google називає бал 100 надзвичайно складним і таким, якого не очікують. Ціль це зелені Core Web Vitals.

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

Порівнювати два окремі запуски. Бал коливається без змін на сайті. Запустіть тест кілька разів і дивіться на тенденцію.

Вмикати lazy loading для всіх зображень. Для головного фото першого екрана це гарантовано погіршує LCP.

Перевіряти на своєму телефоні через офісний Wi-Fi. Ваші клієнти відкривають сайт через мобільний інтернет і, можливо, на слабшому пристрої.