Actualizarea Google din mai 2021: o privire mai atentă la Core Web Vitals

ACTUALIZARE: Lumea marketingului digital se schimbă în mod constant, dar nu vă faceți griji, suntem pe primul loc. Google s-a răzgândit în legătură cu viitorul algoritm.

Citiți modificările recente aici în actualizarea noastră, dar nu ezitați să citiți și acest blog.

În mai 2021, Google va introduce valorile Core Web Vitals (CWV) pentru a face parte din algoritmul lor de căutare. Iată ce trebuie să știți și să faceți înainte ...

Știm cu toții că site-urile rapide sunt importante. Acestea creează o experiență de utilizare mai bună, rezultând creșterea ratelor de conversie și fac deja parte din clasarea căutărilor mobile în Google, împreună cu alte valori privind experiența paginii, cum ar fi compatibilitatea cu dispozitivele mobile.

Dar Google nu se oprește aici. În mai 2020, ne-au spus despre Core Web Vitals, iar pe 10 noiembrie 2020, au anunțat că în mai 2021, Core Web Vitals va fi încorporat ca semnal de căutare în algoritmul general de clasare.

În plus, intenționează să „testeze un indicator vizual care evidențiază paginile din rezultatele căutării care au o experiență excelentă în pagină”. Deci, nu numai că avem șanse crescute de clasamente mai mari prin optimizarea CWV, dar avem și perspectiva creșterii ratelor de clic din paginile cu rezultatele motorului de căutare.

Acționând acum pentru a verifica și a remedia eventualele probleme semnalate cu aceste noi valori CWV, site-urile noastre vor avea șanse mai mari de a obține clasamente Google mai ridicate atunci când această modificare va intra în vigoare în 2021.

Dar mai întâi, o recapitulare ...

Recapitulare: ce sunt Core Web Vitals?

Core Web Vitals sunt un set de 3 valori noi privind experiența paginii care intră în scorurile generale ale vitezei site-ului. Aceste valori iau deja un rol important în instrumentul Google PageSpeed ​​Insights PSI și monitorizarea performanței Lighthouse în altă parte.

Noile valori CWV cuprind următoarele:

Cea mai mare vopsea conținută (LCP)

Acesta este timpul necesar până când cel mai mare element de deasupra elementului de pliere este redat utilizatorului. Acesta reprezintă 25% din mecanismul general de scorare a vitezei și, prin urmare, este extrem de important pentru a simplifica livrarea celui mai mare articol la 2,5 secunde sau mai puțin pe mobil.

Numeroși factori contribuie la un LCP ridicat, inclusiv capacitatea de răspuns a serverului, scripturile și stilurile de blocare a redării, complexitatea CSS, fonturile și imaginile

Prima întârziere de intrare (FID)

Aceasta măsoară interactivitatea; cât de receptivă este pagina la introducerea utilizatorului, de exemplu prin atingeri sau clicuri. Viteza țintă la care browserul răspunde la prima intrare ar trebui să fie de 100 ms sau mai mică.

Dacă browserul analizează sau execută o mulțime de JavaScript în timpul încărcării paginii, acest lucru va lega procesorul sau va bloca „Firul principal”, ceea ce va face ca dispozitivele să fie mai puțin receptive la intrare. Un FID ridicat este de obicei un indicator al JavaScript-ului complex. Acesta ar putea fi un singur script sau funcție sau numeroase scripturi.

Valorile PSI existente pentru Timp până la interactivitate și Timpul total de blocare sunt legate de FID și reprezintă în mod colectiv 35% din scorurile de viteză globale.

Schimbarea aspectului cumulativ (CLS)

Aceasta este o măsură a stabilității vizuale a conținutului de mai sus. Deși cuprinde doar 5% din scorurile de viteză generale, merită încă luată în considerare în imaginea generală. Un CLS ridicat poate indica adesea una sau mai multe modificări ale aspectului vizual în timpul încărcării paginii, de exemplu atunci când sunt încărcate bannere, deplasând conținutul paginii în jos.

Defalcarea scorului de viteză

Diagrama de mai jos prezintă o defalcare a scorului general al vitezei și cât de important joacă aceste noi valori CWV în scorurile GPSI.

