Швидкість завантаження сайту: як перевірити та покращити

Швидкість завантаження сайту: як перевірити та покращити

Розмова про швидкість сайту зазвичай починається з балу в PageSpeed Insights. Власник бачить 43 з 100 на мобільному, червону зону і робить висновок: ось вона, причина всіх проблем. Іноді так і є. Значно частіше — ні.

Google оцінює не бал, а поведінку сторінки у реальних користувачів: як швидко з’являється основний контент, як швидко сторінка реагує на натискання і чи не «стрибає» макет під пальцем. Бал у PageSpeed — це лише симуляція, яка допомагає знайти причини. Оцінює вас не вона.

Розбираємо, що саме вимірюється, як прочитати дані правильно і що виправляти в першу чергу, щоб не витрачати бюджет розробки на речі, які нічого не змінять.

Що Google називає швидкістю: три метрики Core Web Vitals

Замість абстрактного «час завантаження» використовуються три показники. Вони вимірюються на реальних відвідувачах Chrome, а сторінка вважається успішною, якщо у 75% візитів показник потрапив у «добру» зону. Дані беруться за останні 28 днів.

LCP (Largest Contentful Paint) — за скільки секунд з’являється найбільший видимий елемент сторінки: головне зображення, банер, великий заголовок. Добре — до 2,5 секунди. Погано — понад 4 секунди.

INP (Interaction to Next Paint) — наскільки швидко сторінка реагує на дії: натиснули кнопку меню, розгорнули фільтр, відкрили карточку. Добре — до 200 мілісекунд. Ця метрика замінила стару FID у 2024 році, тож якщо ви читаєте матеріал зі згадкою FID — він застарілий.

CLS (Cumulative Layout Shift) — чи не зсувається верстка під час завантаження. Класичний випадок: користувач тягнеться до кнопки, у цю мить дозавантажується банер, кнопка з’їжджає вниз, палець потрапляє не туди. Добре — до 0,1.

Ці три метрики входять до сигналів page experience. Вони працюють як фактор, що спрацьовує на межі: між двома сторінками з однаково релевантним контентом перевагу отримає швидша. Але вони не піднімуть сторінку, яка не відповідає на запит.

Чому бал 100 нічого не гарантує

У PageSpeed Insights є два різні блоки даних, і їх постійно плутають.

Польові дані (зверху, якщо вони є) — реальні візити реальних користувачів за 28 днів. Саме за ними Google оцінює сторінку.

Лабораторні дані (бал від 0 до 100 і список рекомендацій) — симуляція одного завантаження на умовному пристрої з повільним інтернетом. Це діагностика, а не оцінка.

Звідси два практичні наслідки. Перший: сайт може мати бал 62 і при цьому проходити Core Web Vitals, бо реальні користувачі заходять з нормальних пристроїв і мережі. Другий: сайт може мати бал 95 і провалювати LCP, бо лабораторний тест не бачить того, що бачать люди у справжніх умовах.

Якщо польових даних немає взагалі — у сторінки просто замало трафіку для статистики. Тоді орієнтуємось на лабораторні дані, але сприймаємо їх як напрямок, а не як вирок.

Як перевірити швидкість сайту

PageSpeed Insights. Найшвидший спосіб подивитися одну конкретну сторінку. Перевіряйте окремо головну, сторінку послуги чи категорії, картку товару і статтю блогу — у них різні шаблони і різні проблеми.

Звіт Core Web Vitals у Google Search Console. Найкорисніший інструмент, бо показує не одну сторінку, а весь сайт, згрупований за схожими URL. Якщо бачите групу з 300 адрес із поганим LCP — це проблема шаблону, а не 300 окремих проблем. Тут же видно динаміку після виправлень.

Lighthouse у Chrome DevTools. Той самий аудит, але локально і з деталями: панель Performance покаже, який саме ресурс тримає LCP і які скрипти блокують головний потік.

WebPageTest або GTmetrix. Потрібні, коли треба перевірити завантаження з конкретної країни, на конкретній швидкості чи порівняти кілька запусків.

