Măsurarea și optimizarea pentru Google Core Web Vitals: Un ghid tehnic SEO

Colectarea datelor despre performanța site-ului dvs. este primul pas către oferirea unei experiențe excelente pentru utilizator. De-a lungul anilor, Google a oferit diverse instrumente pentru a evalua și raporta performanța web.

Printre acestea se numără Core Web Vitals, un set de semnale de performanță pe care Google le consideră critice pentru toate experiențele web.

Acest articol acoperă setul actual de elemente vitale web de bază și sfaturi și instrumente cheie pentru a vă îmbunătăți performanța web pentru a oferi utilizatorilor o experiență bună a paginii.

O privire asupra evoluției performanței web

Au dispărut vremurile în care îmbunătățirea performanței site-ului era simplă.

În trecut, resursele umflate și conexiunile întârziate au oprit adesea site-urile web. Dar ai putea depăși concurenții comprimând unele imagini, permițând comprimarea textului sau reducând foile de stil și modulele JavaScript.

Astăzi, vitezele de conectare sunt mai mari. Majoritatea resurselor sunt comprimate implicit și multe plugin-uri se ocupă de compresia imaginilor, implementarea cache-ului etc.

Căutarea Google pentru un web mai rapid persistă. PageSpeed ​​Insights (PSI) este încă live pe web.dev, fiind cel mai bun instrument pentru a evalua încărcările individuale ale paginilor.

În timp ce mulți consideră că evaluările PSI sunt în mod inutil punitive, este totuși cel mai aproape de modul în care Google ar putea cântări și clasa site-urile prin semnalele de viteză a paginii.

Pentru a trece cea mai recentă iterație a testului de viteză a paginii Google, va trebui să îndepliniți Evaluarea Core Web Vitals.

Înțelegerea elementelor vitale ale web de bază

Core Web Vitals sunt un set de valori integrate în semnalele mai ample de căutare a experienței de pagină introduse în 2021. Fiecare măsură „reprezintă o fațetă distinctă a experienței utilizatorului, este măsurabilă în teren și reflectă experiența din lumea reală a unui utilizator critic. rezultat centrat”, potrivit Google.

Setul actual de valori vitale web de bază includ:

• Prima vopsea satisfăcătoare
• Întârziere pentru prima introducere (se înlocuiește cu Interacțiune cu următoarea vopsea)
• Interacțiune cu Next Paint
• Este timpul până la primul octet
• Cea mai mare vopsea plină de conținut
• Schimbare cumulativă a aspectului

Web.dev explică cum funcționează fiecare măsurătoare, după cum urmează.

Prima vopsea satisfăcătoare (FCP)

„Metrica First Contentful Paint (FCP) măsoară timpul de la momentul în care pagina începe să se încarce până la momentul în care orice parte a conținutului paginii este redată pe ecran. Pentru această valoare, „conținut” se referă la text, imagini (inclusiv imagini de fundal), elemente <svg> sau elemente <canvas> non-albe.”

Ce înseamnă asta pentru SEO tehnici

FCP este destul de ușor de înțeles. Pe măsură ce o pagină web se încarcă, anumite elemente ajung (sau „sunt pictate”) înaintea altora. În acest context, „pictura” înseamnă randarea pe ecran.

Odată ce orice parte a paginii a fost redată – să presupunem că bara de navigare principală se încarcă înaintea altor elemente – FCP va fi înregistrat în acel moment.

Gândiți-vă la asta ca cât de repede pagina începe să se încarce vizibil pentru utilizatori. Încărcarea paginii nu va fi completă, dar va fi început.

Întârziere la prima intrare (FID)

„FID măsoară timpul de la momentul în care un utilizator interacționează pentru prima dată cu o pagină (adică când face clic pe un link, atinge un buton sau utilizează un control personalizat, bazat pe JavaScript) până la momentul în care browserul poate începe efectiv procesarea handlerelor de evenimente ca răspuns la acea interacțiune.”

Ce înseamnă asta pentru SEO tehnici

FID este o valoare de răspuns la interacțiunea utilizatorului care urmează să fie înlocuită de Interaction to Next Paint (INP) în martie 2024.

Dacă un utilizator interacționează cu un element de pe pagină (de exemplu, un link, sortarea unui tabel sau aplicarea unei navigări fațetate), cât timp va dura site-ul pentru a începe procesarea cererii?

