PageSpeed Insights - cum interpretez și optimizez (Core Web Vitals)

PageSpeed Insights este unealta de la Google care îți arată cât de rapid și de stabil este site-ul tău din perspectiva Core Web Vitals. Aici este partea importantă: 70% dintre antreprenorii care îmi cer ajutor cu „site lent" se uită la scorul mare colorat din raport și ratează exact zona care contează pentru ranking - blocul Field Data. Acest articol îți arată cum să interpretezi corect raportul și ce să optimizezi în ordine de impact real.

În cei 7 ani de DevOps consulting am văzut același tipar repetat: dev junior optimizează un site până la scor Lighthouse 98/100, raportează triumfător, dar Search Console arată în continuare „URL-uri care nu trec Core Web Vitals" pentru jumătate din pagini. Motivul: scorul Lighthouse este date de laborator (sintetice), iar Google folosește date de teren (CrUX). Sunt două lucruri diferite și confuzia asta costă luni de muncă inutilă.

Dacă nu ai citit încă, recomand și Cloudflare gratuit pentru site mic - setup în 15 minute și Top 3 CDN gratuite pentru WordPress - 80% din problemele LCP se rezolvă cu CDN bun.

Ce sunt Core Web Vitals în 2026

Core Web Vitals (CWV) sunt 3 metrici tehnice prin care Google evaluează experiența utilizatorului pe site-ul tău. Din martie 2024, set-ul oficial este:

INP a înlocuit FID (First Input Delay) din 12 martie 2024 ca metrică oficială de responsiveness. Diferența practică: FID măsura doar întârzierea primei interacțiuni, INP măsoară responsivitatea pe toată durata sesiunii (cel mai lent răspuns observat). INP este mult mai dur cu site-urile JavaScript-heavy.

Pe scurt: pentru ca o pagină să fie marcată „passed Core Web Vitals" la nivel agregat în Search Console, 75% dintre vizualizările reale (la percentila 75) trebuie să fie sub pragul „Good" pentru toate cele 3 metrici - simultan, pe mobile și desktop separat.

Lab Data vs Field Data - distincția care contează

Aici este partea importantă pentru care mulți dezvoltatori pierd timp inutil:

Lab Data (Lighthouse, sintetic)

Date obținute prin rularea unui test simulat:

• Hardware emulat (Moto G Power pe Mobile, desktop standard)
• Rețea throttled (Slow 4G: 1,6 Mbps download, 150 ms RTT)
• O singură rulare, în condiții controlate
• Reproducibil, ideal pentru debugging
• Produce scorul 0-100 (Performance, Accessibility, Best Practices, SEO)

Field Data (CrUX, real)

Date agregate de la utilizatori reali Chrome care au activat sincronizarea istoricului:

• Rețele reale (4G românesc lent, WiFi de cafenea, fiber)
• Device-uri reale (de la iPhone 15 Pro la Android entry-level vechi)
• Agregate pe 28 de zile, raportate la percentila 75
• Nereproducibil la moment dat - vezi tendințe
• Vine din Chrome User Experience Report (CrUX)

⚠️ Atenție critică: doar Field Data este folosit de Google ca semnal de ranking. Scorul Lighthouse 0-100 este simulat și nu este factor de ranking direct. Optimizarea pentru scor 100 fără a verifica Field Data este yak shaving.

Trade-off: dacă site-ul tău nu are trafic suficient (sub câteva sute de vizitatori unici Chrome/lună), nu apare în CrUX deloc - Field Data va fi gol și Google va folosi origin-level data (agregat pe tot domeniul) sau, în lipsă, nimic. Pentru site-urile mici, monitorizarea reală vine de la Real User Monitoring (RUM) propriu sau Search Console.

Mobile vs Desktop - focusează pe Mobile

Din 2019, Google folosește Mobile-First Indexing - versiunea mobilă a site-ului este principala folosită pentru ranking. PageSpeed Insights afișează implicit Mobile, dar trebuie să verifici amândouă, separat.

Pro tip dev: 90% dintre problemele de performance apar pe Mobile pentru că:

• CPU mai slab (emulează Moto G Power, ~30% din puterea unui desktop)
• Rețea mai slabă (Slow 4G default)
• Viewport mai mic = layout shifts mai vizibile
• Less RAM = JavaScript heap mai presat