Date sursă din actualizarea scorului Lighthouse

În timp ce valorile non-CWV formează, de asemenea, scorul general, inclusiv First Content Paint (FCP), Time to Interactive (TTI) și Total Blocking Time (TBT), concentrarea pe cele trei valori CWV va avea un impact direct asupra celorlalte. Un LCP rapid nu este posibil, de exemplu, fără un FCP rapid, iar scorurile FID ridicate sunt direct afectate de TBT și TTI.

Sfaturi pentru cea mai mare optimizare a conținutului de vopsea

Metrica LCP este alcătuită din numeroși factori individuali și este afectată direct de un FCP ridicat. Dacă FCP este semnalat ca fiind slab, vă recomandăm să începeți de aici. Orice, de la conectivitatea la rețea, sensibilitatea serverului, Time To First Byte TTFB și fișierele de blocare a redării, vor afecta valoarea FCP. Pentru o scufundare mai profundă în unele dintre aceste recomandări mai generale de viteză a paginii, consultați cartea noastră electronică privind viteza paginii pe acest subiect, în plus față de sfaturile specifice LCP de mai jos.

Dacă valoarea LCP este mult mai mare decât FCP, atunci trebuie să ne uităm la modul în care putem eficientiza mai bine afișarea acestui cel mai mare element.

Determinați cel mai mare element

Primul lucru pe care probabil ai vrea să-l faci este să determini care este cel mai mare element. Cel mai mare element se bazează pe suprafața pixelilor care se poate modifica la diferite puncte de întrerupere, astfel încât o scanare vizuală nu poate identifica neapărat elementul potrivit.

În PSI, ar trebui să existe un panou „Cel mai mare element vopsit conținut” în secțiunea Diagnostic. Alternativ, puteți vizualiza LCP trecând peste indicatorul din instrumentul de monitorizare a performanței Chrome, așa cum se arată mai jos.

Pe site-ul Hallam din exemplul de mai sus, Monitorul de performanță arată LCP ca rubrica principală „Prosperă online”. În mod ideal, LCP ar trebui să urmeze imediat FCP ca în acest exemplu și dacă există un decalaj între cele două, trebuie să încercăm să înțelegem de ce.

Fonturile sunt optimizate?

Dacă cel mai mare element de deasupra elementului de pliere este tipografia, atunci trebuie să ne asigurăm că livrarea fontului este cât mai simplă posibil. Aceasta include:

1. Utilizați fontul de afișare CSS: swap; pentru a asigura afișarea imediată a fontului în timpul încărcării fișierului fontului. Atât Google Fonts, cât și Adobe Typekit au capacitatea de a seta parametrul „afișare” al fontului.
2. Încercați să găzduiți local fișiere de fonturi .woff și .woff2 pe server în loc să faceți cereri între domenii către fonturi terțe. Google Fonts este destul de rapid, fonturile Typekit sunt mai lente și unele turnătorii de fonturi terță parte pot fi mai puțin fiabile.
3. Preîncărcarea fișierelor de fonturi vă poate ajuta. Fonturile găzduite local vor fi deseori incluse în foaia de stil principală a site-urilor web, dar această foaie de stil trebuie descărcată și analizată înainte de a se face o cerere suplimentară pentru fontul din interior. Preîncărcarea îi spune browserului să înceapă să descarce fontul mai devreme, fără a aștepta ca CSS să fie analizat.
4. Utilizați preconnect și dns-prefetch pentru turnătorii de fonturi terță parte. Aceste directive vor ajuta la stabilirea conexiunilor DNS, TLS și TCP între domeniile terților, înainte ca cererea să fie făcută la fonturi.
5. Includeți numai fișiere de fonturi pentru tipografia necesară pentru deasupra afișajului pliant. Elementele de fonturi pentru bibliotecile de pictograme, cum ar fi Font Awesome, sunt notorii, dar cererile către acestea (și biblioteca de pictograme corespunzătoare CSS) pot fi de obicei amânate și încărcate după elementul <head>.
6. Nu efectuați cereri între domenii pentru fișierele de fonturi din foaia de stil a site-ului principal, deoarece aceasta se bazează pe conectivitate și căutare suplimentară a unui domeniu terță parte.
7. Luați în considerare fonturile sigure pentru web. Acestea nu necesită nicio solicitare de fișiere de fonturi, deși pot fi foarte limitate din punct de vedere estetic.

