Cât te costă un site lent — viteza, Core Web Vitals și conversiile
Scris de Rareș Poantă · 6 min de citit · actualizat 2026-09-09
Cât te costă, în bani, un site lent
Imaginează-ți că intri într-un magazin fizic. Ușa se deschide greu, lumina pâlpâie și durează câteva secunde bune până te bagă cineva în seamă. Probabil ieși.
Pe internet se întâmplă la fel, doar că mult mai repede și fără ca tu să afli vreodată. Vizitatorul care închide pagina după trei secunde nu îți lasă niciun semn. Nu apare în statistici ca „client pierdut" — apare, cel mult, ca o vizită scurtă.
Ce spun datele
Cifrele cele mai citate din industrie converg spre aceeași concluzie:
| Constatare | Sursă |
|---|---|
| Peste jumătate dintre vizitatorii de mobil abandonează dacă pagina durează mai mult de 3 secunde | |
| O îmbunătățire de 0,1 secunde a crescut conversiile cu ~8 % în retail | Studiu Google / Deloitte |
| Fiecare 100 ms de întârziere au fost corelate cu ~1 % scădere a vânzărilor | Analiză internă Amazon, larg citată |
Cifrele exacte diferă de la un studiu la altul și de la un domeniu la altul. Direcția însă nu s-a schimbat în cincisprezece ani: fiecare fracțiune de secundă în plus costă vizitatori.
Important de înțeles: efectul nu e liniar. Diferența dintre 1 și 2 secunde e resimțită mult mai puternic decât cea dintre 6 și 7. La 6 secunde ai pierdut deja majoritatea celor care aveau să plece.
Cele trei praguri pe care le măsoară Google
Core Web Vitals sunt trei metrici colectate de la utilizatori reali, din browserele lor — nu din teste de laborator:
| Metrică | Ce măsoară | Prag „bun" |
|---|---|---|
| LCP | Cât durează până apare cel mai mare element vizibil | sub 2,5 s |
| INP | Cât durează până pagina reacționează la un click | sub 200 ms |
| CLS | Cât „sar" elementele în timpul încărcării | sub 0,1 |
Consecința faptului că se măsoară pe utilizatori reali: un site care merge perfect pe laptopul tău poate avea scoruri slabe. Dacă publicul tău îl accesează de pe telefoane de trei ani vechime, pe conexiune mobilă, aceea e realitatea pe care o vede Google — nu experiența ta pe fibră.
Ca factor de poziționare, Core Web Vitals contează mai puțin decât relevanța conținutului. Un site rapid cu conținut slab nu va depăși un site lent cu conținut excelent. Dar între două pagini comparabile, viteza departajează. Iar efectul direct asupra conversiei e, de regulă, mai valoros decât cel asupra poziției.
De ce se încarcă greu site-urile
În ordinea frecvenței cu care le întâlnim în audituri:
1. Imagini neoptimizate. Cauza numărul unu, de departe. O fotografie de 4 MB, urcată direct de pe telefon și micșorată din CSS, se descarcă integral. Aceeași imagine, redimensionată corect și salvată în format modern, poate ajunge la 60 KB — de peste 60 de ori mai mică, fără diferență vizibilă.
2. Prea mult JavaScript. Fiecare bibliotecă adăugată trebuie descărcată, interpretată și executată. Un site de prezentare care livrează un megabyte de JavaScript face telefonul utilizatorului să muncească pentru nimic.
3. Pluginuri care se încarcă peste tot. Tipic la WordPress: un plugin de formulare își încarcă bibliotecile pe toate paginile, inclusiv unde nu există niciun formular.
4. Fonturi externe. Un font încărcat de pe un server extern blochează afișarea textului până se descarcă. Se rezolvă cu găzduire locală și font-display: swap.
5. Găzduire slabă. Un plan partajat ieftin, cu sute de site-uri pe același server, adaugă întârziere înainte ca browserul să primească primul byte.
6. Bază de date neoptimizată. Un index lipsă poate transforma o interogare de 5 milisecunde în una de 2 secunde. Se vede rar în teste, dar apare exact când ai trafic.
Ce poți verifica singur, gratuit, în zece minute
- PageSpeed Insights. Introdu adresa site-ului. Uită-te la secțiunea de date reale (nu doar la scorul din laborator) și la lista „Oportunități" — e ordonată după impact.
- Search Console → Core Web Vitals. Aici vezi cum se comportă site-ul pe utilizatorii tăi reali, grupat pe tipuri de pagini.
- Testul telefonului propriu. Dezactivează Wi-Fi, deschide site-ul pe date mobile și cronometrează. E cel mai onest test disponibil.
Dacă la testul cu telefonul numeri peste trei secunde până vezi conținut util, ai o problemă care costă bani în fiecare zi.
Ce se poate repara ieftin
| Problemă | Efort | Câștig tipic |
|---|---|---|
| Comprimarea imaginilor | Mic | Mare |
| Dimensionarea corectă a imaginilor | Mic | Mare |
| Găzduirea locală a fonturilor | Mic | Mediu |
| Eliminarea pluginurilor nefolosite | Mic | Mediu |
| Activarea caching-ului | Mediu | Mare |
| Reducerea JavaScript-ului | Mare | Mare |
| Schimbarea găzduirii | Mediu | Variabil |
| Rescrierea pe arhitectură statică | Mare | Foarte mare |
Ordinea de mai sus e și ordinea recomandată. Primele patru se rezolvă frecvent într-o zi de muncă și aduc cea mai mare parte a câștigului. Rescrierea completă e ultima opțiune, nu prima.
Abordarea care elimină problema din start
Cea mai eficientă optimizare e să nu ai ce optimiza.
Un site clasic construiește pagina la fiecare vizită: pornește codul de server, interoghează baza de date, rulează pluginurile, asamblează HTML-ul. Un site generat static face munca o singură dată, la publicare, și apoi servește un fișier gata făcut.
Diferența nu e de optimizare, ci de când se face munca. De aici vin timpii sub o secundă, obținuți implicit, fără caching, fără pluginuri de accelerare și fără întreținere lunară.
Aceasta e abordarea pe care o folosim la AlgorX, cu Next.js. Nu pentru că e la modă, ci pentru că mută problema performanței din zona „ceva ce trebuie întreținut permanent" în zona „ceva rezolvat prin construcție". Comparația detaliată cu alternativa clasică e în articolul despre Next.js vs WordPress.
Întrebări frecvente
Ce scor PageSpeed ar trebui să am? Scorul e un indicator, nu obiectivul. Ce contează sunt cele trei praguri Core Web Vitals pe date reale. Un site cu scor 85 și LCP de 1,8 secunde e mai sănătos decât unul cu scor 95 obținut din trucuri de laborator.
Am 100 % pe desktop și 55 % pe mobil. E normal? Da, și e motivul pentru care ar trebui să te uiți doar la mobil. Testele de mobil simulează un dispozitiv mediu pe conexiune lentă — mai aproape de realitatea publicului tău decât desktopul.
Merită să schimb site-ul doar pentru viteză? Rar. Verifică întâi ce se poate repara pe cel existent — de regulă se recuperează mare parte din diferență cu efort mic. Rescrierea se justifică atunci când site-ul are și alte probleme: design învechit, structură care nu mai corespunde, cost de întreținere mare.
Cât durează o optimizare de viteză? Pentru problemele frecvente — imagini, fonturi, caching — între una și trei zile. Pentru probleme de arhitectură sau bază de date, între una și trei săptămâni, în funcție de ce arată auditul.
Concluzie
Viteza nu e un detaliu tehnic pentru programatori. E prima impresie pe care o lași și, spre deosebire de design, se măsoară exact.
Trei lucruri de făcut:
- Testează-ți site-ul acum, pe telefon, pe date mobile. Zece secunde de efort.
- Repară imaginile. E cea mai frecventă cauză și cea mai ieftin de rezolvat.
- Uită-te la datele reale din Search Console, nu doar la scoruri de laborator.
Dacă vrei să știi exact ce încetinește site-ul tău și cât costă fiecare reparație, facem audituri tehnice cu raport și plan prioritizat. Scrie-ne — iar dacă din verificarea inițială reiese că site-ul tău e deja în regulă, îți spunem asta.
Vezi și: Ce sunt Core Web Vitals și Ce este SEO tehnic.