Test viteză site: cum îl faci corect și ce înseamnă cifrele

Cel mai frecvent mesaj pe care îl primesc pe tema asta arată cam așa: „am dat test de viteză la site, mi-a ieșit 47 pe mobil și 92 pe desktop, e grav?". Răspunsul scurt: scorul în sine nu e problema. Problema e ce se ascunde sub el, iar cifra din cerc nu îți spune ce să repari.

Hai să facem testul cum trebuie și să traducem rezultatul în listă de acțiuni.

Cu ce testezi — și în ce ordine

Trei unelte, fiecare cu rolul ei. Ordinea contează, pentru că răspund la întrebări diferite.

Începe cu PageSpeed Insights, pe pagina pe care intră cei mai mulți oameni — de obicei nu prima pagină, ci pagina de serviciu care primește trafic din Google. Verifică în Analytics care e, nu ghici.

Greșelile care fac testul inutil

Jumătate din testele pe care le văd sunt făcute în condiții care produc cifre fără sens:

• Testezi doar desktop. Peste 70% din traficul unui site de firmă în România e mobil. Scorul mobil e cel care contează.
• Testezi o singură dată. Rezultatul de laborator variază ±10 puncte între rulări. Fă trei teste și ia mediana.
• Testezi doar prima pagină. Homepage-ul e de obicei cel mai optimizat. Paginile interioare sunt cele care duc greul.
• Testezi imediat după deploy, cu cache-ul gol. Aștepți câteva minute și repeți.
• Te uiți doar la scorul global și ignori metricile individuale. Acolo e informația.

Ce înseamnă fiecare metrică, pe românește

Scorul global e o medie ponderată. Reparațiile se fac pe metrici. Astea sunt cele trei Core Web Vitals — cele pe care Google le folosește efectiv ca semnal:

LCP — Largest Contentful Paint

Cât durează până apare cel mai mare element vizibil: de obicei imaginea principală sau titlul mare. E metrica „cât aștept până văd ceva util". Prag bun: sub 2,5 secunde. Peste 4 secunde e roșu.

Cauza numărul unu în România: imagine hero de 2–4 MB, încărcată la rezoluție completă și fără format modern.

INP — Interaction to Next Paint

Cât durează până pagina reacționează la o apăsare — click pe meniu, deschis un accordion, trimis un formular. A înlocuit vechiul FID în martie 2024. Prag bun: sub 200 ms. Peste 500 ms, utilizatorul apasă a doua oară crezând că n-a mers.

Cauza obișnuită: prea mult JavaScript care rulează pe firul principal — de regulă scripturi de la terți (chat, heatmap, patru pixeli de tracking).

CLS — Cumulative Layout Shift

Cât „sare" conținutul în timp ce se încarcă. Ai văzut asta: dai să apeși un buton, se încarcă o poză deasupra și butonul fuge în jos. Prag bun: sub 0,1.

Cauze: imagini fără width și height declarate, fonturi care se schimbă la încărcare, bannere de cookie-uri injectate după randare.

Diferența dintre date de laborator și date reale

Aici se încurcă cel mai des lumea. PageSpeed îți arată două secțiuni, iar ele nu spun același lucru:

Dacă site-ul tău e nou sau are trafic mic, secțiunea de date reale lipsește. E normal. Lucrezi pe datele de laborator până se strâng destule vizite.

Reparațiile, în ordinea raportului cost/efect

Din experiența pe site-urile de firmă din România, asta e ordinea în care merită să ataci. Primele două rezolvă majoritatea cazurilor.

1. Imaginile (efect mare, efort mic)

• Convertește în WebP sau AVIF — reducere tipică de 60–80% față de JPEG, la aceeași calitate vizibilă.
• Redimensionează la dimensiunea reală de afișare. O imagine de 4000px lățime într-un container de 800px e risipă pură.
• Pune width și height pe fiecare imagine — rezolvă direct CLS.
• Loading lazy pe tot ce e sub prima vizualizare, dar NU pe imaginea hero.

2. Scripturile de la terți (efect mare, efort mediu)

