Core Web Vitals și Lighthouse: cum măsori și prioritizezi optimizările

Un scor de 90+ în Lighthouse arată bine, dar nu înseamnă automat că site-ul oferă o experiență excelentă tuturor utilizatorilor.

În 2026, performanța unui site trebuie privită din două direcții: scorul Lighthouse, care este un test de laborator, și Core Web Vitals, care urmăresc experiența reală a utilizatorilor.

Dacă vrei un site rapid, obiectivul nu ar trebui să fie doar „să trec de 90”. Trebuie să reduci timpul până când apare conținutul principal, să faci interacțiunile rapide și să împiedici elementele paginii să sară în timpul încărcării.

În acest ghid explicăm ce înseamnă LCP, INP și CLS, de unde apar problemele și ce poți face concret pentru a ajunge la un scor Lighthouse 90+ fără să sacrifici funcționalitatea site-ului.

Lighthouse 90+ și Core Web Vitals nu sunt același lucru

Este una dintre cele mai frecvente confuzii.

Lighthouse rulează un test controlat și generează un scor de performanță pe baza mai multor metrici.

Core Web Vitals urmăresc indicatori care descriu experiența utilizatorului, iar datele reale pot proveni de la utilizatori și dispozitive diferite.

Asta înseamnă că poți avea:

• Lighthouse 95, dar utilizatori reali care au probleme cu LCP;
• Lighthouse 80, dar Core Web Vitals bune pentru majoritatea vizitatorilor;
• un scor excelent pe desktop și unul slab pe mobil;
• un homepage foarte rapid și pagini interne lente.

De aceea, 90+ în Lighthouse este un obiectiv util, dar nu trebuie tratat ca singura măsură a performanței.

Ce sunt Core Web Vitals?

Core Web Vitals sunt un set de metrici folosite pentru a evalua aspecte importante ale experienței utilizatorului.

În prezent, cele trei metrici principale sunt:

• LCP – Largest Contentful Paint;
• INP – Interaction to Next Paint;
• CLS – Cumulative Layout Shift.

Aceste praguri sunt importante deoarece un site nu este cu adevărat rapid dacă doar prima imagine apare repede, dar butoanele răspund greu sau conținutul sare în timp ce utilizatorul încearcă să apese ceva.

LCP: cât de repede apare conținutul principal?

LCP măsoară timpul necesar pentru ca cel mai mare element de conținut vizibil din zona inițială a paginii să fie afișat.

În multe cazuri, LCP poate fi:

• imaginea principală din hero;
• un titlu mare;
• un banner;
• un bloc mare de text;
• un element vizual important.

Dacă LCP este 4-5 secunde, utilizatorul poate avea impresia că site-ul este lent chiar dacă restul paginii se încarcă rapid.

Ținte pentru LCP

• Bun: sub 2,5 secunde;
• De îmbunătățit: 2,5-4 secunde;
• Slab: peste 4 secunde.

De ce este LCP atât de mare?

De multe ori problema nu este doar imaginea.

LCP poate fi afectat de:

• server lent;
• TTFB mare;
• CSS care blochează randarea;
• JavaScript executat prea devreme;
• imagini prea mari;
• fonturi care întârzie afișarea textului;
• prea multe requesturi;
• CDN configurat incorect;
• cache lipsă sau prost configurat.

Google recomandă să privești LCP ca pe un proces format din mai multe etape, nu doar ca pe o problemă de „optimizare a imaginii”.

Cum reduci LCP în practică

1. Optimizează imaginea principală

Dacă imaginea hero are 2-3 MB, nu te mira dacă pagina începe greu.

Folosește formate moderne precum:

• WebP;
• AVIF.

Nu încărca o imagine de 3000-4000 px dacă utilizatorul o vede la aproximativ 1200 px.

Ideal este să generezi dimensiuni potrivite pentru desktop, tabletă și mobil și să folosești srcset și sizes atunci când este cazul.

2. Nu folosi lazy loading pentru imaginea LCP

Una dintre greșelile frecvente este să aplici loading="lazy" tuturor imaginilor.

Imaginea principală vizibilă imediat poate deveni chiar mai lentă dacă browserul așteaptă să decidă când trebuie încărcată.

Imaginile de sub fold pot folosi lazy loading. Elementul LCP trebuie tratat separat.

3. Preload pentru resursele critice

Pentru anumite resurse critice, preload poate ajuta browserul să înceapă încărcarea mai devreme.

<link
  rel="preload"
  as="image"
  href="/images/hero.webp">

Nu trebuie însă să faci preload pentru orice imagine sau fișier. Preload-ul excesiv poate concura cu alte resurse importante.