Interacțiune cu Next Paint (INP)

„INP este o măsurătoare care evaluează capacitatea generală de răspuns a unei pagini la interacțiunile utilizatorului, observând latența tuturor interacțiunilor de clic, atingere și tastatură care au loc pe toată durata de viață a vizitei unui utilizator la o pagină. Valoarea finală a INP este cea mai lungă interacțiune observată, ignorând valorile aberante.”

Ce înseamnă asta pentru SEO tehnici

După cum sa menționat, INP va înlocui FID ca Core Web Vital în martie 2024.

INP ține cont de informații mai profunde (aparent care se întind înapoi la tastatură) și este probabil mai detaliat și mai sofisticat.

Timpul până la primul octet (TTFB)

„TTFB este o măsurătoare care măsoară timpul dintre solicitarea unei resurse și momentul în care începe să sosească primul octet al unui răspuns.”

Ce înseamnă asta pentru SEO tehnici

Odată ce o „resursă” (adică, imagine încorporată, modul JavaScript, foaia de stil CSS etc.) este solicitată, cât timp va dura site-ul pentru a începe să livreze resursa respectivă?

Să presupunem că vizitați o pagină web și pe acea pagină este o imagine încorporată. Începe să se încarce, dar încă nu s-a terminat de încărcat. Cât durează până când primul octet al acelei imagini este livrat de la server la client (browser web)?

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

„Valoarea cea mai mare de vopsea de conținut (LCP) raportează timpul de randare al celui mai mare bloc de imagine sau de text vizibil în fereastra de vizualizare, în raport cu momentul în care pagina a început pentru prima dată să se încarce.”

Ce înseamnă asta pentru SEO tehnici

LCP este una dintre cele mai importante valori, dar și cel mai dificil de satisfăcut.

Odată ce cea mai mare bucată de media vizuală (adică text sau imagine) s-a încărcat, LCP este înregistrat.

Puteți citi acest lucru ca, cât timp durează până se încarcă cea mai mare parte a conținutului principal al unei pagini?

Poate că încă mai sunt mici bucăți care se încarcă mai jos pe pagină și lucruri pe care majoritatea utilizatorilor nu le vor observa.

Dar, în momentul în care LCP este conectat, partea mare și evidentă a paginii dvs. s-a încărcat. Dacă durează prea mult pentru ca acest lucru să se întâmple, veți eșua verificarea LCP.

Schimbare cumulativă a aspectului (CLS)

„CLS este o măsură a celei mai mari explozii de scoruri de schimbare a aspectului pentru fiecare schimbare neașteptată a aspectului care are loc pe toată durata de viață a unei pagini.

O schimbare de aspect are loc de fiecare dată când un element vizibil își schimbă poziția de la un cadru redat la altul. (Consultați mai jos pentru detalii despre modul în care sunt calculate scorurile de schimbare a aspectului individual.)

O explozie de schimbări de aspect, cunoscută sub numele de fereastră de sesiune, este atunci când una sau mai multe schimbări individuale de aspect apar în succesiune rapidă, cu mai puțin de 1 secundă între fiecare schimbare și maximum 5 secunde pentru durata totală a ferestrei.

Cea mai mare explozie este fereastra de sesiune cu scorul cumulat maxim al tuturor schimbărilor de aspect din acea fereastră.”

Ce înseamnă asta pentru SEO tehnici

Pe vremuri, când optimizarea vitezei paginii era mai simplă, mulți proprietari de site-uri și-au dat seama că pot obține evaluări incredibil de mari ale vitezei paginii prin simpla amânare a tuturor resurselor de blocare a randării (de obicei, foi CSS și module JavaScript).

Acest lucru a fost excelent pentru a accelera încărcarea paginilor, dar a făcut web-ul o experiență de navigare mai greșită și mai enervantă.

Dacă CSS-ul dvs. – care controlează întregul stil al paginii dvs. – este amânat, atunci conținutul paginii se poate încărca înainte ca regulile CSS să fie aplicate.

Aceasta înseamnă că conținutul paginii dvs. se va încărca fără stil și apoi va sări puțin pe măsură ce se încarcă CSS.

Acest lucru este cu adevărat enervant dacă încărcați o pagină și faceți clic pe un link, dar apoi linkul sare și faceți clic pe linkul greșit.

