Хтось скинув тобі посилання на PageSpeed Insights, і ти побачив червоні цифри? Не панікуй. Ці метрики простими словами говорять про три речі, які клієнт відчуває на своєму телефоні: чи завантажилася сторінка взагалі, чи вона реагує на натискання і чи все не стрибає під пальцем. Google рекомендує власникам сайтів досягати хороших Core Web Vitals для успіху в пошуку та загального зручності користувачів. Це не вирок — це карта того, що лагодити в першу чергу, щоб сайт не відлякував людей, які вже на нього зайшли.
У цій статті ти знайдеш: точні пороги Google без жаргону, пояснення кожної метрики прикладом із твоєї галузі, схему як читати звіт за п'ять хвилин і конкретний порядок дій. Також дізнаєшся, як розмовляти з підрядником, щоб не витрачати гроші на речі, які не мають сенсу.
Три метрики, три відчуття клієнта
Що вимірює LCP і чому це важливо
Кожна з трьох метрик Core Web Vitals вимірює щось своє, але всі вони відповідають на просте питання: як клієнт почувається на твоєму сайті?
LCP (Largest Contentful Paint) — час, за який з'являється найбільший елемент на екрані. Для клієнта це відповідь на питання: «Сторінка взагалі працює?». Якщо ти відкриваєш сайт стоматолога, а головне фото кабінету завантажується чотири секунди — клієнт думає, що щось не так, і закриває сторінку. Хороший LCP — 2,5 секунди або менше; поріг оцінюється на 75-му перцентилі завантажень сторінки.
Що вимірює INP і чому клієнт дратується
INP (Interaction to Next Paint) — час реакції сторінки на клік, дотик або введення тексту. Для клієнта це відповідь на питання: «Сторінка мене чує?». Коли ти натискаєш кнопку «Записатися», а сторінка мовчить півсекунди, перш ніж щось відбувається — це дратує. Хороший INP — 200 мілісекунд або менше; вище 500 мс вважається поганим.
Що вимірює CLS і чому стрибає текст
CLS (Cumulative Layout Shift) — наскільки все зміщується на екрані під час читання. Для клієнта це відповідь на питання: «Чи можу я спокійно читати?». Уяви, що ти читаєш опис послуги, потім вискакує банер кукисів, текст їде вниз, і ти втрачаєш місце. Сторінки повинні мати CLS 0,1 або менше, вимірюється на 75-му перцентилі.
| Метрика | Що вимірює | Що відчуває клієнт | Хороший поріг |
|---|---|---|---|
| LCP | Час завантаження найбільшого видимого елемента | «Сторінка взагалі працює?» | ≤ 2,5 с |
| INP | Час відгуку на будь-яку взаємодію | «Сторінка мене чує?» | ≤ 200 мс |
| CLS | Загальне зміщення макета під час використання сторінки | «Чи можу я спокійно читати?» | ≤ 0,1 |
Чому 75-й перцентиль, а не середнє
Коли ти бачиш у звіті «LCP 3,2 секунди», можеш задуматися, звідки ця цифра. Google не рахує середнє з усіх візитів. Натомість береться 75-й перцентиль — що це означає на практиці?
Ось приклад на умовних числах — підстав свої. Уяви, що твій сайт відвідує 100 людей на місяць. Час завантаження виглядає так: 70 людей завантажили сторінку за 1,5 секунди, 10 — за 3 секунди, 20 — за 4 секунди. Середнє становило б близько 2,15 секунди і виглядало б добре (менше 2,5 секунди).
Саме це значення показується у звіті, тому що Google хоче знати, у більшості чи користувачів хороший час, а не феноменальний у меншості.
Чому це важливо для тебе?
Метрика на 75-му перцентилі говорить тобі, чи є щонайменше у трьох чвертей клієнтів причина скаржитися.
Поле проти лабораторії в PageSpeed Insights
Коли заходиш на pagespeed.web.dev і вводиш адресу свого сайту, бачиш два типи даних: з поля та з лабораторії. Важливо знати різницю і на які орієнтуватися.
Дані з поля (field data) приходять від реальних користувачів, які відвідували твій сайт за останні 28 днів. Chrome вимірював їх LCP, INP і CLS у фоновому режимі й відправляв цю інформацію в Google. Це дані, яким можна справді довіряти, тому що вони показують, як сайт працює в реальному світі — на різних телефонах, у різних мережах, у різний час доби.
Лабораторні дані (lab data) приходять із симуляції Lighthouse. PageSpeed Insights запускає твій сайт у контрольованому середовищі: на середньому смартфоні, у середній мережі 4G. Це інструмент для пошуку проблем, не для оцінки реальності. Lighthouse може показати червоний LCP, але якщо дані з поля зелені — не панікуй. Звіт може також показувати зелені значення, хоча користувачі скаржаться — тоді дані з поля важливіші.
Чому даних з поля іноді немає? Якщо у твого сайту дуже мало відвідувань, Google не має достатньо даних, щоб показати надійні значення. У такому випадку доводиться покладатися на лабораторні дані, але ставитися до них як до натяку на покращення, не як до остаточного вердикту.
PageSpeed Insights показує лабораторні дані і дані з поля; над розподілом PSI виводить 75-й перцентиль метрик.
Правило: рішення приймаєш за полем, проблеми шукаєш у лабораторії.
Як читати звіт PageSpeed Insights за п'ять хвилин
Тобі не потрібно розуміти кожен рядок у звіті. Досить п'яти кроків:
- 01Адреса
- →02телефон
- →03поле
- →04червоне
- →05діагностика
- →06підрядник
Ось схема:
Введи адресу в PageSpeed Insights → відкрий результат на телефоні → прочитай дані з поля вгорі → якщо метрика червона, прокрути до діагностики → запиши: «На сторінці послуг LCP 4,2 с — головна картинка».
Найчастіші причини поганого CLS — картинки без розмірів, реклама, вбудовування і iframe без розмірів і динамічно вставляється контент. Коли ти вже знаєш, що не так, можна замовити виправлення конкретної речі, а не казати «зроби сторінку швидшою».
Які сторінки на своєму сайті вимірювати
Не потрібно перевіряти кожну сторінку. Досить виміряти чотири-шість ключових сторінок, і ти знатимеш стан усього сайту:
- Головна сторінка — твоя візитка, найчастіше перший контакт.
- Дві-три найважливіші послуги — ті, через які люди телефонують найчастіше.
- Сторінка контактів — коли хтось уже вирішив зателефонувати, у нього не повинно бути проблем із завантаженням номера.
У Search Console (search.google.com/search-console) є розділ Core Web Vitals, який показує, які адреси мають проблеми. Якщо десять різних сторінок послуг мають ту саму проблему — це вина шаблону, не однієї сторінки. У такому випадку лагодиш шаблон, і всі сторінки покращуються одночасно.
Що лагодити першим — матриця впливу та складності
Не все можна виправити одразу. Ось пріоритети, які дозволять тобі почати з того, що дає найбільше за найменше зусиль:
| Що лагодити | Вплив на метрику | Складність | Коли лагодити |
|---|---|---|---|
| Картинки без розмірів (width/height) | CLS, LCP | Низька | Зразу |
| Важкі графічні баннери на телефон | LCP | Низька | Зразу |
| Сторонні скрипти (чат, карти, відгуки) | INP | Середня | Після картинок |
| Шрифти зі зовнішніх серверів | LCP | Середня | Після картинок |
| Плагіни, які завантажують зайвий JavaScript | INP | Середня | Після чату |
| Оптимізація сервера (CDN, стиснення) | LCP | Висока | Наприкінці |
Найчастіші причини поганого CLS — картинки без розмірів, реклама, вбудовування та iframe без розмірів і динамічно вставляється контент.
Чого не робити
Перш ніж витрачати гроші на «пришвидшення сайту», запам'ятай три правила:
Не женеться за 100 балами в Lighthouse. Результат 100 означає, що сторінка ідеально оптимізована під тест, не під твоїх клієнтів. Досягнення 100 часто вимагає відмови від важливих функцій (карт, форм, галерей). Цілися в зелене поле, не в сотню.
Не встановлювати «плагіни пришвидшення» без вимірювання до і після. Більшість таких плагінів — це набори готових рішень, які іноді працюють, а іноді ламають більше, ніж лагодять. Виміряй сторінку перед зміною, внеси одну зміну, виміряй знову. Тільки тоді дізнаєшся, чи допомогло.
Не видаляти аналітику навмання. Google Analytics, Meta Pixel та інші інструменти — це джерела знання про те, що роблять твої клієнти. Замість видалення перевір, чи завантажуються вони асинхронно (не блокують завантаження сторінки). Зазвичай цього достатньо.
Швидкість сайту — не все
Ти можеш мати ідеальні Core Web Vitals, але якщо на сторінці немає зрозумілої пропозиції — клієнт усе одно не зателефонує. Сторінка може завантажуватися за секунду, але якщо незрозуміло, що ти пропонуєш, за скільки і як замовити, жодна швидкість не допоможе.
Перш ніж витрачати гроші на технічну оптимізацію, перевір, чи є на сторінці: заголовок із назвою та основною послугою, прайс-лист або зрозуміла кнопка дії, інструкція як замовити. Якщо цього немає, жодна швидкість не замінить контент. Більше про те, чому клієнти не залишають запитів, читай у статті Чому клієнти не залишають запитів. А про те, як дані фірми впливають на видимість, — у статті Дані фірми в Google і на порталах.
Зроби це сам за один вечір
Тобі не потрібен програміст, щоб почати. Ось п'ять кроків, які ти виконаєш сьогодні ввечері:
- Зайди на pagespeed.web.dev і введи адресу своєї головної сторінки.
- Зроби те саме для двох найважливіших послуг і сторінки контактів.
- Запиши в таблицю (можна в Excel або на папері): адреса сторінки, LCP, INP, CLS — з кольором: зелений, бурштиновий або червоний.
- Для кожної червоної метрики прочитай один рядок у розділі «Діагностика» — це натяк на те, що не так.
- Надішли підряднику повідомлення: «На сторінці [адреса] у мене [метрика] [значення], результат передбачає [опис з діагностики]. Прошу оцінити виправлення цього конкретного елемента.»
Повтори вимірювання після внесення змін. Якщо підрядник каже, що щось неможливо або дорого — повернися до цієї статті, перевір, це дійсно пріоритет, і виріши, чи варто воно того.
Як це виглядає, коли за швидкість сайту відповідає система
Ручна перевірка PageSpeed Insights раз на квартал — хороший початок, але легко забути. Краще перетворити це на постійний ритм: регулярно вимірювати ключові сторінки в полі (дані реальних користувачів), генерувати звіт із метриками, перетворювати червоні значення на конкретні завдання і повторювати вимірювання після внесення змін. Результат — історія змін, яку ти бачиш чітко: було погано, зробили X, тепер краще.
Коли замовляєш сайт, з першого дня отримуєш мобільну версію як основну, базову налаштування SEO та аналітику. Найчастіша помилка — публікація без виміру — тому варто перевірити результати одразу після запуску. Дізнайся, як це працює, на сторінці послуг. Якщо цікавить також конверсія на сайті, просування, проектування інтерфейсів або аналітика — можемо зробити повний аудит твого сайту. Більше про те, як вимірювати результати, читай у статті Автоматизація звітності. А про те, з чого почати автоматизацію в малому бізнесі — у статті Чотири пороги замість аналізу.
Часті питання
Чи потрібні зелені Core Web Vitals, щоб бути високо в Google?
Google враховує багато факторів. Хороші Core Web Vitals — один із сигналів, який може допомогти, але сам по собі не гарантує позицій. Сторінка з чудовими метриками, але без контенту та без цінності для користувача не обгонить сторінку з трохи гіршими метриками, але з кращою відповіддю на питання клієнта.
Що робити, якщо PageSpeed Insights показує дані з поля, але у мого сайту мало відвідувань?
Якщо у тебе менше кількох сотень візитів на місяць, Google може не мати достатньо даних. У такому випадку покладайся на лабораторні дані (Lighthouse) як натяк, але стався до них скептично — тестує на штучних умовах. У такій ситуації краще просто подбати про основи: оптимізовані картинки, жодних зайвих скриптів, робочий HTML-код.
Чи можу я сам полагодити CLS, якщо не знаю HTML?
Часто так. Найчастіша причина поганого CLS — картинки без розмірів. Якщо використовуєш WordPress або іншу CMS, у більшості випадків достатньо додати атрибути width і height до картинки в редакторі. У конструкторах (Wix, Webflow, GoDaddy) зазвичай система додає їх автоматично — перевір у налаштуваннях галереї або в опціях картинки.
Скільки коштує виправлення Core Web Vitals?
Це залежить від проблеми. Додавання розмірів до картинок — хвилина роботи — навіть безкоштовно, якщо робиш сам. Оптимізація сервера або переписування коду під великий трафік — більший проект. Ключ — почати з вимірювання та конкретної проблеми, не з загального «зроби сайт швидшим».
Видалення плагінів завжди допомагає?
Не завжди. Іноді плагін необхідний (наприклад, форма контактів, карта Google). Замість видалення перевір, чи є легша альтернатива або чи є в плагіна опція асинхронного завантаження. Іноді один плагін сповільнює сайт більше, ніж десять інших — варто виміряти, який.
Як часто перевіряти Core Web Vitals?
Після внесення змін — протягом тижня, щоб підтвердити, що допомогло. Потім досить раз на квартал, якщо не додаєш нові функції (нові галереї, плагіни, інтеграції) — тоді перевіряй після кожної зміни.