Cum se folosește PageSpeed Insights: ghid în 7 pași

Ca să afli cum se folosește PageSpeed Insights, ai nevoie de trei lucruri: adresa unei pagini publice, cinci minute pentru primul test și răbdarea de a citi raportul în ordinea corectă. Instrumentul gratuit de la Google îți arată două lucruri diferite pe aceeași pagină: cum au trăit vizitatorii reali încărcarea paginii în ultimele 28 de zile (date din Chrome User Experience Report) și ce găsește Lighthouse într-un test simulat chiar acum. Greșeala cea mai des întâlnită este să te uiți doar la cifra mare de la 0 la 100 și să tragi concluzii din ea.

Ghidul de mai jos te duce prin 7 pași: pornești analiza, citești datele reale, citești testul de laborator, alegi paginile de testat, apoi rezolvi pe rând LCP, INP și CLS. Denumirile butoanelor și ale secțiunilor sunt cele din interfața în limba română a PageSpeed Insights, iar pragurile sunt cele publicate de Google în documentația PSI și pe web.dev. Dacă nu poți modifica fișierele, imaginile sau serverul site-ului, vei putea citi raportul, dar remedierile vor trebui făcute de cine administrează partea tehnică.

Ce îți arată PageSpeed Insights: datele utilizatorilor reali și testul de laborator

Documentația oficială spune clar că PageSpeed Insights (PSI) oferă atât date de laborator, cât și date din teren despre o pagină. Datele de laborator sunt utile pentru depanare, pentru că sunt colectate într-un mediu controlat, dar pot rata blocajele din lumea reală. Datele din teren surprind experiența reală a utilizatorilor, însă au un set mai restrâns de valori.

În practică, raportul are două blocuri mari:

• Descoperă experiența utilizatorilor reali: datele din teren, preluate din setul Chrome User Experience Report (CrUX), pentru perioada de colectare a ultimelor 28 de zile. Aici apare evaluarea Core Web Vitals, tradusă în interfața în română drept „Evaluarea Detaliilor de funcționare de bază pentru web”.
• Diagnostichează problemele de performanță: testul Lighthouse, rulat într-un mediu simulat, cu scoruri pentru categoriile Performanță, Accesibilitate, Cele mai bune practici și SEO, plus lista de audituri cu ce poți repara.

Core Web Vitals sunt trei valori: Largest Contentful Paint (LCP) pentru încărcare, Interaction to Next Paint (INP) pentru reacția la interacțiuni și Cumulative Layout Shift (CLS) pentru stabilitatea vizuală. INP a înlocuit First Input Delay (FID) ca valoare Core Web Vitals în 2024, așa că ghidurile care vorbesc încă despre FID sunt depășite.

Ce îți trebuie înainte de primul test

Raportul are valoare doar dacă îl poți transforma în modificări. Pregătește resursele de mai jos înainte să pornești analiza:

Resursă	De unde o obții	Ce pierzi dacă lipsește
URL public al paginii	Adresa exactă, publicată online	PSI nu poate testa pagini locale sau protejate cu parolă
Acces la Google Search Console	Proprietatea site-ului tău	Nu poți vedea grupurile de URL-uri cu aceeași problemă la nivel de site
Acces la CMS sau server	Panoul de administrare, găzduirea, FTP	Vezi problemele, dar nu le poți repara
Chrome cu DevTools	Browserul de pe calculatorul tău	Nu poți reproduce local testele Lighthouse și blocajele de interacțiune
Lista paginilor importante	Paginile cu cel mai mult trafic sau cu conversii	Testezi doar pagina principală și ratezi problemele din paginile adânci

Pasul 1: Introdu adresa URL și pornește analiza

Deschide pagespeed.web.dev. În câmpul „Introdu adresa URL a unei pagini web” lipește adresa completă a paginii, cu https://, exact așa cum o accesează vizitatorii (cu sau fără www, cu sau fără bara finală, după cum este configurat site-ul). Apasă butonul Analizează.

