Un ghid aprofundat pentru măsurarea elementelor vitale ale web

Google a anunțat că din mai 2021 ( editare : data tocmai a fost mutată în iunie 2021), va începe să ia în considerare „Experiența paginii” ca parte a clasamentului în căutare, măsurată printr-un set de valori numite Core Web Vitals. Acea dată se apropie rapid și sunt sigur că mulți dintre noi ni se cere să ne asigurăm că trecem de Core Web Vitals, dar de unde poți ști dacă ai ajuns?

Răspunsul la această întrebare este de fapt mai dificil decât ați putea presupune și, în timp ce o mulțime de instrumente expun acum aceste elemente vitale de bază ale web, există multe concepte și subtilități importante de înțeles. chiar și instrumentele Google precum PageSpeed ​​Insights și raportul Core Web Vitals din Google Search Console par să ofere informații confuze.

De ce și cum poți fi sigur că remediile tale au funcționat cu adevărat? Cum puteți obține o imagine exactă a Core Web Vitals pentru site-ul dvs.? În această postare, voi încerca să explic un pic mai multe despre ce se întâmplă aici și să explic câteva dintre nuanțe și neînțelegeri ale acestor instrumente.

Care sunt elementele vitale ale web de bază?

Core Web Vitals sunt un set de trei valori concepute pentru a măsura experiența „de bază” a faptului că un site web se simte rapid sau lent pentru utilizatori și, astfel, oferă o experiență bună.

Paginile web vor trebui să se încadreze în măsurătorile ecologice pentru toate cele trei Core Web Vitals pentru a beneficia pe deplin de orice creștere a clasamentului. În afara intervalului bun, valorile diferite ale valorii Core Web Vital pe două pagini ar putea avea ca rezultat o clasare diferită a experienței paginii.

1. Cea mai mare vopsea plină de conținut (LCP)

Această măsurătoare este probabil cea mai ușor de înțeles dintre acestea - măsoară cât de repede obțineți cel mai mare element desenat pe pagină - care este probabil piesa de conținut de care este interesat utilizatorul. Aceasta ar putea fi o imagine banner, o bucată de text sau tot ceea ce. Faptul că este cel mai mare element de conținut de pe pagină este un bun indicator că este cea mai importantă piesă. LCP este relativ nou și obișnuiam să măsuram First Contentful Paint (FCP), numită similar, dar LCP a fost văzut ca o măsură mai bună pentru atunci când conținutul pe care vizitatorul probabil dorește să-l vadă este desenat.

LCP ar trebui să măsoare performanța de încărcare și este un bun proxy pentru toate valorile vechi pe care le folosim în comunitatea de performanță (adică Time to First Byte (TTFB), DOM Content Loaded, Start Render, Speed ​​Index) - dar din experiență a utilizatorului. Nu acoperă toate informațiile acoperite de acele valori, dar este o valoare mai simplă, unică, care încearcă să ofere o indicație bună despre încărcarea paginii.

2. Întârziere la prima intrare (FID)

Această a doua măsurătoare măsoară timpul dintre momentul în care utilizatorul interacționează cu o pagină, făcând clic pe un link sau un buton, de exemplu, și când browser-ul procesează acel clic. Este acolo pentru a măsura interactivitatea unei pagini . Dacă tot conținutul este încărcat, dar pagina nu răspunde, atunci este o experiență frustrantă pentru utilizator.

Un aspect important este că această valoare nu poate fi simulată, deoarece depinde cu adevărat de momentul în care un utilizator face clic sau interacționează în alt mod cu o pagină și apoi de cât timp durează pentru a fi acționat. Timpul total de blocare (TBT) este un bun proxy pentru FID atunci când utilizați un instrument de testare fără nicio interacțiune directă cu utilizatorul, dar urmăriți și Time to Interactive (TTI) atunci când vă uitați la FID.

3. Schimbare cumulativă a aspectului (CLS)

O măsurătoare foarte interesantă, destul de diferită de alte valori care au apărut înainte din mai multe motive. Este conceput pentru a măsura stabilitatea vizuală a paginii - practic cât de mult sare pe măsură ce noul conținut se instalează. Sunt sigur că am dat clic cu toții pe un articol, am început să citim și apoi am avut textul să sară pe măsură ce imaginile, reclamele și alt conținut sunt încărcate.

Acest lucru este destul de supărător și enervant pentru utilizatori, așa că cel mai bine este să-l minimizezi. Mai rău este când acel buton pe care urma să dai clic se mișcă brusc și faci clic pe alt buton în schimb! CLS încearcă să țină seama de aceste schimbări de aspect.

Laborator versus RUM

Unul dintre punctele cheie de înțeles despre Core Web Vitals este că se bazează pe valorile de câmp sau pe valorile reale ale utilizatorilor (RUM). Google folosește date anonime de la utilizatorii Chrome pentru a feedback-ul valorilor și le pune la dispoziție în Raportul despre experiența utilizatorului Chrome (CrUX). Aceste date sunt cele pe care le folosesc pentru a măsura aceste trei valori pentru clasamentele de căutare. Datele CrUX sunt disponibile într-o serie de instrumente, inclusiv în Google Search Console pentru site-ul dvs.

Faptul că sunt utilizate datele RUM este o distincție importantă , deoarece unele dintre aceste valori (cu excepția FID) sunt disponibile în instrumente de performanță web sintetice sau „bazate în laborator”, cum ar fi Lighthouse, care au fost elementul de bază al monitorizării performanței web pentru mulți în trecut. . Aceste instrumente rulează încărcări de pagini pe rețele și dispozitive simulate și apoi vă spun care au fost valorile pentru acea rulare de testare.

