Site lent? Verifică și repară Core Web Vitals.
Ar fi o idee proastă să afli de ce pleacă oamenii înainte să se încarce pagina?
Un audit Core Web Vitals află de ce paginile tale se încarcă greu, sar pe ecran sau reacționează târziu la click. Apoi repar: server, imagini, scripturi, fonturi și așezarea paginii, până când site-ul trece testul și pentru vizitatorii reali.
Trimite-mi URL-ul și îți spun unde sunt cele mai mari probleme.
Dacă site-ul pare lent, verifică întâi Core Web Vitals.
Core Web Vitals sunt felul în care Google măsoară ce simt vizitatorii pe site. Când un site pare lent, de aici afli de ce.
Vizitatorii pleacă înainte să se încarce pagina
Fiecare secundă în plus de așteptare te costă click-uri, înscrieri și vânzări. Majoritatea vizitatorilor nu-ți spun că site-ul e lent. Se întorc în Google și aleg următorul rezultat.
Și Google, și roboții AI observă asta
Core Web Vitals fac parte din semnalele prin care Google evaluează experiența pe pagină. Un server lent îl face și pe Googlebot să viziteze mai puține pagini, iar roboții AI ca GPTBot sar adesea peste conținutul care depinde de mult JavaScript.
Un scor slab ascunde multe probleme
Un raport Core Web Vitals picat e doar simptomul. În spate sunt lucruri ca hosting ieftin, teme încărcate, prea multe pluginuri, imagini neoptimizate, scripturi externe și fonturi care blochează pagina.
Pe această pagină
Ce măsoară Core Web Vitals și ce înseamnă un scor bun
Core Web Vitals sunt trei măsurători prin care Google urmărește viteza de încărcare, reacția la click și stabilitatea paginii, pe baza datelor de la vizitatori reali din Chrome. O pagină trece testul când cel puțin 75% din vizite sunt pe verde la toate trei.
Cât durează până se vede conținutul principal (de obicei imaginea mare sau titlul).
Cât de repede reacționează pagina când cineva dă click, atinge ecranul sau scrie. INP a înlocuit FID în 2024.
Cât de mult se mișcă elementele pe ecran în timp ce se încarcă pagina.
„Core Web Vitals assessment: failed” în PageSpeed sau Search Console
De obicei așa afli. PageSpeed Insights arată un „Failed” roșu sus, sau raportul Core Web Vitals din Google Search Console listează grupuri de URL-uri „Poor” sau „Need improvement”. Raportul îți spune ce măsurătoare pică, dar nu și de ce.
Search Console grupează URL-urile asemănătoare, așa că un singur tip de pagină lent (toate paginile de produs, toate articolele) poate pica sute de URL-uri deodată. Vestea bună: îl repari o dată și se îmbunătățesc toate.
De obicei cauza e
- Un tip de pagină lent, repetat pe tot site-ul
- Date de la vizitatori reali pe mobil, cu internet mai lent
- Timp de răspuns al serverului (TTFB) care variază în funcție de trafic
- Schimbări ca o temă nouă, un plugin sau un script de tracking
Ce verific și repar
- Ce măsurătoare pică și pe ce grupuri de URL-uri
- Date de la vizitatori reali vs teste simulate și de ce diferă
- Elementul sau scriptul exact care cauzează problema
- O listă de reparații, ordonată după câte URL-uri afectează
LCP lent: conținutul principal apare prea târziu
Un Largest Contentful Paint lent înseamnă că vizitatorii se uită la o pagină goală sau pe jumătate încărcată. Elementul LCP e de obicei imaginea principală, un banner sau primul bloc mare de text, iar un LCP mai bun înseamnă să aduci mai repede pe ecran exact acel element.
De obicei cauza e
- Server sau hosting lent (TTFB mare)
- Imaginea principală prea mare, încărcată cu întârziere sau fără prioritate
- CSS și fonturi care blochează afișarea paginii
- Conținut generat din JavaScript după încărcare
Ce verific și repar
- Identific elementul LCP pe fiecare tip de pagină important
- Compresie de imagini, WebP/AVIF și prioritate de încărcare
- Cache, CDN și timpul de răspuns al serverului
- CSS critic și încărcarea fonturilor
Elemente care sar (CLS): pagina se mișcă și vizitatorii apasă greșit
Cumulative Layout Shift e momentul în care vrei să apeși un buton și o reclamă sau un banner îl împinge în jos. E enervant pe orice site și scump pe un magazin online, unde duce la click-uri greșite și coșuri abandonate.
De obicei cauza e
- Imagini și video fără dimensiuni setate
- Reclame, conținut încorporat și iframe-uri fără spațiu rezervat
- Bannere de cookie și notificări care apar sus
- Fonturi care se schimbă la încărcare și modifică mărimea textului
Ce verific și repar
- Spațiu rezervat pentru imagini, reclame și conținut încorporat
- Bannere și pop-up-uri care se încarcă târziu, rezolvate
- Fonturi de rezervă cu aceeași mărime ca fontul real
- Retestare pe ecrane reale de telefon
INP slab: click-urile și atingerile răspund cu întârziere
Un Interaction to Next Paint slab înseamnă că pagina pare gata, dar nu răspunde: un meniu se deschide târziu, butonul „Adaugă în coș” se blochează, un formular rămâne în urmă când scrii. Cauza e aproape mereu prea mult JavaScript rulat la momentul greșit.
De obicei cauza e
- Teme grele și page buildere
- Scripturi externe: chat, analytics, reclame, teste A/B
- Sarcini JavaScript lungi care blochează pagina
- Pagini foarte mari, cu mii de elemente
Ce verific și repar
- Ce scripturi blochează interacțiunile și când
- Scot sau amân tot ce nu e necesar
- Scripturile externe, încărcate doar pe paginile unde sunt folosite
- Alternative mai ușoare pentru pluginurile grele
Site-ul tău WordPress sau WooCommerce e lent
Majoritatea site-urilor lente pe care le văd rulează pe WordPress. Nu pentru că WordPress e lent, ci pentru că se adună ani de pluginuri, o temă grea și un hosting ieftin, partajat. Optimizarea vitezei pe WordPress înseamnă mai ales să scoți din greutate, nu să mai adaugi încă un plugin de viteză.
De obicei cauza e
- Prea multe pluginuri, unele încărcate pe fiecare pagină
- Page buildere și teme „care fac de toate”
- Fără cache sau cu cache setat greșit
- Imagini mari, neoptimizate, în biblioteca media
Ce verific și repar
- Analiza pluginurilor: cât încetinește fiecare pagina
- Setări de cache, bază de date și hosting
- Optimizarea tuturor imaginilor din biblioteca media
- Paginile de coș, checkout și filtre din WooCommerce
Rapid pe desktop, lent pe mobil
Site-ul poate merge bine pe calculatorul din birou și totuși să pice Core Web Vitals. Google evaluează întâi versiunea de mobil, iar majoritatea vizitelor vin de pe telefoane obișnuite, pe date mobile. Asta e experiența pe care o testez și o optimizez: aspectul pe mobil, zonele de atingere, mărimea imaginilor și scripturile care dau probleme doar pe ecrane mici.
Contează Core Web Vitals pentru pozițiile în Google?
Da, dar nu singure. Core Web Vitals fac parte din semnalele prin care Google evaluează experiența pe pagină. Nu vor urca o pagină slabă peste una mai relevantă, dar între pagini de calitate apropiată pot face diferența.
Efectele mai mari sunt indirecte: un site mai rapid e parcurs mai ușor de Google, ține vizitatorii mai mult și transformă mai mult din traficul pe care îl ai deja în clienți. De asta verific Core Web Vitals în fiecare audit SEO tehnic.
Repară viteza întâi pentru vizitatori. Beneficiul în Google vine după.
De la verificarea Core Web Vitals la rezolvare
- 1
Verific datele de la vizitatori reali
Date din Search Console și Chrome UX Report, ca să văd ce măsurători pică, pe ce pagini, pentru vizitatorii reali.
- 2
Găsesc cauza
Teste pe fiecare tip de pagină important, ca să găsesc exact elementul, scriptul sau problema de server din spatele fiecărei măsurători picate.
- 3
Repar sau îți dau lista de reparații
Fac modificările în CMS, în cod sau pe server, sau le dau programatorilor tăi o listă concretă, în ordinea importanței.
- 4
Validez și monitorizez
Pornesc validarea în Search Console și urmăresc datele reale până când paginile trec testul.