4. Redu timpul de răspuns al serverului

Dacă serverul răspunde greu, optimizarea frontendului nu poate rezolva complet problema.

Verifică:

• hostingul;
• CPU și RAM;
• TTFB;
• cache-ul serverului;
• PHP-FPM;
• query-urile bazei de date;
• CDN-ul;
• configurația web serverului.

Un site WordPress foarte încărcat pe shared hosting poate avea probleme de performanță chiar dacă imaginile sunt perfect optimizate.

INP: de ce site-ul trebuie să răspundă rapid

INP – Interaction to Next Paint măsoară cât de repede reacționează pagina la interacțiunile utilizatorului.

Exemple de interacțiuni:

• click pe meniu;
• deschiderea unui modal;
• căutarea unui produs;
• adăugarea unui produs în coș;
• completarea unui formular;
• deschiderea unui dropdown;
• interacțiuni într-o aplicație web.

Un site poate încărca foarte repede, dar să se simtă lent dacă JavaScript-ul blochează browserul după încărcare.

Ținte pentru INP

• Bun: sub 200 ms;
• De îmbunătățit: 200-500 ms;
• Slab: peste 500 ms.

Cea mai mare problemă pentru INP: JavaScript-ul

Unul dintre principalii vinovați pentru INP slab este JavaScript-ul prea greu sau executat în momente nepotrivite.

Problemele apar frecvent din:

• framework-uri și librării încărcate inutil;
• pluginuri WordPress;
• trackere;
• widgeturi externe;
• chat-uri;
• scripturi de advertising;
• cod third-party;
• bundle-uri JavaScript foarte mari.

Folosește defer pentru scripturile care nu sunt critice

<script src="/js/app.js" defer></script>

Astfel, browserul poate continua procesarea HTML-ului fără ca scriptul să blocheze imediat parsarea documentului.

Nu aplica automat defer tuturor scripturilor fără să verifici dependențele. Unele scripturi trebuie executate într-o anumită ordine.

Elimină JavaScript-ul inutil

Nu este suficient să minifici un fișier de 1 MB și să spui că este optimizat.

Întrebarea corectă este:

Este nevoie de tot acel cod pe această pagină?

Dacă un plugin încarcă JavaScript pe toate paginile, dar este folosit doar pe contact, încărcarea globală a scriptului poate fi inutilă.

CLS: când pagina „sare” în timp ce se încarcă

CLS – Cumulative Layout Shift măsoară schimbările neașteptate de poziție ale elementelor din pagină.

Probabil ai întâlnit situația în care vrei să apeși un buton, iar exact atunci apare un banner și butonul se mută.

Aceasta este o problemă de layout shift.

Ținta pentru CLS

CLS bun: sub 0,1.

Cum reduci CLS

1. Definește dimensiunile imaginilor

Browserul trebuie să știe cât spațiu va ocupa o imagine înainte ca aceasta să fie afișată.

<img
  src="/images/banner.webp"
  width="1200"
  height="630"
  alt="Banner">

Poți folosi și CSS modern cu aspect-ratio pentru componentele care trebuie să păstreze o proporție stabilă.

2. Rezervă spațiu pentru reclame și embeduri

Dacă un banner publicitar apare după încărcarea paginii și nu are un spațiu rezervat, conținutul de sub el poate fi împins în jos.

Același lucru se poate întâmpla cu:

• iframe-uri;
• video-uri;
• widgeturi externe;
• formulare încărcate dinamic;
• cookie banners;
• elemente injectate prin JavaScript.

3. Optimizează fonturile

Fonturile pot contribui la schimbări vizuale dacă textul este randat inițial cu un font și apoi schimbat cu altul.

Folosește o strategie clară pentru încărcarea fonturilor și evită să încarci zeci de variante de font pe aceeași pagină.

Serverul contează mai mult decât cred mulți

Poți avea un frontend foarte bine optimizat, dar dacă serverul are un timp mare de răspuns, utilizatorul va aștepta oricum.

Înainte să modifici zeci de fișiere CSS și JavaScript, verifică infrastructura.

Ce merită verificat pe server

• TTFB;
• cache-ul HTTP;
• OPcache;
• PHP-FPM;
• versiunea PHP;
• MySQL/MariaDB;
• CPU;
• RAM;
• disk I/O;
• serverul web;
• CDN;
• compresia Brotli/Gzip.

Un VPS bine configurat poate oferi rezultate mult mai stabile decât un shared hosting suprasolicitat, dar un VPS prost configurat poate fi mai lent decât un hosting bun.