Deci, dacă rulați Lighthouse pe mașina dvs. de dezvoltator de mare putere și obțineți scoruri grozave, este posibil să nu reflecte ceea ce experimentează utilizatorii în lumea reală și, prin urmare, ce va folosi Google pentru a măsura experiența utilizatorului site-ului dvs.

LCP va depinde foarte mult de condițiile rețelei și de puterea de procesare a dispozitivelor utilizate (și probabil că mulți dintre utilizatorii dvs. folosesc dispozitive cu o putere mai mică decât vă dați seama!). Un contrapunct este însă că, pentru multe site-uri occidentale, cel puțin, telefoanele noastre mobile nu au o putere atât de redusă pe cât sugerează instrumente precum Lighthouse în modul mobil, deoarece acestea sunt destul de accelerate. Așa că este posibil să observați că datele dvs. de teren de pe mobil sunt mai bune decât testarea cu acest lucru sugerează (există câteva discuții despre schimbarea setărilor pentru mobil Lighthouse).

În mod similar, FID depinde adesea de viteza procesorului și de modul în care dispozitivul poate gestiona tot acest conținut pe care îl trimitem - fie că este vorba de imagini de procesat, de elemente de aspect pe pagină și, desigur, de tot acel JavaScript pe care ne place să-l trimitem. la browser pentru a trece.

CLS este, teoretic, măsurat mai ușor în instrumente, deoarece este mai puțin susceptibil la variațiile de rețea și hardware, așa că ați crede că nu este la fel de supus diferențelor dintre LAB și RUM - cu excepția câtorva considerații importante care ar putea să nu fie evidente inițial :

• Este măsurată pe toată durata de viață a paginii și nu doar pentru încărcarea paginii, așa cum o fac instrumentele obișnuite, pe care o vom explora mai târziu în acest articol. Acest lucru provoacă multă confuzie atunci când încărcările paginilor simulate în laborator au un CLS foarte scăzut, dar scorul CLS al câmpului este mult mai mare, din cauza CLS cauzat de derulare sau alte modificări după încărcarea inițială pe care instrumentele de testare o măsoară de obicei.
• Poate depinde de dimensiunea ferestrei browser - de obicei instrumente precum PageSpeed ​​Insights, măsoară dispozitivele mobile și desktop, dar diferitele dispozitive mobile au dimensiuni diferite ale ecranului, iar desktopurile sunt adesea mult mai mari decât setul de aceste instrumente (Web Page Test a crescut recent dimensiunea implicită a ecranului). pentru a încerca să reflecte mai exact utilizarea).
• Diferiți utilizatori văd lucruri diferite pe paginile web . Bannerele cookie, conținutul personalizat cum ar fi promoțiile, blocatorii de anunțuri, testele A/B pentru a numi doar câteva elemente care ar putea fi diferite, toate influențează conținutul desenat și, prin urmare, ceea ce pot experimenta utilizatorii CLS.
• Încă evoluează, iar echipa Chrome a fost ocupată cu repararea schimburilor „invizibile” și altele asemenea, care nu ar trebui să conteze pentru CLS. Sunt, de asemenea, în desfășurare modificări mai mari ale modului în care este măsurat efectiv CLS. Aceasta înseamnă că puteți vedea diferite valori CLS în funcție de versiunea de Chrome rulată.

Folosirea aceluiași nume pentru valorile în instrumentele de testare bazate pe laborator, atunci când este posibil să nu fie reflectări exacte ale versiunilor din viața reală, este confuză și unii sugerează că ar trebui să redenumim unele sau toate aceste valori în Lighthouse pentru a distinge aceste valori simulate de valorile RUM din lumea reală care alimentează clasamentele Google.

Valori anterioare de performanță web

Un alt punct de confuzie este că aceste valori sunt noi și diferite de valorile pe care le folosim în mod tradițional în trecut pentru a măsura performanța web și care sunt evidențiate de unele dintre aceste instrumente, cum ar fi PageSpeed ​​Insights - un instrument de audit online gratuit. Pur și simplu introduceți adresa URL pe care doriți să faceți un audit și faceți clic pe Analizați, iar câteva secunde mai târziu vi se vor afișa două file (una pentru mobil și alta pentru desktop) care conțin o mulțime de informații:

În partea de sus se află marele scor de performanță Lighthouse din 100. Acesta este binecunoscut în comunitățile de performanță web de ceva vreme și este adesea citat ca o măsură cheie de performanță pentru a viza și pentru a rezuma complexitățile multor valori într-un simplu , număr ușor de înțeles. Acest lucru are o oarecare suprapunere cu obiectivul Core Web Vitals, dar nu este un rezumat al celor trei Core Web Vitals (chiar și versiunile bazate pe laborator), ci al unei varietăți mai mari de valori.

În prezent, șase valori alcătuiesc scorul de performanță Lighthouse - inclusiv unele dintre Core Web Vitals și alte valori:

• Prima vopsea satisfăcătoare (FCP)
• SpeedIndex (SI)
• Cea mai mare vopsea plină de conținut (LCP)
• Time to Interactive (TTI)
• Timp total de blocare (TBT)
• Schimbare cumulativă a aspectului (CLS)

