Core Web Vitals обяснени: LCP, INP и CLS на разбираем език

Core Web Vitals не са тест за личността на вашия уебсайт

Core Web Vitals често се третират като мистериозна система за оценяване. Страницата получава червено число, някой публикува екранна снимка в Slack и екипът започва да спори за JavaScript frameworks.

Това не е особено полезно.

По-добрият начин да мислите за Core Web Vitals е по-прост: те са три измервания за това дали една страница се усеща използваема за реален човек на реално устройство. Те не обхващат всеки аспект на производителността, достъпността или качеството. Но улавят три често срещани източника на неудовлетворение:

• Основното съдържание се появява твърде бавно.
• Страницата реагира бавно, когато потребителят се опита да направи нещо.
• Оформлението подскача, докато потребителят чете или докосва.

Това са трите Core Web Vitals: LCP, INP и CLS.

Google ги използва като част от сигналите си за изживяване на страницата, но SEO гледната точка не е най-добрата причина да ви е грижа. По-добрата причина е, че бавните, подскачащи и неотзивчиви страници губят времето на потребителите. Те също така обикновено конвертират по-зле, поддържат се по-трудно и остаряват лошо.

Трите метрики в по едно изречение

Преди да влезем в подробности, ето версията на разбираем език:

• LCP, или Largest Contentful Paint, измерва колко време отнема зареждането на основното видимо съдържание.
• INP, или Interaction to Next Paint, измерва колко бързо страницата реагира на потребителски взаимодействия по време на посещението.
• CLS, или Cumulative Layout Shift, измерва колко много страницата се мести неочаквано.

Обичайните прагове са:

| Метрика | Добро | Нуждае се от подобрение | Лошо | |---|---:|---:|---:| | LCP | 2.5s или по-бързо | 2.5s–4.0s | Над 4.0s | | INP | 200ms или по-бързо | 200ms–500ms | Над 500ms | | CLS | 0.1 или по-ниско | 0.1–0.25 | Над 0.25 |

Тези числа обикновено се оценяват на 75-ия перцентил от реалните потребителски посещения. Това има значение. Не се опитвате да направите един перфектен лабораторен тест. Опитвате се да направите изживяването добро за повечето потребители, включително хората с по-бавни телефони и по-нестабилни мрежи.

Ако гледате автоматизиран отчет и не сте сигурни откъде да започнете, помага да отделите диагностиката от паниката. Имаме отделно ръководство за това как да четете Lighthouse отчет, без да се паникьосвате, което разглежда този работен процес по-подробно.

LCP: кога страницата се усеща заредена?

Largest Contentful Paint измерва времето за рендиране на най-големия видим елемент със съдържание във viewport. На практика това често е:

• hero изображение,
• голямо заглавие,
• водещо изображение към статия,
• продуктово изображение,
• голям блок текст.

LCP не пита кога всеки script, tracking pixel и изображение под прегъва на страницата са приключили със зареждането. Той пита: кога основното нещо, което потребителят е дошъл да види, стана видимо?

Това прави LCP по-човешка метрика от старомодното „време за зареждане на страницата“. Една страница може технически да приключи зареждането късно, но пак да се усеща бърза, ако основното съдържание се появи бързо. Обратното също е вярно: една страница може да задейства load event, докато hero зоната все още е празна, замъглена или блокирана от забавяне при рендиране.

Чести причини за лош LCP

Повечето проблеми с лош LCP идват от няколко предвидими места:

1. Бавен отговор от сървъра

Ако HTML документът пристигне късно, всичко останало започва късно.

1. CSS или JavaScript, които блокират рендирането

Браузърът има съдържанието, но още не може да го изрисува.

1. Неоптимизирани hero изображения

Най-големият елемент е твърде голям, в неподходящ формат, без приоритет или погрешно зареден с lazy loading.

1. Web fonts, които забавят рендирането на текста

Голямо заглавие може да бъде LCP елементът, а зареждането на шрифта може да го забави или визуално да го промени.

1. Забавяния от client-side rendering

Ако страницата се нуждае от голям JavaScript bundle, преди да може да покаже смислено съдържание, LCP страда.

Как да подобрите LCP

Започнете с действителния LCP елемент. Не оптимизирайте случайни assets, докато не знаете какво измерва браузърът.

Практическите корекции включват:

• Сервирайте HTML бързо: кеширайте, където е подходящо, намалете работата на backend, избягвайте бавни redirects.
• Оптимизирайте LCP изображението: използвайте правилните размери, компресия и формат.
• Не зареждайте hero изображението над прегъва с lazy loading.
• Използвайте fetchpriority="high" внимателно за основното изображение, когато то наистина е приоритет.
• Inline-вайте critical CSS само когато това значимо намалява забавянето при рендиране.
• Намалете JavaScript, необходим преди първото смислено рендиране.
• Използвайте font-display: swap или друга съзнателна стратегия за шрифтове.

Изображенията и шрифтовете често са виновници. При изображенията компромисът не е просто „малък файл е добре“. Изборът на формат, усилието за encoding и поддръжката от браузърите имат значение, затова поддържаме практическо дърво за решения за кога AVIF побеждава WebP и кога не. За страници с много типография web fonts все още са една от най-лесните победи за производителност, защото много сайтове изпращат повече файлове с шрифтове, отколкото използват.

INP: реагира ли страницата при докосване?

Interaction to Next Paint измерва отзивчивостта. По-конкретно, той разглежда забавянето между потребителско взаимодействие и следващото визуално обновяване, след като браузърът е обработил това взаимодействие.

Взаимодействията включват неща като:

• click върху бутон,
• tap върху меню,
• избор на checkbox,
• писане във form field,
• отваряне на accordion.

INP замени First Input Delay като Core Web Vital през 2024 г. Това беше добра промяна. First Input Delay разглеждаше само първото взаимодействие. INP е по-широк: той отчита взаимодействията през цялото посещение на страницата и докладва взаимодействие с висока латентност като оценката за отзивчивост на страницата.

На разбираем език: INP улавя страници, които изглеждат заредени, но се усещат блокирали.

Вероятно сте използвали такава страница. Тя изглежда готова. Докосвате менюто. Нищо не се случва половин секунда. Докосвате отново. После две неща се случват наведнъж. Това е INP проблем.

Чести причини за лош INP

INP обикновено е проблем на main thread. Браузърът иска да реагира, но JavaScript, работа по рендиране или изчисляване на layout му пречат.

Типичните причини включват:

• големи JavaScript bundles,
• скъпи event handlers,
• hydration работа при client-rendered apps,
• third-party scripts, които се конкурират за main thread,
• дълги tasks след зареждане на страницата,
• сложни DOM updates, задействани от малки взаимодействия,
• layout thrashing, при който кодът многократно чете и записва layout стойности.

Marketing tags, analytics, chat widgets и consent banners могат да допринесат. Това не означава „премахнете всичко“. Означава, че всеки script на страницата има цена, а латентността при взаимодействие е мястото, където тази цена често става видима.

Как да подобрите INP

Подобряването на INP е по-малко въпрос на един магически attribute и повече въпрос на намаляване на конкуренцията за main thread.

Полезните подходи включват:

• Разбийте дългите JavaScript tasks на по-малки части.
• Отложете несъществената работа, докато страницата стане използваема.
• Премахнете неизползвания JavaScript, вместо само да го minify-вате.
• Поддържайте event handlers малки и предвидими.
• Избягвайте повторно рендиране на големи части от интерфейса за малки промени в state.
• Използвайте CSS за прости визуални states, където е възможно.
• Одитирайте third-party scripts и ги зареждайте само където са нужни.

Погледнете и дизайна на взаимодействията. Бутон, който дава незабавна визуална обратна връзка, може да се усеща по-отзивчив, дори ако последващата работа отнема повече време. Това не е заместител на производителността, но е част от доброто инженерство на интерфейси. Нашият checklist за достъпни web buttons се припокрива с това: ясни states, правилна семантика и предвидимо поведение помагат както на потребителите, така и на браузърите.

CLS: остава ли страницата там, където потребителят очаква?

Cumulative Layout Shift измерва неочакваното движение на видими елементи. Ако потребител започне да чете параграф и реклама, изображение или banner се зареди над него, избутвайки текста надолу, това допринася за CLS.

CLS не се измерва в секунди. Това е оценка, базирана на това колко съдържание се е преместило и колко далеч се е преместило. По-ниско е по-добре.

