De ce un site rapid in test poate avea Core Web Vitals slabe pentru utilizatorii reali

Un site poate obtine un rezultat foarte bun intr-un test Lighthouse si, in acelasi timp, sa apara cu probleme Core Web Vitals in Google Search Console. Situatia pare contradictorie doar daca tratam cele doua rapoarte ca si cum ar masura acelasi lucru.

Nu il masoara.

PageSpeed Insights combina doua categorii de informatii: date despre utilizatori reali din Chrome User Experience Report, atunci cand exista suficiente date, si un test de laborator realizat cu Lighthouse. Search Console foloseste la randul sau date reale pentru raportul Core Web Vitals si grupeaza URL-uri cu experiente similare.

Prin urmare, un test rapid facut acum pe un dispozitiv simulat nu poate invalida automat experientele mai lente pe care vizitatorii reali le-au avut in ultimele saptamani.

Primul lucru de clarificat: laboratorul si utilizatorii reali raspund la intrebari diferite

Google descrie field data ca date despre modul in care utilizatorii reali au experimentat site-ul. Lab data descrie cum s-ar comporta pagina intr-un mediu controlat sau simulat.

Lighthouse face parte din a doua categorie. Ruleaza pagina intr-un set definit de conditii si produce un rezultat repetabil, util pentru comparatii si debugging.

Chrome UX Report, cunoscut ca CrUX, colecteaza in schimb date agregate din browsere Chrome reale eligibile. Aceste date stau la baza informatiilor Core Web Vitals din mai multe instrumente Google.

Field data iti spune daca utilizatorii au o problema; laboratorul te ajuta sa cauti cauza.

Ce metrici sunt urmarite

Core Web Vitals includ in prezent:

• LCP pentru performanta incarcarii;
• INP pentru responsivitatea la interactiuni;
• CLS pentru stabilitatea vizuala.

Google recomanda pentru o experienta buna LCP de cel mult 2,5 secunde, INP de cel mult 200 ms si CLS de cel mult 0,1, evaluate la percentila 75.

Asta inseamna ca nu conteaza doar cea mai buna vizita sau media simpla. Conteaza cum se comporta site-ul pentru majoritatea utilizatorilor, inclusiv pentru o parte dintre cei care au conditii mai dificile.

PageSpeed Insights iti poate arata doua realitati pe aceeasi pagina

PageSpeed Insights foloseste CrUX pentru date reale si Lighthouse pentru diagnosticul de laborator. Google explica explicit ca lab data este utila pentru debugging, dar poate sa nu surprinda blocajele care apar in lumea reala.

De aceea, atunci cand deschizi un raport, separa mental cele doua zone.

Sectiunea cu experienta utilizatorilor reali

Daca exista suficiente date, PageSpeed Insights raporteaza experientele utilizatorilor reali pentru URL sau pentru origin. Datele CrUX utilizate de PSI reprezinta o perioada mobila de 28 de zile.

Aceste valori sunt cele mai relevante atunci cand vrei sa raspunzi la intrebarea: „Cum functioneaza site-ul pentru oamenii care chiar il folosesc?”

Sectiunea Lighthouse

Mai jos in raport este rulat un test Lighthouse. Acesta foloseste un mediu simulat si produce inclusiv scorul Performance de la 0 la 100.

Un scor de 95 sau 100 nu inseamna automat ca pagina trece Core Web Vitals pentru utilizatorii reali. Chiar documentatia PageSpeed Insights precizeaza ca rezultate bune de laborator nu garanteaza experiente reale bune.

O diferenta importanta: Lighthouse nu poate reproduce singur INP-ul real al unei sesiuni

INP necesita interactiuni ale utilizatorului. Un Lighthouse care doar incarca pagina fara ca un om sa foloseasca meniul, filtrul, formularul sau cosul nu poate reproduce toate aceste interactiuni.

In laborator, metrici si audituri precum Total Blocking Time pot indica riscul unor probleme de responsivitate, dar nu sunt identice cu INP-ul masurat din vizitele reale.

1. Telefonul utilizatorului poate fi mult mai lent decat dispozitivul tau

Un site nu este executat doar pe infrastructura serverului. O parte importanta a muncii este facuta pe dispozitivul utilizatorului: parsare HTML, CSS, JavaScript, calcul de stil, layout, paint si raspuns la interactiuni.

