Core Web Vitals објашњени: LCP, INP и CLS једноставним језиком

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

Core Web Vitals се често посматрају као мистериозна табела резултата. Страница добије црвени број, неко објави screenshot у Slack-у, а тим почне да се расправља о JavaScript framework-овима.

То није нарочито корисно.

Бољи начин да размишљате о Core Web Vitals је једноставнији: то су три мерења која показују да ли страница делује употребљиво стварној особи на стварном уређају. Они не обухватају сваки аспект перформанси, приступачности или квалитета. Али хватају три честа извора фрустрације:

• Главном садржају треба предуго да се појави.
• Страница споро реагује када корисник покуша нешто да уради.
• Распоред скаче док корисник чита или додирује екран.

То су три Core Web Vitals: LCP, INP и CLS.

Google их користи као део својих сигнала за page experience, али 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 не пита када су се свака скрипта, tracking pixel и слика испод прелома странице завршили са учитавањем. Он пита: када је главна ствар због које је корисник дошао постала видљива?

Зато је LCP људскија метрика од старомодног „времена учитавања странице“. Страница технички може касно да заврши учитавање, али и даље да делује брзо ако се главни садржај појави брзо. Важи и обрнуто: страница може да окине load event док је hero зона још празна, замућена или блокирана кашњењем рендеровања.

Чести узроци лошег LCP-а

Већина проблема са лошим LCP-ом долази из неколико предвидљивих места:

1. Спор одговор сервера

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

1. CSS или JavaScript који блокирају рендеровање

Прегледач има садржај, али још не може да га прикаже.

1. Неоптимизоване hero слике

Највећи елемент је превелик, у погрешном формату, није приоритетизован или је грешком учитан lazy-load-ом.

1. Web fonts који одлажу рендеровање текста

Велики наслов може бити LCP елемент, а учитавање фонта може да га одложи или визуелно промени.

1. Кашњења због client-side rendering-а

Ако страници треба велики JavaScript bundle пре него што може да прикаже смислен садржај, LCP трпи.

Како побољшати LCP

Почните од стварног LCP елемента. Не оптимизујте насумичне ресурсе док не знате шта прегледач мери.

Практична решења укључују:

• Испоручујте HTML брзо: кеширајте где има смисла, смањите рад backend-а, избегавајте споре redirect-е.
• Оптимизујте LCP слику: користите одговарајуће димензије, компресију и формат.
• Немојте lazy-load-овати hero слику изнад прелома странице.
• Пажљиво користите fetchpriority="high" за главну слику када је она заиста приоритет.
• Inline-ујте критични CSS само када то смислено смањује кашњење рендеровања.
• Смањите JavaScript потребан пре првог смисленог рендеровања.
• Користите font-display: swap или другу намерну стратегију за фонтове.

Слике и фонтови су чести кривци. Код слика, компромис није само „мала датотека је добра“. Избор формата, напор кодирања и подршка прегледача су важни, због чега одржавамо практично стабло одлучивања за када AVIF побеђује WebP, а када не. За странице са много типографије, web fonts су и даље једна од најлакших победа за перформансе, јер многи сајтови испоручују више датотека фонтова него што користе.

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

Interaction to Next Paint мери одзивност. Прецизније, посматра кашњење између корисничке интеракције и следећег визуелног ажурирања након што је прегледач обрадио ту интеракцију.

Интеракције укључују ствари као што су:

• клик на дугме,
• додир менија,
• избор checkbox-а,
• куцање у поље форме,
• отварање accordion-а.

INP је 2024. заменио First Input Delay као Core Web Vital. То је била добра промена. First Input Delay је посматрао само прву интеракцију. INP је шири: узима у обзир интеракције током целе посете страници и пријављује интеракцију са великом латенцијом као оцену одзивности странице.

Једноставно речено: INP хвата странице које изгледају учитано, али делују заглављено.

Вероватно сте користили такву страницу. Делује спремно. Додирнете мени. Ништа се не дешава пола секунде. Додирнете поново. Онда се две ствари догоде одједном. То је INP проблем.

Чести узроци лошег INP-а

INP је обично проблем главне нити. Прегледач жели да реагује, али му JavaScript, рад на рендеровању или израчунавање распореда стоје на путу.

Типични узроци укључују:

• велике JavaScript bundle-ове,
• скупе event handler-е,
• hydration рад у апликацијама рендерованим на клијенту,
• third-party скрипте које се такмиче за главну нит,
• дуготрајне задатке после учитавања странице,
• сложена ажурирања DOM-а покренута малим интеракцијама,
• layout thrashing, где код изнова чита и уписује вредности распореда.

Маркетиншки тагови, аналитика, chat widget-и и consent banner-и могу сви да допринесу. То не значи „уклоните све“. Значи да свака скрипта на страници има цену, а латенција интеракције је место где та цена често постаје видљива.

Како побољшати INP

Побољшање INP-а мање је ствар једног магичног атрибута, а више смањења надметања за главну нит.

Корисни приступи укључују:

• Разбијте дуге JavaScript задатке на мање делове.
• Одложите несуштински рад док страница не постане употребљива.
• Уклоните некоришћени JavaScript уместо да га само minify-ујете.
• Држите event handler-е малим и предвидљивим.
• Избегавајте поновно рендеровање великих делова интерфејса због ситних промена стања.
• Користите CSS за једноставна визуелна стања где је могуће.
• Ревидирајте third-party скрипте и учитавајте их само тамо где су потребне.

Погледајте и дизајн интеракције. Дугме које одмах даје визуелну повратну информацију може деловати одзивније, чак и ако накнадни рад траје дуже. То није замена за перформансе, али јесте део доброг инжењеринга интерфејса. Наша checklist-а за приступачну web дугмад се преклапа са овим: јасна стања, исправна семантика и предвидљиво понашање помажу и корисницима и прегледачима.

CLS: да ли страница остаје тамо где је корисник очекује?

Cumulative Layout Shift мери неочекивано померање видљивих елемената. Ако корисник почне да чита пасус, а оглас, слика или banner се учита изнад њега и гурне текст надоле, то доприноси CLS-у.

CLS се не мери у секундама. То је резултат заснован на томе колико се садржај померио и колико далеко се померио. Ниже је боље.

Кључна реч је неочекивано. Промене распореда изазване корисничком радњом обично се не рачунају на исти начин. Ако неко додирне „прикажи више“ и садржај се прошири, то је очекивано. Ако се newsletter banner појави на врху после три секунде и гурне све надоле, то није.

Чести узроци лошег CLS-а

CLS неуспеси су често прозаични:

• слике без width и height атрибута,
• огласи или embed-ови без резервисаног простора,
• cookie banner-и уметнути изнад садржаја,
• web fonts који се замењују фонтовима са различитим метрикама,
• касно учитане промотивне траке,
• динамички уметнут садржај близу врха странице.

Решење је обично да се простор резервише пре него што садржај стигне. Прегледач треба да зна облик странице што је раније могуће.

Како побољшати CLS

Почните од видљивих померања. Погледајте снимак или користите алате прегледача да утврдите који елементи се померају.

Затим примените досадна решења:

• Додајте експлицитне width и height атрибуте сликама.
• Користите CSS aspect-ratio за responsive media containers.
• Резервишите фиксни или минимални простор за огласе, embed-ове и iframe-ове.
• Избегавајте уметање banner-а изнад постојећег садржаја после учитавања.
• Изаберите fallback фонтове са метрикама сличним финалном фонту.
• Избегавајте анимације које мењају layout properties као што су top, left, width или height; радије користите transforms.

CLS је једна од ретких метрика перформанси где дисциплина побеђује досетљивост. Ако страница има стабилне оквире, обично има добар резултат.

Field data и lab data су обоје корисни, али одговарају на различита питања

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

Field data долази од стварних корисника. Одражава стварне уређаје, мреже, локације и услове у прегледачу. Google Chrome User Experience Report је пример field data.

Lab data долази из контролисаног тест окружења. Lighthouse је познат пример. Поновљив је и користан за debugging, али није исто што и проживљено искуство ваших корисника.

Користите field data да одлучите да ли корисници имају стварни проблем. Користите lab data да репродукујете и debug-ујете тај проблем.

Такође имајте на уму да се Core Web Vitals обично процењују по URL-у или URL групи, а не као једно апстрактно својство вашег бренда. Ваша почетна страница, blog чланак, pricing страница и checkout могу имати веома различита уска грла.

Разуман редослед рада

Ако су све три метрике лоше, искушење је да почнете свуда. Одуприте се томе.

Практичан редослед је:

1. Прво исправите очигледан CLS

Недостајуће димензије слика и нестабилни banner-и често су брзе победе.

1. Побољшајте LCP за важне template-е

Фокусирајте се на странице које су важне: product pages, landing pages, articles, sign-up flows.

1. Истражите INP кроз стварне интеракције

Кликните на ствари на које корисници заиста кликћу. Менији, филтери, форме и checkout контроле често открију више него почетни траг учитавања.

1. Ревидирајте third-party скрипте

Задржите оне које оправдавају своју цену. Уклоните или одложите оне које је не оправдавају.

1. Поставите performance budget

Без буџета, побољшања перформанси пропадају. Нове скрипте, слике и design components тихо ће поништити рад.

Важна поента: не оптимизујте за значку. Оптимизујте за корисничко путовање. Маргинално побољшање резултата на страници са малим саобраћајем може бити мање важно од благо несавршене, али много брже checkout интеракције.

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

💡 Испробајте ово: Пошто је LCP обично проблем са сликом, смањите свој главни визуелни елемент помоћу Image Compressor као прву, лаку победу.

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

Шта вам Core Web Vitals не говоре

Core Web Vitals су корисни, али непотпуни.

Не говоре вам да ли је ваш садржај добар. Не говоре вам да ли ваша навигација има смисла. Не гарантују приступачност. Не мере приватност, безбедност, поверење, читљивост нити то да ли страница одговара на корисниково питање.

Такође не замењују расуђивање. Страница може проћи Core Web Vitals и и даље бити непријатна. Сложена апликација може промашити праг, а да је и даље одговорно пројектована у складу са својим ограничењима.

Третирајте LCP, INP и CLS као аларме за дим. Када се огласе, истражите. Када су тихи, наставите да одржавате зграду.