Viteza de încărcare influențează pozițiile în Google, dar nu în felul în care se spune de obicei. Un site rapid nu urcă automat, iar unul lent nu cade automat. Viteza contează când doi concurenți sunt la fel de relevanți pentru aceeași căutare, și contează mult mai des ca factor de comportament al utilizatorului decât ca semnal direct.

Aproape fiecare discuție de audit ajunge, la un moment dat, la o captură de ecran cu un scor roșu din PageSpeed Insights. Clientul întreabă dacă de aia nu urcă site-ul. Răspunsul scurt e „probabil nu”. Răspunsul lung ocupă restul articolului.

Ce spune Google despre viteză, fără interpretări

Google a confirmat public că experiența pe pagină, inclusiv Core Web Vitals, este folosită ca semnal în ranking. Nu a spus că este semnalul principal și nici că un site rapid bate un site mai relevant. Documentația vorbește despre viteză ca despre un factor de diferențiere între pagini care, altfel, ar fi comparabile.

Core Web Vitals sunt trei metrici, cu nume proprii, care merită folosite corect când discuți cu un dezvoltator: LCP (cât durează până apare cel mai mare element vizibil), INP (cât durează până pagina reacționează la o interacțiune) și CLS (cât se mișcă vizual pagina în timp ce se încarcă). Le găsești în raportul Core Web Vitals din Search Console, pe date reale de utilizatori, nu pe teste de laborator.

Diferența asta contează. PageSpeed Insights îți dă două seturi de date: unul simulat, într-un laborator, și unul măsurat de la utilizatori reali, prin Chrome User Experience Report. Al doilea set e cel pe care se uită Google. Primul e util pentru diagnostic tehnic, dar nu e verdictul.

De ce un site lent pierde poziții chiar și când viteza nu e semnal direct

Aici e mecanismul pe care majoritatea articolelor îl sar. Google nu se uită doar la ce e pe pagină, ci și la ce fac oamenii după ce ajung acolo. Când un vizitator dă înapoi în două secunde pentru că pagina încă se încarcă și revine în rezultate, ăsta e un semnal comportamental. Se acumulează, în timp, pentru interogările unde site-ul apare.

Efectul indirect e mai mare decât cel direct. Un site care încarcă lent primește:

• mai puține pagini crawl-ate de Googlebot pe sesiune, pentru că serverul răspunde greu;
• rate de conversie mai mici, ceea ce înseamnă că bugetul de conținut sau de linkuri produce mai puțin;
• abandonuri mai mari pe mobil, unde răbdarea vizitatorului e minimă;
• penalizări indirecte din partea userului, care nu revine.

Nu poți măsura direct câte poziții ai pierdut din cauza vitezei. Poți însă vedea, în raportul Statistici de crawl din Search Console, dacă timpul mediu de răspuns al serverului tău a crescut. Dacă a crescut și traficul a scăzut la câteva săptămâni după, ai o corelație pe care merită să o investighezi.

Ce înseamnă „rapid” pentru Google, în termeni utilizabili

Google publică praguri pentru Core Web Vitals: „bun”, „necesită îmbunătățiri”, „slab”. Pragurile sunt documentate în ghidul oficial web.dev despre Web Vitals. Ce nu se spune la fel de des e că pragurile astea sunt praguri de trecere, nu ținte finale. Un LCP de 2,4 secunde e „bun”. Unul de 1,1 secunde nu îți aduce automat mai mult decât cel de 2,4.

Regula de lucru pe care o aplicăm în audit: obiectivul e să treci pragurile în verde, pe date reale, pe mobil. După aceea, orice optimizare suplimentară intră în categoria „ajută experiența, poate ajuta conversia, nu se traduce direct în poziții”.

De unde vine, de obicei, problema de viteză

Pe site-urile de client, cauzele reale sunt aproape mereu aceleași, în ordinea în care le găsim:

1. hosting subdimensionat sau shared prost, cu timpi de răspuns ai serverului mari; se vede în TTFB, timpul până la primul byte;
2. imagini încărcate direct din upload, fără redimensionare și fără format modern (WebP sau AVIF);
3. o temă WordPress încărcată cu funcții pe care nimeni nu le folosește, plus 30+ plugin-uri active;
4. slidere pe home, pop-up-uri de newsletter, chat-uri și scripturi de tracking care se încarcă înainte de conținut;
5. lipsa unui sistem de cache, sau unul configurat greșit;
6. fonturi web încărcate de pe servere externe, fără preload.

Ce nu e cauza, deși e prima suspectă în ochii clientului: „codul site-ului”. În 9 din 10 cazuri, codul e în regulă. Ce trebuie schimbat e configurația și ce se încarcă, nu ce se scrie.

Ce optimizări au impact real și în ce ordine

Ordonat după impactul mediu pe site-urile pe care lucrăm, nu la întâmplare:

1. Hosting decent și configurare de server. Un TTFB sub 600ms rezolvă mai mult decât orice plugin de optimizare pus peste un hosting slab. Migrarea pe un hosting mai bun e cea mai rapidă îmbunătățire posibilă.
2. Cache și compresie. Un plugin de cache configurat corect (nu instalat și lăsat pe default) plus compresie Brotli sau Gzip la nivel de server.
3. Imagini. Redimensionare la dimensiunile reale afișate, conversie la WebP, lazy loading pentru ce e sub fold. Aici se rezolvă majoritatea problemelor de LCP.
4. Scripturi terțe. Amânarea scripturilor care nu sunt necesare pentru primul render: chat-uri, tracking secundar, pop-up-uri. INP se îmbunătățește semnificativ când thread-ul principal nu mai e ocupat.
5. Curățare de plugin-uri și cod. Dezactivarea a ce nu se folosește, ștergerea funcționalităților duplicate.
6. CSS și JS critice. Aici intri în teritoriul dezvoltatorului. E util, dar cu randamente descrescătoare.

Dacă ai făcut primele trei și nu ai văzut diferență în raportul Core Web Vitals după 28 de zile (fereastra pe care o folosește Google), problema e în altă parte: pe partea de conținut, structură sau linkuri. Nu în viteză.

Ce nu funcționează, deși se recomandă

„Instalează un plugin de optimizare și gata.” Nu gata. Plugin-urile de tip „all-in-one speed” fac lucruri utile, dar pe un site prost configurat pot rupe layout-ul, pot bloca funcționalități sau pot îmbunătăți scorul din laborator fără să miște datele reale. În loc: alege un plugin de cache serios, configurează-l manual, testează pas cu pas ce activezi.

„Trecem pe un CDN.” Un CDN ajută la site-uri cu trafic internațional sau cu vizitatori din zone geografice distante de server. Pentru o firmă locală din România, cu server în România și clienți din România, câștigul e marginal. În loc: verifică întâi locația și calitatea serverului tău.

„Vrem 100 la PageSpeed Insights.” Scorul de 100 e o distragere. E măsurat în laborator, cu setări specifice, și nu reflectă experiența utilizatorului. Un site cu 78 pe mobil, dar cu Core Web Vitals în verde pe date reale, e mai bun decât unul cu 96 în laborator și INP slab în raport. În loc: uită-te la raportul Core Web Vitals din Search Console, nu la scorul din tool.

Ce nu se poate măsura cu certitudine

Nu poți spune cu cifre exacte cât ai câștigat în poziții după o optimizare de viteză. Pozițiile se schimbă din mai multe motive simultan: conținut nou, linkuri primite, algoritm actualizat, ce fac concurenții. Când raportăm rezultatele unei optimizări de viteză, spunem ce s-a îmbunătățit tehnic și ce corelații se văd, nu inventăm procente de creștere atribuite unui singur factor.

Nici invers nu funcționează: dacă traficul a scăzut și site-ul e lent, nu e automat din cauza vitezei. E prima ipoteză de verificat, nu concluzia.

Ce depinde de tine, dacă vrei să investighezi singur

Înainte să ceri unei agenții să îți optimizeze viteza, poți verifica singur:

• deschide Search Console și uită-te la raportul Core Web Vitals; dacă e roșu pe mobil, ai o problemă reală, măsurată pe utilizatorii tăi;
• rulează site-ul prin PageSpeed Insights și uită-te la secțiunea „Discover what your real users are experiencing”, nu la scorul mare colorat;
• verifică ce hosting ai și ce timpi de răspuns oferă; dacă TTFB e peste o secundă constant, asta e prima problemă;
• fă o listă cu plugin-urile active și întreabă-te sincer care sunt folosite.

Dacă vrei o verificare mai amplă, poți începe cu un audit SEO gratuit pe site-ul tău. Tool-ul rulează peste 60 de verificări automate, inclusiv pe partea de viteză și structură tehnică, și îți trimite raportul pe email. Ce nu poate face un tool automat: să îți spună dacă problema e în hosting, în configurație sau în tema aleasă. Pentru asta e nevoie de o privire de om peste site.

Întrebări frecvente

Cât de repede se văd efectele unei optimizări de viteză în Search Console?

Raportul Core Web Vitals se actualizează pe o fereastră de 28 de zile de date reale. Adică schimbările pe care le faci azi apar complet în raport peste aproximativ o lună. Pozițiile, dacă se mișcă din cauza vitezei, se mișcă la câteva săptămâni după, când Google recrawl-uiește și recalculează. Nu aștepta rezultate în prima săptămână.

Un site rapid dar cu conținut slab urcă în Google?

Nu. Viteza nu compensează relevanța. Am văzut site-uri cu scoruri excelente pe PageSpeed Insights care nu apar pe niciun cuvânt important, pentru că nu au conținut care să răspundă la ce caută oamenii. Viteza e un factor de diferențiere între pagini deja competitive, nu un substitut pentru substanță.

Pot să îmi optimizez singur viteza site-ului?

Da, parțial. Compresia imaginilor, activarea unui plugin de cache, curățarea plugin-urilor inutile – toate se pot face fără dezvoltator. Ce nu se poate face fără cineva tehnic: schimbarea hostingului, configurarea serverului, intervenția pe tema WordPress. Regula: încearcă primele trei, iar dacă LCP-ul rămâne peste 2,5s pe mobil, ai nevoie de ajutor mai profund.