Накратко: Core Web Vitals са три показателя за усещането на посетителя: LCP мери кога се появява основното съдържание, INP мери колко бързо страницата отговаря на действие, а CLS мери дали съдържанието се разминава под пръста. Добрите стойности са до 2,5 секунди за LCP, до 200 милисекунди за INP и до 0,1 за CLS, измерени при 75-ия персентил от посещенията. Реалните данни се виждат в Search Console и в PageSpeed Insights, а при сайтовете на малки фирми поправките почти винаги започват от изображенията, шрифтовете, добавките и хостинга.
Данните и праговете по-долу са към 16 септември 2026 г. и са взети от документацията на Google и от web.dev. Праговете се променят рядко, но се променят, затова ги сверявайте.
Какво измерват LCP, INP и CLS?
- LCP (Largest Contentful Paint): кога се показва водещото съдържание в екрана, обикновено голямата снимка или заглавието. Това е моментът, в който посетителят решава, че страницата е заредена.
- INP (Interaction to Next Paint): колко време минава от действието на посетителя до видимата реакция на страницата. Натиснат бутон, отворено меню, попълнено поле.
- CLS (Cumulative Layout Shift): колко се разместват елементите, докато страницата се дозарежда. Точно това кара човек да натисне грешния бутон.
| Показател | Какво мери | Добра стойност | Слаба стойност |
|---|---|---|---|
| LCP | Зареждане на основното съдържание | до 2,5 секунди | над 4 секунди |
| INP | Отзивчивост при действие | до 200 милисекунди | над 500 милисекунди |
| CLS | Разместване на съдържанието | до 0,1 | над 0,25 |
Двете уточнения, които се пропускат: праговете важат при 75-ия персентил от посещенията, отделно за телефон и за компютър, а между добрата и слабата стойност има междинна зона, която Search Console нарича «нуждае се от подобрение».
Има и промяна, която още обърква хората. На 12 март 2024 г. INP стана постоянен показател от Core Web Vitals и замени FID, а инструментите на Chrome престанаха да осигуряват наличността на FID след 9 септември 2024 г. Ако получавате отчет, в който още се говори за FID, той е стар.
Къде да видите реални данни и къде лабораторни?
Разликата между двата вида данни обяснява защо един и същ сайт получава различни оценки на различни места.
- Реални данни (field): идват от Chrome User Experience Report, тоест от истински посетители с Chrome. PageSpeed Insights показва данните за предходния период от 28 дни. В CrUX влизат само страници, които са публично достъпни и имат достатъчно посещения, затова малък сайт може да няма реални данни.
- Лабораторни данни (lab): Lighthouse зарежда страницата в контролирана среда, на едно устройство и при фиксирани мрежови условия. Полезни са за търсене на причината, но не описват какво преживяват Вашите посетители.
Отчетът Core Web Vitals в Search Console също стъпва на CrUX. Той групира сходни адреси и показва състоянието на групата по слабия показател, а групи без достатъчно данни не се показват. За собственик това е удобната отправна точка: виждате кои групи страници са проблемни, а не една случайна страница.
Съвет от ScaleLab: Започвайте от Search Console, а не от оценката в PageSpeed Insights. Оценката е лабораторна и се променя при всяко пускане, докато отчетът в Search Console показва какво се е случвало при реални посетители през последните седмици. Поправяйте страници, а не числа.
Влияе ли скоростта на класирането в Google?
Тук е важно да се цитира самият Google, а не блоговете. В документацията за page experience, обновена на 10 декември 2025 г., Google пише, че основните му системи за класиране целят да награждават съдържание, което предлага добро преживяване на страницата, и че Core Web Vitals се използват от системите за класиране. В същия текст пише и че няма единен сигнал и че добрите стойности в отчетите не осигуряват първо място.
Отделно Google посочва, че търсачката винаги се стреми да покаже съдържанието с висока степен на съответствие на търсенето, дори когато преживяването на страницата е слабо. Преведено за собственика на бизнес: скоростта не замества липсата на подходящо съдържание, но при близки по качество страници тя е разликата, която се усеща и в класирането, и в броя на запитванията.
Google предлага и проста самопроверка. Добри Core Web Vitals, защитена връзка, съдържание, което изглежда добре на телефон, без прекомерни реклами върху основното съдържание, без натрапчиви изскачащи прозорци и ясно разделение между основното съдържание и останалото.
Какво обикновено бави сайта на малка фирма?
В практиката причините се повтарят и рядко са екзотични.
- Изображения: качени в оригинален размер от телефон или фотоапарат. Документацията за LCP препоръчва подходящ размер, съвременни формати и компресия, а самият елемент с LCP да се открива още в HTML кода на страницата.
- Бавен отговор на сървъра: според препоръките за LCP времето до първия байт обикновено трябва да е около 40% от целия бюджет за LCP. Когато хостингът е претоварен или далече, останалите поправки не помагат. Как се избира хостинг, разглеждаме в статията за домейна и хостинга на фирмения сайт.
- Блокиращи ресурси: синхронни скриптове в главата на документа и тежки стилови файлове бавят показването. Препоръката е блокиращите стилове да се намалят или вградят.
- Прекалено много добавки и външни скриптове: всеки чат, банер, карта и пиксел е чужд код на Вашата страница. При INP основната причина е изпълнението на JavaScript и дългите задачи, които държат основната нишка заета.
- Шрифтове и елементи без размери: честите причини за CLS са изображения, реклами, вградени елементи и iframe без зададени размери, съдържание, което се вмъква динамично, и уеб шрифтове, при които текстът се преподрежда, когато шрифтът се зареди.
За онлайн магазин цената на тези проблеми е пряка: бавната продуктова страница и разместващият се бутон за поръчка се плащат в изоставени колички. Повече за подредбата на магазина ще намерите на страницата за маркетинг за онлайн магазини.
Какво да поправите първо?
Следващата подредба е наша препоръка по правилото «първо това, което дава голям резултат при малко работа».
1. Изображенията
Намалете размерите до реално нужните, минете към съвременен формат и компресирайте. Задайте ширина и височина на всяко изображение, за да не се разместват елементите.
2. Сървърът и кешът
Проверете времето до първия байт. Кеширане, разумен хостинг и по-малко пренасочвания дават резултат, който се вижда на всяка страница, а не само на една.
3. Скриптовете, които не носят нищо
Направете списък на всичко външно: чатове, карти, пиксели, вградени видеа, инструменти за отзиви. Махнете каквото не използвате и заредете останалото след основното съдържание.
4. Шрифтовете
Ограничете броя на шрифтовете и стиловете. Всеки допълнителен шрифт е допълнително чакане и допълнителен риск от разместване.
5. Добавките
При WordPress прегледайте кои добавки се зареждат на всяка страница. Част от тях качват свои стилове и скриптове навсякъде, макар да се използват на едно място. Как се поддържат добавките без излишен риск, описваме в статията за сигурността на WordPress.
Съвет от ScaleLab: Измервайте една промяна наведнъж и записвайте датата. Ако сменяте едновременно тема, добавки и хостинг, няма да знаете кое е помогнало и кое е навредило, а реалните данни идват със закъснение от няколко седмици.
Ако не сте сигурни откъде да започнете, безплатният одит на сайта и маркетинга дава външен поглед към скоростта и към пътя до запитването. Изборът на платформа също влияе на това колко лесно се поправят тези неща: сравнението е в статията за избора на платформа за сайт.
При изработка на сайт работата по изображенията, кода и сървъра върви заедно с настройката на измерването, преди сайтът да бъде пуснат.
Често задавани въпроси
Каква скорост е достатъчно добра?
Ориентирайте се по праговете: LCP до 2,5 секунди, INP до 200 милисекунди и CLS до 0,1 при 75-ия персентил от посещенията. Ако и трите са в зелено на телефон, скоростта не е Вашият проблем.
Защо PageSpeed Insights и Search Console показват различни числа?
Защото мерят различни неща. Search Console и полето с реални данни в PageSpeed Insights идват от истински посетители за предходните 28 дни, а оценката на Lighthouse е лабораторна, на едно устройство при фиксирани условия.
Сайтът ми е нов и няма данни в отчета. Какво да правя?
В CrUX влизат страници с достатъчно посещения, затова новите сайтове често нямат реални данни. Дотогава използвайте лабораторните инструменти и проверявайте ръчно на истински телефон, а не само на компютър.
Ще се класирам ли по-високо, ако поправя Core Web Vitals?
Google посочва, че Core Web Vitals се използват от системите за класиране, но че няма единен сигнал и че добрите стойности не осигуряват първо място. Приемете скоростта като условие, а не като начин да изпреварите по-подходящото съдържание.
Колко време минава, преди поправката да се види в отчета?
Реалните данни се натрупват за период от 28 дни, затова изчакайте няколко седмици, преди да съдите за резултата. Лабораторният тест показва промяната веднага, но не доказва, че посетителите я усещат.
Източници
- web.dev: Core Web Vitals, метрики и прагове
- web.dev: Interaction to Next Paint is officially a Core Web Vital (12 март 2024 г.)
- Google Search Central: Understanding page experience in Google Search results (обновено на 10 декември 2025 г.)
- Google Search Console Help: Core Web Vitals report
- Google Developers: About PageSpeed Insights, полеви и лабораторни данни
- Chrome for Developers: Chrome UX Report, методология и допустимост
- web.dev: Optimize Largest Contentful Paint
- web.dev: Optimize Interaction to Next Paint
- web.dev: Optimize Cumulative Layout Shift