Pentru a spori complexitatea, fiecare dintre aceste șase este ponderat diferit în scorul de performanță, iar CLS, în ciuda faptului că este unul dintre principalele elemente vitale ale web, reprezintă în prezent doar 5% din scorul de performanță Lighthouse (voi paria bani pe această creștere la scurt timp după următoarea iterație a CLS este lansată). Toate acestea înseamnă că puteți obține un scor de performanță Lighthouse foarte mare, de culoare verde și puteți crede că site-ul dvs. este bine și, totuși, nu reușiți să treceți pragul Core Web Vitals. Prin urmare, ar putea fi necesar să vă reorientați eforturile acum pentru a analiza aceste trei valori de bază.

Trecând peste scorul verde mare din acea captură de ecran, trecem la datele de câmp și obținem un alt punct de confuzie: First Contentful Paint este afișat în acest câmp de date împreună cu celelalte trei Core Web Vitals, deși nu fac parte din Core Web Vitale și, la fel ca în acest exemplu, adesea găsesc că este semnalat ca un avertisment , chiar dacă ceilalți trec cu toții. (Poate că pragurile pentru acest lucru au nevoie de o mică ajustare?) A pierdut FCP să fie un Core Web Vital sau poate doar arată mai bine echilibrat cu patru metrici? Această secțiune de date de câmp este importantă și vom reveni la asta mai târziu.

Dacă nu sunt disponibile date de câmp pentru adresa URL specifică testată, atunci vor fi afișate în schimb datele de origine pentru întregul domeniu (acest lucru este ascuns în mod implicit când datele de câmp sunt disponibile pentru acea adresă URL, așa cum se arată mai sus).

După datele de teren, obținem datele de laborator și vedem cele șase valori care compun scorul de performanță în partea de sus. Dacă faceți clic pe comutatorul din dreapta sus, veți obține chiar și o descriere mai mică a acelor valori:

După cum puteți vedea, versiunile de laborator ale LCP și CLS sunt incluse aici și, deoarece fac parte din Core Web Vitals, primesc o etichetă albastră pentru a le marca ca foarte importante. PageSpeed ​​Insights include, de asemenea, un link de calculator util pentru a vedea impactul acestor scoruri asupra scorului total din partea de sus și vă permite să le ajustați pentru a vedea ce îmbunătățire va aduce scorul dvs. Dar, după cum am spus, este probabil ca scorul de performanță web să ocupe un loc în spate pentru un pic, în timp ce Core Web Vitals se bucură de strălucirea toată atenția în acest moment.

Lighthouse efectuează, de asemenea, aproape 50 de alte verificări asupra oportunităților și diagnosticelor suplimentare. Acestea nu afectează în mod direct scorul, nici Core Web Vitals, dar pot fi folosite de dezvoltatorii web pentru a îmbunătăți performanța site-ului lor . Acestea sunt, de asemenea, afișate în PageSpeed ​​Insights sub toate valorile, așa că tocmai ieșite din captură de ecran de mai sus. Gândiți-vă la acestea ca sugestii despre cum să îmbunătățiți performanța, mai degrabă decât probleme specifice care trebuie neapărat abordate.

Diagnosticarea vă va arăta elementul LCP și schimbările care au contribuit la scorul dvs. CLS, care sunt informații foarte utile atunci când optimizați pentru Core Web Vitals!

Așadar, în timp ce în trecut susținătorii performanței web s-ar fi concentrat în mare măsură pe scorurile și auditurile Lighthouse, văd că acest lucru se concentrează pe cele trei metrici Core Web Vital - cel puțin pentru perioada următoare, în timp ce ne înțelegem. Celelalte valori Lighthouse și scorul general sunt în continuare utile pentru a optimiza performanța site-ului dvs., dar Core Web Vitals ocupă în prezent cea mai mare parte a cernelii pentru performanța web și postările de blog SEO.

Vizualizarea elementelor vitale web de bază pentru site-ul dvs

Cel mai simplu mod de a arunca o privire rapidă asupra Core Web Vitals pentru o adresă URL individuală și pentru întreaga origine este să introduceți o adresă URL în PageSpeed ​​Insights, așa cum sa discutat mai sus. Cu toate acestea, pentru a vedea modul în care Google vede Core Web Vitals pentru întregul dvs. site, obțineți acces la Google Search Console. Acesta este un produs gratuit creat de Google care vă permite să înțelegeți cum Google „văd” întregul dvs. site, inclusiv Core Web Vitals pentru site-ul dvs. (deși există unele – să spunem – „ frustări ” cu cât de des se actualizează datele aici ).

Google Search Console a fost folosită de multă vreme de echipele SEO, dar odată cu contribuția de care dezvoltatorii de site-uri vor avea nevoie pentru a aborda Core Web Vitals, echipele de dezvoltare ar trebui să aibă într-adevăr acces la acest instrument, dacă nu au făcut-o deja. Pentru a obține acces, veți avea nevoie de un cont Google și apoi pentru a verifica calitatea de proprietar al site-ului prin diferite mijloace (plasarea unui fișier în serverul dvs. web, adăugarea unei înregistrări DNS... etc.).

Raportul Core Web Vitals din Google Search Console vă oferă un rezumat al modului în care site-ul dvs. îndeplinește Core Web Vitals în ultimele 90 de zile:

În mod ideal, pentru a fi considerat că trec complet Core Web Vitals, doriți ca toate paginile dvs. să fie verzi , fără chihlimbar sau roșu. În timp ce un chihlimbar este un bun indicator că sunteți aproape de trecere, doar verdețurile contează pentru a obține beneficiul maxim, așa că nu vă mulțumiți cu cel mai bun al doilea. Dacă aveți nevoie de trecerea tuturor paginilor dvs. sau doar a celor cheie, depinde de dvs., dar adesea vor apărea probleme similare pe multe pagini, iar remedierea acestora pentru site poate ajuta la aducerea numărului de adrese URL care nu trec într-un mod mai ușor de gestionat. nivel în care puteți lua acele decizii.

