Скорост на сайта и Core Web Vitals: какво се измерва и как се подобрява

Core Web Vitals са три показателя, с които Google описва как реалните посетители усещат една страница: LCP (колко бързо се появява основното съдържание), INP (колко бързо страницата реагира на докосване, клик или писане) и CLS (колко се размества оформлението, докато страницата се зарежда). Почти всички бавни сайтове страдат от едни и същи причини: прекалено големи изображения, уеб шрифтове, скриптове, които блокират изобразяването, външни скриптове, елементи без запазено място и бавен отговор от сървъра. Отстранявайте ги по реда на ефекта им и съдете за резултата по данните от реални посетители. Един тест в офиса на бърза връзка лесно скрива проблема.

#Какво измерват LCP, INP и CLS

Largest Contentful Paint (LCP) отбелязва момента, в който най-големият видим елемент в първия екран е изобразен. Обикновено това е основното изображение, снимка на продукт или главното заглавие. Показателят отговаря на първия въпрос на посетителя: заредила ли се е страницата.

Interaction to Next Paint (INP) следи взаимодействията по време на посещението, например отваряне на меню, добавяне в количката или писане в търсачката, и измерва след колко време страницата показва видима реакция. Той замени по-стария показател First Input Delay, който отчиташе само първото взаимодействие. Слабият INP се усеща като страница, която за миг не ви обръща внимание след всеки клик.

Cumulative Layout Shift (CLS) сумира колко видимо съдържание се премества неочаквано. Типичният случай: посягате към бутон, в този момент над него се зарежда банер, бутонът слиза надолу и натискате нещо друго.

За всеки показател Google публикува граници за „добър“, „нуждае се от подобрение“ и „слаб“ резултат и ги оценява по висок персентил на реалните зареждания, така че по-бавните посещения също се броят. Границите вече са били променяни, затова проверете актуалните стойности в официалната документация за Web Vitals на web.dev, преди да си поставите цели.

#Лабораторни и реални данни

Лабораторните данни идват от тест, който пускате сами: Lighthouse в Chrome DevTools, лабораторната част на PageSpeed Insights или WebPageTest. Страницата се зарежда веднъж при контролирани условия. Такива тестове са повторяеми и затова са удобни за откриване на причината и за проверка на поправка преди пускане. INP обаче не могат да измерят точно, защото никой не кликва, и вместо него показват косвени стойности като Total Blocking Time.

Реалните данни идват от посетители на техните собствени устройства и мрежи. Докладът Chrome User Experience Report (CrUX) ги събира от потребители на Chrome, които са дали съгласие. Тях виждате най-горе в PageSpeed Insights и на тях се основава докладът за Core Web Vitals в Search Console. Важният резултат е този, но той се натрупва за седмици и поправката проличава бавно. Страници с малко посещения може изобщо да нямат реални данни.

Работещият подход използва и двата източника:

• В Search Console откривате кои групи страници не покриват изискванията при реалните посетители.
• Възпроизвеждате проблема в лабораторен инструмент с ограничена мрежа и процесор, за да симулирате обикновен телефон.
• Поправяте, проверявате в лабораторията, пускате и следите реалните данни през следващите седмици.
• За по-бърза обратна връзка събирате собствени реални данни с библиотеката с отворен код web-vitals и ги изпращате към своята аналитика.

#Защо LCP е бавен и как се оправя

Изображения

Елементът за LCP най-често е изображение и то често е много по-голямо, отколкото трябва. Използвайте съвременни формати като WebP или AVIF, оразмерявайте изображенията според реалния им размер на екрана и добавете srcset, за да изтеглят телефоните по-малък файл. Никога не зареждайте отложено (lazy loading) изображението в първия екран. Отбележете го с fetchpriority="high", за да го поиска браузърът рано. Отложено зареждайте изображенията по-надолу в страницата.

Шрифтове