După ce analiza se termină, deasupra raportului apar două file: Mobil și Computer. Raportul se deschide pe fila Mobil. Începe mereu cu ea: condițiile simulate pentru mobil sunt mai dure, iar majoritatea problemelor apar mai întâi acolo.

Raportul are și butonul Copiază linkul, cu care trimiți colegilor exact rezultatul pe care îl vezi, cu data și ora testului. Este mai sigur decât o captură de ecran, pentru că păstrează și auditurile detaliate.

Dacă analiza se oprește cu o eroare de încărcare, verifică întâi trei lucruri: pagina se deschide fără parolă dintr-o rețea externă, certificatul SSL este valid și un firewall sau un serviciu anti-bot nu blochează cererile automate. Pentru un mediu de test protejat cu parolă folosește Lighthouse din Chrome DevTools, pe calculatorul tău.

Pasul 2: Citește evaluarea Core Web Vitals din datele reale

Prima secțiune a raportului, Descoperă experiența utilizatorilor reali, răspunde la întrebarea care contează cel mai mult: cum au trăit vizitatorii tăi încărcarea paginii. În dreapta ei ai comutatorul Această adresă URL / Origine. Prima variantă arată datele doar pentru pagina testată, a doua pentru tot site-ul (originea).

Cum se citește blocul:

1. Uită-te la verdict: „Evaluarea Detaliilor de funcționare de bază pentru web: reușită” sau „nereușită”. Conform documentației PSI, evaluarea este reușită dacă percentila 75 a celor trei valori (LCP, INP și CLS) se află în zona „Bine”. Dacă pentru INP nu există date suficiente, evaluarea se face doar pe LCP și CLS.
2. Citește valoarea afișată deasupra fiecărei bare. Ea este percentila 75: trei sferturi dintre vizite au avut o valoare egală sau mai bună. Google a ales percentila 75 ca să vezi experiențele cele mai frustrante, nu media.
3. Privește bara colorată: verde, portocaliu și roșu arată ce parte din vizite a fost în zona „Bine”, „Necesită îmbunătățiri” sau „Slab”.
4. Coboară la ALTE VALORI IMPORTANTE: First Contentful Paint (FCP) și Time to First Byte (TTFB). Ele nu fac parte din Core Web Vitals, dar te ajută să înțelegi de unde vine un LCP slab.
5. Verifică rândul de jos al blocului: „Ultima perioadă de 28 de zile”, sursa (Raportul UX Chrome) și condițiile (diferite dispozitive mobile, diferite conexiuni la rețea).

Dacă pagina e nouă sau are prea puține vizite, PSI nu are destule date pentru ea și trece la nivelul originii. Dacă nici originea nu are date suficiente, blocul de date reale lipsește și rămâi doar cu testul de laborator.

Pragurile de mai jos sunt cele din documentația PSI, aliniate cu inițiativa Web Vitals:

Valoare	Bine	Necesită îmbunătățiri	Slab	Face parte din Core Web Vitals?
LCP	până la 2,5 s	peste 2,5 s și până la 4 s	peste 4 s	Da
INP	până la 200 ms	peste 200 ms și până la 500 ms	peste 500 ms	Da
CLS	până la 0,1	peste 0,1 și până la 0,25	peste 0,25	Da
FCP	până la 1,8 s	peste 1,8 s și până la 3 s	peste 3 s	Nu (valoare de diagnostic)
TTFB (experimentală)	până la 0,8 s	peste 0,8 s și până la 1,8 s	peste 1,8 s	Nu (valoare de diagnostic)

Datele reale din PSI se actualizează zilnic, dar fiecare actualizare acoperă tot ultimele 28 de zile. De aceea o remediere de azi nu schimbă imediat verdictul: vizitele vechi, lente, ies treptat din fereastra de 28 de zile. Același tip de date stă la baza raportului Core Web Vitals din Google Search Console, unde vezi problemele grupate pe tipuri de pagini.

Pasul 3: Citește scorul de performanță și valorile din laborator