Setup minim: dacă scorul Desktop e 95 și Mobile e 60, ai 3 ore de muncă pe Mobile, nu pe Desktop.

Cum interpretez raportul PageSpeed Insights pas cu pas

Deschide PageSpeed Insights (pagespeed.web.dev) și introdu URL-ul paginii (nu doar domeniul - testează paginile cele mai vizitate: homepage, top article, top categorie, checkout).

Pas 1 - Citește blocul Field Data (Discover what your real users are experiencing)

Acesta este primul bloc afișat și singurul cu valoare pentru SEO. Conține:

• LCP, INP, CLS, FCP (First Contentful Paint), TTFB (Time to First Byte) la percentila 75
• Etichetă „Passed Core Web Vitals" verde / „Failed" roșie
• Distribuție vizuală (cât % din vizite cad în Good, Needs Improvement, Poor)

Dacă blocul afișează „The Chrome User Experience Report does not have sufficient real-world speed data for this page", site-ul tău nu are destul trafic Chrome - sari direct la Lab Data, dar nu te baza orbește pe el.

Pas 2 - Citește blocul Lab Data (Diagnose performance issues)

Lab Data afișează:

• Scorul Performance (0-100) cu cele 6 metrici Lighthouse
• Filmstrip al încărcării pe etape (Screenshot timeline)
• Metrici detaliate: FCP, LCP, TBT (Total Blocking Time), Speed Index, CLS

Folosește Lab Data pentru debugging și reproducere, nu pentru raportare către management.

Pas 3 - Secțiunea „Opportunities"

Listă de oportunități rankuite după impact estimat în secunde (Estimated Savings). Exemplu real:

Opportunities
- Properly size images        Est. savings of 2,4 s
- Eliminate render-blocking   Est. savings of 1,2 s
- Defer offscreen images      Est. savings of 0,8 s
- Minify CSS                  Est. savings of 0,1 s

Începe întotdeauna cu primele 2-3 (impact mare). Nu pierde timp cu „minify CSS - savings 0,1s" până nu ai rezolvat imaginile.

Pas 4 - Secțiunea „Diagnostics"

Probleme secundare care nu salvează timp direct dar afectează maintainability:

• Avoid an excessive DOM size (peste 1 500 noduri)
• Reduce JavaScript execution time
• Minimize main-thread work
• Largest Contentful Paint element (identifică EXACT ce element e LCP-ul tău - critic)

Pas 5 - Secțiunea „Passed Audits"

Ce-i deja OK. Util pentru încredere și pentru a nu strica ce funcționează când faci modificări.

💡 Pro tip dev: dacă în Field Data toate 3 metrici sunt verzi dar scorul Lighthouse e 65, nu mai optimiza nimic. Site-ul tău este OK pentru Google. Ce-ți arată Lighthouse sunt probleme teoretice, nu reale.

Top 10 fixuri în ordine de impact

Lista de mai jos este ordonată pe baza a peste 100 de audit-uri reale pe site-uri WordPress și custom românești. Top 3 rezolvă 80% din probleme.

1. Reduce LCP image (impact MARE)

Elementul LCP este de obicei imaginea hero / featured image. Optimizările:

• Convertește în WebP sau AVIF (50-70% mai mic decât JPEG)
• Dimensiuni reale (nu servi 4000x3000 px pentru un container 800x600)
• Preload pentru LCP image: <link rel="preload" as="image" href="hero.webp">
• NU lazy-load pe LCP image (loading="eager" sau fără atribut)
• Toate celelalte imagini below the fold: loading="lazy"

<!-- LCP image - preload + eager -->
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
<img src="/img/hero.webp" width="1200" height="630" alt="..." loading="eager">

<!-- Below the fold images - lazy -->
<img src="/img/section-2.webp" width="800" height="450" alt="..." loading="lazy">

2. Eliminate render-blocking CSS (impact MARE)

CSS-ul blochează rendering-ul până e descărcat și parsat. Soluții:

• Critical CSS inline în <head> (CSS-ul pentru above-the-fold, ~14 KB)
• Restul CSS-ului încărcat asincron cu media="print" onload

