Core Web Vitals: LCP, INP și CLS

Modulul 4: Viteză, mobil și https · Timp de citire: 13 minute

Obiectivul lecției: După această lecție veți putea explica cele trei Core Web Vitals împreună cu valorile lor limită, veți putea numi diferența dintre datele de teren și datele de laborator, veți putea citi o măsurătoare cu PageSpeed Insights, veți putea aborda cele mai importante cauze ale unui scor slab și veți putea aprecia corect cât de mult contează viteza în rezultatele căutării.

Concepte cheie: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), percentila 75, date de teren (CrUX), date de laborator (Lighthouse), PageSpeed Insights, raportul Core Web Vitals din Search Console, TTFB, compresie, width și height la imagini, loading="lazy", experiența paginii

Viteza în trei cifre

„Este site-ul meu rapid?” este o întrebare vagă. Google și creatorii Chrome au transformat-o în trei întrebări măsurabile, Core Web Vitals:

Câteva lucruri pe care este bine să le înțelegeți:

• LCP măsoară momentul în care apare cel mai mare element vizibil. De obicei este o fotografie mare în partea de sus (imaginea „hero”) sau un bloc mare de text. La Bloemenatelier Lotte este fotografia aranjamentului floral de pe pagina principală.
• INP ia în calcul toate clicurile, atingerile și apăsările de taste din timpul vizitei și raportează (aproape) cea mai lentă reacție. La 12 martie 2024, INP a înlocuit măsurătoarea mai veche FID (First Input Delay), care se uita doar la primul clic și doar la așteptarea dinaintea procesării. Dacă întâlniți FID într-un articol vechi, informația este depășită.
• CLS nu este un timp, ci un scor fără unitate de măsură. Acesta crește când elementele se deplasează în timp ce citiți: vreți să atingeți un buton și exact în acel moment apare deasupra un banner, astfel încât atingeți altceva.

Percentila 75

O pagină „trece” de Core Web Vitals dacă 75 la sută din vizite obțin un scor bun la toate trei, măsurate separat pentru mobil și desktop. Acest lucru se numește percentila 75. Înseamnă că nu contează computerul dumneavoastră rapid, conectat la fibră optică, ci experiența majorității vizitatorilor, inclusiv a celor cu un telefon mai vechi pe 4G.

Date de teren și date de laborator

Există două tipuri de măsurători, iar acestea dau adesea cifre diferite.

• Datele de teren provin de la vizitatori reali. Chrome colectează anonim (la utilizatorii care permit acest lucru) cât de rapide au fost paginile, în Chrome User Experience Report (CrUX). PageSpeed Insights afișează datele de teren din ultimele 28 de zile. Raportul Core Web Vitals din Search Console folosește aceeași sursă. Dacă pagina dumneavoastră are prea puțini vizitatori, PageSpeed Insights afișează cifrele întregului site (așa-numitul „origin”), iar dacă nici acesta nu are destui, nu există date de teren.
• Datele de laborator provin dintr-un test simulat cu Lighthouse: o singură încărcare pe un telefon și o conexiune medii, simulate. Lighthouse nu poate măsura INP (nimeni nu dă clic), de aceea oferă alte cifre, precum Total Blocking Time, care sunt totuși un indiciu pentru INP.

Datele de teren sunt cele care contează pentru evaluare. Datele de laborator sunt utile pentru a găsi cauzele și pentru a vedea imediat după o îmbunătățire dacă aceasta ajută, fără să așteptați 28 de zile.

Cât de mult contează?

Aici se exagerează mult. Iată ce spune Google însuși în documentația despre experiența paginii:

• „Core Web Vitals are used by our ranking systems”: deci contează.
• Nu există un „semnal de experiență a paginii” separat. Alte componente ale unei experiențe bune (https, fără ferestre pop-up intruzive, utilizare ușoară pe mobil) nu vă ajută direct să urcați mai sus, potrivit Google, dar fac site-ul dumneavoastră mai plăcut.
• „Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” O pagină lentă cu cel mai bun răspuns poate deci să apară foarte bine pe primul loc.
• Obținerea unui scor perfect doar pentru SEO „poate nu este cea mai bună utilizare a timpului dumneavoastră”, potrivit Google.

Concluzie: asigurați-vă că vă aflați în zona verde sau cel puțin în cea portocalie, mai ales pentru că vizitatorii abandonează o pagină lentă sau care se deplasează. Urmărirea saltului de la 90 la 100 de puncte în Lighthouse aduce puțin în rezultatele căutării.

Cauzele pe care le puteți aborda singuri

O primă reacție lentă (TTFB)

Totul începe cu momentul în care sosește primul byte din HTML, Time to First Byte. TTFB nu este el însuși un Core Web Vital, dar un TTFB lent face aproape imposibil un LCP bun. web.dev indică drept valoare orientativă: bun înseamnă 0,8 secunde sau mai puțin, slab înseamnă peste 1,8 secunde. Cauzele, potrivit web.dev: putere de calcul prea mică la găzduire, lipsa cache-ului (fiecare pagină este construită din nou, tipic pentru WordPress fără plugin de cache), redirecționările (lecția 4.1) și un server aflat departe, fără CDN.