Cache-ul este una dintre cele mai importante optimizări

Un sistem bun de cache poate reduce foarte mult timpul necesar pentru generarea paginii.

În funcție de site, poți avea:

• browser cache;
• page cache;
• object cache;
• OPcache;
• CDN cache;
• cache pentru query-uri sau date.

Pentru WordPress, cache-ul paginii poate avea un impact foarte mare deoarece reduce necesitatea executării PHP și a query-urilor MySQL la fiecare vizită.

Pentru Laravel, poți optimiza separat configurația, rutele, view-urile și cache-ul aplicației.

CDN: când merită folosit?

Un CDN poate ajuta prin livrarea resurselor de la infrastructură mai apropiată de utilizator.

Este util în special pentru:

• imagini;
• CSS;
• JavaScript;
• fonturi;
• fișiere statice;
• site-uri cu utilizatori din mai multe regiuni.

Dar CDN-ul nu repară automat un backend lent.

Dacă HTML-ul inițial este generat foarte greu, trebuie optimizat și serverul de origine.

Imaginile: cea mai simplă zonă de optimizat

Imaginile sunt deseori printre cele mai mari fișiere descărcate de browser.

Un site modern ar trebui să folosească:

• dimensiuni corecte;
• WebP sau AVIF unde este potrivit;
• compresie;
• srcset;
• sizes;
• lazy loading pentru imaginile care nu sunt critice.

Nu transforma însă toate imaginile în AVIF doar pentru că este un format modern. Verifică suportul, calitatea și impactul real asupra paginii.

CSS: mai puțin înseamnă de multe ori mai bine

Un site poate încărca sute de kilobytes de CSS pentru a afișa doar câteva componente.

Verifică:

• CSS neutilizat;
• framework-uri încărcate integral;
• librării duplicate;
• fișiere CSS multiple;
• stiluri încărcate doar pentru anumite pagini.

Pentru proiectele construite cu Tailwind CSS, este important ca build-ul de producție să elimine clasele care nu sunt utilizate.

Pentru proiectele clasice, eliminarea CSS-ului nefolosit poate reduce semnificativ dimensiunea resurselor.

Fonturile pot afecta performanța

Un site care încarcă cinci familii de fonturi, fiecare cu mai multe greutăți, poate genera multe requesturi și fișiere inutile.

În multe proiecte sunt suficiente:

• un font principal;
• două sau trei greutăți;
• subseturi potrivite.

De asemenea, verifică dacă fonturile externe sunt într-adevăr necesare sau dacă pot fi servite mai eficient.

Third-party scripts: problema pe care Lighthouse o poate scoate la suprafață

Uneori site-ul tău este rapid, dar scripturile externe îl încetinesc.

Exemple:

• Google Analytics;
• Google Tag Manager;
• Google Ads;
• chat-uri;
• heatmap-uri;
• social widgets;
• reclame;
• video embeduri;
• tool-uri de tracking.

Nu trebuie să elimini toate aceste servicii.

Trebuie să verifici însă dacă fiecare script este necesar și dacă poate fi încărcat după conținutul critic sau doar pe paginile unde este folosit.

Preload, preconnect și dns-prefetch: folosește-le cu măsură

Aceste mecanisme pot ajuta browserul să pregătească anumite resurse, dar utilizarea lor excesivă poate avea efectul opus.

De exemplu, dacă ai nevoie de o conexiune către o origine externă critică, poți folosi:

<link rel="preconnect" href="https://example.com">

Dar nu are sens să adaugi preconnect pentru zeci de domenii care nu sunt folosite imediat.

Regula simplă este: prioritizează resursele care contribuie direct la randarea conținutului critic.

WordPress: cum ajungi la Lighthouse 90+

Pe WordPress, problemele de performanță provin frecvent din combinația dintre temă, pluginuri, imagini, scripturi externe și hosting.

Începe cu:

1. alege un hosting suficient de rapid;
2. activează page cache;
3. verifică OPcache;
4. optimizează imaginile;
5. elimină pluginurile inutile;
6. nu încărca pluginuri pe paginile unde nu sunt necesare;
7. redu JavaScript-ul third-party;
8. optimizează CSS-ul;
9. verifică fonturile;
10. folosește CDN unde are sens;
11. verifică baza de date;
12. testează separat mobil și desktop.

Nu instala cinci pluginuri de optimizare și presupune că rezultatul va fi automat mai bun. Unele funcții se pot suprapune și pot produce conflicte.

WooCommerce: performanța este și mai importantă

Magazinele online au mai multe elemente dinamice decât un site de prezentare.