<!-- Critical CSS inline -->
<style>
  /* Above-the-fold CSS aici, max 14 KB */
  body{margin:0;font-family:system-ui}
  .hero{background:#0f1e3d;color:#fff;padding:2rem}
</style>

<!-- Non-critical CSS asincron -->
<link rel="preload" href="/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/style.css"></noscript>

3. Defer offscreen images (impact MEDIU)

loading="lazy" pe toate imaginile sub fold. Suportat nativ în browsere moderne (Chrome 76+, Firefox 75+, Safari 15.4+):

<img src="/img/below-fold.webp" loading="lazy" width="800" height="450" alt="...">

4. Minify CSS/JS (impact MIC)

Elimină whitespace, comentarii, scurtează nume variabile. Tools: Terser pentru JS, cssnano pentru CSS. WordPress: WP Rocket, Autoptimize sau LiteSpeed Cache fac asta automat.

5. Preconnect to required origins (impact MEDIU)

Stabilește conexiunea TCP+TLS pentru domenii externe (Google Fonts, CDN, analytics) înainte să fie nevoie:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">

Trade-off: NU preconnect la mai mult de 4-6 origins, devine contra-productiv (consumă resurse).

6. Server response time TTFB (impact MARE pe site lent)

TTFB sub 200 ms este obiectivul. Dacă raportul arată TTFB peste 800 ms, problema e la hosting/backend, nu la frontend. Soluții:

• CDN edge (Cloudflare Free face minuni pentru site-uri statice/cached)
• Page caching (WP Rocket, LiteSpeed Cache, W3 Total Cache)
• Object cache Redis pentru WooCommerce/WordPress cu multe query-uri
• PHP 8.2+ cu OPcache (vs PHP 7.4 = 30-50% mai rapid)
• Hosting mai bun - shared overcrowded = TTFB 1-3 s; NVMe + LiteSpeed = 100-300 ms

Dacă ești pe shared overcrowded, vezi cum alegi hosting WooCommerce optimizat România - schimbarea de provider este uneori singura soluție.

7. Reduce unused JavaScript (impact MEDIU-MARE)

JavaScript nefolosit pe pagina respectivă (scripturi încărcate global pe tot site-ul). Soluții:

• Code splitting (route-based pentru SPA)
• Lazy load scripturi non-critical (analytics, chat widget)
• Dezactivează plugin-uri WordPress care încarcă JS pe toate paginile dar sunt folosite doar pe 1-2 (ex: Contact Form 7 pe homepage)

Plugin recomandat WordPress: Asset CleanUp Pro (dezactivează selectiv CSS/JS per pagină).

8. Image dimensions explicit (impact pe CLS)

Toate <img> și <video> trebuie să aibă width și height atribute (chiar dacă CSS le override). Browser rezervă spațiul, evită layout shift:

<!-- CORECT -->
<img src="/img/photo.webp" width="800" height="450" alt="...">

<!-- INCORECT - cauzează CLS -->
<img src="/img/photo.webp" alt="...">

9. Avoid large layout shifts (impact pe CLS)

Webfonts sunt cauza nr. 1 de CLS pentru site-uri WordPress. Soluție:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 105%;
  ascent-override: 90%;
  descent-override: 22%;
}

font-display: swap afișează fallback-ul imediat. size-adjust și *-override ajustează metric-urile font-ului fallback să se potrivească cu webfont-ul = zero shift când se încarcă.

Alternativă rapidă: folosește system-ui fonts (Helvetica, Arial, sistem) și uită de webfonts. 95% dintre utilizatori nu observă.

10. Reduce DOM size (impact pe INP și LCP)

DOM cu peste 1 500 noduri = parser browser muncește mult. Cauze tipice WordPress:

• Page builders (Elementor, Divi) cu wrapping divs excesiv
• Comentarii cu nested replies
• Tabele uriașe sau galerie cu 100+ imagini

Setup minim pentru remediere:

• Page Builder Pro Tip: folosește block-uri Gutenberg native când e posibil
• Paginare comentarii (Settings → Discussion → „Break comments into pages")
• Lazy loading pentru galerii (Justified Image Grid, FooGallery cu lazy)

Tabel comparativ - metrică × prag × prioritate fix × unealtă

Specific WordPress - stack-ul minim viabil

Pentru un site WordPress „mediu" (10-100 articole, 5-20 plugin-uri, tematică SaaS / blog / ecommerce mic), setup-ul care rezolvă 70-90% din Core Web Vitals în 2 ore de configurare:

Caching plugin

• WP Rocket (49 USD/an) - cel mai prieten user, configurare 5 min, Vizitează WP Rocket
• LiteSpeed Cache (gratuit, dar necesită server LiteSpeed/OpenLiteSpeed)
• W3 Total Cache (gratuit, dar configurare complexă, învechit UI)

Recomandare practică: dacă hosting-ul are LiteSpeed (Hostico, cyberfolks, THC), folosește LSCache gratuit. Altfel, WP Rocket este investiția de 49 USD/an care se recuperează în 1 zi de muncă economisită.

Image optimization

• ShortPixel (de la 4,99 USD/lună pentru 7 000 imagini) - WebP/AVIF auto, Vizitează ShortPixel
• Smush (free tier limitat la 5 MB/imagine, Pro 7,5 USD/lună)
• Imagify (free 20 MB/lună, plătit de la 5,99 USD/lună)

Setup minim: activează WebP delivery + lazy load + compression Lossy 80%. Rezultat: imagini cu 60-70% mai mici, LCP cu 1-2 secunde mai rapid.

Critical CSS

• WP Rocket îl generează automat (Remove Unused CSS feature)
• Autoptimize + Critical CSS plugin (gratuit, dar manual setup)
• Servicii externe: CriticalCSS.com, Pegasaas

CDN

• Cloudflare Free (suficient pentru 95% site-uri RO) - vezi Cloudflare gratuit setup în 15 minute
• BunnyCDN (0,01 USD/GB) pentru trafic peste 50 GB/lună
• KeyCDN, Bunny pentru ecommerce cu trafic mare

Stack-ul meu recomandat pentru WordPress blog/SaaS

It depends - context matters: dacă rulezi WooCommerce cu peste 500 produse, adaugă Redis Object Cache (gratuit) și un VPS managed de la 25 EUR/lună - shared hosting nu mai face față.

Unelte complementare pentru audit performance

PageSpeed Insights nu este singura unealtă, dar este punctul de start. Pentru analiză profundă:

• webpagetest.org - cea mai detaliată unealtă, filmstrip, waterfall, conexiuni multiple location
• GTmetrix - UI mai prietenos decât WPT, conține Lighthouse + waterfall
• Chrome DevTools Lighthouse - rulează local, util pentru testare pre-deploy
• search.google.com/search-console - secțiunea Core Web Vitals arată Field Data agregat pe tot site-ul + paginile problematice exacte
• Chrome DevTools Performance Insights - debugging granular, INP per interacțiune
• web.dev/measure - varianta web a Lighthouse, agregat cu recomandări

RTFM: documentația oficială web.dev este excelentă pentru aprofundare - „web.dev/articles/vitals" și „web.dev/articles/optimize-lcp" sunt obligatorii dacă faci performance audit pentru clienți.

Întrebări frecvente

Ce este INP și de ce a înlocuit FID?

INP (Interaction to Next Paint) măsoară responsivitatea pe toată sesiunea, nu doar prima interacțiune cum făcea FID. FID era „prea bun" - majoritatea site-urilor treceau pragul ușor pentru că măsura doar prima interacțiune (de obicei fast). INP a fost introdus în 2022, anunțat ca metrică oficială în mai 2023, și a înlocuit FID din 12 martie 2024. Pragul „Good" este sub 200 ms, ceea ce este mult mai dur pentru site-urile JavaScript-heavy.

Am nevoie de scor 100 la PageSpeed pentru ranking bun?

NU. Scorul Lighthouse 0-100 nu este factor de ranking direct - este date simulate. Google folosește Field Data din CrUX. Dacă Field Data arată „Passed Core Web Vitals" (verde pe LCP, INP, CLS la percentila 75), site-ul tău este OK pentru Google chiar dacă scorul Lighthouse e 70. Invers, scor 100 Lighthouse + Field Data roșu = problemă reală nerezolvată.

De ce scorul meu pe Mobile e mult mai mic decât pe Desktop?

Mobile folosește emulare hardware mai slab (Moto G Power, CPU 4x slowdown) și rețea throttled (Slow 4G). Desktop folosește hardware standard fără throttling. Diferența de 20-40 puncte este normală. Focus pe Mobile - Google folosește Mobile-First Indexing din 2019, deci scorul Mobile contează pentru ranking.

Cum diferă CrUX field data de Lighthouse lab data?

CrUX = date reale de la utilizatori Chrome care au activat sincronizarea, agregate pe 28 de zile la percentila 75. Lab = un singur test sintetic în condiții simulate (Moto G Power + Slow 4G). CrUX este factor de ranking, Lab nu. CrUX este indisponibil pentru site-uri cu trafic mic, Lab e disponibil oricând. Lab este reproducibil pentru debugging, CrUX nu.

Site-ul meu nu apare în Field Data - ce fac?

Înseamnă că nu ai suficient trafic Chrome (vizitatori unici cu sincronizare activată) pentru ca CrUX să raporteze. Soluții: 1) Implementează Real User Monitoring propriu (Cloudflare Web Analytics, SpeedCurve, Vercel Analytics gratuit), 2) Folosește Lab Data ca aproximare, 3) Verifică în Search Console - uneori apare la origin-level deși nu apare per URL.