Inițial, Google va aplica clasamentul Core Web Vitals doar pe mobil, dar este cu siguranță doar o chestiune de timp până când acesta va fi lansat și pe desktop, așa că nu ignorați desktopul în timp ce vă aflați acolo, revizuindu-vă și remediați paginile.

Făcând clic pe unul dintre rapoarte, vă veți oferi mai multe detalii despre care dintre elementele vitale web nu sunt îndeplinite și apoi o mostră de adrese URL afectate. Google Search Console grupează adresele URL în compartimente pentru a vă permite, teoretic, să abordați pagini similare împreună. Puteți apoi să faceți clic pe o adresă URL pentru a rula PageSpeed ​​Insights pentru a efectua un audit rapid de performanță pe adresa URL anume (inclusiv afișarea datelor din câmpul Core Web Vitals pentru pagina respectivă, dacă acestea sunt disponibile). Apoi remediați problemele pe care le evidențiază, rulați din nou PageSpeed ​​Insights pentru a confirma că valorile de laborator sunt acum corecte, apoi treceți la pagina următoare.

Cu toate acestea, odată ce începi să te uiți la acel raport Core Web Vitals (obsesiv pentru unii dintre noi!), s-ar putea să fi fost frustrat că acest raport pare să nu se actualizeze pentru a reflecta munca ta. Se pare că se actualizează în fiecare zi pe măsură ce graficul se mișcă, dar deseori abia se schimbă chiar și după ce ați lansat corecțiile - de ce?

În mod similar, datele câmpului PageSpeed ​​Insights arată în continuare acea adresă URL și site-ul ca eșuând. Atunci care e povestea aici?

Raportul despre experiența utilizatorului Chrome (CrUX)

Motivul pentru care Web Vitals se actualizează lent, este că datele de câmp se bazează pe ultimele 28 de zile de date din Chrome User Experience Report (CrUX) și, în cadrul acestuia, doar a 75-a percentila a acestor date. Utilizarea datelor în valoare de 28 de zile și percentilele 75 de date sunt lucruri bune, deoarece elimină variațiile și extremele pentru a oferi o reflectare mai precisă a performanței site-ului dvs., fără a provoca mult zgomot greu de interpretat.

Valorile de performanță sunt foarte sensibile la rețea și dispozitive, așa că trebuie să netezim acest zgomot pentru a ajunge la povestea reală a modului în care site-ul dvs. funcționează pentru majoritatea utilizatorilor. Cu toate acestea, reversul este că se actualizează frustrant de lenți, creând o buclă de feedback foarte lentă de la corectarea problemelor, până când vedeți rezultatele acelei corecție reflectate acolo.

Centila 75 (sau p75) este interesantă în special și întârzierea pe care o creează, deoarece nu cred că este bine înțeles. Se uită la ce valoare 75% din vizualizările de pagină ale vizitatorilor dvs. în acele 28 de zile pentru fiecare dintre principalele elemente vitale ale web.

Prin urmare, este cel mai mare scor Core Web Vital de 75% din vizualizările paginii dvs. (sau, dimpotrivă, cel mai mic scor Core Web Vitals pe care 75% din vizualizările paginii dvs. îl vor avea mai puțin). Deci nu este media acestor 75% din vizualizările paginii, ci cea mai proastă valoare a acelui set de utilizatori.

Acest lucru creează o întârziere în raportare, ceea ce nu ar face o medie rulantă care nu este bazată pe percentile. Va trebui să facem puțină matematică aici (voi încerca să o mențin la minimum), dar să spunem, din motive de simplitate, toată lumea a primit un LCP de 10 secunde în ultima lună și ai rezolvat-o, așa că acum durează doar 1 secundă și să presupunem că ai avut exact același număr de vizitatori în fiecare zi și toți au obținut acest LCP.

În acel scenariu prea simplist, veți obține următoarele valori:

Așa că puteți vedea că nu vedeți îmbunătățirile drastice ale scorului CrUX până în ziua 22, când brusc trece la noua valoare mai mică (odată ce depășim 75% din media pe 28 de zile - fără coincidență!). Până atunci, peste 25% dintre utilizatorii dvs. s-au bazat pe datele culese înainte de modificare și, prin urmare, obținem vechea valoare de 10 și, prin urmare, valoarea dvs. p75 a fost blocată la 10.

Prin urmare, se pare că nu ați făcut niciun progres pentru o lungă perioadă de timp, în timp ce o medie medie (dacă ar fi fost folosită) ar arăta o scădere treptată care începe imediat și astfel progresul ar putea fi observat. În plus, în ultimele zile, media este de fapt mai mare decât valoarea p75, deoarece p75, prin definiție, filtrează complet extremele.

Exemplul din tabelul de mai sus, deși simplificat masiv, explică un motiv pentru care mulți ar putea vedea grafice Web Vitals ca mai jos, prin care într-o zi toate paginile dvs. trec un prag și apoi sunt bune ( woohoo! ):

Acest lucru poate fi surprinzător pentru cei care se așteaptă la schimbări mai graduale (și instantanee) pe măsură ce rezolvați problemele legate de pagini și deoarece unele pagini sunt vizitate mai des decât altele. Într-o notă similară, nu este neobișnuit să vedeți graficul din Search Console trecând printr-o perioadă chihlimbar , în funcție de remedieri și de modul în care acestea afectează pragurile, înainte de a atinge culoarea verde dulce și dulce:

Dave Smart, a desfășurat un experiment fascinant Urmărirea modificărilor în Datele vitale web ale rapoartelor de bază ale Search Console, în care a vrut să analizeze cât de repede a fost nevoie pentru a actualiza graficele. El nu a ținut cont de porțiunea de percentila 75 a CrUX (ceea ce face ca lipsa de mișcare în unele dintre graficele sale să aibă mai mult sens), dar totuși un experiment fascinant în viața reală despre cum se actualizează acest grafic și merită citit!

Experiența mea este că această metodologie p75 de 28 de zile nu explică pe deplin decalajul din raportul Core Web Vitals și vom discuta câteva alte motive potențiale într-un moment.

Deci, este cel mai bun lucru pe care îl puteți face, faceți remediile, apoi așteptați cu răbdare, atingând degetele, până când CrUX consideră că remediile dvs. sunt demne și actualizează graficul în Search Console și PageSpeed ​​Insights? Și dacă se dovedește că remediile tale nu au fost suficient de bune, atunci reîncepi întregul ciclu? În această zi de feedback instantaneu pentru a ne satisface poftele și bucle de feedback strânse pentru dezvoltatori pentru a îmbunătăți productivitatea , acest lucru nu este deloc satisfăcător!

Ei bine, există câteva lucruri pe care le puteți face între timp pentru a încerca să vedeți dacă remediile vor avea impactul scontat.

Aprofundarea datelor Crux mai detaliat

Deoarece nucleul măsurării sunt datele CrUX, haideți să ne aprofundăm mai mult și să vedem ce ne mai poate spune. Revenind la PageSpeed ​​Insights, putem vedea că evidențiază nu numai valoarea p75 pentru site, ci și procentul de vizualizări ale paginii din fiecare dintre gălețile verde, chihlimbar și roșu afișate în barele de culoare de mai jos:

Captura de ecran de mai sus arată că CLS nu atinge scorul Core Web Vitals cu o valoare p75 de 0,11, care este peste limita de trecere de 0,1. Cu toate acestea, deși culoarea fontului este roșie, acesta este de fapt un clasament chihlimbar (deoarece roșu ar fi peste 0,25). Mai interesant este că bara verde este la 73% - odată ce atinge 75%, această pagină trece de Core Web Vitals.

Deși nu puteți vedea valorile istorice CrUX, puteți monitoriza acest lucru în timp. Dacă mâine ajunge la 74%, atunci vom merge în direcția corectă (sub rezerva fluctuațiilor!) și putem spera să atingem magia 75% în curând. Pentru valorile care sunt mai îndepărtate, puteți verifica periodic și puteți vedea creșterea , apoi puteți proiecta când ați putea începe să apară ca trecător.

CrUX este, de asemenea, disponibil ca un API gratuit pentru a obține cifre mai precise pentru acele procente. După ce v-ați înscris pentru o cheie API, o puteți apela cu o comandă curl ca aceasta (înlocuind API_KEY, formFactor și URL-ul după caz):

 curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{"formFactor":"PHONE","url":"https://www.example.com"}'

Și veți primi un răspuns JSON, ca acesta:

 { "record": { "key": { "formFactor": "PHONE", "url": "https://www.example.com/" }, "metrics": { "cumulative_layout_shift": { "histogram": [ { "start": "0.00", "end": "0.10", "density": 0.99959769344240312 }, { "start": "0.10", "end": "0.25", "density": 0.00040230655759688886 }, { "start": "0.25" } ], "percentiles": { "p75": "0.00" } }, "first_contentful_paint": { ... } } }, "urlNormalizationDetails": { "originalUrl": "https://www.example.com", "normalizedUrl": "https://www.example.com/" } }

De altfel, dacă mai sus vă sperie puțin și doriți o modalitate mai rapidă de a vedea aceste date pentru o singură adresă URL, atunci PageSpeed ​​Insights returnează și această precizie pe care o puteți vedea deschizând DevTools și apoi rulând testul PageSpeed ​​Insights și găsind apelul XHR îl face:

Există, de asemenea, un explorator interactiv CrUX API care vă permite să faceți exemple de interogări ale API-ului CrUX. Cu toate acestea, pentru apelarea regulată a API-ului, obținerea unei chei gratuite și utilizarea Curl sau a unui alt instrument API este de obicei mai ușor.

API-ul poate fi, de asemenea, apelat cu o „origine”, în loc de o adresă URL, moment în care va oferi valoarea rezumată a tuturor vizitelor de pagină pe acel domeniu. PageSpeed ​​Insights expune aceste informații, care pot fi utile dacă adresa URL nu are informații despre CrUX disponibile, dar Google Search Console nu are. Google nu a declarat (și este puțin probabil să o facă!) exact modul în care Core Web Vitals va afecta clasamentul . Scorul la nivel de origine va afecta clasamentele sau numai scorurile individuale ale adreselor URL? Sau, la fel ca PageSpeed ​​Insights, Google va reveni la scorurile de nivel inițial atunci când datele individuale ale adreselor URL nu există? Este dificil de știut în acest moment și singurul indiciu de până acum este acesta din Întrebări frecvente:

Î : Cum se calculează un scor pentru o adresă URL care a fost publicată recent și care nu a generat încă 28 de zile de date?

R : Similar modului în care Search Console raportează datele despre experiența paginilor, putem folosi tehnici precum gruparea paginilor care sunt similare și calcularea scorurilor pe baza acelei agregari. Acest lucru se aplică paginilor care primesc puțin sau deloc trafic, astfel încât site-urile mici fără date de câmp nu trebuie să vă faceți griji.