Уеб шрифтовете могат да скрият текста, докато не пристигнат. Задайте font-display: swap или optional, заредете предварително (preload) един или два файла, нужни за първия екран, хоствайте ги при себе си, ако лицензът го позволява, и ограничете броя на дебелините. Всяка допълнителна дебелина е още едно изтегляне. При сайт на български проверете и дали шрифтът изобщо съдържа кирилица, за да не се зарежда резервен.

Скриптове и CSS, които блокират изобразяването

Скрипт в head на страницата без defer или async спира изобразяването, докато не се изтегли и изпълни. Отложете всичко, което не е нужно за първия екран, разделете големите JavaScript пакети, така че всяка страница да зарежда само своя код, и вградете в HTML малкото CSS за първия екран, когато останалото е голямо.

Отговор на сървъра и кеширане

Нищо не се изобразява, преди да пристигне HTML. Времето до първия байт зависи от сървъра, от заявките към базата данни зад страницата и от разстоянието до посетителя. Кеширайте цели страници, където съдържанието го позволява, кеширайте тежките заявки, добавете липсващите индекси в базата и сервирайте статичните файлове с дълги кеш заглавки през CDN. Ако сайтът е надраснал хостинг плана си, може да му трябват и повече ресурси. За това решение сме писали в статията кога да преминете от споделен хостинг към VPS.

#Защо INP е слаб

INP страда, когато основната нишка на браузъра е заета и не може да отговори. Обичайните причини са:

• Външни скриптове. Аналитика, чат приспособления, рекламни скриптове, топлинни карти и tag мениджъри работят в същата нишка като страницата ви. Преглеждайте ги веднъж годишно, махнете онези, чиито данни никой не гледа, и зареждайте останалите, след като страницата е готова за работа.
• Тежки обработчици на събития. Клик, който предизвиква голямо преизобразяване или бавно изчисление, забавя следващото изрисуване. Първо покажете видима реакция, после свършете тежката работа и разделяйте дългите задачи на по-малки.
• Твърде много JavaScript като цяло. Голяма рамка, която „съживява“ (hydration) цялата страница на телефон от среден клас, отнема време. Изобразявайте повече на сървъра и изпращайте по-малко код към браузъра.

#Откъде идва разместването на оформлението

CLS обикновено се поправя най-лесно, защото причините се виждат, щом започнете да ги търсите:

• Изображения и видео без атрибути width и height или CSS aspect-ratio, така че браузърът не може да им запази място.
• Банери за бисквитки, промоционални ленти и вградени елементи, които се вмъкват над вече показано съдържание. Запазете им място или ги показвайте върху страницата.
• Реклами и iframe елементи, които сменят размера си след зареждане. Задайте на контейнерите им фиксиран минимален размер.
• Уеб шрифтове, които при смяната се оказват с много различни размери. Изберете резервен шрифт с близки пропорции или го коригирайте с CSS дескриптора size-adjust.
• Съдържание, което JavaScript добавя след зареждане, например блок „подобни продукти“, без заместител с правилната височина.

#Колко работа по скоростта си струва

Core Web Vitals са един от многото сигнали на Google и за класирането полезното съдържание продължава да тежи повече. По-силната причина да се занимавате със скоростта са посетителите: страница, която се зарежда бързо и реагира веднага, се ползва по-лесно и от нея се купува по-лесно. Можете да го измерите за собствения си сайт, като сравните в аналитиката конверсиите или отказите при по-бързите и по-бавните групи страници преди и след поправката.

Скоростта се влошава с времето. Нови скриптове, по-големи изображения и допълнителни плъгини идват един по един. Добавете лабораторна проверка към процеса по пускане на нови версии, за да хващате промените, които вредят на скоростта, преди да стигнат до посетителите, и преглеждайте реалните данни като част от редовната поддръжка на сайта след пускането.

#Как може да помогне PN Scripts

PN Scripts изработва и поддържа уеб приложения на различни технологии и прегледът на скоростта може да е част от тази работа: откриваме какво забавя страниците ви при реалните посетители, поправяме го по реда на ефекта и добавяме проверки, за да не се върне проблемът. Ако сайтът ви има нужда от такова внимание, вижте страницата за уеб разработка по поръчка.