Швидкість сайту у 2026: Core Web Vitals, офіційні пороги і наш кейс із мобільним блогом
Сервер відповідав за 0,23 секунди, а статті на телефоні не з'являлися зовсім. Розбираємо офіційні пороги Core Web Vitals, що Google каже про їхній вплив на пошук, і наш власний кейс: як ми знайшли причину, зменшили обкладинки з ~2 МБ до 213 КБ і що перевірити на вашому сайті.
Які показники швидкості Google вважає головними?
Core Web Vitals — три показники. LCP (завантаження): найбільший елемент сторінки має з'явитися за 2,5 секунди або швидше. INP (відгук): сторінка має реагувати на дії за 200 мілісекунд або швидше. CLS (стабільність): зсув макета — 0,1 або менше. Рахують за 75-м процентилем завантажень, окремо для мобільних і комп'ютерів, і сторінка «проходить», лише якщо в нормі всі три. INP замінив FID у 2024 році. Web.dev прямо пише, що стабільні показники змінюються не частіше разу на рік, тож «нові пороги 2026», які трапляються в блогах, Google не підтверджує.
Чи впливає швидкість на позиції в пошуку?
Google пише, що Core Web Vitals разом з іншими аспектами зручності сторінки відповідають тому, що винагороджують основні системи ранжування, і наполегливо радить мати хороші показники. Окремої ваги швидкості в ранжуванні Google не називає, тож це не чарівна кнопка, а одна з умов. Реальні дані користувачів видно у звіті «Core Web Vitals» у Search Console.
Що ми знайшли на власному сайті?
11 листопада 2026 ми відкрили блог Metriverra з телефону — і статті «дуже довго вантажилися». Заміри показали: сервер відповідав за 0,23 секунди, тож проблема була не в ньому. Стрічка з 19 статей була одним блоком з анімацією появи, яка спрацьовувала, коли на екрані видно 12% блоку. На телефоні блок мав 8 509 пікселів заввишки, екран — 844, тобто 9,9%: поріг не досягався, і статті лишалися невидимими. До того ж обкладинки віддавалися в повному розмірі — близько 2 МБ на стрічку. Ми прибрали анімацію зі стрічки, зробили сторінки по 10 і 9 статей і віддаємо зменшені копії обкладинок: 12 обкладинок важили 213 КБ замість приблизно 2 МБ.
Що перевірити на своєму сайті?
Відкрийте звіт «Core Web Vitals» у Search Console й почніть з мобільних сторінок. Перевірте сторінку в справжньому мобільному вікні, а не лише швидкість відповіді сервера: контент, захований до спрацювання скрипта, користувач просто не побачить. Віддавайте зображення розміром під екран (srcset), відкладайте завантаження картинок нижче першого екрана, але не головного зображення. Резервуйте місце під картинки, щоб макет не стрибав. І пам'ятайте, що важкі скрипти й теги погіршують відгук — INP.
Що зробити зараз
- Відкрийте звіт «Core Web Vitals» у Search Console і почніть з мобільних URL-адрес.
- Перевірте ключові сторінки в мобільному вікні: чи видно контент без очікування анімацій і скриптів.
- Віддавайте зображення під розмір екрана і зменшені копії для списків і карток.
- Не відкладайте завантаження головного зображення першого екрана — лише ті, що нижче.
- Перевіряйте показники після кожної великої зміни сайту, а не раз на рік.
У Metriverra поведінку відвідувачів і конверсії видно щодня, тож після зміни швидкості сайту легко порівняти відмови й продажі до і після.
Коротко
- Пороги Google: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 за 75-м процентилем.
- Стабільні показники змінюються не частіше разу на рік; «нові пороги 2026» Google не підтверджує.
- Google: Core Web Vitals відповідають тому, що винагороджують системи ранжування.
- Наш кейс: сервер 0,23 с, але статті на телефоні були невидимі через анімацію.
- Обкладинки стрічки: ~2 МБ → 213 КБ.
Джерела: web.dev — Web Vitals · Google Search Central — Understanding Core Web Vitals and Google search results