A doua secțiune, Diagnostichează problemele de performanță, începe cu patru cercuri cu scoruri: Performanță, Accesibilitate, Cele mai bune practici și SEO. Pentru viteză te interesează primul. Documentația PSI spune că un scor de 90 sau mai mare este considerat bun, între 50 și 89 necesită îmbunătățiri, iar sub 50 este slab. Legenda de sub scor arată aceleași intervale: 0–49, 50–89, 90–100.

Sub scor ai secțiunea VALORI, cu cinci valori de laborator: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift și Speed Index. Observă că INP lipsește: un test simulat nu are un om care să atingă butoane, așa că Lighthouse folosește Total Blocking Time (TBT) ca indicator apropiat pentru problemele de reacție.

Sub valori, raportul îți spune în ce condiții a rulat testul: dispozitivul mobil simulat, versiunea Lighthouse, „Limitare 4G lentă” și „Încărcarea inițială a paginii”. Interfața scrie direct „Valorile sunt estimate și pot varia”, deci două teste la rând pot da scoruri diferite.

Tabelul de mai jos rezumă diferențele dintre cele două secțiuni:

Criteriu	Date din teren (Descoperă experiența utilizatorilor reali)	Date de laborator (Diagnostichează problemele de performanță)
Sursă	Vizite reale în Chrome, din setul CrUX	O singură încărcare simulată, rulată de Lighthouse
Perioadă	Ultimele 28 de zile	Momentul testului
Dispozitive și rețele	Variate, ale vizitatorilor tăi	Un dispozitiv simulat și o rețea fixă
Valori	LCP, INP, CLS, FCP, TTFB	FCP, LCP, TBT, CLS, Speed Index
La ce folosește	Să afli dacă vizitatorii au o experiență bună	Să găsești cauza și să verifici o remediere
Reacția la o modificare	Treptată, pe măsură ce se adună vizite noi	Imediată, la următorul test

Documentația PSI explică de ce cele două secțiuni se contrazic uneori: datele din teren sunt un istoric al vizitelor pe multe dispozitive și conexiuni, iar cele de laborator vin dintr-o singură încărcare, pe un singur dispozitiv. Un scor bun în laborator cu verdict „nereușită” în teren înseamnă de obicei că vizitatorii tăi folosesc telefoane sau rețele mai slabe decât simularea. Când cele două se contrazic, decizia o iei după datele reale, iar testul de laborator îl folosești ca să găsești cauza.

Ai reparat viteza paginilor? Cu Orova SEO alegi cuvintele-cheie din Search Console, AI-ul scrie articole optimizate cu imagini și le publică direct în WordPress, fără plugin.

Pasul 4: Testează mai multe tipuri de pagini, nu doar pagina principală

Pagina principală este de obicei cea mai îngrijită, dar vizitatorii din căutare intră adesea direct pe paginile adânci. Rulează analize separate pentru câte o pagină din fiecare tip important:

1. Pagina principală: prima impresie și resursele comune tuturor paginilor.
2. O pagină de categorie sau de listare: multe imagini mici, filtre și paginare.
3. O pagină de produs sau un articol lung: galerii foto, comentarii, butoane de distribuire.
4. Pagina de coș, de comandă sau formularul de contact: aici contează cel mai mult reacția la atingeri.
5. O pagină cu video, hărți sau alte elemente încorporate de la terți.

Notează rezultatele într-un tabel simplu, ca să vezi unde este problema cea mai mare:

Tip pagină	URL testat	Verdict Core Web Vitals (Mobil)	LCP	INP	CLS	Scor Performanță	Primul audit de rezolvat
Pagina principală	[completezi]	[reușită/nereușită]	[valoare]	[valoare]	[valoare]	[scor]	[audit]
Categorie	[completezi]	[reușită/nereușită]	[valoare]	[valoare]	[valoare]	[scor]	[audit]
Produs/articol	[completezi]	[reușită/nereușită]	[valoare]	[valoare]	[valoare]	[scor]	[audit]
Coș/formular	[completezi]	[reușită/nereușită]	[valoare]	[valoare]	[valoare]	[scor]	[audit]

Dacă pentru o pagină PSI arată doar datele originii, notează asta în tabel: valoarea nu este a paginii, ci a întregului site.