Порядок дій простий: беремо групу сторінок із найгіршими показниками в Search Console, ганяємо два-три типові URL з цієї групи через PageSpeed Insights і DevTools, знаходимо причину — і виправляємо в шаблоні, а не на окремих сторінках.

Що найчастіше гальмує сайт

Зображення. Найпоширеніша причина поганого LCP. Фото на 3 МБ, завантажене в блок шириною 400 пікселів, у форматі JPEG замість WebP. Окремий нюанс: відкладене завантаження (lazy load) потрібне для картинок нижче першого екрана, але його не можна ставити на головне зображення вгорі — саме воно зазвичай і є вашим LCP-елементом.

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

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

Шрифти. Кілька родин по чотири накреслення, підвантажені без font-display: swap. Текст або не видно, або він перемальовується з іншим накресленням — і це вже CLS.

Плагіни та теми CMS. На WordPress типова картина: 30 плагінів, кожен додає свій CSS і JS на всі сторінки, включно з тими, де він не використовується.

Ланцюжки редиректів. Коли замість однієї адреси браузер проходить три послідовні переходи, кожен додає затримку. Це та сама зона, що й биті сторінки: докладно про правильну роботу з редиректами ми розбирали в статті про помилку 404.

Елементи без зарезервованого місця. Зображення без вказаних width і height, банери, які вантажаться з затримкою, блоки реклами. Верстка добудовується на льоту — і стрибає.

З чого починати: порядок виправлень

1. Визначте, яка метрика провалюється. Не «сайт повільний», а «LCP 4,8 секунди на мобільному в шаблоні категорій».
2. Візьміть шаблон, а не URL. Виправлення в шаблоні закриває сотні сторінок одразу.
3. Почніть з зображень і сервера. У 8 випадках із 10 LCP лікується стисненням картинок, WebP, правильними розмірами і кешуванням. Це найдешевші роботи з найбільшим ефектом.
4. Приберіть зайві скрипти. Спочатку видаліть непотрібне, і лише потім оптимізуйте те, що залишилось.
5. Зафіксуйте розміри елементів. width, height, зарезервовані блоки під банери — і CLS зазвичай закривається за одну ітерацію.
6. Дайте час на перерахунок. Польові дані оновлюються за ковзні 28 днів, тож результат у Search Console ви побачите не наступного дня, а через кілька тижнів.

Коли швидкість справді впливає на трафік, а коли ні

Швидкість критична, якщо показники у червоній зоні: LCP понад 4 секунди, сторінка не реагує на дотик, макет стрибає. Тут ви втрачаєте не позиції, а людей — вони йдуть до того, як побачать пропозицію. Для мобільного трафіку та інтернет-магазинів це прямі гроші.

Швидкість другорядна, якщо LCP у вас 2,7 секунди, а трафік не росте вже пів року. Різниця між 2,7 і 2,3 секунди не зрушить позиції. У такій ситуації проблема майже завжди в іншому — у структурі, релевантності сторінок або конкуренції за запит. Ми розбирали ці сценарії окремо в матеріалі про те, чому сайт не росте в Google .

Практичне правило: швидкість — це гігієна, а не драйвер росту. Вона прибирає перешкоду, але не створює попит.

Чого оптимізація швидкості не виправить

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

Тому перед тим, як замовляти роботи з продуктивності, варто пройтися базовою перевіркою всього сайту — для цього ми зібрали чек-лист із 25 пунктів, який можна пройти самостійно за годину.

Якщо потрібно зрозуміти, де у вашому випадку справжня точка гальмування — у швидкості, структурі чи контенті — з цього починається SEO-аудит.

Катерина Тучинська

Власниця SEO-агенції Altior з понад 10 роками досвіду у SEO. Працює зі стратегією просування, аудитами, структурою та розвитком сайтів. У матеріалах Altior пояснює SEO через практичну логіку: що саме заважає сайту рости, що варто змінювати і в якій послідовності