Core Web Vitals explicate: LCP, INP și CLS în limbaj simplu

Core Web Vitals nu sunt un test de personalitate pentru site-ul tău

Core Web Vitals sunt adesea tratate ca o fișă de scor misterioasă. O pagină primește un număr roșu, cineva postează o captură de ecran în Slack, iar echipa începe să se certe despre framework-uri JavaScript.

Asta nu este deosebit de util.

Un mod mai bun de a privi Core Web Vitals este mai simplu: sunt trei măsurători ale faptului că o pagină se simte utilizabilă pentru o persoană reală, pe un dispozitiv real. Nu surprind fiecare aspect al performanței, accesibilității sau calității. Dar surprind trei surse frecvente de frustrare:

• Conținutul principal apare prea greu.
• Pagina reacționează lent când utilizatorul încearcă să facă ceva.
• Layoutul sare în timp ce utilizatorul citește sau atinge ecranul.

Acestea sunt cele trei Core Web Vitals: LCP, INP și CLS.

Google le folosește ca parte a semnalelor sale privind experiența pe pagină, dar unghiul SEO nu este cel mai bun motiv pentru care ar trebui să-ți pese. Motivul mai bun este că paginile lente, instabile și fără răspuns irosesc timpul utilizatorilor. De asemenea, tind să convertească mai slab, să genereze mai multe probleme de suport și să îmbătrânească prost.

Cele trei metrici, într-o propoziție fiecare

Înainte de detalii, iată versiunea în limbaj simplu:

• LCP, sau Largest Contentful Paint, măsoară cât durează până se încarcă principalul conținut vizibil.
• INP, sau Interaction to Next Paint, măsoară cât de repede răspunde pagina la interacțiunile utilizatorului pe parcursul vizitei.
• CLS, sau Cumulative Layout Shift, măsoară cât de mult se mișcă neașteptat pagina.

Pragurile obișnuite sunt:

| Metrică | Bun | Necesită îmbunătățiri | Slab | |---|---:|---:|---:| | LCP | 2,5s sau mai rapid | 2,5s–4,0s | Peste 4,0s | | INP | 200ms sau mai rapid | 200ms–500ms | Peste 500ms | | CLS | 0,1 sau mai mic | 0,1–0,25 | Peste 0,25 |

Aceste numere sunt evaluate în mod normal la percentila 75 a vizitelor utilizatorilor reali. Asta contează. Nu încerci să obții o rulare perfectă în laborator. Încerci să faci experiența bună pentru majoritatea utilizatorilor, inclusiv pentru oameni pe telefoane mai lente și rețele mai dezordonate.

Dacă te uiți la un raport automatizat și nu știi de unde să începi, ajută să separi diagnosticul de panică. Avem un ghid separat despre cum să citești un raport Lighthouse fără să intri în panică, care acoperă acest flux de lucru mai detaliat.

LCP: când se simte pagina încărcată?

Largest Contentful Paint măsoară timpul de randare al celui mai mare element de conținut vizibil din viewport. În practică, acesta este adesea:

• o imagine hero,
• un titlu mare,
• o imagine principală de articol,
• o imagine de produs,
• un bloc mare de text.

LCP nu întreabă când au terminat de încărcat toate scripturile, pixelii de tracking și imaginile de sub zona vizibilă inițial. Întreabă: când a devenit vizibil lucrul principal pe care utilizatorul a venit să îl vadă?

Asta face din LCP o metrică mai umană decât vechiul „timp de încărcare a paginii”. O pagină poate termina tehnic încărcarea târziu, dar totuși să se simtă rapidă dacă principalul conținut apare repede. Și inversul este adevărat: o pagină poate declanșa evenimentul de load în timp ce zona hero este încă goală, neclară sau blocată de o întârziere de randare.

Cauze frecvente ale unui LCP slab

Cele mai multe probleme de LCP slab vin din câteva locuri previzibile:

1. Răspuns lent al serverului

Dacă documentul HTML ajunge târziu, tot restul începe târziu.

1. CSS sau JavaScript care blochează randarea

Browserul are conținutul, dar încă nu îl poate afișa.

1. Imagini hero neoptimizate

Cel mai mare element este prea mare, în formatul greșit, neprioritizat sau încărcat lazy din greșeală.

1. Fonturi web care întârzie randarea textului

Un titlu mare poate fi elementul LCP, iar încărcarea fontului îl poate întârzia sau modifica vizual.

1. Întârzieri de randare pe client

Dacă pagina are nevoie de un bundle JavaScript mare înainte să poată afișa conținut semnificativ, LCP are de suferit.

Cum să îmbunătățești LCP

Începe cu elementul LCP real. Nu optimiza asset-uri la întâmplare până nu știi ce măsoară browserul.

Remedieri practice includ:

• Servește HTML rapid: folosește cache unde este potrivit, redu munca din backend, evită redirecturile lente.
• Optimizează imaginea LCP: folosește dimensiunile, compresia și formatul potrivite.
• Nu încărca lazy imaginea hero aflată deasupra zonei vizibile inițial.
• Folosește fetchpriority="high" cu grijă pentru imaginea principală atunci când este cu adevărat prioritară.
• Include inline CSS critic doar când reduce semnificativ întârzierea de randare.
• Redu JavaScript-ul necesar înainte de prima randare semnificativă.
• Folosește font-display: swap sau o altă strategie intenționată pentru fonturi.

Imaginile și fonturile sunt vinovați frecvenți. Pentru imagini, compromisul nu este doar „fișier mic bun”. Alegerea formatului, efortul de codare și suportul browserelor contează toate, motiv pentru care păstrăm un arbore decizional practic pentru când AVIF bate WebP și când nu. Pentru paginile cu mult text, fonturile web rămân una dintre cele mai ușoare victorii de performanță, deoarece multe site-uri livrează mai multe fișiere de font decât folosesc.

INP: răspunde pagina când este atinsă?

Interaction to Next Paint măsoară capacitatea de răspuns. Mai exact, analizează întârzierea dintre o interacțiune a utilizatorului și următoarea actualizare vizuală după ce browserul a procesat acea interacțiune.

Interacțiunile includ lucruri precum:

• click pe un buton,
• atingerea unui meniu,
• selectarea unui checkbox,
• tastarea într-un câmp de formular,
• deschiderea unui accordion.

INP a înlocuit First Input Delay ca Core Web Vital în 2024. A fost o schimbare bună. First Input Delay analiza doar prima interacțiune. INP este mai amplu: ia în considerare interacțiunile pe tot parcursul vizitei pe pagină și raportează o interacțiune cu latență mare ca scor de responsivitate al paginii.

În limbaj simplu: INP surprinde paginile care par încărcate, dar se simt blocate.

Probabil ai folosit o astfel de pagină. Pare gata. Atingi meniul. Nu se întâmplă nimic timp de jumătate de secundă. Atingi din nou. Apoi se întâmplă două lucruri deodată. Aceasta este o problemă de INP.

Cauze frecvente ale unui INP slab

INP este de obicei o problemă de main thread. Browserul vrea să răspundă, dar JavaScript-ul, munca de randare sau calculul layoutului stau în cale.

Cauze tipice includ:

• bundle-uri JavaScript mari,
• event handlers costisitori,
• muncă de hydration în aplicații randate pe client,
• scripturi third-party care concurează pentru main thread,
• taskuri de lungă durată după încărcarea paginii,
• actualizări complexe ale DOM-ului declanșate de interacțiuni mici,
• layout thrashing, când codul citește și scrie repetat valori de layout.

Tagurile de marketing, analytics, widgeturile de chat și bannerele de consimțământ pot contribui toate. Asta nu înseamnă „elimină tot”. Înseamnă că fiecare script de pe pagină are un cost, iar latența interacțiunilor este locul în care acel cost devine adesea vizibil.

Cum să îmbunătățești INP

Îmbunătățirea INP ține mai puțin de un atribut magic și mai mult de reducerea competiției pe main thread.

Abordări utile includ:

• Împarte taskurile JavaScript lungi în bucăți mai mici.
• Amână munca neesențială până după ce pagina este utilizabilă.
• Elimină JavaScript-ul nefolosit, nu doar îl minifica.
• Păstrează event handlers mici și previzibili.
• Evită rerandarea unor părți mari ale interfeței pentru schimbări minuscule de stare.
• Folosește CSS pentru stări vizuale simple, unde este posibil.
• Auditează scripturile third-party și încarcă-le doar acolo unde sunt necesare.

Uită-te și la designul interacțiunilor. Un buton care oferă feedback vizual imediat poate părea mai responsiv, chiar dacă munca ulterioară durează mai mult. Nu este un substitut pentru performanță, dar face parte din ingineria bună a interfețelor. Checklistul nostru pentru butoane web accesibile se suprapune cu acest subiect: stările clare, semantica potrivită și comportamentul previzibil ajută atât utilizatorii, cât și browserele.

CLS: rămâne pagina acolo unde se așteaptă utilizatorul?

Cumulative Layout Shift măsoară mișcarea neașteptată a elementelor vizibile. Dacă un utilizator începe să citească un paragraf și o reclamă, o imagine sau un banner se încarcă deasupra lui, împingând textul în jos, asta contribuie la CLS.

CLS nu se măsoară în secunde. Este un scor bazat pe cât conținut s-a mișcat și pe ce distanță s-a mișcat. Mai mic este mai bine.

