Cum obții un scor PageSpeed de 100, și ce înseamnă el de fapt.

Un 100 în PageSpeed Insights e unul dintre puținele numere din dezvoltarea web pe care le poți urca până la un maxim literal, exact de-aia îl urmăresc echipele — e un scor, nu o senzație. E, în același timp, doar un scor de laborator: o singură încărcare simulată, pe un device și o conexiune fixate, rulată o dată. Să-l obții e o disciplină cu adevărat utilă, care forțează reparații reale. Să-l tratezi ca linia de sosire e greșeala pe care o fac aproape toți cei care îl urmăresc. Iată din ce e făcut de fapt numărul, ce mișcă fiecare parte a lui și ce mai merită verificat după ce scorul de laborator arată 100.

Cele cinci metrici din spatele numărului

TBT și LCP împreună sunt 55% din scor. Echipele care repară mai întâi imaginile hero și abia apoi JavaScript-ul, pentru că imaginile par vinovatul evident, văd adesea un salt mai mic decât se așteptau — numărul mai mare aștepta în spatele tagului de script.

Din ce e făcut de fapt scorul

Scorul de 0–100 e o medie ponderată a cinci metrici, fiecare notată pe propria curbă și apoi combinate: Total Blocking Time la 30%, Largest Contentful Paint la 25%, Cumulative Layout Shift la 25%, First Contentful Paint la 10% și Speed Index la 10%. TBT singur cântărește de trei ori mai mult decât FCP, motiv pentru care două site-uri cu aceeași primă impresie de „pare rapid” pot ajunge la o diferență de 20 de puncte — unul are un script care blochează firul principal timp de două secunde după acel prim randaj, iar scorul pedepsește exact asta.

Fiecare metrică nu e notată liniar. Documentația proprie Chrome plasează curba pe o distribuție log-normală construită din date reale HTTP Archive, cu două puncte fixe: percentila 25 a site-urilor reale primește scorul 50, iar percentila 8 primește 90. Între aproximativ 50 și 92 relația e aproape liniară — reducerea timpului la o metrică lentă cumpără un număr previzibil de puncte. Peste 96 nu mai e așa: același timp economisit cumpără o fracțiune de punct, motivul matematic pentru care ultimele puncte până la 100 cer disproporționat mai multă muncă decât primele șaizeci.

De ce firul principal face cea mai mare pagubă

TBT măsoară fiecare interval în care firul principal e blocat mai mult de 50 de milisecunde între First Contentful Paint și momentul în care pagina devine interactivă, adunate. Rareori e un singur lucru lent — de obicei sunt o duzină de lucruri mici: un bundle care se parsează și execută înainte să poată rula altceva, un widget de chat sau un tag de analytics care se încarcă imediat, o bibliotecă de carusel care face muncă în DOM pentru ceva la care nimeni n-a derulat încă. Fiecare, izolat, pare inofensiv într-un code review. Suprapuse, sunt ceea ce trăiește un vizitator ca pe o pagină care pare gata și nu răspunde când o atingi.

Reparația rareori înseamnă „scrie cod mai rapid” — mai degrabă înseamnă ordine. Amână tot ce nu e necesar pentru primul randaj, împarte bundle-urile mari ca browserul să nu fie forțat să parseze cod pentru funcționalități la care nimeni n-a derulat încă, și încarcă scripturile terțe — chat, reclame, pixeli de marketing — după prima interacțiune, nu odată cu pagina, pentru că niciunul dintre ele nu e motivul pentru care a venit cineva pe pagină. O trecere de performanță concentrată e de obicei exact această listă, făcută o dată, corect, în loc de o reconstrucție.

De ce se mișcă scorul între rulări, chiar pe aceeași pagină

O singură rulare Lighthouse e un eșantion, nu o măsurătoare — documentația proprie de scoring a Chrome listează teste A/B, schimbări în livrarea reclamelor, rute de internet care se schimbă, încărcarea device-ului, extensii de browser și antivirus ca surse normale de variație de la o rulare la alta, peste orice ai schimbat tu însuți la deploy. Un scor de 94 într-un minut și 88 în următorul nu e de obicei o regresie; e aceeași pagină măsurată în condiții ușor diferite. Judecă un trend pe mai multe rulări, nu un singur număr făcut captură de ecran pentru un raport.