Pasul 5: Găsește și repară cauza unui LCP slab

LCP măsoară când apare pe ecran cel mai mare element vizibil din prima parte a paginii: o imagine, un banner, un video sau un bloc mare de text. Pe web.dev, pragul pentru o experiență bună este un LCP de cel mult 2,5 secunde.

În secțiunea de diagnostic, la „Vezi audituri relevante pentru”, apasă filtrul LCP. Raportul păstrează doar auditurile care influențează această valoare. Caută în primul rând:

• Detalierea valorii LCP: arată care este elementul LCP și cum se împarte timpul până la afișarea lui.
• Solicitări de blocare a redării: fișiere CSS sau JavaScript din antet care opresc desenarea paginii până sunt descărcate.
• Îmbunătățește livrarea imaginilor: imagini prea mari, în formate vechi sau prea puțin comprimate.

Ce faci, în funcție de elementul LCP:

• Dacă este o imagine: servește-o în format modern (WebP sau AVIF), la dimensiunea afișată pe mobil, și adaugă fetchpriority="high". Scoate loading="lazy" de pe această imagine: amânarea încărcării pentru primul element vizibil îl întârzie.
• Dacă este un bloc de text: verifică fontul web și auditul Afișarea fontului. Încarcă fontul local, în format WOFF2, și setează font-display în regula @font-face.
• Dacă elementul este creat de JavaScript (de exemplu primul cadru al unui carusel): pune-l direct în HTML-ul trimis de server, ca browserul să îl găsească fără să aștepte scriptul.
• Dacă vezi solicitări de blocare a redării: păstrează în antet doar stilurile necesare primului ecran și încarcă scripturile cu defer (cele care depind de structura paginii) sau async (cele independente, cum sunt scripturile de măsurare).

Exemplu (ipotetic): un magazin online vede în PSI că elementul LCP de pe pagina de produs este prima fotografie din galerie, încărcată de un script de carusel. Echipa pune prima fotografie direct în HTML, o convertește în WebP la dimensiunea afișată pe mobil, îi adaugă fetchpriority="high" și golește memoria cache a CDN-ului. Apoi rulează din nou testul și verifică în Detalierea valorii LCP dacă elementul se încarcă mai devreme. Verdictul din datele reale se va schimba abia după ce se adună vizite noi.

Pasul 6: Repară reacția lentă la interacțiuni (INP)

INP măsoară cât de repede răspunde pagina când vizitatorul apasă un buton, deschide meniul sau scrie într-un câmp. Valoarea raportată ține cont de interacțiunile din toată vizita, nu doar de prima. Pe web.dev, pragul pentru o experiență bună este un INP de cel mult 200 de milisecunde.

Pentru că testul de laborator nu are interacțiuni reale, cauzele le cauți indirect. Apasă filtrul TBT și citește auditurile:

• Evită activitățile îndelungate în firul principal: listează sarcinile lungi. Pe web.dev, o sarcină lungă este orice sarcină care ține ocupat firul principal mai mult de 50 de milisecunde; în acest timp pagina nu poate răspunde la atingeri.
• Minimizează procesarea firului principal: arată pe ce se duce timpul (evaluarea scripturilor, stiluri, aranjare în pagină).
• Redu codul JavaScript nefolosit: cod descărcat și procesat, dar nefolosit pe pagina respectivă.
• Terțe părți: cât de mult încarcă scripturile externe (reclame, chat, pixeli de urmărire).

Remedierile obișnuite:

1. Împarte funcțiile lungi în bucăți mai mici și cedează controlul browserului între ele (de exemplu cu scheduler.yield() acolo unde browserul îl acceptă, sau cu setTimeout()), ca pagina să poată afișa schimbarea vizuală între pași.
2. Amână scripturile care nu sunt necesare imediat: pixeli, widgeturi de chat, scripturi de analiză. Elimină din Google Tag Manager etichetele pe care nu le mai folosești.
3. Mută calculele grele (filtrarea listelor mari, procesarea datelor) într-un Web Worker, ca firul principal să rămână liber.