Doua telefoane care folosesc aceeasi conexiune pot afisa rezultate foarte diferite.

Un dispozitiv mai slab poate:

• executa JavaScript mai lent;
• procesa un DOM mare mai greu;
• intarzia randarea dupa o interactiune;
• avea memorie disponibila mai mica;
• resimti mai puternic impactul scripturilor third-party.

Acest lucru este relevant in special pentru INP. Daca un event handler necesita multa munca pe main thread, diferenta dintre un desktop performant si un telefon modest poate fi foarte mare.

Un laptop rapid poate ascunde probleme reale

Daca dezvoltatorul deschide site-ul pe un calculator puternic, cu fibra si cache deja populat, pagina poate parea instantanee. Aceasta vizita spune foarte putin despre un utilizator care intra pentru prima data de pe un telefon modest si o conexiune mobila instabila.

2. Conexiunea utilizatorului nu este o valoare fixa

Latenta si viteza efectiva variaza. Un utilizator poate intra prin Wi-Fi rapid, altul printr-o retea mobila aglomerata, iar altul dintr-o zona cu semnal slab.

Google explica faptul ca una dintre cauzele normale ale diferentelor dintre lab si field data este varietatea conditiilor reale de retea.

Pentru LCP, fiecare intarziere se poate acumula

LCP include mai mult decat timpul de descarcare al unei imagini. Documentatia web.dev arata ca pot conta si redirecturile, configurarea conexiunii si Time to First Byte.

Daca HTML-ul ajunge tarziu, imaginea LCP este descoperita tarziu si conexiunea utilizatorului este lenta, efectele se aduna.

Un test facut intr-un moment bun poate sa nu reproduca toate aceste conditii.

3. Cache-ul poate face laboratorul fie mai lent, fie mai rapid decat vizitele reale

Lighthouse foloseste in mod normal o incarcare controlata, apropiata de experienta unui vizitator nou. In lumea reala exista insa ambele categorii:

• vizitatori care intra pentru prima data si nu au resurse in cache;
• vizitatori recurenti care au deja anumite fisiere salvate;
• utilizatori pentru care cache-ul a fost invalidat de o versiune noua;
• sesiuni in care service worker-ul sau strategia de caching modifica traseul resurselor.

Prin urmare, nu exista o singura „viteza a site-ului”. Exista o distributie de experiente.

Si continutul afisat poate fi diferit

web.dev mentioneaza si faptul ca un vizitator nou poate vedea componente precum bannerul de cookie, in timp ce un utilizator care si-a exprimat deja optiunea nu le mai vede.

Aceste diferente pot modifica incarcarea, interactiunile si chiar stabilitatea layout-ului.

4. INP poate deveni slab abia dupa ce utilizatorul incepe sa foloseasca pagina

Aici este probabil cea mai mare diferenta dintre un test automat simplu si o sesiune reala.

Un utilizator:

• deschide meniul;
• tasteaza intr-o cautare;
• schimba filtre;
• deschide un modal;
• adauga produse in cos;
• selecteaza variante;
• completeaza formulare;
• navigheaza intre tab-uri;
• declanseaza scripturi de analytics sau personalizare.

Oricare dintre aceste actiuni poate genera o interactiune lenta.

Exemplu: magazin online care se incarca impecabil, dar filtreaza greu

Pagina de categorie poate avea LCP bun si scor Lighthouse excelent. Utilizatorul selecteaza insa un filtru, iar browserul trebuie sa proceseze o lista mare de produse, sa actualizeze DOM-ul si sa ruleze mai multe callback-uri.

Daca feedbackul vizual apare tarziu, INP poate fi slab chiar daca incarcarea initiala a fost rapida.

Acest tip de problema este relevant si pentru conversie. In articolul despre problemele tehnice si UX din checkout sunt analizate situatii in care intarzierea unei actiuni poate fi interpretata de utilizator drept o problema a site-ului.

Scripturile care nu par importante pot conta exact cand utilizatorul apasa

Analytics, chat, tag manager, personalizare, reclame sau cod propriu pot ocupa main thread-ul. Daca utilizatorul interactioneaza exact in acel moment, input-ul poate astepta pana cand browserul poate incepe procesarea lui.