Desktop și mobil nici nu sunt același test cu o etichetă diferită. Din Lighthouse v6 rulează pe curbe de scoring separate, calibrate pe date reale diferite, iar mobilul e limitat deliberat la un profil mai lent și mai constrâns — menit să reprezinte un telefon de gamă medie pe o rețea reală, nu conexiunea de fibră pe care rulează testul. O pagină care ia 100 pe desktop și 74 pe mobil nu e un bug al uneltei; e unealta făcând exact ce e menită să facă.

Diferența dintre 100 în laborator și „bun” pentru vizitatori reali

PageSpeed Insights arată datele de laborator și cele de teren una lângă alta, iar Google e explicit că nu le combină: scorul de 0–100 se bazează în întregime pe rularea de laborator, iar datele de teren — vizite reale, agregate din Chrome UX Report — sunt raportate separat, fără să atingă acel număr. Documentația proprie o spune direct: date bune de laborator nu înseamnă neapărat că experiențele utilizatorilor reali vor fi și ele bune. Un 100 îți spune că încărcarea simulată pe device-ul și rețeaua testate a fost excelentă. Nu-ți spune ce s-a întâmplat pe un telefon Android de trei ani pe un 4G instabil, acolo unde stă de fapt o parte semnificativă din traficul real.

Aici intră Core Web Vitals ca un număr separat, și în anumite privințe mai important — date de teren judecate la percentila 75 a vizitelor reale pe o fereastră glisantă, exact ce se uită sistemele de ranking ale Google. Un site poate avea 100 în laborator și totuși să pice la Core Web Vitals pe teren, dacă publicul lui real folosește device-uri mai vechi sau conexiuni mai lente decât simulează testul de laborator. Verifică-le pe amândouă. Răspund la întrebări diferite.

Când merită să urmărești 100 literal, și când nu

Curba log-normală înseamnă că ultimele puncte sunt cele mai scumpe de pe toată pagina, cu o marjă mare — ceea ce face din 100 ținta corectă pentru un set mic de pagini și una cu adevărat risipitoare pentru majoritatea site-ului. Paginile care merită ultimul kilometru sunt cele cu greutate comercială: homepage-ul, landing page-urile principale spre care duce traficul din reclame, orice spre care duce o campanie plătită. Un articol de blog la două clickuri distanță are șanse foarte mici să-ți recupereze orele investite ca să închizi un gol de la 94 la 100.

Nouăzeci e acolo unde se oprește de obicei randamentul practic, și codul de culori propriu al Chrome e de acord — 90 și peste e notat „bun”, punct, fără nicio distincție între 90 și 100. Cheltuie ora marginală pe pagina pe care nimeni n-a reparat-o încă, nu pe cea care e deja verde.

Cum abordăm asta în practică

Un Audit tehnic e de unde pornește asta — îți spune care dintre cele cinci metrici te costă de fapt puncte pe paginile tale important comercial, în loc să ghicești dintr-o singură rulare Lighthouse. De acolo, o trecere de performanță concentrată repară lista specifică, nu una generică.

La un site nou, asta nu e o linie separată — un proiect Website de afaceri e construit pe o stivă modernă exact ca scorul să fie aproape de acest interval din prima zi, nu ceva de reparat retroactiv peste un an, după ce template-urile și lista de scripturi terțe au crescut amândouă dincolo de punctul unde reparația mai e ieftină.

Surse

Ponderile de scoring, metodologia și distincția laborator/teren de mai sus vin din acestea, verificate în august 2026.

• Chrome for Developers — Lighthouse performance scoring ↗

  Ponderile actuale ale metricilor (TBT 30%, LCP 25%, CLS 25%, FCP 10%, SI 10%), curba de scoring log-normală calibrată pe date HTTP Archive (percentila 25 = 50, percentila 8 = 90) și sursele variației de scor de la o rulare la alta.

• Google for Developers — About PageSpeed Insights ↗

  Precizează că scorul afișat se bazează doar pe date de laborator, că datele de teren și cele de laborator sunt arătate separat, nu combinate, și că „date bune de laborator nu înseamnă neapărat că experiențele utilizatorilor reali vor fi și ele bune”.

• Chrome for Developers — CrUX methodology ↗

  Cum funcționează eligibilitatea pentru date de teren și de ce reflectă condiții reale de vizită, nu o singură încărcare simulată.