Exemplu (ipotetic): pe un site de știri, vizitatorii se plâng că meniul de pe mobil se deschide greu. Auditul de sarcini lungi arată un script de măsurare care rulează sincron la fiecare clic. Dezvoltatorul face ca meniul să se deschidă imediat, iar colectarea datelor este mutată după afișare, cu requestIdleCallback(). Rezultatul se confirmă în datele reale INP, după ce se adună vizite noi.

Pasul 7: Stabilizează pagina și elimină deplasările de aspect (CLS)

CLS măsoară cât de mult se mișcă elementele paginii fără ca vizitatorul să fi făcut ceva: textul care sare când apare o reclamă, butonul care fuge de sub deget. Pe web.dev, pragul pentru o experiență bună este un CLS de cel mult 0,1.

Apasă filtrul CLS în raport. Auditurile de urmărit sunt:

• Principalii factori care au cauzat schimbarea aspectului: elementele care s-au mișcat și ce a provocat mișcarea.
• Elementele imagine nu au width și height explicite: imagini pentru care browserul nu știe cât loc să rezerve.
• Afișarea fontului: fonturi care, la încărcare, schimbă dimensiunea textului.

Remedieri:

• Adaugă width și height pe fiecare <img> și <video> sau folosește aspect-ratio în CSS, ca browserul să rezerve spațiul din start.
• Rezervă spațiu (min-height) pentru reclame, bannere de consimțământ și alte casete care apar după încărcare.
• Pentru fonturi, folosește font-display și alege un font de rezervă cu dimensiuni apropiate, ca textul să nu se reașeze când se încarcă fontul web.

Verifică rezultatul în DevTools, în modul de emulare mobilă: reîncarcă pagina și urmărește dacă textul și butoanele rămân pe loc în timp ce se încarcă imaginile și reclamele.

Erori frecvente când interpretezi PageSpeed Insights

Cele mai multe ore pierdute la optimizare vin din citirea greșită a raportului, nu din lipsa de soluții tehnice:

Eroare	De ce se întâmplă	Ce faci corect
Urmărești scorul 100	Confunzi scorul Lighthouse cu verdictul pentru utilizatorii reali	Urmărești întâi verdictul Core Web Vitals din datele reale
Testezi doar pe Computer	Condițiile simulate pentru desktop ascund problemele	Pornești mereu de la fila Mobil
Compari două teste rulate la câteva minute distanță	Valorile de laborator sunt estimate și pot varia	Rulezi testul de mai multe ori și te uiți la tendință, nu la o singură cifră
Pui loading="lazy" pe toate imaginile	Pluginul aplică regula și pe imaginea din primul ecran	Scoți lazy loading de pe elementul LCP
Retestezi imediat după modificare și nu vezi nimic	Cache-ul CMS sau al CDN-ului servește încă versiunea veche	Golești cache-ul, apoi retestezi
Aștepți ca verdictul real să se schimbe a doua zi	Datele reale acoperă ultimele 28 de zile	Verifici remedierea în laborator, iar verdictul real îl urmărești în timp

Ce faci când scorul variază mult de la un test la altul

Dacă scorul de performanță sare de la un test la altul sau coboară în zona 0–49 fără să fi schimbat nimic, parcurge lista de mai jos în ordine:

• [ ] Verifică în fila Network din DevTools dacă serverul răspunde lent la prima cerere (TTFB). O supraîncărcare temporară a serverului strică tot lanțul.
• [ ] Verifică dacă în momentul testului rula pe server o copie de siguranță sau o sarcină programată grea.
• [ ] Testează pagina cu cache-ul CMS oprit, ca să vezi timpul real de generare.
• [ ] Verifică dacă CDN-ul a servit pagina din cache sau a mers la serverul de origine.
• [ ] Blochează pe rând, din DevTools, scripturile externe (Google Tag Manager, reclame, chat) și vezi care dintre ele face scorul instabil.
• [ ] Rulează Lighthouse din DevTools într-o fereastră fără extensii, ca să elimini influența calculatorului tău.
• [ ] Verifică jurnalele firewallului: dacă cererile de test sunt limitate sau blocate, resursele se descarcă incomplet.