API-ul CrUX poate fi apelat programatic, iar Rick Viscomi de la echipa Google CrUX a creat un monitor Google Sheets care vă permite să verificați în bloc adresele URL sau originile și chiar să urmăriți automat datele CrUX de-a lungul timpului dacă doriți să monitorizați îndeaproape un număr de adrese URL sau origini. . Pur și simplu clonați foaia, accesați Tools → Script și apoi introduceți o proprietate de script CRUX_API_KEY cu cheia dvs. (acest lucru trebuie făcut în editorul moștenit), apoi rulați scriptul și va apela API-ul CrUX pentru respectivul URL-uri sau origini și adăugați rânduri în partea de jos a foii cu datele. Acesta poate fi apoi rulat periodic sau programat să ruleze în mod regulat.

Am folosit acest lucru pentru a verifica toate adresele URL pentru un site cu un raport Core Web Vitals care se actualizează lentă în Google Search Console și a confirmat că CrUX nu avea date pentru multe adrese URL și majoritatea celorlalte au trecut, deci din nou arătând că Raportul Google Search Console este în urmă - chiar și din datele CrUX pe care ar trebui să se bazeze. Nu sunt sigur dacă se datorează adreselor URL care au eșuat anterior, dar acum nu au suficient trafic pentru a obține date CrUX actualizate care arată că acestea trec, sau dacă se datorează altceva, dar acest lucru îmi dovedește că acest raport este cu siguranță lent .

Bănuiesc că o mare parte din aceasta se datorează adreselor URL fără date în CrUX și Căutarea Google fac tot posibilul pentru a reprezenta o valoare pentru ele. Prin urmare, acest raport este un loc minunat pentru a începe să obțineți o imagine de ansamblu asupra site-ului dvs. și unul pentru a monitoriza viitorul, dar nu este un raport excelent pentru a rezolva problemele în care doriți un feedback mai imediat.

Pentru cei care doresc să se aprofundeze și mai mult în CrUX, există tabele lunare cu date CrUX disponibile în BigQuery (numai la nivel de origine, deci nu pentru adrese URL individuale) și Rick a documentat, de asemenea, cum puteți crea un tablou de bord CrUX pe baza celui care poate fi o modalitate bună de a monitoriza performanța generală a site-ului dvs. de-a lungul lunilor.

Alte informații despre datele Crux

Așadar, cu cele de mai sus, ar trebui să înțelegeți bine setul de date CrUX, de ce unele dintre instrumentele care îl folosesc par să se actualizeze lente și neregulate și, de asemenea, cum să îl explorați puțin mai mult. Dar înainte de a trece la alternative la acesta, mai sunt câteva lucruri de înțeles despre CrUX pentru a vă ajuta să înțelegeți cu adevărat datele pe care le arată. Deci, iată o colecție de alte informații utile pe care le-am adunat despre CrUX în legătură cu Core Web Vitals.

CrUX este doar Chrome . Toți acei utilizatori iOS și alte browsere (Desktop Safari, Firefox, Edge... etc.), ca să nu mai vorbim de browserele mai vechi (Internet Explorer — grăbește-te și ai vrea să dispari!) nu au experiența lor de utilizator reflectată în datele CrUX și așadar în viziunea Google despre Core Web Vitals.

Acum, utilizarea Chrome este foarte mare (deși poate nu pentru vizitatorii site-ului dvs.?) și, în cele mai multe cazuri, problemele de performanță pe care le evidențiază vor afecta și celelalte browsere, dar este ceva de care trebuie să fiți conștienți. Și, cel puțin, se pare că poziția de monopol a Google în căutare îi încurajează pe oameni să optimizeze browserul lor. Vom vorbi mai jos despre soluții alternative pentru această viziune limitată.

Versiunea de Chrome utilizată va avea, de asemenea, un impact, deoarece aceste valori (în special CLS) continuă să evolueze, iar erorile sunt găsite și remediate . Acest lucru adaugă o altă dimensiune a complexității înțelegerii datelor. Au existat îmbunătățiri continue ale CLS în versiunile recente de Chrome, cu o redefinire mai mare a CLS care a ajuns în Chrome 91. Din nou, faptul că datele de câmp sunt utilizate înseamnă că ar putea dura ceva timp pentru ca aceste modificări să fie transmise utilizatorilor și apoi în datele CrUX.

CrUX este doar pentru utilizatorii conectați la Chrome sau pentru a cita definiția reală:

„[CrUX este] agregat de la utilizatorii care s-au înscris pentru sincronizarea istoricului lor de navigare, nu au configurat o expresie de acces pentru sincronizare și au activată raportarea statisticilor de utilizare.”

— Raport despre experiența utilizatorului Chrome, Google Developers

Deci, dacă căutați informații pe un site vizitat în mare parte din rețelele corporative, unde astfel de setări sunt dezactivate de politicile IT centrale, atunci este posibil să nu vedeți multe date - mai ales dacă acești utilizatori corporativi săraci sunt încă forțați să folosească Internetul Explorer și el!

CrUX include toate paginile, inclusiv cele care nu apar în mod obișnuit în Căutarea Google, cum ar fi „paginile nu vor fi indexate / furate / conectate” (deși există praguri minime pentru ca o adresă URL și origine să fie expuse în CrUX). Acum, aceste categorii de pagini probabil nu vor fi incluse în rezultatele Căutării Google și, prin urmare, impactul de clasare asupra lor este probabil neimportant, dar vor fi în continuare incluse în CrUX. Cu toate acestea, raportul Core Web Vitals din Google Search Console pare să afișeze numai adrese URL indexate , așa că nu vor apărea acolo.