Acesta este unul dintre motivele pentru care diagnosticul INP trebuie facut pe interactiuni reale, nu doar la page load.

5. CLS se poate deteriora dupa ce testul de incarcare s-a terminat

Cumulative Layout Shift poate fi influentat de comportamentul paginii pe durata vizitei. web.dev subliniaza ca pentru CLS datele de teren sunt deosebit de importante, deoarece utilizatorul poate derula pagina, deschide componente sau declansa continut dinamic pe care testul Lighthouse initial nu il foloseste.

Ce poate produce CLS dupa cateva secunde sau minute

• un banner care apare dupa un delay;
• reclame sau iframe-uri cu dimensiuni variabile;
• un formular care afiseaza mesaje si muta continutul;
• un widget incarcat dupa consimtamant;
• continut infinit incarcat la scroll;
• imagini fara spatiu rezervat;
• fonturi care schimba geometria textului;
• componente deschise in urma interactiunilor.

Daca Lighthouse nu ajunge in acel scenariu, valoarea sa poate fi excelenta, in timp ce utilizatorii reali continua sa genereze layout shifts.

6. Nici elementul LCP nu trebuie sa fie acelasi pentru fiecare utilizator

web.dev explica faptul ca elementul identificat ca LCP intr-un test de laborator poate sa nu fie acelasi pentru toate vizitele reale.

Motivul poate fi simplu:

• viewport diferit;
• imagine responsive diferita;
• banner personalizat;
• continut conditionat de autentificare;
• variatii de template;
• incarcarea unei alte componente in zona initial vizibila.

Pe un desktop, un bloc mare de text poate deveni LCP. Pe un telefon, imaginea hero poate fi elementul dominant.

Un LCP slab nu inseamna automat imagine prea mare

Cauza poate fi serverul, descoperirea tarzie a resursei, timpul de descarcare sau intarzierea de randare. Ghidul despre diagnosticarea problemelor LCP, INP si CLS explica separat aceste componente.

7. Search Console nu retesteaza pagina ta in momentul in care deschizi raportul

Raportul Core Web Vitals din Search Console este bazat pe date reale de utilizare. Google grupeaza URL-urile cu experiente similare si aplica statusuri precum Good, Need improvement sau Poor la nivelul grupului.

Asta explica una dintre cele mai derutante situatii: deschizi un URL dintr-un grup problematic, il testezi acum in Lighthouse si vezi verde.

Nu exista neaparat o contradictie. Compari:

• experiente reale agregate ale unui grup de URL-uri;
• cu o rulare actuala, individuala si simulata.

Problema raportata poate apartine unui template comun

Daca paginile de produs folosesc acelasi template, Search Console le poate grupa pentru ca au o experienta similara.

Aceasta este de fapt o informatie utila. Daca un grup mare are aceeasi problema, cauza poate fi comuna:

• aceeasi imagine hero;
• acelasi script;
• acelasi widget;
• acelasi layout;
• aceeasi logica a filtrelor;
• aceeasi problema de server sau cache.

De ce unele pagini nu au deloc field data

CrUX nu include automat orice pagina de pe internet. Chrome precizeaza ca exista criterii de eligibilitate si este necesar suficient trafic pentru o colectare semnificativa statistic.

Daca PageSpeed Insights nu are suficiente date pentru un URL, poate afisa date la nivel de origin. Daca nici origin-ul nu are suficiente date, sectiunea cu experienta reala poate lipsi.

Absenta field data nu inseamna ca pagina este rapida sau lenta; inseamna doar ca acel set public nu poate furniza o evaluare suficienta.

Cum investighezi cand laboratorul este verde, dar utilizatorii reali sunt rosii

Nu incerca sa faci Lighthouse si Search Console sa afiseze acelasi numar. Obiectivul este sa descoperi de ce o parte dintre utilizatori au experiente slabe.

1. Identifica metrica problematica

Este LCP, INP sau CLS? Fara aceasta separare, investigatia ramane prea generala.

2. Citeste field data separat de scorul Performance

In PageSpeed Insights, verifica daca datele sunt pentru URL sau pentru origin si analizeaza distributia experientelor. Nu folosi scorul Lighthouse ca substitut pentru aceasta sectiune.