Cum testez INP fără să aștept date CrUX?

În Chrome DevTools, deschide tab Performance Insights, înregistrează o sesiune normală (click-uri, scroll, form submits), apoi caută interacțiunile cu cel mai lung „Next Paint" timing. Sub 200 ms = bine, peste 500 ms = problemă. Alternativ, pe Chrome 121+ se poate folosi extension „Core Web Vitals" pentru measure live INP.

Ce TTFB este realist pentru hosting partajat?

Pe shared bun cu cache activ: 100-300 ms. Pe shared overcrowded fără cache: 800 ms - 3 s. Pe VPS managed cu NVMe + Redis: 50-150 ms. Dacă vezi TTFB peste 1 secundă consistent, problema nu este la frontend optimizations - este la hosting sau cache. Ordinea corectă: cache plugin → CDN → schimbare hosting (în această ordine de cost).

Imaginile mele sunt deja WebP dar LCP e tot lent - de ce?

Cauze tipice: 1) Imaginea LCP NU este preîncărcată (lipsă <link rel="preload">), 2) Imaginea are lazy loading aplicat din greșeală (loading="lazy" pe LCP), 3) TTFB-ul serverului este lent (problema reală e backend, nu imaginea), 4) Imaginea WebP e tot prea mare ca dimensiuni (3000x2000 px pentru un container 800x450). Verifică în secțiunea „Largest Contentful Paint element" din Lighthouse - îți arată exact ce element e LCP-ul și de ce e lent.

Concluzie

PageSpeed Insights este unealta de start pentru orice audit de performance, dar trebuie folosită corect: Field Data pentru deciziile de business (ranking, real UX), Lab Data pentru debugging și reproducere. Concentrează-te pe Core Web Vitals 2026 (LCP, INP, CLS), pe Mobile, și în ordinea de impact: LCP image > render-blocking CSS > TTFB. Pentru WordPress, stack-ul LSCache/WP Rocket + ShortPixel + Cloudflare Free rezolvă 70-90% din probleme în 2 ore de configurare.

Trade-off final: nu vânezi scor 100 Lighthouse - vânezi Field Data verde pe toate 3 metricile la percentila 75. Asta este ce vede Google și ce simt utilizatorii reali. Restul este vanity metric.

Setup minim recomandat: testează săptămânal cu PageSpeed Insights paginile top 5 pe trafic, urmărește Search Console Core Web Vitals lunar, și ține un baseline (screenshot raport inițial) ca să vezi progresul după fiecare optimizare. Battle-tested: site-urile pe care le-am optimizat trec de la „Failed CWV" la „Passed" în 2-4 săptămâni cu acest workflow.

Surse

• https://web.dev/articles/vitals
• https://web.dev/articles/inp
• https://developers.google.com/search/blog/2023/05/introducing-inp
• https://developer.chrome.com/docs/crux/methodology
• https://pagespeed.web.dev/
• https://web.dev/articles/optimize-lcp
• https://web.dev/articles/cls