Sunt imaginile optimizate?

Destul de des, cel mai mare element de deasupra elementului de pliere va fi o imagine atât de importantă pentru a asigura optimizarea imaginilor. Următoarele sunt bune practici în general, dar deosebit de importante pentru elementul LCP.

1. Utilizați tipul corect de fișier imagine. Imaginile JPG ar trebui folosite pentru fotografii, SVG-urile pentru grafică vectorială și icoane sau PNG pentru imagini mai complexe, non-fotografice și dacă este necesară transparență.
2. Asigurați-vă că imaginile JPG sunt salvate sau afișate cu o calitate de aproximativ 50-60%. La acest nivel, nu ar trebui să existe pierderi discernabile de calitate. De asemenea, asigurați-vă că imaginile au avut metadate scoase din ele.
3. Plugin-urile de compresie sau serviciile precum tinypng.com pot optimiza automat și în bloc imagini și pot elimina meta date inutile.
4. Imaginile trebuie să fie dimensionate corespunzător pentru zona în care sunt afișate. Nu scoateți imaginea desktop de înaltă calitate pe mobil.
5. Imaginile ar trebui să fie afișate folosind eticheta standard <img> cu atributul „srcset” pentru imaginile receptive.
6. Sub imaginile de pe pliere sau în afara ecranului ar trebui să se utilizeze atributul de încărcare = „leneș”.
7. Utilizați următoarea generație de format de fișier imagine .web pentru rate de compresie și mai bune. Acest lucru poate economisi cu ușurință 30% și, în multe cazuri, mult mai mare.
8. Luați în considerare preîncărcarea celei mai mari de deasupra imaginii de pliere pentru a iniția descărcarea mai repede înaintea altor conținuturi potențial mai puțin critice.

Reduceți fișierele de blocare a redării

Orice fișier JavaScript sau CSS încărcat în elementul <head> </head> este considerat blocarea redării, deoarece aceste fișiere trebuie descărcate înainte ca pagina să poată începe redarea. Acest lucru poate avea un impact imens atât asupra metricei FCP, cât și asupra LCP. Fișierele de blocare a randării din cap trebuie utilizate numai dacă sunt critice pentru inițialul de deasupra afișajului de pliere a paginii.

Eliminarea oricăror fișiere neutilizate din <head>, încărcarea fișierelor non-critice în subsol sau combinarea mai multor fișiere în mai puține fișiere va reduce cantitatea de active care blochează redarea.

Nu utilizați JavaScript pentru a afișa LCP

Înainte de CWV, aceasta nu era o mare problemă. Este obișnuit ca JavaScript să fie folosit pentru a anima sau afișa deasupra elementelor de pliere, cum ar fi textul decolorat sau caruselele de eroi, de multe ori cu un impact redus sau deloc asupra scorurilor de viteză.

Dacă afișarea celui mai mare element se bazează pe JavaScript, acest lucru poate provoca adesea o întârziere mare, deoarece JavaScript trebuie descărcat, analizat și executat înainte ca elementul să apară. Fișierele JavaScript sunt încărcate de obicei (și pe bună dreptate) după elementul <head>, deci nu sunt „blocare de redare”, dar asta înseamnă că pot bloca în mod eficient redarea LCP.

Aruncați o privire la exemplul de mai jos (sigla estompată și titlul schimbat), acesta provine dintr-un alt punctaj cu un punctaj ridicat din PSI. LCP (textul principal al antetului) este la câteva secunde mai departe de FCP, care este cauzat de cerința JavaScript (reprezentat de benzile galbene) de a descărca, analiza și executa înainte ca textul să se poată estompa.

Textul care se estompează în sine poate fi, de asemenea, o problemă, provocând afișarea întârziată a celui mai mare element.

Tehnici JavaScript precum aceasta pot reduce imediat scorurile de viteză generală cu 25% și nu ar trebui utilizate pentru a împiedica sau preveni încărcarea celui mai mare element în niciun fel.

Executați scripturi la încărcarea ferestrei