3. Separarea mobil versus desktop este obligatorie

Core Web Vitals sunt evaluate separat pe aceste categorii. O problema poate fi evidenta pe mobil si aproape inexistenta pe desktop.

4. Testeaza fluxul, nu doar refresh-ul paginii

Daca problema este INP sau CLS, foloseste efectiv site-ul:

• deschide meniurile;
• deruleaza;
• foloseste filtrele;
• completeaza formulare;
• adauga in cos;
• deschide modaluri;
• asteapta incarcarea componentelor intarziate.

5. Foloseste Performance panel pentru cauza tehnica

Cauta task-uri lungi, randari costisitoare, layout shifts si momentul in care este afisat elementul LCP. Aici laboratorul devine foarte valoros: permite repetarea scenariului pana cand cauza poate fi izolata.

6. Pentru proiecte importante, colecteaza propriile date RUM

CrUX poate confirma ca exista o problema, dar fiind un set agregat nu explica intotdeauna exact ce componenta a produs-o.

web.dev recomanda colectarea propriilor date de teren atunci cand este posibil. Biblioteca web-vitals poate fi folosita pentru masurarea LCP, INP si CLS si transmiterea rezultatelor catre o platforma proprie de analytics.

Astfel poti corela problemele cu:

• URL-ul;
• tipul paginii;
• dispozitivul;
• versiunea aplicatiei;
• interactiunea lenta;
• elementul care produce layout shift;
• elementul LCP.

Pentru un site cu probleme persistente, o analiza de optimizare viteza si Core Web Vitals ar trebui sa porneasca tocmai de la aceste diferente dintre utilizatorii reali si scenariile de laborator.

Greseli frecvente de interpretare

1. „Am 100 in PageSpeed, deci nu putem avea probleme Core Web Vitals”

Scorul Lighthouse Performance este un scor de laborator calculat din mai multe metrici. Nu este acelasi lucru cu evaluarea Core Web Vitals pe date reale.

2. Testul este repetat pana apare rezultatul dorit

Variatia intre teste exista. Daca rulezi raportul de zece ori si pastrezi doar cea mai buna valoare, nu ai diagnosticat problema. Ai selectat doar rezultatul favorabil.

3. Datele la nivel de origin sunt confundate cu datele URL-ului

Cand nu exista suficiente date pentru pagina individuala, PSI poate afisa date agregate pentru intregul origin. Verifica eticheta raportului inainte sa atribui rezultatul unei pagini anume.

4. O reparatie facuta astazi este cautata imediat in field data

Datele CrUX din PSI reprezinta o fereastra mobila de 28 de zile. O imbunatatire tehnica poate fi vizibila imediat intr-un test local, dar datele agregate reale se modifica pe masura ce intra vizite noi.

5. Toata optimizarea se opreste cand pagina pare incarcata

Pentru INP si o parte dintre problemele CLS, ceea ce se intampla dupa load este esential. O pagina poate porni rapid si se poate comporta slab exact in momentul in care utilizatorul incearca sa o foloseasca.

6. Field data este ignorata pentru ca nu ofera un stack trace

Rolul datelor reale este sa confirme problema si amploarea ei. Pentru cauza folosesti DevTools, Lighthouse, profiling si, daca este nevoie, instrumentare RUM proprie.

Checklist practic: site rapid in test, Core Web Vitals slabe in realitate

Un test rapid demonstreaza ca pagina poate fi rapida, nu ca este rapida pentru toata lumea

Aceasta este diferenta esentiala.

Un laborator controlat este excelent pentru reproducere, debugging si prevenirea regresiilor. Datele reale sunt cele care arata diversitatea experientelor de productie: telefoane diferite, retele diferite, continut diferit si comportamente pe care un test automat nu le poate anticipa complet.

Cand Lighthouse este verde si Search Console este rosu, nu trebuie sa alegi care instrument are dreptate. Trebuie sa afli ce experienta masoara fiecare si de ce utilizatorii reali ajung intr-un scenariu pe care testul tau nu il reproduce.

Abia dupa aceasta separare optimizarea devine utila: LCP este investigat ca incarcare si randare, INP ca interactiune reala, iar CLS ca stabilitate pe durata intregii experiente.