Compresia face și ea parte din acest subiect: serverul ar trebui să trimită HTML, CSS și JavaScript comprimate cu gzip sau Brotli. Recunoașteți acest lucru după antetul Content-Encoding: gzip sau br. Aproape orice găzduire face acest lucru implicit, dar o setare greșită sau un server vechi o poate dezactiva.

Imagini

Imaginile sunt cea mai frecventă cauză a unui LCP și CLS slab:

1. Prea mari. O fotografie de 4.000 de pixeli lățime și 5 MB pentru un spațiu de 800 de pixeli. Micșorați-o înainte de încărcare și folosiți un format modern precum WebP sau AVIF.

2. Fără lățime și înălțime. Fără width și height, browserul nu știe cât spațiu are nevoie imaginea, iar textul de dedesubt se deplasează imediat ce imaginea sosește. web.dev recomandă să adăugați width și height la fiecare <img>:

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

3. Încărcarea leneșă a celei mai importante fotografii. loading="lazy" face ca o imagine să se încarce abia când ajunge pe ecran. Este foarte bine pentru fotografiile mai de jos, dar web.dev spune clar: imaginile care sunt deja vizibile la deschidere, și cu atât mai mult imaginea LCP, NU trebuie încărcate leneș. Altfel browserul amână tocmai fotografia care vă determină LCP-ul.

Conținut care se deplasează și reacții lente

Alte cauze ale CLS, potrivit web.dev: fonturi care își schimbă dimensiunea la încărcare, reclame și widgeturi încorporate care se măresc singure și conținut inserat ulterior deasupra conținutului existent (de exemplu o bară de cookie-uri care împinge pagina în jos în loc să stea deasupra ei). Un INP slab se datorează aproape întotdeauna prea multului JavaScript: teme grele, slidere, widgeturi de chat și instrumente de urmărire ale terților. Analizați critic fiecare plugin sau serviciu încorporat; aici mai puțin înseamnă cu adevărat mai mult.

În practică: măsurarea cu PageSpeed Insights

Accesați pagespeed.web.dev, introduceți adresa paginii dumneavoastră principale și dați clic pe Analyze. Primiți două file (Mobile și Desktop). În partea de sus se află evaluarea Core Web Vitals pe baza datelor de teren, dacă acestea există. Dedesubt se află testul Lighthouse, cu un scor și o listă „Diagnostics” cu puncte concrete, de exemplu despre imagini mai mari decât este necesar sau o imagine LCP încărcată leneș (denumirile exacte se schimbă odată cu versiunile noi de Lighthouse). Începeți cu Mobile: acolo rezultatul este de obicei mai slab, iar Google se uită mai întâi la versiunea mobilă (lecția 4.2).

Dacă aveți site-ul în Search Console (modulul 2), consultați și Experience, Core Web Vitals. Acolo vedeți grupuri de pagini similare cu starea lor, inclusiv pentru pagini pe care nu le-ați testat singuri.

Un site realizat cu AI Builder adaugă lățimea și înălțimea la imaginile a căror dimensiune este cunoscută, încarcă prima fotografie a paginii direct și cu prioritate (fetchpriority="high"), iar pe celelalte leneș, și creează la publicare o variantă de 800 de pixeli lățime a fotografiilor mari. În WordPress ajută cel mai mult un plugin de cache și micșorarea imaginilor; cursul despre WordPress tratează acest subiect mai detaliat în modulul 6. La alte platforme de creare a site-urilor și la alte firme de găzduire lucrurile funcționează asemănător: butoanele diferă, cauzele sunt aceleași.

Rezumat

• Core Web Vitals sunt LCP (bun până la 2,5 s), INP (bun până la 200 ms, din martie 2024 în locul FID) și CLS (bun până la 0,1), măsurate la percentila 75 pentru fiecare tip de dispozitiv.
• Datele de teren (CrUX, 28 de zile) determină evaluarea; datele de laborator (Lighthouse) ajută la găsirea cauzelor.
• Google folosește Core Web Vitals în clasament, dar relevanța are prioritate: un scor perfect nu este un scop în sine.
• Cel mai mare câștig: reacție rapidă a serverului cu cache și compresie, imagini mici cu width și height, fără încărcare leneșă pentru cea mai importantă fotografie, mai puțin JavaScript de la terți.

Test

Exercițiu

Exercițiul A4.3: Răspuns rapid și imagini ușoare. Introduceți adresa unei pagini. Programul măsoară de trei ori timpul până la primul byte (TTFB) de pe serverul nostru și ia valoarea din mijloc, verifică dacă HTML-ul este trimis comprimat (gzip, Brotli sau zstd), numără imaginile fără width și height și verifică dacă imaginea principală din partea de sus nu este încărcată cu loading="lazy". Atenție: aceasta este o măsurătoare dintr-un singur loc, nu o măsurătoare a vizitatorilor dumneavoastră. Nu aveți un site propriu? Folosiți www.wikipedia.org.

Exercițiul D4.3: Core Web Vitals pentru site-ul dvs. Rulați PageSpeed Insights pe pagina dumneavoastră principală și pe încă o pagină importantă, mai întâi pe Mobile. Notați pentru fiecare pagină: dacă există date de teren (pentru pagină sau pentru întregul site), valorile LCP, INP și CLS din datele de teren, scorul Lighthouse și elementul indicat de Lighthouse drept element LCP. Alegeți îmbunătățirea care credeți că aduce cel mai mult și explicați de ce.

Resurse suplimentare

• 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