Trebuie să fii atent la:

• filtre de produse;
• căutare;
• coș;
• checkout;
• plăți;
• tracking;
• stocuri;
• pluginuri externe;
• query-uri MySQL.

Nu toate paginile WooCommerce pot fi cache-uite în același mod.

Pagini precum coșul și checkout-ul au nevoie de o strategie diferită față de paginile statice de categorie sau de conținut.

Laravel: cum optimizezi un proiect custom

Laravel oferă mult mai mult control asupra performanței deoarece poți optimiza direct aplicația și infrastructura.

Verifică:

• query-urile SQL;
• indexurile bazei de date;
• N+1 queries;
• cache-ul;
• queue-urile;
• Redis;
• PHP-FPM;
• OPcache;
• config cache;
• route cache;
• view cache;
• asset build-ul.

De exemplu, o pagină care execută zeci sau sute de query-uri SQL poate rămâne lentă indiferent cât de bine sunt optimizate imaginile.

Nu încărca date inutile

Dacă o pagină are nevoie de 20 de produse, nu este eficient să încarci 2.000 din baza de date și să le filtrezi ulterior în PHP.

Optimizarea trebuie făcută cât mai aproape de sursa datelor.

Mobile este testul care contează cel mai mult

Un site poate avea un scor excelent pe desktop și un rezultat mult mai slab pe mobil.

Motivul este simplu: dispozitivele mobile pot avea:

• CPU mai lent;
• conexiuni mai lente;
• mai puțină memorie;
• latență mai mare;
• mai puține resurse disponibile pentru JavaScript.

De aceea, după fiecare optimizare trebuie să verifici rezultatul pe mobil și desktop separat.

Nu încerca să păcălești Lighthouse

Scopul optimizării nu este să obții un număr verde într-un screenshot.

Poți obține temporar un scor mai bun prin eliminarea unor componente, amânarea agresivă a scripturilor sau dezactivarea unor funcții importante.

Dar dacă utilizatorul nu mai poate folosi corect site-ul, nu ai făcut o optimizare reală.

Performanța trebuie îmbunătățită fără să distrugi experiența și funcționalitatea.

Ordinea corectă de optimizare

Dacă vrei rezultate reale, nu începe prin a modifica aleatoriu fișierele.

Urmează o ordine logică:

1. măsoară situația actuală;
2. identifică cel mai mare bottleneck;
3. optimizează serverul;
4. optimizează LCP;
5. optimizează JavaScript și INP;
6. elimină layout shift și îmbunătățește CLS;
7. optimizează imaginile;
8. optimizează CSS;
9. verifică fonturile;
10. verifică third-party scripts;
11. configurează cache și CDN;
12. testează din nou.

Nu încerca să repari zece lucruri simultan. Dacă schimbi totul deodată, devine dificil să afli ce a avut efectul real.

Ce să verifici în Lighthouse

Când rulezi un test, nu te uita doar la numărul mare de la Performance.

Uitǎ-te la:

• Largest Contentful Paint;
• Interaction to Next Paint;
• Cumulative Layout Shift;
• First Contentful Paint;
• Speed Index;
• Total Blocking Time;
• Time to First Byte;
• opportunities;
• diagnostics;
• network requests;
• dimensiunea resurselor.

Oportunitățile din Lighthouse sunt utile pentru a găsi probleme, dar trebuie interpretate în contextul site-ului.

Un exemplu de strategie pentru un site care are Lighthouse 62

Să presupunem că ai:

• Lighthouse Mobile: 62;
• LCP: 4,2 secunde;
• INP: 280 ms;
• CLS: 0,22;
• imagine hero de 2,4 MB;
• 700 KB JavaScript;
• hosting cu TTFB ridicat.

Nu începe prin a schimba fontul.

O strategie logică ar fi:

1. optimizează imaginea hero;
2. verifică serverul și TTFB;
3. îmbunătățește încărcarea resurselor critice;
4. redu JavaScript-ul;
5. amână scripturile non-critice;
6. rezervă spațiu pentru imagini și widgeturi;
7. verifică cache-ul;
8. rulează din nou Lighthouse;
9. verifică dacă îmbunătățirile se reflectă și în datele reale.

Această abordare este mult mai eficientă decât să instalezi un plugin de optimizare și să activezi toate opțiunile disponibile.

Checklist pentru Lighthouse 90+

