Core Web Vitals: LCP, INP и CLS

Модул 4: Скорост, мобилни устройства и https · Време за четене: 13 минути

Цел на урока: След този урок ще можете да обясните трите Core Web Vitals и техните гранични стойности, да посочите разликата между полеви данни и лабораторни данни, да разчетете измерване с PageSpeed Insights, да отстраните най-важните причини за лош резултат и честно да прецените колко тежи скоростта в резултатите от търсенето.

Основни понятия: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75-и перцентил, полеви данни (CrUX), лабораторни данни (Lighthouse), PageSpeed Insights, отчет Core Web Vitals в Search Console, TTFB, компресия, width и height при изображенията, loading="lazy", изживяване на страницата (page experience)

Скоростта в три числа

„Бърз ли е моят сайт?“ е неясен въпрос. Google и създателите на Chrome са го превърнали в три измерими въпроса, Core Web Vitals:

Няколко неща, които е добре да разберете:

• LCP измерва момента, в който се появява най-големият видим елемент. Обикновено това е голяма снимка в горната част (т.нар. „hero“) или голям текстов блок. При Bloemenatelier Lotte това е снимката на цветната аранжировка на началната страница.
• INP следи всички щраквания, докосвания и натискания на клавиши по време на посещението и отчита (почти) най-бавната реакция. На 12 март 2024 г. INP замени по-старото измерване FID (First Input Delay), което гледаше само първото щракване и само изчакването преди обработката. Ако срещнете FID в стара статия, тази информация е остаряла.
• CLS не е време, а оценка без мерна единица. Тя се увеличава, когато елементи се разместват, докато четете: искате да докоснете бутон и точно в този момент над него се появява банер, така че докосвате нещо друго.

75-ият перцентил

Една страница „покрива“ Core Web Vitals, когато 75 процента от посещенията имат добър резултат и по трите показателя, измерени поотделно за мобилни устройства и за настолни компютри. Това се нарича 75-и перцентил. Означава, че не се брои Вашият собствен бърз компютър с оптична връзка, а изживяването на повечето посетители, включително тези с по-стар телефон през 4G.

Полеви и лабораторни данни

Има два вида измервания и те често дават различни числа.

• Полевите данни идват от реални посетители. Chrome събира анонимно (при потребители, които са разрешили това) колко бързо са се заредили страниците, в Chrome User Experience Report (CrUX). PageSpeed Insights показва полевите данни за последните 28 дни. Отчетът Core Web Vitals в Search Console използва същия източник. Ако Вашата страница има твърде малко посетители, PageSpeed Insights показва данните за целия Ви сайт („origin“), а ако и те са недостатъчни, полеви данни няма.
• Лабораторните данни идват от симулиран тест с Lighthouse: едно зареждане на имитиран телефон от среден клас с имитирана връзка. Lighthouse не може да измери INP (никой не щраква), затова дава други числа, като Total Blocking Time, които все пак са индикация за INP.

За оценката значение имат полевите данни. Лабораторните данни са полезни, за да откриете причините и след подобрение веднага да видите дали то помага, без да чакате 28 дни.

Колко тежи това?

Тук често се преувеличава. Ето какво казва самият Google в документацията за изживяването на страницата:

• „Core Web Vitals are used by our ranking systems“: значи те се вземат предвид.
• Няма отделен „сигнал за изживяване на страницата“. Според Google другите елементи на доброто изживяване (https, липса на натрапчиви изскачащи прозорци, удобство на мобилни устройства) не Ви помагат пряко да се класирате по-високо, но правят сайта Ви по-приятен.
• „Google Search always seeks to show the most relevant content, even if the page experience is sub-par.“ Тоест бавна страница с най-добрия отговор спокойно може да е най-отгоре.
• Според Google стремежът към перфектен резултат само заради SEO „може би не е най-доброто използване на Вашето време“.

Извод: погрижете се да сте в зелената или поне в оранжевата зона, преди всичко защото посетителите напускат бавни или разместващи се страници. Гонитбата от 90 до 100 точки в Lighthouse носи малко в резултатите от търсенето.

Причините, които можете да отстраните сами

Бавен първи отговор (TTFB)

Всичко започва с момента, в който пристига първият байт от HTML кода, т.нар. Time to First Byte. TTFB сам по себе си не е Core Web Vital, но бавният TTFB прави добрия LCP почти невъзможен. web.dev посочва като ориентир: добре е 0,8 секунди или по-малко, лошо е повече от 1,8 секунди. Причини според web.dev: недостатъчна изчислителна мощност на хостинга, липса на кеш (всяка страница се изгражда наново, типично за WordPress без плъгин за кеширане), пренасочвания (урок 4.1) и отдалечен сървър без CDN.

Компресията също е част от това: сървърът трябва да изпраща HTML, CSS и JavaScript компресирани с gzip или Brotli. Това се вижда от заглавния ред Content-Encoding: gzip или br. Почти всеки хостинг го прави по подразбиране, но грешна настройка или стар сървър може да го изключи.