Cifra de origine afișată în PageSpeed ​​Insights și în datele brute CrUX va include acele pagini neindexate, nepublice și, așa cum am menționat mai sus, nu suntem siguri de impactul acestui lucru. Un site pe care lucrez are un procent mare de vizitatori care vizitează paginile noastre conectate și, în timp ce paginile publice erau foarte performante, paginile conectate nu au fost, iar acest lucru a denaturat grav scorurile de origine Web Vitals.

API-ul CrUX poate fi folosit pentru a obține datele acestor adrese URL conectate , dar instrumente precum PageSpeed ​​Insights nu pot (deoarece rulează un browser real și, prin urmare, vor fi redirecționate către paginile de conectare). Odată ce am văzut acele date CrUX și ne-am dat seama de impact, le-am reparat, iar cifrele de origine au început să scadă, dar, ca întotdeauna, durează timp pentru a trece.

Paginile fără indexare sau autentificate sunt, de asemenea, adesea „aplicații”, mai degrabă decât colecții individuale de pagini, așa că se poate folosi o metodologie de aplicare a unei singure pagini cu o singură adresă URL reală, dar mai multe pagini diferite sub aceasta. Acest lucru poate afecta CLS în special datorită faptului că este măsurat pe toată durata de viață a paginii (deși sperăm că modificările viitoare ale CLS vor ajuta cu asta).

După cum am menționat anterior, raportul Core Web Vitals din Google Search Console, deși se bazează pe CrUX, cu siguranță nu este aceleași date. După cum am spus mai devreme, bănuiesc că acest lucru se datorează în primul rând Google Search Console care încearcă să estimeze valorile vitale web pentru adresele URL în care nu există date CrUX. Exemplele de URL-uri din acest raport sunt, de asemenea, incompatibile cu datele CrUX.

I've seen many instances of URLs that have been fixed, and the CrUX data in either PageSpeed Insights, or directly via the API, will show it passing Web Vitals, yet when you click on the red line in the Core Web Vitals report and get sample URLs these passing URLs will be included as if they are failing . I'm not sure what heuristics Google Search Console uses for this grouping, or how often it and sample URLs are updated, but it could do with updating more often in my opinion!

CrUX is based on page views . That means your most popular pages will have a large influence on your origin CrUX data. Some pages will drop in and out of CrUX each day as they meet these thresholds or not, and perhaps the origin data is coming into play for those? Also if you had a big campaign for a period and lots of visits, then made improvements but have fewer visits since, you will see a larger proportion of the older, worse data.

CrUX data is separated into Mobile , Desktop and Tablet — though only Mobile and Desktop are exposed in most tools. The CrUX API and BigQuery allows you to look at Tablet data if you really want to, but I'd advise concentrating on Mobile and then Desktop. Also, note in some cases (like the CrUX API) it's marked as PHONE rather than MOBILE to reflect it's based on the form factor, rather than that the data is based on being on a mobile network.

All in all, a lot of these issues are impacts of field (RUM) data gathering, but all these nuances can be a lot to take on when you've been tasked with “fixing our Core Web Vitals”. The more you understand how these Core Web Vitals are gathered and processed, the more the data will make sense, and the more time you can spend on fixing the actual issues, rather than scratching your head wondering why it's not reporting what you think it should be.

Getting Faster Feedback

OK, so by now you should have a good handle on how the Core Web Vitals are collected and exposed through the various tools, but that still leaves us with the issue of how we can get better and quicker feedback. Waiting 21–28 days to see the impact in CrUX data — only to realize your fixes weren't sufficient — is way too slow. So while some of the tips above can be used to see if CrUX is trending in the right direction, it's still not ideal. The only solution, therefore, is to look beyond CrUX in order to replicate what it's doing, but expose the data faster.

There are a number of great commercial RUM products on the market that measure user performance of your site and expose the data in dashboards or APIs to allow you to query the data in much more depth and at much more granular frequency than CrUX allows. I'll not give any names of products here to avoid accusations of favoritism, or offend anyone I leave off! As the Core Web Vitals are exposed as browser APIs (by Chromium-based browsers at least, other browsers like Safari and Firefox do not yet expose some of the newer metrics like LCP and CLS), they should, in theory, be the same data as exposed to CrUX and therefore to Google — with the same above caveats in mind!