JavaScript este rar necesar (și nu ar trebui să fie necesar) pentru a afișa elemente critice deasupra conținutului, dar o problemă comună pe care o vedem este că funcțiile pot fi declanșate imediat ce DOM este gata. În cadrul popular jQuery, acest lucru se face prin evenimentul „gata”. Managerul de etichete Google poate declanșa, de asemenea, funcții sau „etichete” pe gata.

Luați în considerare declanșarea tuturor JavaScript-urilor care nu sunt necesare pentru afișarea critică a conținutului pe evenimentul de încărcare a ferestrei, după ce conținutul paginii principale este încărcat pentru a preveni orice potențială interferență cu redarea conținutului de deasupra pliantului și a elementului LCP.

Comutați LCP

Indiferent cât de bine este optimizată și eficientizată o imagine, aproape întotdeauna va dura mai mult descărcarea și afișarea față de un element tipografic. Deși este în întregime posibil să se obțină scoruri LCP rapide pentru imagini, uneori o modificare pentru a reduce cel mai mare element de imagine, astfel încât este mai mică decât cel mai mare element de text, va însemna că textul poate fi folosit în loc pentru LCP.

Acest lucru poate face o mare diferență în scoruri, dacă proiectul permite, așa cum se arată în exemplul de mai jos, în care LCP a fost comutat la un element text.

Sfaturi pentru optimizarea primei întârzieri de intrare

După cum am menționat anterior, FID măsoară cât de receptivă este pagina la introducerea utilizatorului. Acesta combină Time To Interactive TTI și Total Blocking Time TBT, care poate reprezenta până la 35% din scorurile de viteză generale.

Aceste valori sunt afectate în principal de analizarea și executarea scripturilor pe măsură ce pagina este încărcată; blocarea firului principal al procesorului și afectarea potențială a răspunsului dispozitivului, în special pentru dispozitivele smartphone de ultimă generație.

Este important să rețineți că „Datele de laborator” afișate în PSI nu măsoară direct FID. Acest lucru se datorează naturii interactive a măsurătorilor de la atingeri sau clicuri de către utilizator, care este greu de simulat. În schimb, este colectat prin „Date de teren”; măsurători adunate de la utilizatori reali pe o perioadă de 28 de zile pe baza raportului CrUX privind experiența utilizatorului Chrome.

Ca atare, optimizarea directă pentru FID este puțin mai dificilă, deoarece nu putem schimba ceva și putem aștepta 28 de zile pentru a fi colectate mai multe date. Prin urmare, ar trebui să folosim valorile TTI și TBT în datele de laborator pentru aceasta, întrucât timpurile mici pentru aceste valori vor fi corelate cu un FID scăzut.

Deci, cum putem face optimizarea pentru aceste valori?

Verificați JavaScript

JavaScript poate avea toate formele și dimensiunile și nu este neobișnuit ca o singură încorporare video, widget de chat, script ReCaptcha sau integrarea HubSpot să fie singura cauză din spatele valorilor ridicate FID, TTI și TBT.

Panourile de diagnostic din Page Speed ​​Insights sunt un loc bun pentru a începe. Secțiunea „Minimizați lucrul cu firul principal” vă va spune cât de mult timp de execuție este preluat de JavaScript, secțiunea „Reduceți timpul de execuție JavaScript” va indica care fișiere au timp de analiză și de execuție ridicat și „Reduceți impactul terților cod 'va evidenția și grupa scripturile terților cu impact ridicat.

Captura de ecran de mai jos prezintă un site care suferă de mai multe scripturi grele, cu o valoare de timp până la interactiv de 15 secunde. Multe scripturi provin de la terțe părți, inclusiv HubSpot și Vimeo.

Pentru o analiză și vizualizare mai profundă a modului în care aceste scripturi influențează încărcarea paginii, instrumentul de monitorizare a performanței Chrome poate fi o modalitate excelentă de a detalia în ce scripturi și funcții sunt declanșate, impactul relativ al acestor scripturi și în ce moment al paginii se încarcă acestea sunt executate scripturi lungi.