Изображения

Изображенията са най-честата причина за лош LCP и CLS:

1. Твърде големи. Снимка с ширина 4000 пиксела и 5 MB за поле от 800 пиксела. Намалете размера преди качването и използвайте модерен формат като WebP или AVIF.

2. Без ширина и височина. Без width и height браузърът не знае колко място е нужно за изображението и текстът под него се измества, щом то се зареди. web.dev препоръчва да поставяте width и height на всеки <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Отложено зареждане на най-важната снимка. loading="lazy" зарежда изображението едва когато то стане видимо. Това е чудесно за снимки по-надолу, но web.dev казва ясно: изображенията, които се виждат още при отварянето, и особено LCP изображението, НЕ трябва да се зареждат отложено. Иначе браузърът забавя точно снимката, която определя Вашия LCP.

Разместващо се съдържание и бавни реакции

Други причини за CLS според web.dev: шрифтове, които променят размера си при зареждане, реклами и вградени уиджети, които сами се уголемяват, и съдържание, вмъквано по-късно над съществуващото (например лента за бисквитки, която избутва страницата надолу, вместо да стои върху нея). Лошият INP почти винаги се дължи на прекалено много JavaScript: тежки теми, слайдери, чат уиджети и проследяващи скриптове на трети страни. Преценявайте критично всеки плъгин и всяка вградена услуга; тук наистина по-малко означава повече.

На практика: измерване с PageSpeed Insights

Отидете на pagespeed.web.dev, въведете адреса на началната си страница и щракнете Analyze. Получавате два раздела (Mobile и Desktop). Най-отгоре е оценката на Core Web Vitals въз основа на полевите данни, ако има такива. Под нея е тестът на Lighthouse с резултат и списък „Diagnostics“ с конкретни точки, например за изображения, по-големи от необходимото, или за LCP изображение, което се зарежда отложено (точните наименования се променят с новите версии на Lighthouse). Започнете от Mobile: там резултатът обикновено е по-лош, а Google гледа първо мобилната версия (урок 4.2).

Ако сайтът Ви е добавен в Search Console (модул 2), погледнете и в Experience, Core Web Vitals. Там виждате групи от подобни страници с техния статус, включително за страници, които сами не сте тествали.

Сайт, създаден с AI Builder, задава ширина и височина на изображенията с известен размер, зарежда първата снимка на страницата веднага и с приоритет (fetchpriority="high"), а останалите отложено, и при публикуване създава вариант с ширина 800 пиксела на големите снимки. В WordPress най-много помагат плъгин за кеширане и намаляването на размера на изображенията; курсът за WordPress разглежда това по-подробно в модул 6. При другите конструктори на сайтове и хостинг компании е подобно: бутоните са различни, причините са същите.

Обобщение

• Core Web Vitals са LCP (добре до 2,5 s), INP (добре до 200 ms, от март 2024 г. вместо FID) и CLS (добре до 0,1), измерени при 75-ия перцентил за всеки вид устройство.
• Полевите данни (CrUX, 28 дни) определят оценката; лабораторните данни (Lighthouse) помагат да откриете причините.
• Google използва Core Web Vitals при класирането, но релевантността е с предимство: перфектният резултат не е цел сам по себе си.
• Най-голяма полза: бърз отговор на сървъра с кеш и компресия, малки изображения с width и height, без отложено зареждане на най-важната снимка, по-малко JavaScript от трети страни.

Тест

Задача

Задача A4.3: Бърз отговор и леки изображения. Въведете адреса на страница. Програмата измерва три пъти времето до първия байт (TTFB) от нашия сървър и взема средната стойност по ред (медианата), проверява дали HTML кодът се изпраща компресиран (gzip, Brotli или zstd), преброява изображенията без width и height и проверява дали най-важното изображение в горната част не се зарежда с loading="lazy". Внимание: това е измерване от едно място, а не измерване на Вашите посетители. Нямате собствен сайт? Използвайте www.wikipedia.org.

Задача D4.3: Вашите Core Web Vitals. Пуснете PageSpeed Insights за началната си страница и за още една важна страница, първо в Mobile. Запишете за всяка страница: има ли полеви данни (за страницата или за целия сайт), стойностите на LCP, INP и CLS от полевите данни, резултата от Lighthouse и елемента, който Lighthouse посочва като LCP елемент. Изберете едно подобрение, което според Вас ще донесе най-много, и обяснете защо.

Прочетете още

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Search Console Help, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
• Четене на PageSpeed Insights: Core Web Vitals на обикновен език
• Уебсайтът ми е бавен или използва твърде много CPU: ето как да го ускорите
• Безплатен курс по WordPress 6.1: Какво прави един сайт бавен и как се измерва това?
• Безплатен курс по WordPress 6.3: Изображения, PHP и други подобрения в скоростта