Cum îmbunătățiți viteza site-ului: Core Web Vitals pe înțeles

Ca să îmbunătățiți viteza site-ului, măsurați mai întâi cu PageSpeed Insights unde sunt problemele și apoi atacați cele mai mari frâne: imagini prea mari, lipsa cache-ului, fonturi și scripturi care blochează și un răspuns lent al serverului. Google evaluează experiența utilizatorului cu trei indicatori, Core Web Vitals. Acest articol explică ce înseamnă, cum îi măsurați corect și ce măsuri aduc cel mai mult, cu indicații speciale pentru WordPress.

Cei trei indicatori Core Web Vitals și pragurile lor

Pragurile provin de la Google (web.dev, situația din octombrie 2026). O pagină le respectă când cel puțin 75 % dintre afișări sunt în zona verde, separat pentru mobil și desktop. În martie 2024, INP a înlocuit indicatorul anterior FID (First Input Delay).

Merită să urmăriți și Time to First Byte (TTFB), adică timpul până la primul răspuns al serverului. Google consideră bună o valoare de 0,8 secunde sau mai puțin. TTFB nu este un indicator Core Web Vitals, dar influențează direct LCP: ce livrează serverul târziu, browserul nu poate afișa devreme.

Măsurarea corectă: date de laborator și date de teren

• PageSpeed Insights (pagespeed.web.dev) afișează sus datele de teren de la utilizatori reali ai Chrome din ultimele 28 de zile, dacă sunt suficiente, iar dedesubt un test de laborator cu Lighthouse și recomandări concrete.
• Raportul „Core Web Vitals” din Google Search Console grupează datele de teren pe categorii de pagini similare și arată ce URL-uri au rezultate slabe. După o corectură puteți porni acolo o validare.
• Chrome DevTools, cu Lighthouse și fila Performance, sunt utile pentru teste în timp ce lucrați la site.

Pentru evaluarea Google contează datele de teren, nu scorul din testul de laborator. Site-urile mai mici au adesea prea puține vizite pentru date de teren; atunci testul de laborator este cel mai bun reper. Testați întotdeauna și varianta pentru mobil, care de obicei este mai lentă decât cea pentru desktop.

Sfat: Măsurați mai multe pagini tipice, nu doar pagina principală: de exemplu o pagină de produs sau de serviciu, un articol de blog și formularul de contact. Apoi schimbați un singur lucru odată și măsurați din nou.

Imaginile: cea mai frecventă cauză a unui LCP slab

Pe multe pagini, elementul LCP este o imagine mare, de exemplu o imagine de antet sau un slider. Aici aceste măsuri au cel mai mare efect:

• Livrați imaginile la dimensiunea afișată efectiv și oferiți cu srcset dimensiuni diferite pentru telefon și desktop.
• Folosiți formate moderne: WebP sau AVIF sunt de obicei mult mai mici decât JPEG sau PNG la o calitate comparabilă.
• Nu amânați încărcarea imaginii principale din zona vizibilă (fără lazy loading) și dați-i prioritate cu fetchpriority="high"; imaginile de mai jos, în schimb, cu lazy loading.
• Indicați lățimea și înălțimea fiecărei imagini, ca browserul să rezerve spațiul. Așa evitați deplasările și îmbunătățiți CLS.
• Renunțați la slidere în antet dacă o singură imagine este suficientă.

Cache și răspunsul serverului

Orice pagină pe care serverul nu trebuie să o construiască mai întâi ajunge mai repede la vizitatori. Trei niveluri sunt importante:

• Cache de pagini: salvează paginile HTML gata generate. Pe serverele LiteSpeed se ocupă de asta LSCache, direct în serverul web.
• Cache-ul browserului: cu antete de cache potrivite, browserul nu mai descarcă din nou imaginile, CSS-ul și JavaScript-ul la următoarea vizită.
• Cache de obiecte, de exemplu Redis: accelerează paginile dinamice precum coșul sau zona pentru membri, care nu pot fi puse în cache ca pagină întreagă.

Dacă TTFB rămâne ridicat în ciuda cache-ului, cauza este adesea serverul: o versiune PHP depășită, prea puține resurse sau un cont supraîncărcat. Atunci ajută o versiune PHP actuală sau o găzduire cu resurse alocate.

Fonturi și scripturi

Fonturi web