Exemplul de mai jos este de pe același site și arată JavaScript reprezentat de bare galbene, roz și portocalii, cu bare mai lungi care arată sarcini de executare mai lungi. Când facem clic pe aceste sarcini mai lungi, putem vedea scripturile evidențiate corelate cu scripturile mari evidențiate de PSI de mai sus.

Odată ce avem o imagine mai bună a scripturilor care afectează performanța, există mai multe tehnici pe care le putem folosi pentru a minimiza impactul acestora, după cum se arată mai jos.

Încărcați scripturile în mod asincron

JavaScript implicit se va executa în ordine. Dacă există scripturi care nu se bazează pe încărcarea altora, aceste scripturi trebuie încărcate cu atributul „asincronizat”, astfel încât să nu blocheze analiza și executarea altor scripturi.

Încărcați condiționat JavaScript

O problemă obișnuită pe care o vedem pe multe site-uri este că scripturile grele sunt încărcate la nivel global sau pe pagini atunci când nu sunt necesare. Dacă trebuie să utilizați ReCaptcha, de exemplu, pentru a ajuta la oprirea spamului la trimiterea formularelor, asigurați-vă că încărcați scripturi numai pe paginile care au formulare.

Simplificați pachetele JavaScript

Bibliotecile JavaScript, cum ar fi jQuery UI sau Bootstrap, sunt adesea folosite pentru a oferi funcții și funcții JavaScript suplimentare. Dacă utilizați un pachet, asigurați-vă că includeți numai funcțiile relevante în pachet pentru a salva JavaScript inutile de la descărcare și analiză.

Scripturi de încărcare leneșă atunci când este necesar

Chiar dacă JavaScript este încărcat numai pe paginile pe care este necesar, scriptul în sine nu trebuie neapărat să analizeze și să execute în timpul încărcării paginii sau a evenimentului de încărcare a ferestrei. Încărcarea JavaScript numai atunci când este de fapt necesară poate face o diferență masivă în valorile TTI, TBT și FID. Aici sunt cateva exemple:

1. Încorporările video precum YouTube și Vimeo au de obicei un impact ridicat. Luați în considerare încărcarea acestor scripturi numai atunci când dați clic pe o miniatură video.
2. Integrările de formulare terțe, cum ar fi HubSpot, pot fi intensive. Dacă formularul apare într-un mod sau în partea de jos a unei pagini, luați în considerare încărcarea sau injectarea scriptului necesar în derulare sau activare modală în loc de încărcare a paginii.
3. Widgeturile de chat live pot afecta scorurile de viteză generală cu până la 35%. Luați în considerare mutarea widgetului de chat live pe o pagină de contact dedicată cu suportul CTA global de „chat live” sau injectarea scriptului de chat live numai atunci când se face clic pe butonul „Chat cu noi”.
4. Adăugarea atributului „încărcare =” leneș ”pe conținutul bazat pe iFrame poate ajuta, dar este o funcție nouă a browserului și va trebui testată în funcție de încorporarea iFrame utilizată.

Evaluează instrumentele de business intelligence

Analiza comportamentului utilizatorului cu instrumente precum Hotjar sau software de testare A / B, cum ar fi VWO, este cu adevărat importantă pentru business intelligence și, în multe cazuri, beneficiile lor vor depăși impactul asupra vitezei site-ului.

Acestea fiind spuse, merită încă evaluată importanța utilizării acestor instrumente 24/7 în funcție de frecvența cu care sunt analizate datele. Testarea A / B ar trebui să fie dezactivată dacă nu se execută teste active, de exemplu, iar instrumentele de analiză a comportamentului, cum ar fi Hotjar, pot fi dezactivate după ce au fost colectate și procesate suficiente date.

Sfaturi pentru optimizarea Cumulative Layout Shift

Cumulative Layout Shift (CLS) pot reprezenta doar 5% din scorurile de viteză globale, dar totuși, o parte importantă a imaginii generale, mai ales că cantitatea mare de elemente de schimbare la încărcarea paginii poate fi o experiență discordantă pentru utilizator.

Determinați elementul CLS

Uneori poate părea evident ce element sau elemente provoacă o schimbare a conținutului, dar merită întotdeauna să verificați acest lucru prin panoul Layout Shift din PSI așa cum se arată mai jos.