Dacă ești un pic TOC ca mine, astfel de experiențe sunt absolut enervante (chiar dacă costă doar câteva secunde de timp).

Datorită faptului că proprietarii de site-uri încercau să „joace” evaluările vitezei paginii prin amânarea tuturor resurselor, Google avea nevoie de o contra-metrică, care să compenseze toate câștigurile de viteză ale paginii cu deficitul de experiență a utilizatorului.

Introduceți Schimbarea aspectului cumulativ (CLS). Acesta este un client dificil, care dorește să vă strice ziua dacă încercați să aplicați creșteri ale vitezei paginii fără a vă gândi la utilizatori.

CLS va analiza, practic, încărcările paginii dvs. pentru schimbări greșite și reguli CSS întârziate.

Dacă sunt prea multe, veți eșua evaluarea Core Web Vitals, în ciuda faptului că ați îndeplinit toate valorile legate de viteză.

Evaluarea elementelor vitale web de bază pentru rezultate mai bune UX și SEO

Una dintre cele mai bune modalități de a analiza performanța unei singure pagini web este să o încărcați în PageSpeed ​​Insights. Vederea este împărțită într-o combinație de:

• date la nivel de URL.
• Date de origine (la nivel de domeniu).
• Date de laborator.
• Date de câmp.

Pentru a înțelege acest lucru, trebuie să ne uităm la un exemplu:

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Aici, putem vedea evaluările și valorile vitezei paginii pentru pagina de pornire TechCrunch.

Mai sus, puteți vedea că Evaluarea Core Web Vitals a eșuat.

Într-un web pe mobil, este important să selectați fila Rezultate mobile , care ar trebui să fie redată în mod implicit (acestea sunt rezultatele care contează cu adevărat).

Selectați comutatorul Origine , astfel încât să vedeți datele generale mediate pe domeniul site-ului dvs., mai degrabă decât doar pagina de pornire (sau orice pagină pe care ați introdus-o pentru a scana).

Mai jos pe pagină, veți vedea vechea, familiară evaluare numerică a vitezei paginii:

Deci, care este diferența dintre noua evaluare Core Web Vitals și vechea evaluare a vitezei paginii?

În esență, noua evaluare Core Web Vitals (Succes/Eșec) se bazează pe date de câmp (utilizator real).

Vechea evaluare numerică se bazează pe accesări cu crawlere mobile simulate și pe date de laborator, care sunt doar estimări.

În esență, Google a trecut la evaluarea Core Web Vitals în ceea ce privește modificarea clasamentelor de căutare.

Pentru a fi clar, datele de laborator simulate pot oferi o defalcare frumoasă în ceea ce privește ceea ce nu merge bine, dar Google nu utilizează această evaluare numerică în algoritmii lor de clasare.

În schimb, evaluarea Core Web Vitals nu oferă prea multe informații granulare. Cu toate acestea, această evaluare este luată în considerare în algoritmii de clasare ai Google.

Prin urmare, scopul dvs. principal este să utilizați diagnosticul de laborator mai bogat, astfel încât să treceți în cele din urmă de evaluarea Core Web Vitals (derivată din datele de teren).

Rețineți că, atunci când faceți modificări site-ului dvs., în timp ce evaluarea numerică poate observa imediat modificări, va trebui să așteptați ca Google să extragă mai multe date de câmp înainte de a putea trece în cele din urmă evaluarea Core Web Vitals.

Veți observa că atât evaluarea Core Web Vitals, cât și evaluarea veche a vitezei paginii utilizează unele dintre aceleași valori.

De exemplu, ambele fac referire la First Contentful Paint (FCP), Largest Contentful Paint (LCP) și Cumulative Layout Shift (CLS).

Într-un fel, tipurile de metrici examinate de fiecare sistem de rating sunt destul de asemănătoare. Este nivelul de detaliu și sursa datelor examinate, care este diferit.

Trebuie să urmăriți să promovați evaluarea Core Web Vitals pe teren. Cu toate acestea, deoarece datele nu sunt prea bogate, este posibil să doriți să utilizați datele și diagnosticele tradiționale de laborator pentru a progresa.

Speranța este că puteți trece evaluarea Core Web Vitals abordând oportunitățile și diagnosticele de laborator. Dar nu uitați, aceste două teste nu sunt intrinsec conectate.

