Core Web Vitals: какво мерят, колко тежат за Google и как се оправят, без да гоните 100 точки

Какво са Core Web Vitals

Core Web Vitals са три показателя, с които Google мери как се усеща една страница за истински посетител. Първият е LCP (Largest Contentful Paint): колко време минава, докато се покаже най-големият елемент в екрана, обикновено основната снимка или заглавието. Вторият е INP (Interaction to Next Paint): колко бързо страницата реагира, когато човек натисне бутон, отвори меню или избере размер. Третият е CLS (Cumulative Layout Shift): колко „скача“ съдържанието, докато се зарежда.

Казано по-просто, трите въпроса са: показва ли се бързо, реагира ли бързо и стои ли на място. Всеки, който е натиснал „Купи“ точно в момента, в който над бутона се зареди банер и той е избягал надолу, знае защо третият показател съществува.

INP е най-новият от трите. Google го направи официален Core Web Vital през март 2024 г., на мястото на по-стария показател FID, който мереше само първото докосване. INP мери всички взаимодействия по време на посещението, затова е и по-строг.

Праговете: кога резултатът е добър

Google публикува ясни прагове и в документацията на web.dev, и в помощта на Search Console. Ето ги на едно място:

• LCP: добро до 2,5 секунди, лошо над 4 секунди.
• INP: добро до 200 милисекунди, лошо над 500 милисекунди.
• CLS: добро до 0,1, лошо над 0,25.
• Всичко между двете граници е „нужда от подобрение“.

Откъде идват числата и защо PageSpeed не е присъда

Тук е най-честото объркване. Google не оценява сайта ви по резултата, който виждате, когато натиснете „Анализ“ в PageSpeed Insights (pagespeed.web.dev). Тези 58 точки са лабораторен тест: едно симулирано зареждане на един симулиран телефон с бавна връзка. Полезен е за откриване на проблеми, но не е това, което Google брои.

Отчетът Core Web Vitals в Search Console ползва данни от CrUX, тоест анонимни измервания от реални посетители с Chrome. Страницата минава, ако 75% от зарежданията (75-ият процентил) са в добрата зона и за трите показателя. Search Console групира адресите в групи от подобни страници и дава на групата най-лошия статус, който има. Ако даден тип страници няма достатъчно посещения, те просто не се появяват в отчета, а при малки сайтове Google понякога оценява целия домейн заедно.

Практическото следствие: малък магазин с няколкостотин посещения на ден често вижда в Search Console „няма достатъчно данни“. Това не е грешка. В такъв случай гледате горната част на PageSpeed Insights, където пише какво са преживели реалните потребители (ако има данни), и чак после лабораторните точки.

Когато оправите нещо, в Search Console натискате „Проверка на поправката“. Google следи групата 28 дни и ако проблемът не се появи отново, го смята за решен. Тоест резултат от поправката виждате след около месец, а не на другия ден.

Колко тежат Core Web Vitals за класирането

По-малко, отколкото обещават продавачите на оптимизация, и повече от нула. В страницата си за „page experience“ Google казва две неща едновременно. Първото: търсачката винаги се стреми да покаже най-полезното съдържание, дори когато преживяването на страницата е слабо. Второто: когато няколко страници са сходно полезни, доброто преживяване може да помогне.

Освен това Google пише изрично, че добрите резултати в Search Console или в чужд инструмент не гарантират място най-горе в резултатите. Иначе казано, скоростта решава при равни други условия, а в останалите случаи решава съдържанието.

Моят прочит от годините с магазини е по-приземен. Бавната продуктова страница рядко губи позиции заради скоростта. Тя губи клиенти, които са дошли от реклама, платили сте за клика и те са затворили таба, преди снимката да се зареди. Затова мерим скоростта заради продажбите, а позициите в Google идват като бонус.

Ако обаче продуктовата ви страница има три реда текст, копирани от производителя, никакво LCP няма да я изкара напред. Какво има значение за класирането на магазин, сме описали в „SEO и съдържание“.

Как стоят сайтовете средно

Ако резултатът ви е лош, сте в добра компания. Според годишния доклад Web Almanac на HTTP Archive за 2024 г. само 43% от сайтовете на мобилни устройства минават и трите Core Web Vitals, а на компютър делът е 54%. На мобилен 59% от страниците имат добро LCP, 74% имат добро INP и 79% имат добро CLS.