Notă: numele auditurilor se mai schimbă de la o versiune Lighthouse la alta. Dacă un ghid mai vechi vorbește despre un audit pe care nu îl găsești, folosește filtrele FCP, LCP, TBT și CLS și caută după subiect (imagini, fișiere care blochează redarea, sarcini lungi).

Ai articole vechi care au nevoie de actualizare? Orova SEO le optimizează și le publică din nou la aceeași adresă URL. Toate funcțiile sunt gratuite până la 7 iulie 2027 inclusiv.

Verifică rezultatul în Search Console, nu doar în PSI

După ce ai publicat modificările, ai două locuri de verificare. În PSI, secțiunea Diagnostichează problemele de performanță îți arată imediat dacă auditul care te interesa a dispărut sau s-a îmbunătățit. Verdictul pentru utilizatorii reali se schimbă însă treptat, pe măsură ce vizitele noi înlocuiesc vizitele vechi din fereastra de 28 de zile.

Pentru tot site-ul, deschide raportul Core Web Vitals din Google Search Console. Centrul de ajutor Search Console nu are acest articol în limba română, așa că denumirile de mai jos sunt cele din engleză. Raportul grupează URL-urile după stare (Poor, Need improvement, Good), după valoare (LCP, INP, CLS) și în grupuri de pagini asemănătoare, pe baza datelor reale. Apar doar URL-uri indexate, iar starea unui grup este dată de valoarea lui cea mai slabă.

După ce ai reparat o problemă pe toate URL-urile afectate, poți porni validarea remedierii. Search Console deschide o perioadă de monitorizare de 28 de zile: dacă problema nu mai apare pe niciun URL în acest interval, este considerată rezolvată. Viteza paginilor este doar o parte din munca tehnică; o listă completă de pași găsești în ghidul despre cum să îmbunătățești SEO-ul unui site de firmă, iar contextul general îl ai în articolul despre ce este SEO.

După ce paginile sunt rapide: conținutul, cu Orova SEO

PageSpeed Insights îți spune cât de repede se încarcă paginile, dar nu le scrie și nu le actualizează. Partea de conținut o poți muta în Orova SEO: AI-ul scrie articole optimizate SEO, cu imagini, le publică direct în WordPress, optimizează articolele vechi, iar cifrele din Search Console le citești în același loc. Orova SEO nu măsoară Core Web Vitals: pentru viteză rămâi la PSI și Search Console.

Aplicația nu are încă interfață în limba română, așa că butoanele de mai jos au numele din interfața în engleză:

1. Deschide fila Write din Orova SEO. Aici vezi lista cuvintelor-cheie, cu stadiul fiecăruia și adresa articolului publicat.
2. Apasă + Add keyword pentru un cuvânt-cheie nou sau Import from Excel dacă ai deja o listă.
3. În fereastra Add keyword alegi proiectul, intenția de căutare, lungimea articolului și imaginile.
4. Alegi cum se publică: Publish as soon as possible sau Schedule publishing pentru o dată anume, apoi confirmi cu Add keyword.

Ce cuvinte-cheie alegi și unde se publică articolele

Orova SEO propune cuvinte-cheie prioritare din datele Search Console ale propriului site, cele pe care paginile tale se află deja pe pozițiile 8–30. Articolele se publică în WordPress prin Application Password, fără plugin. Un articol vechi poate fi optimizat și publicat din nou peste cel existent, păstrând aceeași adresă URL, iar fiecare proiect poate avea propria voce de brand, în 50 de limbi. Din meniul Actions gestionezi cuvintele-cheie din listă. Dacă vrei să vezi cum arată un articol bine construit înainte să pornești, citește ghidul despre articole SEO.

Tendințele în măsurarea vitezei: opinia autorului

