Dacă ați căutat „evaluare Core Web Vitals nereușită” după ce ați văzut un scor de viteză verde, începeți prin a verifica ce date descrie fiecare rezultat. PageSpeed Insights (PSI) combină dovezi din vizite reale cu un test controlat separat. Notați adresa, dispozitivul, aria datelor și indicatorul care nu îndeplinește cerințele înainte să cumpărați un instrument sau să cereți refacerea site-ului.
Începem cu această înregistrare deoarece „faceți scorul verde” lasă prea multe lucruri neclare. Dezvoltatorul trebuie să știe ce experiență necesită atenție și ce dovezi vor arăta că remedierea este utilă.
Evaluare Core Web Vitals nereușită: ce a măsurat raportul?
Evaluarea descrie experiențe înregistrate ale vizitatorilor, în timp ce secțiunea Lighthouse rulează un test de diagnostic. Documentația Google pentru PageSpeed Insights explică faptul că datele din utilizarea reală provin din Chrome User Experience Report, sau CrUX, pe o perioadă retrospectivă de colectare de 28 de zile. Prin urmare, un diagnostic nou și acel istoric pot afișa rezultate diferite.
Condițiile testelor diferă. O rulare controlată nu poate acoperi toate dispozitivele, conexiunile și acțiunile din vizitele reale. Folosiți-o pentru a investiga o cauză posibilă; păstrați alături datele vizitatorilor când decideți ce rămâne nerezolvat.
Rezultatul poate acoperi o arie mai largă. Dacă există prea puține date pentru pagina exactă, PSI poate folosi datele originii, adică, în linii mari, adresa comună a site-ului, inclusiv protocolul și numele gazdei. Un rezultat la nivel de origine combină vizite de pe mai multe pagini. Citiți aria afișată înainte să considerați rezultatul o dovadă despre o anumită pagină de produs sau serviciu.
Perioada include vizite mai vechi. O modificare făcută astăzi nu rescrie observațiile de ieri. Salvați data implementării ca să puteți distinge verificarea imediată a remedierii de dovezile ulterioare despre vizitatori.
Aceste diferențe dau rapoartelor roluri distincte: dovezile despre vizitatori identifică experiența de investigat; un test controlat ajută la reproducerea și examinarea ei.
Ce indicator necesită atenție?
Examinați separat LCP, INP și CLS înainte să alegeți remedierea. Ghidul Google Web Vitals separă încărcarea, capacitatea de răspuns și stabilitatea vizuală. Tabelul de mai jos prezintă pragurile pentru categoria Good din acel ghid, evaluate la percentila 75 pentru populația relevantă de dispozitive. Ghidul Google privind pragurile explică percentila 75: cel puțin 75% dintre afișările de pagină măsurate trebuie să îndeplinească pragul Good pentru indicatorul respectiv. Acest lucru diferă de o medie sau de scorul general Lighthouse.
| Indicator | Ce descrie | Pragul Good | Ce să întrebați responsabilul tehnic |
|---|---|---|---|
| LCP, Largest Contentful Paint | Când apare cel mai mare element de conținut vizibil | Cel mult 2,5 secunde | Ce element întârzie și în ce etapă a încărcării sale? |
| INP, Interaction to Next Paint | Cât de prompt răspunde pagina la interacțiuni | Cel mult 200 de milisecunde | Ce atingere, clic sau apăsare de tastă este lentă în condițiile afectate? |
| CLS, Cumulative Layout Shift | Deplasări neașteptate ale elementelor din pagină | Cel mult 0,1 | Ce element se deplasează și în ce moment al vizitei? |
Când toate aceste valori au suficiente date, PSI cere ca valorile lor la percentila 75 să fie în categoria Good pentru ca evaluarea să fie trecută. Dacă datele INP sunt insuficiente, LCP și CLS în categoria Good pot permite totuși trecerea evaluării. Dacă datele pentru LCP sau CLS sunt insuficiente, PSI nu poate evalua pagina sau originea respectivă.
Tratați lipsa datelor ca pe o incertitudine. Metodologia Google CrUX cere vizite eligibile și un nivel suficient de popularitate; nu publică un număr minim universal de vizitatori. Absența unui rezultat nu vă spune că nu intră nimeni pe site, că experiența este bună sau că remedierea a eșuat.
Ce puteți verifica înainte să plătiți o lucrare?
Salvați un raport de referință și parcurgeți același traseu al clientului pe un telefon înainte să alegeți un instrument. Aveți nevoie de o descriere clară a problemei: pagina, datele din spatele avertizării și comportamentul pe care îl puteți reproduce. Dacă nu îl puteți reproduce, consemnați această limită în loc să umpleți golul cu o presupunere.
- Deschideți în PSI pagina exactă relevantă pentru afacere. Păstrați adresa și data raportului. Includeți pagina de destinație sau șablonul important pentru solicitarea ori achiziția pe care o investigați.
- Notați dispozitivul, mobil sau desktop, și aria datelor. Copiați dacă secțiunea de date reale reprezintă adresa URL, originea sau date insuficiente. Folosiți aceeași selecție la comparațiile ulterioare.
- Numiți indicatorul care necesită atenție. Folosiți rezultatele individuale Core Web Vitals, apoi citiți secțiunea de diagnostic pentru indicii. Menționați explicit eșantioanele lipsă.
- Parcurgeți o sarcină reală pe telefon. Deschideți meniul, folosiți filtrul relevant sau completați formularul relevant. Notați ce se încarcă târziu, răspunde lent sau se deplasează neașteptat.
- Legați un indiciu de un test. Cereți responsabilului tehnic să reproducă acțiunea afectată sau întârzierea de încărcare și să explice ce poate stabili testul.
Pentru verificări mai ample ale imaginilor, widgeturilor, memoriei cache și găzduirii, folosiți ghidul nostru despre cauzele frecvente ale unui site lent. Mențineți sarcina actuală concentrată pe evaluarea nereușită și pe dovezile necesare verificării unei remedieri.
Ce ar trebui să includă remedierea?
Alegeți cea mai mică modificare susținută de diagnostic, apoi conveniți cum o veți verifica. Porniți de la rapoartele și funcționalitatea pe care le aveți deja. Lucrarea tehnică devine mai ușor de evaluat când responsabilul numește pagina sau șablonul afectat, explică blocajul și păstrează comparabile condițiile de dinainte și de după.
- Legați propunerea de indicator. Ghidul web.dev despre LCP separă întârzierile de răspuns, descoperire, încărcare și randare a celui mai mare element. Ghidul despre INP concentrează investigația asupra interacțiunilor lente. Ghidul despre CLS include deplasările care apar după încărcarea inițială. Cereți dovezile relevante în locul unei promisiuni generale de îmbunătățire a vitezei.
- Modificați cauza identificată și retestați comportamentul. O remediere punctuală a unei resurse sau a unui șablon poate face parte din dezvoltarea și întreținerea site-ului. Păstrați o evidență a modificărilor și a momentului lor și notați cum se pot anula, acolo unde este posibil.
- Verificați că sarcina clientului funcționează în continuare. Testați navigarea, formularele și pașii de cumpărare relevanți pentru pagină. Păstrați funcționale mecanismele de consimțământ; investigați-le comportamentul și dispunerea fără să compromiteți consimțământul legal.
- Decideți dacă sunt necesare mai multe dovezi. Dacă rapoartele disponibile nu pot identifica interacțiunea sau pagina afectată, măsurarea suplimentară poate ajuta. Întrebați la ce întrebare răspunde monitorizarea propusă înainte să adăugați un serviciu plătit.
Dacă prioritatea tehnică este neclară, lucrările de SEO tehnic pot începe cu un diagnostic și o listă de lucrări verificabilă. O refacere de design sau un pachet de optimizare necesită propria justificare.
Puteți copia această fișă de lucru și lăsa necompletate câmpurile necunoscute:
Pagina și sarcina relevantă pentru afacere:
Dispozitivul și aria datelor reale:
Indicatorul care necesită atenție:
Comportamentul observat și condițiile testului:
Cauza și modificarea propuse:
Data implementării:
Verificare comparabilă după modificare:
Observație ulterioară din utilizarea reală și incertitudini rămase:Cum verificați dacă lucrarea a ajutat?
Analizați mai întâi comportamentul modificat, apoi comparați dovezile ulterioare din utilizarea reală în aceeași arie. Conform documentației sale, PSI actualizează zilnic datele reale, păstrând însă o fereastră retrospectivă de colectare. Păstrați data implementării în evidență. Acea fereastră nu este un termen promis până la trecerea evaluării.
Comparați indicatorul vizat și sarcina clientului în condiții de testare similare. Dacă simptomul rămâne, redeschideți diagnosticul. Dacă testul se îmbunătățește, dar dovezile reale ulterioare nu susțin modificarea, investigați din nou paginile afectate și condițiile vizitatorilor. Lipsa datelor reale trebuie să rămână o limitare explicită.
Cum vă putem ajuta
Pornim de la raport, de la paginile importante și de la o sarcină pe care o putem reproduce. Separăm remedierea propusă, verificarea ei și dovezile ulterioare de la vizitatori, astfel încât fiecare decizie să aibă o bază pe care o puteți evalua. Un brief pentru performanța site-ului poate începe cu fișa de lucru de mai sus; păstrați vizibile câmpurile necunoscute.