• ☐ Hosting suficient de rapid
• ☐ TTFB optimizat
• ☐ HTTPS configurat corect
• ☐ Cache activ
• ☐ CDN configurat unde este necesar
• ☐ Imagini WebP/AVIF optimizate
• ☐ Imaginile au dimensiuni corecte
• ☐ Imaginea LCP nu este lazy-loaded inutil
• ☐ CSS critic optimizat
• ☐ CSS neutilizat eliminat
• ☐ JavaScript redus
• ☐ Scripturile non-critice sunt amânate
• ☐ Third-party scripts verificate
• ☐ Fonturile sunt optimizate
• ☐ Dimensiunile imaginilor și iframe-urilor sunt definite
• ☐ Layout shift redus
• ☐ Query-urile bazei de date optimizate
• ☐ PHP și OPcache configurate corect
• ☐ Site-ul este testat pe mobil
• ☐ Site-ul este testat pe desktop
• ☐ Core Web Vitals sunt monitorizate în timp

Concluzie: 90+ nu trebuie să fie obiectivul final

Un scor Lighthouse 90+ este un obiectiv foarte bun pentru optimizarea unui site, dar nu este o garanție că fiecare utilizator va avea o experiență perfectă.

Un site performant trebuie să fie rapid la prima încărcare, să răspundă rapid la interacțiuni și să păstreze layout-ul stabil.

De aceea, urmărește împreună:

• Lighthouse pentru testarea de laborator;
• Core Web Vitals pentru experiența utilizatorului;
• PageSpeed Insights pentru analiza combinată;
• Chrome User Experience Report atunci când există suficiente date;
• monitorizarea proprie pentru a vedea cum se comportă site-ul în timp.

În cazul aplicațiilor SPA, merită ținut cont și de evoluțiile recente ale măsurării Core Web Vitals: Chrome 151 a introdus API-uri noi pentru măsurarea metricilor în timpul navigărilor de tip SPA, iar integrarea acestora în instrumentele de măsurare este încă în evoluție.

Și cel mai important: nu optimiza doar pentru un scor. Optimizează pentru utilizator.

Un Lighthouse 90+ este foarte bun. Un site care se simte rapid, răspunde instantaneu și nu „sare” în timpul încărcării este și mai bun.

Întrebări frecvente

Ce scor Lighthouse este considerat bun?

Un scor de 90 sau mai mare este considerat foarte bun pentru categoria Performance. Totuși, scorul Lighthouse este un test de laborator și trebuie analizat împreună cu datele reale Core Web Vitals.

De ce am Lighthouse 95, dar Core Web Vitals sunt slabe?

Lighthouse testează pagina într-un mediu controlat, în timp ce datele reale pot proveni de la utilizatori cu dispozitive, conexiuni și condiții diferite. Un scor bun de laborator nu garantează automat rezultate bune pentru toți utilizatorii.

Care este cel mai important Core Web Vital?

Nu există o singură metrică suficientă. LCP măsoară încărcarea conținutului principal, INP răspunsul la interacțiuni, iar CLS stabilitatea vizuală. Toate trei contează.

Cât trebuie să fie LCP?

Pentru o experiență considerată bună, LCP ar trebui să fie de cel mult 2,5 secunde la percentila 75.

Cât trebuie să fie INP?

Un INP de până la 200 ms este considerat bun. Peste acest nivel, interacțiunile pot începe să se simtă mai puțin responsive.

Cât trebuie să fie CLS?

Pentru un rezultat bun, CLS trebuie să fie sub 0,1.

Un CDN îmi garantează Lighthouse 90+?

Nu. Un CDN poate ajuta la livrarea resurselor și la reducerea latenței, dar nu repară automat JavaScript-ul greu, query-urile lente, imaginile supradimensionate sau un backend prost optimizat.

WordPress poate ajunge la Lighthouse 90+?

Da. WordPress poate avea rezultate foarte bune dacă tema, pluginurile, imaginile, cache-ul, hostingul și scripturile externe sunt configurate corect.

Laravel este mai rapid decât WordPress?

Nu există o regulă universală. Laravel oferă mai mult control asupra arhitecturii și poate fi foarte performant, dar performanța depinde de implementare, baza de date, server și frontend. Un WordPress bine optimizat poate fi mai rapid decât o aplicație Laravel prost optimizată.

Trebuie să optimizez mai întâi desktop sau mobile?

Ideal este să le verifici pe ambele. Mobile este deosebit de important deoarece dispozitivele și conexiunile mai lente pot scoate la iveală probleme care nu apar pe desktop.

Continuă cu un pas practic

• Laravel pentru începători: de la zero la primul proiect live
• Cum muți un site pe alt hosting fără downtime: ghid complet

Pentru lucru ghidat:

SEO practic pentru site-uri — lecții de probă și fișă de proiect.