Valoarea CLS ar trebui să fie sub 0,1, dar în exemplul de mai sus, aceasta este depășită cu peste 400% și va costa o scădere cu 5% a scorurilor. Dacă aceasta este o problemă globală, aceasta reprezintă 5% pe fiecare pagină.

Elementele de schimbare trebuie identificate și abordate în ordinea impactului și pot include elemente deasupra și dedesubtul pliului. Am evidențiat mai jos câteva dintre cele mai frecvente cauze și rezoluții ale modificării aspectului.

Ferește-te de animație

Este destul de obișnuit ca anumite tehnici de animație să fie utilizate pentru a schimba modul în care conținutul este prezentat utilizatorului, de exemplu prin estomparea sau glisarea în imagini, text sau panouri de conținut pe măsură ce utilizatorul derulează o pagină. Deși acestea pot fi plăcute din punct de vedere estetic (în funcție de cine întrebați), este important ca aceste tehnici să nu schimbe niciun conținut în timpul încărcării paginii.

Dacă trebuie să ascundeți și apoi să estompați conținutul către utilizator, asigurați-vă că dimensiunea containerului sau înălțimea totală a paginii nu se modifică ca conținut în timp ce se încarcă. Conținutul poate fi ascuns (dacă este necesar) folosind reguli de vizibilitate CSS în loc să fie afișate: niciuna; care va păstra cantitatea de bază de spațiu de care are nevoie.

Specificați dimensiunile imaginii

Dacă eticheta <img> nu are setat atributul de lățime și înălțime sau CSS nu este utilizat pentru a seta dimensiunile sau raportul imaginii, browserele vor trebui să descarce mai întâi imaginea înainte de a putea determina suprafața pixelilor de care are nevoie. afișare în. Acest lucru poate provoca o schimbare a oricărui conținut redat sub imagine, pe măsură ce imaginea este încărcată.

Specificarea lățimii și înălțimii imaginii sau setarea dimensiunilor sau raportului imaginii (sau a containerului părinte) în CSS înainte de descărcarea imaginii va asigura browserele să cunoască zona în care trebuie să se afișeze imaginea și să evite aspectul potențial schimb.

Bannere

Reclamele, barele legii cookie-urilor sau orice alte informații utilizate pentru a afișa informații importante într-un banner sunt probabil una dintre cele mai frecvente cauze ale unui CLS ridicat.

Este obișnuit ca conținutul bannerului să fie încărcat dintr-o sursă de date externă sau prin JavaScript de pe același site, ceea ce înseamnă că dimensiunea containerului bannerului nu poate fi calculată până când nu a fost încărcat conținutul. Când se întâmplă acest lucru, conținutul de sub banner se va deplasa în jos odată ce conținutul bannerului este încărcat și afișat utilizatorului.

Există o serie de rezoluții în acest sens:

1. Setați o înălțime minimă pentru banner sau container pentru banner în CSS, astfel încât browserul să poată reda în mod eficient un substituent. Deși acest lucru poate fi problematic dacă cantitatea de conținut este dinamică și necunoscută.
2. Absolut sau fixați poziția bannerului în partea de sus sau de jos a ecranului. Pentru bannere care pot fi închise sau respinse, aceasta este o considerație bună deoarece elementele fixe nu vor afecta poziționarea niciunui alt element.
3. Uitați-vă la redarea pe server a conținutului bannerului, dacă este posibil, ceea ce înseamnă că conținutul și dimensiunile bannerului pot fi încărcate dinainte înainte de a ajunge la utilizator.

rezumat

Sperăm că veți găsi câteva dintre tehnicile evidențiate mai sus utile pentru diagnosticarea și depanarea problemelor de performanță în jurul noilor Core Web Vitals de la Google. În ultimele luni la Hallam, am ajutat un număr de clienți să îmbunătățească performanțele site-ului web atât în ​​ceea ce privește auditurile noastre de viteză, cât și îmbunătățirile directe aduse de echipa noastră de dezvoltare.

Dacă vi s-a părut util acest articol, vă recomandăm, de asemenea, să consultați eBook-ul nostru privind performanța site-ului web, care face o scufundare mai profundă în unele dintre recomandările mai generice în ceea ce privește viteza paginilor de care oricine poate construi sau gestiona un site web.