Evaluarea CWV-urilor dvs. prin PageSpeed ​​Insights

Acum că știți principalele valori ale Core Web Vitals și cum pot fi îndeplinite din punct de vedere tehnic, este timpul să treceți printr-un exemplu.

Să revenim la examinarea noastră a TechCrunch:

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Aici, FID este satisfăcut, iar INP eșuează doar cu o marjă îngustă.

CLS are unele probleme, dar principalele probleme sunt cu LCP și FCP.

Să vedem ce are de spus PageSpeed ​​Insights în ceea ce privește Oportunitățile și diagnosticarea .

Acum trebuie să trecem de la datele de teren la cele de laborator și să încercăm să izolam orice tipare care ar putea avea un impact asupra Core Web Vitals:

Mai sus, puteți vedea o mică sub-navigare în colțul din dreapta sus, în casetă verde.

Puteți utiliza aceasta pentru a restrânge diferitele oportunități și diagnostice la anumite valori Core Web Vitals.

În acest caz, însă, datele spun o poveste foarte clară, fără a se îngusta.

În primul rând, ni se spune să reducem JavaScript neutilizat. Aceasta înseamnă că uneori, JavaScript este încărcat fără a fi executat.

Există, de asemenea, note pentru a reduce CSS neutilizat. Cu alte cuvinte, unele stiluri CSS se încarcă, care nu sunt aplicate (o problemă similară).

De asemenea, ni se spune să eliminăm resursele care blochează randarea, care sunt aproape întotdeauna legate de modulele JavaScript și foile CSS.

Resursele de blocare a redării trebuie amânate pentru a le împiedica să blocheze încărcarea unei pagini. Cu toate acestea, așa cum am explorat deja, acest lucru poate perturba ratingul CLS.

Din acest motiv, ar fi înțelept să începeți să creați atât un CSS critic, cât și o cale de redare JavaScript critică. Făcând acest lucru, JavaScript și CSS sunt necesare deasupra pliului, amânând restul.

Această abordare îi permite proprietarului site-ului să satisfacă cerințele de încărcare a paginii, echilibrând în același timp cu valoarea CLS. Nu este un lucru ușor de făcut și, de obicei, necesită un dezvoltator web senior.

Deoarece am găsit, de asemenea, CSS și JavaScript neutilizate, putem emite și un audit general de cod JavaScript pentru a vedea dacă JavaScript ar putea fi implementat mai inteligent.

Să revenim la Oportunități și diagnosticare :

Acum, vrem să ne concentrăm pe diagnosticare. Google limitează în mod deliberat aceste verificări prin conexiuni 4G slabe, astfel încât elemente precum firul principal de lucru par atât de lungi (17 secunde).

Acest lucru este deliberat pentru a satisface utilizatorii cu lățime de bandă redusă și/sau dispozitive lente, care sunt comune în întreaga lume.

Vreau să vă atrag atenția aici asupra „Minimizarea activității în firul principal”. Această singură intrare este adesea o mină de aur de perspective.

În mod implicit, majoritatea sarcinilor de randare și execuție a scripturilor (JavaScript) ale unei pagini web sunt transmise prin firul de procesare principal al browserului web al unui client (un singur fir de procesare). Puteți înțelege cum acest lucru cauzează blocaje semnificative de încărcare a paginii.

Chiar dacă întregul dvs. JavaScript este minificat perfect și livrat rapid către browserul utilizatorului, acesta trebuie să aștepte într-o singură coadă de procesare a firelor în mod implicit, ceea ce înseamnă că un singur script poate fi executat deodată.

Așadar, trimiterea rapidă a încărcăturilor de JavaScript către utilizatorul dvs. este echivalentul cu tragerea unui furtun de incendiu către un zid de cărămidă cu un spațiu de un centimetru.

Bună treabă de livrare, dar nu totul va merge!

Din ce în ce mai mult, Google impune ca responsabilitatea noastră capacitatea de răspuns la viteză la nivel de client. Îți place sau bulgă, așa este (deci ar fi bine să te familiarizezi).

Ai putea spune frustrat: „De ce este așa!? Browserele web au avut acces la mai multe fire de procesare de ani de zile, chiar și browserele mobile au ajuns din urmă. Nu e nevoie ca lucrurile să fie atât de incomode, nu?

Defapt da. Unele scripturi se bazează pe rezultatul altor scripturi înainte ca ele însele să poată fi executate.