Ключовата дума е неочаквано. Промените в layout, причинени от действие на потребителя, обикновено не се броят по същия начин. Ако някой докосне „покажи още“ и съдържанието се разшири, това е очаквано. Ако newsletter banner се появи в горната част след три секунди и избута всичко надолу, това не е.

Чести причини за лош CLS

Провалите при CLS често са прозаични:

• изображения без width и height attributes,
• ads или embeds без запазено пространство,
• cookie banners, вмъкнати над съдържанието,
• web fonts, които се сменят с различни metrics,
• късно зареждащи се promotional bars,
• динамично инжектирано съдържание близо до горната част на страницата.

Корекцията обикновено е да се запази пространство, преди съдържанието да пристигне. Браузърът трябва да знае формата на страницата възможно най-рано.

Как да подобрите CLS

Започнете с видимите размествания. Гледайте запис или използвайте browser tooling, за да установите кои елементи се движат.

След това приложете скучните корекции:

• Добавете explicit width и height attributes към изображенията.
• Използвайте CSS aspect-ratio за responsive media containers.
• Запазете фиксирано или минимално пространство за ads, embeds и iframes.
• Избягвайте инжектиране на banners над съществуващо съдържание след зареждане.
• Изберете font fallbacks с metrics, подобни на крайния шрифт.
• Избягвайте animations, които променят layout properties като top, left, width или height; предпочитайте transforms.

CLS е една от малкото метрики за производителност, при които дисциплината побеждава хитростта. Ако страницата има стабилни boxes, тя обикновено получава добър резултат.

Field data и lab data са полезни, но отговарят на различни въпроси

Чест източник на объркване е, че различните инструменти показват различни числа. Това е нормално.

Field data идват от реални потребители. Те отразяват действителни устройства, мрежи, локации и условия в браузъра. Chrome User Experience Report на Google е пример за field data.

Lab data идват от контролирана тестова среда. Lighthouse е познатият пример. Те са повторяеми и полезни за debugging, но не са същото като преживяното изживяване на вашите потребители.

Използвайте field data, за да решите дали потребителите имат реален проблем. Използвайте lab data, за да възпроизведете и debug-нете този проблем.

Също така помнете, че Core Web Vitals обикновено се оценяват по URL или URL група, а не като едно абстрактно свойство на вашия brand. Вашата начална страница, blog article, pricing page и checkout могат да имат много различни bottlenecks.

Разумен ред на работа

Ако и трите метрики са лоши, изкушението е да започнете навсякъде. Устоявайте.

Практическият ред е:

1. Първо поправете очевидния CLS

Липсващите размери на изображенията и нестабилните banners често са бързи победи.

1. Подобрете LCP за важните templates

Фокусирайте се върху страниците, които имат значение: product pages, landing pages, articles, sign-up flows.

1. Проучете INP с реални взаимодействия

Click-нете нещата, които потребителите действително click-ват. Menus, filters, forms и checkout controls често разкриват повече от initial load trace.

1. Одитирайте third-party scripts

Запазете тези, които оправдават цената си. Премахнете или отложете тези, които не го правят.

1. Задайте performance budget

Без budget подобренията в производителността се разпадат. Нови scripts, images и design components тихо ще отменят свършената работа.

Важното: не оптимизирайте за badge. Оптимизирайте за user journey. Незначително подобрение на оценката на страница с нисък трафик може да е по-малко важно от леко несъвършено, но много по-бързо checkout interaction.

<!-- tool-cta:start -->

💡 Опитайте това: Тъй като LCP обикновено е проблем с изображение, намалете размера на основното си изображение с Image Compressor като първа, лесна победа.

<!-- tool-cta:end -->

Какво Core Web Vitals не ви казват

Core Web Vitals са полезни, но непълни.

Те не ви казват дали съдържанието ви е добро. Не ви казват дали навигацията ви има смисъл. Не гарантират достъпност. Не измерват поверителност, сигурност, доверие, четимост или дали страницата отговаря на въпроса на потребителя.

Те също така не заместват преценката. Една страница може да покрива Core Web Vitals и пак да е неприятна. Сложно приложение може да не достигне праг, но пак да е отговорно инженерно проектирано спрямо ограниченията си.

Отнасяйте се към LCP, INP и CLS като към датчици за дим. Когато се задействат, разследвайте. Когато са тихи, продължавайте да поддържате сградата.