От тези числа се вижда кое е най-трудно: LCP на телефон. Същият доклад дава и причината. При 73% от мобилните страници най-големият елемент е снимка. Тоест в повечето случаи въпросът „защо LCP е лошо“ означава „защо основната снимка се зарежда бавно“.

Поправките, които дават най-много в онлайн магазин

Подредил съм ги по това колко често виждам проблема и колко евтино се оправя. Повечето от тях са и в препоръките на Shopify за производителност на темите, които важат и за други платформи.

1. Не отлагайте зареждането на основната снимка. Отложеното зареждане (lazy loading) е за снимките надолу по страницата. Ако го сложите и на първата снимка, браузърът я тегли последна. Web Almanac 2024 отчита, че около 16% от мобилните страници със снимка за LCP правят точно тази грешка. Shopify препоръчва основната снимка да се зарежда веднага и да е маркирана с висок приоритет (fetchpriority="high"), като го нарича промяна от един ред с измеримо подобрение.
2. Давайте размери на всяка снимка. Когато браузърът не знае колко място ще заеме снимката, той подрежда страницата, после снимката идва и всичко под нея се измества. Това е CLS. Според Web Almanac 2024 66% от мобилните страници имат поне една снимка без зададени размери.
3. Пращайте снимка с правилния размер. Банер, качен в 4000 пиксела ширина и показан на телефон в 400, тегли десет пъти повече, отколкото трябва. Платформите като Shopify могат сами да подават различни размери на различните екрани, ако темата го използва.
4. Прегледайте приложенията и пикселите. Всеки чат, всяко ревю, всеки пиксел за реклама и всеки „брояч на хора, които гледат продукта“ добавя скрипт. Shopify съветва да прегледате всички скриптове, включително от приложенията, и да махнете всичко, което не изкарва цената си в скорост. Това е и най-честата причина за лошо INP: бутонът реагира бавно, защото браузърът е зает с пет чужди скрипта.
5. Не наливайте тежка JavaScript библиотека за неща, които се правят с обикновен HTML и CSS. Слайдер с три снимки не изисква рамка от няколкостотин килобайта.

Платена тема, приложения и защо правим собствени теми

В нашите магазини не ползваме платени теми и това до голяма степен е заради скоростта. Платената тема се продава на хиляди магазини с различни нужди, затова идва с всичко вградено: пет вида слайдери, анимации, мега менюта, секции, които никога няма да включите. Част от този код се зарежда, дори да не го ползвате. Собствената тема съдържа само това, което магазинът наистина показва, и когато нещо е бавно, знаем точно къде е.

Същото важи за приложенията. Всяко приложение решава един проблем и добавя една заявка към всяко зареждане. След година магазинът има петнайсет приложения, а никой не помни защо е инсталирано единайсетото. Когато правим модул сами (с AI агенти и по писан стандарт, без външни скриптове в магазина), той не тежи на страницата. Повече за това как подхождаме към темите и модулите има в „Shopify магазини“.

Справедливо е да кажа и обратното: собствена тема, написана небрежно, е по-бавна от добра платена. Shopify поставя на темите в своя магазин за теми минимален резултат 60 в Lighthouse, така че там има поне някакъв под. Собствената тема има смисъл, когато някой я поддържа и мери.

Как да проверите сайта си за половин час

Не ви трябва платен одит, за да разберете къде сте. Редът, който ползвам:

1. Отворете Search Console, раздел Core Web Vitals, и вижте отделно мобилен и компютър. Ако има групи „лоши“, отворете ги и вижте кой показател е виновен и за кои адреси.
2. Пуснете в PageSpeed Insights три страници: началната, една категория и най-продавания продукт. Гледайте първо горната част с данните от реални потребители, после лабораторния тест.
3. В лабораторния тест потърсете кой елемент е LCP. Ако е снимка, проверете дали е с отложено зареждане и колко тежи.
4. Отворете страницата на телефона си през мобилни данни, не през офисния интернет, и натиснете няколко бутона: меню, филтър, избор на вариант. Ако нещо реагира със закъснение, това е INP.
5. Запишете какво сте сменили и на коя дата. След 28 дни се връщате в Search Console и виждате дали има разлика.