După toate probabilitățile, dacă toate browserele ar începe brusc să proceseze tot JavaScript în paralel, în afara secvenței, cea mai mare parte a web-ului probabil s-ar prăbuși și s-ar arde.

Deci, există un motiv întemeiat pentru care execuția secvențială a scripturilor este comportamentul implicit pentru browserele web moderne. Continui să subliniez cuvântul „implicit”. De ce este asta?

Pentru că există și alte opțiuni. Unul este de a împiedica browserul clientului să proceseze orice scripturi prin procesarea lor în numele utilizatorului. Acest lucru este cunoscut sub numele de randare pe server (SSR).

Este un instrument puternic pentru a descurca nodurile de execuție JavaScript la nivelul clientului, dar și foarte scump.

Serverul dvs. trebuie să proceseze toate solicitările de script (de la toți utilizatorii) mai repede decât browserul utilizatorului mediu procesează un singur script. Lasă-l pe acesta să se cufunde pentru o clipă.

Nu sunteți fan al acestei opțiuni? OK, haideți să explorăm paralelizarea JavaScript. Ideea de bază este de a folosi lucrătorii web pentru a defini ce scripturi se vor încărca în secvență față de care se pot încărca în paralel.

Deși puteți forța JavaScript să se încarce în paralel, acest lucru în mod implicit este extrem de nerecomandabil. Integrarea unei astfel de tehnologii ar atenua în mare măsură necesitatea SSR în majoritatea cazurilor.

Cu toate acestea, va fi foarte greu de implementat și va necesita (ați ghicit!) timpul unui dezvoltator web senior.

Același tip pe care îl angajați pentru a efectua auditul complet al codului JavaScript ar putea să vă ajute și în acest sens. Dacă combinați paralelizarea JavaScript cu o cale critică de redare JavaScript, atunci zburați cu adevărat.

În acest exemplu, iată lucrul cu adevărat interesant:

Puteți vedea imediat că, în timp ce firul principal este ocupat timp de 17 secunde, execuția JavaScript reprezintă 12 secunde.

Înseamnă asta că 12 secunde din cele 17 secunde de lucru în fir sunt execuții JavaScript? Este foarte probabil.

Știm că tot JavaScript este împins prin firul principal în mod implicit.

Tot așa este configurat implicit WordPress, CMS-ul activ.

Deoarece acest site rulează WordPress, toate acele 12 secunde de timp de execuție JavaScript provin probabil din cele 17 secunde de lucru în firul principal.

Aceasta este o perspectivă grozavă, deoarece ne spune că cea mai mare parte a timpului principal de procesare este cheltuită executând JavaScript. Și uitându-ne la numărul de scripturi de referință, asta nu este greu de crezut.

Ducând cruciada către Chrome Dev Tools

Este timpul să te tehnic și să scoți roțile de antrenament.

Deschideți o nouă instanță de Chrome. Ar trebui să deschideți un profil de invitat pentru a vă asigura că nu există aglomerație sau pluginuri activate care să ne umfle descoperirile.

Rețineți: efectuați aceste acțiuni dintr-un profil Chrome pentru invitați curat.

Încărcați site-ul pe care doriți să îl analizați. În cazul nostru, acesta este TechCrunch.

Acceptați cookie-urile după cum este necesar. Odată ce pagina este încărcată, deschideți Chrome DevTools (faceți clic dreapta pe o pagină și selectați Inspectați ).

Navigați la Performanță > Capturi de ecran.

Apăsați butonul de reîncărcare pentru a înregistra încărcarea paginii. Apoi va fi generat un raport:

Aici toți trebuie să respirăm adânc și să încercăm să nu intrăm în panică.

Deasupra, cutie verde, puteți vedea un panou subțire care ilustrează cererile de-a lungul timpului.

În această casetă, puteți trage mouse-ul pentru a selecta o secțiune de timp, iar restul paginii și analiza se vor adapta automat.

Regiunea pe care am selectat-o ​​manual este zona acoperită cu o casetă albastră semitransparentă.

Acolo are loc încărcarea paginii principale și ceea ce mă interesează să examinez.

În acest caz, am selectat aproximativ intervalul de timp și evenimente între 32 ms și 2,97 secunde. Să ne concentrăm privirea asupra interiorului firului principal:

Știi cum, mai devreme, spuneam că majoritatea sarcinilor de randare și execuțiilor JavaScript sunt forțate prin blocajul firului principal?

Ei bine, acum ne uităm la interiorul acelui fir principal de-a lungul timpului. Și da, în galben, puteți vedea o mulțime de sarcini de scripting.

Pe primele două rânduri, pe măsură ce trece timpul, există din ce în ce mai multe bucăți galbene închise care confirmă toate scripturile care se execută și cât timp durează procesarea. Puteți face clic pe bucăți de bară individuale pentru a obține o citire pentru fiecare articol.

Deși aceasta este o imagine puternică, veți găsi una mai puternică în secțiunea Rezumat :

Aceasta rezumă toate datele granulare, împărțite în secțiuni tematice simple (de exemplu, Scripting , Loading , Rendering ) prin mediul vizual ușor de digerat al unei diagrame donut.

După cum puteți vedea, scripting (execuția scriptului) ocupă cea mai mare parte a încărcării paginii. Deci, presupunerea noastră anterioară din combinația de date de teren și de laborator de la Google, care a arătat cu degetul la blocajele de execuție JavaScript din firul principal, pare să fi fost corectă.

În 2023, aceasta este una dintre problemele cele mai întâlnite, cu puține soluții simple, disponibile.

Este complex să creezi căi critice de redare JavaScript. Este nevoie de expertiză pentru a efectua audituri de cod JavaScript și nu este atât de simplu să adoptați paralelizarea JavaScript sau SSR.

Acum să mergem și să ne uităm la Arborele de apeluri :

Arborele de apeluri este adesea mai util decât Bottom-Up .

Datele sunt similare, dar Call Tree va grupa tematic sarcinile în compartimente utile, cum ar fi Evaluate Script (execuția scriptului).

Puteți apoi să faceți clic pe un grup, să îl extindeți și să vedeți scripturile și cât timp a durat să se încarce. 11% din timp a fost folosit pentru încărcarea pubads_impl.jsm , în timp ce 6% din timp a fost folosit pentru încărcarea opus.js .

Nu știu care sunt acele module (și poate nici tu nu), dar aici începe adesea călătoria de optimizare.

Acum putem face un pas înapoi la:

• Căutați pe Google aceste scripturi și vedeți dacă fac parte din biblioteci terțe, ce fac și care este impactul.
• Consultați dezvoltatorul în ceea ce privește modul în care acestea ar putea fi implementate mai inteligent.
• Reduceți problema la resurse individuale și căutați alternative.
• Rezolvați deficitul de performanță (sau, alternativ, luptați pentru mai multe resurse/lățime de bandă, un mediu de găzduire puternic – dacă acest lucru este într-adevăr necesar).

Alte instrumente de măsurare și optimizare pentru Core Web Vitals

Dacă ai reușit să rămâi cu mine până aici, felicitări. În ceea ce privește analiza profundă a corespondenței web și a vitezei paginii, am folosit doar:

• PageSpeed ​​Insights
• Chrome DevTools (fila Performanță )

Da, chiar poți fi atât de slabă. Cu toate acestea, există și alte instrumente care vă pot fi de mare ajutor:

• GTMetrix : Util în special pentru diagrama cascadă (necesită un cont gratuit pentru cascadă), pe care o poți afla cum să o citești aici. Nu uitați că GTMetrix va rula nelimitat în mod implicit, dând rezultate prea favorabile. Asigurați-vă că îl setați la o conexiune LTE.
• Google Search Console : dacă configurați acest lucru și verificați site-ul dvs., puteți vedea o mulțime de date de performanță și de utilizare în timp, inclusiv valorile Core Web Vitals pe mai multe pagini (agregate).
• Screaming Frog SEO Spider : Acesta poate fi conectat la API-ul de viteză a paginii, pentru a permite preluarea în bloc a notelor Core Web Vitals Pass sau Fail (pentru mai multe pagini). Dacă utilizați API-ul gratuit pentru viteza paginii, nu îl ciocăniți într-un mod nerezonabil

Îmbunătățirea evaluărilor de viteză a paginii dvs. era la fel de simplă ca și comprimarea și încărcarea unor imagini.

In zilele de azi? Este o cruciadă complexă Core Web Vitals.

Pregătește-te să te implici pe deplin. Orice mai puțin se va întâlni cu eșecul.