• Găzduiți fonturile pe propriul site în loc să le încărcați de pe servere externe. Economisiți conexiuni și protejați mai bine datele vizitatorilor.
• Încărcați doar grosimile necesare, de exemplu normal și bold, în format WOFF2.
• Cu font-display: swap, browserul afișează imediat textul cu un font de rezervă.
• Preîncărcați cel mai important font cu rel="preload".

JavaScript și servicii terțe

INP are de suferit mai ales din cauza mult JavaScript care blochează browserul. Vinovații tipici sunt widgeturile de chat, scripturile de urmărire și publicitate, bannerele de cookie-uri cu multe servicii integrate, conținutul încorporat din rețelele sociale și page builderele grele.

• Eliminați scripturile de care nu aveți nevoie, în loc doar să le optimizați.
• Încărcați scripturile cu defer sau async, ca să nu blocheze construirea paginii.
• Încărcați videoclipurile și hărțile abia după un clic: mai întâi o imagine de previzualizare, apoi conținutul încorporat.
• Micșorați și combinați CSS-ul și JavaScript-ul, dar testați site-ul după fiecare modificare.

Evitarea deplasărilor de layout (CLS)

Puține lucruri deranjează mai mult decât un buton care se mută exact când îl atingeți, pentru că mai sus încă se încarcă ceva. Exact aceste deplasări le măsoară CLS. Cele mai frecvente cauze și ce ajută:

• Imagini, videoclipuri și iframe-uri fără dimensiuni: indicați lățimea și înălțimea sau un raport fix (aspect-ratio).
• Elemente încărcate ulterior, precum bannere de cookie-uri, bare de notificare sau spații publicitare: afișați-le peste conținut sau rezervați spațiul dinainte.
• Fonturi web care schimbă lățimea textului când înlocuiesc fontul de rezervă: alegeți un font de rezervă cu proporții asemănătoare.
• Conținut inserat prin JavaScript deasupra zonei vizibile: inserați-l doar după o acțiune a vizitatorului.

CDN: când merită

O rețea de livrare a conținutului (CDN) păstrează fișierele statice pe servere din multe țări și le livrează din locația cea mai apropiată. Aduce cel mai mult când vizitatorii sunt răspândiți pe mai multe continente. Dacă site-ul se adresează mai ales clienților din Elveția și Liechtenstein, cache-ul, imaginile optimizate și un răspuns rapid al serverului aduc de obicei mai mult. Un CDN poate fi totuși util, de exemplu la multe imagini mari sau descărcări.

WordPress: cele mai importante reglaje

• Folosiți un plugin de cache potrivit serverului web. Pe LiteSpeed acesta este LiteSpeed Cache, care poate și să optimizeze CSS-ul și JavaScript-ul, să controleze lazy loading și să convertească imaginile în WebP sau AVIF prin serviciul QUIC.cloud.
• WordPress acceptă WebP din versiunea 5.8 și AVIF din versiunea 6.5. Din versiunea 6.3, WordPress adaugă automat fetchpriority="high" imaginii care va fi probabil elementul LCP.
• Folosiți o temă de blocuri ușoară în locul unui page builder greu.
• Verificați regulat plugin-urile și eliminați tot ce nu folosiți.
• Curățați baza de date: revizii vechi, comentarii spam și transients expirate, după un backup.
• Folosiți o versiune PHP actuală; WordPress recomandă în prezent PHP 8.3 sau mai nou.

Sfat: Mai multe sfaturi practice găsiți în articolul nostru „Cum accelerați WordPress: 8 măsuri care chiar funcționează”.

Procedați în această ordine

1. Notați situația actuală pentru mobil și desktop cu PageSpeed Insights și Search Console.
2. Identificați elementul LCP (PageSpeed Insights îl afișează) și optimizați-l țintit; de obicei este imaginea principală.
3. Activați cache-ul de pagini și verificați TTFB.
4. Convertiți imaginile în WebP sau AVIF și indicați lățimea și înălțimea.
5. Găzduiți fonturile pe propriul site și reduceți scripturile terțe.
6. Măsurați din nou după fiecare modificare și verificați datele de teren după câteva săptămâni.

Pe pachetele WordPress de la HostOn, LiteSpeed Cache este preconfigurat, iar site-urile rulează pe servere LiteSpeed cu stocare NVMe. Cache-ul de pagini și răspunsul serverului sunt astfel acoperite; imaginile, fonturile și scripturile rămân sarcina site-ului însuși.