Fă inventarul onest: chat, Analytics, Meta Pixel, Google Ads, heatmap, widget de recenzii, banner de cookie-uri. Fiecare costă. Întreabă pentru fiecare: l-am folosit în ultimele 90 de zile? Ce se pierde dacă îl scot? Ce rămâne, se încarcă amânat, nu în head.

3. Fonturile (efect mediu, efort mic)

• Servește-le de pe domeniul tău, nu din CDN extern — economisești o conexiune întreagă.
• Maximum două familii, maximum trei greutăți. Fiecare greutate e un fișier.
• font-display: swap, ca textul să apară imediat cu fontul de sistem.

4. Hosting și cache (efect variabil, efort mic)

Dacă TTFB — timpul până la primul octet — trece de 600 ms, nicio optimizare de front-end nu te salvează. Ai deja o jumătate de secundă pierdută înainte să înceapă ceva. Verifică dacă hosting-ul e shared supraîncărcat și dacă ai cache activ.

5. Rescrierea pe stivă modernă (efect maxim, efort mare)

Când site-ul e WordPress cu page builder greu și 30 de plugin-uri, optimizarea are o limită. La un moment dat costul lunar al plasturilor depășește costul refacerii. Comparația detaliată e în <a href="/blog/nextjs-vs-wordpress-comparatie-completa">Next.js vs WordPress</a>.

Cât contează viteza pentru poziția în Google

Onest: mai puțin decât se spune. Core Web Vitals sunt un semnal de clasare confirmat, dar unul slab în comparație cu relevanța conținutului și autoritatea domeniului. Un site rapid cu conținut prost nu bate un site mediu cu conținut bun.

Unde contează mult mai tare e conversia. Fiecare secundă în plus la încărcare taie din vizitatorii care rămân, iar pe mobil efectul e brutal. Am detaliat partea de business în <a href="/blog/de-ce-site-ul-lent-iti-costa-clienti">de ce un site lent îți costă clienți</a>. Articolul de față e partea tehnică — cum măsori și ce repari.

Viteza nu te urcă în Google. Lipsa ei te costă clienții care ajunseseră deja la tine.

Ce scor e „suficient de bun"

Nu urmări 100. E o vânătoare cu randament descrescător, iar ultimele 10 puncte costă mai mult decât primele 40. Ținte rezonabile pentru un site de firmă:

Dacă toate cele trei Core Web Vitals sunt în verde pe date reale, ai terminat. Restul e cosmetică.

Întrebări frecvente

De ce am scor mare pe desktop și mic pe mobil?

PageSpeed simulează pe mobil un telefon de gamă medie pe conexiune 4G lentă, cu procesor încetinit intenționat. Desktop-ul primește procesor rapid și conexiune bună. Diferența de 30–40 de puncte între cele două e normală. Contează scorul mobil, pentru că acolo e majoritatea traficului real.

Cât de des ar trebui să testez viteza site-ului?

Lunar e suficient pentru un site care nu se schimbă des, plus obligatoriu după orice modificare mare: temă nouă, plugin nou, script de tracking adăugat, secțiune nouă pe prima pagină. Search Console te anunță oricum când o grupă de pagini iese din verde.

Un site lent poate fi penalizat de Google?

Nu există o penalizare în sensul clasic. Core Web Vitals sunt un factor de clasare printre sute de altele, folosit mai ales ca departajare între pagini altfel echivalente ca relevanță. Impactul direct pe poziție e mic; impactul indirect, prin oameni care închid pagina, e mare.

De ce nu îmi apar date reale în PageSpeed Insights?

Secțiunea de date de teren vine din raportul CrUX, care are nevoie de un prag minim de utilizatori Chrome pe pagina respectivă în ultimele 28 de zile. Site-urile noi sau cu trafic mic nu îl ating și văd doar datele de laborator. Nu e o eroare de configurare.

Merită să plătesc un plugin de optimizare a vitezei?

Pe WordPress, un plugin bun de cache și optimizare imagini aduce de obicei un câștig real de 15–30 de puncte, la 200–400 RON pe an. Merită ca prim pas. Nu rezolvă însă o temă construită prost sau un hosting slab — alea rămân probleme structurale.