Cred că diferența dintre datele de laborator și cele reale va conta tot mai mult. Scorul Lighthouse rămâne un instrument bun de depanare, dar deciziile se iau din ce în ce mai des după experiența vizitatorilor reali. Recomandarea mea este să raportezi echipei sau clientului verdictul Core Web Vitals pe mobil, nu scorul de laborator. Mă pot înșela dacă datele reale devin mai greu de colectat, de exemplu din cauza unor reguli mai stricte de confidențialitate în browsere.

Cred, de asemenea, că INP va rămâne cea mai greu de ținut sub control dintre cele trei valori. Fiecare script de analiză, chat sau personalizare adăugat pe pagină concurează pentru același fir principal. Sugerez ca orice script nou să treacă printr-un test PSI înainte de publicare, nu după ce vizitatorii se plâng. Această previziune se poate schimba dacă browserele vor oferi mecanisme mai bune de planificare a sarcinilor, pe care site-urile să le folosească implicit.

În fine, înclin să cred că instrumentele AI vor citi tot mai des rapoartele PSI în locul oamenilor și vor propune modificări de cod. Asta e util, dar numai dacă cineva verifică după aceea rezultatul în datele reale. Sfatul meu: tratează orice remediere propusă de AI ca pe o ipoteză și confirm-o în PSI și în Search Console.

Întrebări frecvente despre cum se folosește PageSpeed Insights

De ce este scorul pe mobil mai mic decât pe computer?

Pentru fila Mobil, Lighthouse simulează un telefon de gamă medie cu o conexiune mobilă limitată, în timp ce pentru Computer simulează un desktop cu conexiune prin cablu. Același cod are nevoie de mai mult timp pentru a fi descărcat și procesat în condițiile mobile, așa că scorul iese de obicei mai mic.

De ce variază scorul între două teste consecutive?

Valorile de laborator sunt estimate și pot varia: depind de cât de repede răspunde serverul în acel moment, de scripturile externe și de rețea. Documentația PSI menționează și că testul rulează într-un centru de date Google care poate fi diferit de la un test la altul. Rulează testul de mai multe ori și urmărește tendința.

Cum testez un site de test (staging) protejat cu parolă?

PSI nu poate accesa pagini din spatele unei autentificări sau dintr-o rețea privată. Deschide pagina în Chrome, intră în DevTools, alege fila Lighthouse și rulează analiza local.

Am nevoie de scorul 100 ca să apar sus în Google?

Nu. Scorul de performanță Lighthouse este un instrument de diagnostic. Contează ca vizitatorii reali să aibă o experiență bună, adică LCP, INP și CLS în zona „Bine” la percentila 75. Nu sacrifica funcții utile ale paginii doar ca să urci scorul de laborator.

De ce nu văd date reale pentru pagina mea?

Pagina nu are destule vizite înregistrate în setul CrUX, de exemplu pentru că este nouă. PSI afișează atunci datele originii (tot site-ul), iar dacă nici acestea nu sunt suficiente, rămâi doar cu testul de laborator.

Cât de des ar trebui să rulez PageSpeed Insights?

De fiecare dată când schimbi tema, adaugi un plugin sau un script nou ori schimbi găzduirea. În rest, verifică periodic paginile din tabelul de la Pasul 4 și urmărește raportul Core Web Vitals din Search Console.

De unde ar trebui să începi?

Dacă ai un site și nu programezi: rulează azi PSI pe fila Mobil pentru pagina principală și pentru pagina ta cea mai vizitată. Notează verdictul Core Web Vitals și primul audit din listă, apoi trimite linkul obținut cu Copiază linkul celui care administrează site-ul.

Dacă lucrezi în marketing: deschide Google Tag Manager și elimină etichetele și pixelii pe care nu îi mai folosești în campanii. Apoi rulează din nou testul și verifică auditul Terțe părți.

Dacă ești dezvoltator: pornește de la filtrul LCP din raport și de la Solicitări de blocare a redării, apoi treci la sarcinile lungi care afectează INP. Oricare ar fi rolul tău, să știi cum se folosește PageSpeed Insights înseamnă să citești întâi datele reale, apoi testul de laborator, și să verifici fiecare remediere în ambele.