For those without access to these RUM products, Google has also made available a Web Vitals JavaScript library, which allows you to get access to these metrics and report them back as you see fit. This can be used to send this data back to Google Analytics by running the following script on your web pages:

 <script type="module"> import {getFCP, getLCP, getCLS, getTTFB, getFID} from 'https://unpkg.com/web-vitals?module'; function sendWebVitals() { function sendWebVitalsGAEvents({name, delta, id, entries}) { if ("function" == typeof ga) { ga('send', 'event', { eventCategory: 'Web Vitals', eventAction: name, // The `id` value will be unique to the current page load. When sending // multiple values from the same page (eg for CLS), Google Analytics can // compute a total by grouping on this ID (note: requires `eventLabel` to // be a dimension in your report). eventLabel: id, // Google Analytics metrics must be integers, so the value is rounded. // For CLS the value is first multiplied by 1000 for greater precision // (note: increase the multiplier for greater precision if needed). eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta), // Use a non-interaction event to avoid affecting bounce rate. nonInteraction: true, // Use `sendBeacon()` if the browser supports it. transport: 'beacon' }); } } // Register function to send Core Web Vitals and other metrics as they become available getFCP(sendWebVitalsGAEvents); getLCP(sendWebVitalsGAEvents); getCLS(sendWebVitalsGAEvents); getTTFB(sendWebVitalsGAEvents); getFID(sendWebVitalsGAEvents); } sendWebVitals(); </script>

Or alternatively, you can include this as an external script instead:

 <script type="module" src="/javascript/send-web-vitals.js"></script>

Now I realize the irony of adding another script to measure the impact of your website, which is probably slow in part because of too much JavaScript, but as you can see above, the script is quite small and the library it loads is only a further 1.7 kB compressed (4.0 kB uncompressed). Additionally, as a module (which will be ignored by older browsers that don't understand web vitals), its execution is deferred so shouldn't impact your site too much, and the data it can gather can be invaluable to help you investigate your Core Web Vital, in a more real-time manner than the CrUX data allows.

The script registers a function to send a Google Analytics event when each metric becomes available. For FCP and TTFB this is as soon as the page is loaded, for FID after the first interaction from the user, while for LCP and CLS it is when the page is navigated away from or backgrounded and the actual LCP and CLS are definitely known. You can use developer tools to see these beacons being sent for that page, whereas the CrUX data happens in the background without being exposed here.

The benefit of putting this data in a tool like Google Analytics is you can slice and dice the data based on all the other information you have in there, including form factor (desktop or mobile), new or returning visitors, funnel conversions, Chrome version, and so on. And, as it's RUM data, it will be affected by real usage — users on faster or slower devices will report back faster or slower values — rather than a developer testing on their high spec machine and saying it's fine.

At the same time, you need to bear in mind that the reason the CrUX data is aggregated over 28 days, and only looks at the 75th percentile is to remove the variance. Having access to the raw data allows you to see more granular data , but that means you're more susceptible to extreme variations. Still, as long as you keep that in mind, keeping early access to data can be very valuable.

Google's Phil Walton created a Web-Vitals dashboard, that can be pointed at your Google Analytics account to download this data, calculate the 75th percentile (so that helps with the variations!) and then display your Core Web Vitals score, a histogram of information, a time series of the data, and your top 5 visited pages with the top elements causing those scores.

Using this dashboard, you can filter on individual pages (using a ga:pagePath==/page/path/index.html filter), and see a very satisfying graph like this within a day of you releasing your fix, and know your fix has been successful and you can move on to your next challenge!:

With a little bit more JavaScript you can also expose more information (like what the LCP element is, or which element is causing the most CLS) into a Google Analytics Custom Dimension. Phil wrote an excellent Debug Web Vitals in the field post on this which basically shows how you can enhance the above script to send this debug information as well, as shown in this version of the script.

These dimensions can also be reported in the dashboard (using ga:dimension1 as the Debug dimension field, assuming this is being sent back in Google Analytics Customer Dimension 1 in the script), to get data like this to see the LCP element as seen by those browsers:

Așa cum am spus anterior, produsele comerciale RUM vor expune adesea și acest tip de date (și mai multe!), dar pentru cei care doar își scufundă piciorul în apă și nu sunt pregătiți pentru angajamentul financiar al acelor produse, aceasta oferă cel puțin prima distracție. în valorile bazate pe RUM și cât de utile pot fi acestea pentru a obține acel feedback crucial mai rapid cu privire la îmbunătățirile pe care le implementați. Și dacă acest lucru vă trezește apetitul pentru aceste informații, atunci cu siguranță uitați-vă la celelalte produse RUM de acolo pentru a vedea cum vă pot ajuta și pe dvs.

Când vă uitați la măsurători alternative și la produse RUM, nu uitați să vă întoarceți la ceea ce vede Google pentru site-ul dvs., deoarece poate fi diferit. Ar fi păcat să muncești din greu la performanță, dar să nu obții toate beneficiile de clasament ale acestui lucru în același timp! Așa că, urmăriți graficele din Search Console pentru a vă asigura că nu pierdeți nimic.

Concluzie

Core Web Vitals sunt un set interesant de valori cheie care caută să reprezinte experiența utilizatorului de navigare pe web. În calitate de susținător pasionat al performanței web, salut orice efort de a îmbunătăți performanța site-urilor, iar impactul în clasament al acestor valori a creat cu siguranță o mare popularitate în comunitățile de performanță web și SEO.

În timp ce valorile în sine sunt foarte interesante, ceea ce este poate mai interesant este utilizarea datelor CrUX pentru a le măsura. Acest lucru expune, practic, datele RUM către site-uri web care nu s-au gândit niciodată să măsoare performanța site-ului în domeniu în acest mod înainte. Datele RUM sunt ceea ce experimentează de fapt utilizatorii , în toate configurațiile lor sălbatice și variate și nu există un substitut pentru înțelegerea modului în care site-ul dvs. funcționează cu adevărat și cum este experimentat de utilizatori.

Dar motivul pentru care am fost atât de dependenți de datele de laborator atât de mult timp este că datele RUM sunt zgomotoase. Pașii pe care îi face CrUX pentru a reduce acest lucru ajută la oferirea unei vederi mai stabile, dar cu prețul faptului că este dificil să se vadă modificările recente.

Sperăm că această postare explică diferitele modalități de accesare a datelor Core Web Vitals pentru site-ul dvs. web și unele dintre limitările fiecărei metode. De asemenea, sper că va explica unele dintre datele pe care v-ați chinuit să le înțelegeți, precum și să sugereze câteva modalități de a evita aceste limitări.

Optimizare fericită!