Cuvântul-cheie este neașteptată. Schimbările de layout cauzate de o acțiune a utilizatorului nu sunt de obicei contabilizate în același fel. Dacă cineva atinge „arată mai mult” și conținutul se extinde, asta este de așteptat. Dacă un banner de newsletter apare în partea de sus după trei secunde și împinge totul în jos, nu este.

Cauze frecvente ale unui CLS slab

Eșecurile CLS sunt adesea banale:

• imagini fără atribute width și height,
• reclame sau embeduri fără spațiu rezervat,
• bannere de cookies inserate deasupra conținutului,
• fonturi web care se schimbă cu metrici diferite,
• bare promoționale încărcate târziu,
• conținut injectat dinamic aproape de partea de sus a paginii.

Remedierea este de obicei să rezervi spațiu înainte ca acel conținut să ajungă. Browserul ar trebui să cunoască forma paginii cât mai devreme posibil.

Cum să îmbunătățești CLS

Începe cu deplasările vizibile. Urmărește o înregistrare sau folosește instrumentele browserului pentru a identifica elementele care se mișcă.

Apoi aplică remedierile plictisitoare:

• Adaugă atribute explicite width și height imaginilor.
• Folosește CSS aspect-ratio pentru containere media responsive.
• Rezervă spațiu fix sau minim pentru reclame, embeduri și iframes.
• Evită injectarea bannerelor deasupra conținutului existent după încărcare.
• Alege fonturi fallback cu metrici similare fontului final.
• Evită animațiile care schimbă proprietăți de layout precum top, left, width sau height; preferă transforms.

CLS este una dintre puținele metrici de performanță unde disciplina bate istețimea. Dacă pagina are casete stabile, tinde să obțină un scor bun.

Datele din teren și datele de laborator sunt ambele utile, dar răspund la întrebări diferite

O sursă frecventă de confuzie este faptul că instrumente diferite arată numere diferite. Este normal.

Datele din teren provin de la utilizatori reali. Ele reflectă dispozitive, rețele, locații și condiții reale ale browserului. Chrome User Experience Report de la Google este un exemplu de date din teren.

Datele de laborator provin dintr-un mediu de testare controlat. Lighthouse este exemplul familiar. Este repetabil și util pentru debugging, dar nu este același lucru cu experiența trăită de utilizatorii tăi.

Folosește datele din teren pentru a decide dacă utilizatorii au o problemă reală. Folosește datele de laborator pentru a reproduce și depana acea problemă.

Amintește-ți și că Core Web Vitals sunt de obicei evaluate pe URL sau pe grup de URL-uri, nu ca o singură proprietate abstractă a brandului tău. Pagina de start, articolul de blog, pagina de prețuri și checkoutul pot avea blocaje foarte diferite.

O ordine de lucru rezonabilă

Dacă toate cele trei metrici sunt slabe, tentația este să începi peste tot. Rezistă.

O ordine practică este:

1. Rezolvă mai întâi CLS-ul evident

Dimensiunile lipsă ale imaginilor și bannerele instabile sunt adesea victorii rapide.

1. Îmbunătățește LCP pentru template-urile importante

Concentrează-te pe paginile care contează: pagini de produs, landing pages, articole, fluxuri de înscriere.

1. Investighează INP cu interacțiuni reale

Dă click pe lucrurile pe care utilizatorii chiar dau click. Meniurile, filtrele, formularele și controalele de checkout dezvăluie adesea mai mult decât trace-ul încărcării inițiale.

1. Auditează scripturile third-party

Păstrează-le pe cele care își justifică costul. Elimină-le sau întârzie-le pe cele care nu o fac.

1. Stabilește un buget de performanță

Fără un buget, îmbunătățirile de performanță se degradează. Scripturi, imagini și componente de design noi vor anula în tăcere munca.

Ideea importantă: nu optimiza pentru o insignă. Optimizează pentru parcursul utilizatorului. O îmbunătățire marginală a scorului pe o pagină cu trafic redus poate conta mai puțin decât o interacțiune de checkout ușor imperfectă, dar mult mai rapidă.

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

💡 Încearcă asta: Deoarece LCP este de obicei o problemă de imagine, micșorează elementul hero cu Image Compressor ca o primă victorie ușoară.

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

Ce nu îți spun Core Web Vitals

Core Web Vitals sunt utile, dar incomplete.

Nu îți spun dacă ai conținut bun. Nu îți spun dacă navigarea ta are sens. Nu garantează accesibilitatea. Nu măsoară confidențialitatea, securitatea, încrederea, lizibilitatea sau dacă pagina răspunde la întrebarea utilizatorului.

De asemenea, nu înlocuiesc judecata. O pagină poate trece Core Web Vitals și totuși să fie neplăcută. O aplicație complexă poate rata un prag și totuși să fie proiectată responsabil pentru constrângerile sale.

Tratează LCP, INP și CLS ca pe niște alarme de fum. Când pornesc, investighează. Când sunt tăcute, continuă să întreții clădirea.