De ce viteza site-ului îți decide vânzările — și cum o reparăm

Viteza unui site nu e un moft tehnic, e bani. Când Deloitte și Google au analizat peste 30 de milioane de sesiuni pe 37 de branduri mari, au descoperit ceva surprinzător de concret: o îmbunătățire de doar o zecime de secundă a vitezei pe mobil a crescut rata de conversie în retail cu 8,4%, iar la produsele de lux trecerea de la pagina de produs la coș a urcat cu peste 40%.

Cu alte cuvinte: dacă site-ul tău e lent, pierzi clienți în fiecare zi — pur și simplu nu-i vezi plecând. În articolul ăsta îți arătăm ce spun datele, cum te măsoară Google, ce încetinește de fapt un site și, mai ales, ce facem noi concret ca să-l facem rapid — pe WordPress, pe site-uri PHP la comandă și la nivel de server.

Ce spun cifrele

Relația dintre viteză și vânzări e una dintre cele mai studiate din web. Câteva repere solide și recente:

• 0,1 secunde contează. Studiul „Milliseconds Make Millions" (Deloitte & Google) arată că o îmbunătățire de 100 de milisecunde a crescut conversiile în retail cu 8,4% și valoarea medie a comenzii cu 9,2%.
• Sub 2 secunde e zona de aur. O analiză Portent pe peste 100 de milioane de afișări a găsit că rata de conversie e maximă la 1–2 secunde (~3%) și scade până spre 0,7% la 4 secunde.
• Viteza, testată direct. Într-un test A/B real, magazinul Rakuten 24 a obținut, cu o pagină optimizată pe viteză, +53% venit per vizitator și +33% rată de conversie.

Și invers — cu cât e mai lent, cu atât pleacă mai mulți. Un model Google/SOASTA arată cum crește probabilitatea ca vizitatorul de pe mobil să abandoneze pagina, pe măsură ce încărcarea durează mai mult:

Statisticile celebre cu „Amazon pierdea 1% din vânzări la fiecare 100 ms" sau „53% abandonează un site mobil mai lent de 3 secunde" sunt reale, dar vechi (2006–2016). Le menționăm pentru context — concluzia lor se confirmă însă și azi, prin datele de mai sus.

Core Web Vitals: cele 3 cifre prin care te măsoară Google

Google a transformat „viteza" în trei măsurători concrete, numite Core Web Vitals. Sunt măsurate pe vizitatori reali (la percentila 75 — adică experiența celor mai mulți utilizatori) și contează inclusiv pentru poziționarea în căutări:

• LCP (Largest Contentful Paint) — cât de repede apare conținutul principal al paginii. Țintă: sub 2,5 secunde.
• INP (Interaction to Next Paint) — cât de repede reacționează pagina când dai clic sau atingi. Țintă: sub 200 ms. (Din martie 2024 a înlocuit vechiul indicator FID.)
• CLS (Cumulative Layout Shift) — cât de stabil stă layout-ul, fără ca elementele să „sară" sub deget. Țintă: sub 0,1.

Cum stă, de fapt, web-ul

Realitatea e că majoritatea site-urilor nu trec testul. Conform HTTP Archive Web Almanac (date pe vizitatori reali, 2025), doar 48% dintre site-urile mobile trec toate cele trei Core Web Vitals. Pagina medie a ajuns la ~2,2 MB și 70+ de cereri către server.

Și contează mult pe ce platformă ești. Iată câte site-uri trec testul, pe mobil, în funcție de platformă:

Ce încetinește, de fapt, un site

O pagină grea e, în mare parte, imagini și cod JavaScript. Iată din ce e făcută o pagină medie:

Dar greutatea e doar jumătate din poveste. Ce „ucide" cel mai des viteza:

• Serverul lent (TTFB). Timpul până la primul răspuns al serverului e cea mai mare piesă din LCP-ul prost — pe site-urile lente, serverul singur „mănâncă" peste 2 secunde. Doar 42% dintre site-urile mobile au un TTFB bun.
• Imagini neoptimizate — încărcate la rezoluție uriașă, în formate vechi, fără lazy-load.
• Prea mult JavaScript. Scripturile (mai ales cele de la terți: analytics, chat, consimțământ) blochează firul principal și fac pagina să răspundă greu la clic — principala cauză a unui INP slab.
• Lipsa cache-ului. Fără cache, fiecare vizitator pune serverul să reconstruiască pagina de la zero.

Un mit util de spulberat: „comprim imaginea și gata". Datele Google arată că, pe site-urile lente, browserul pierde de departe cel mai mult timp așteptând să înceapă încărcarea (din cauza serverului și a scripturilor care blochează), nu descărcând imaginea propriu-zisă. De aceea reparația reală e mai degrabă la server și la cache decât la o singură poză.

Ce facem pentru WordPress

WordPress poate fi rapid — depinde cum e construit și întreținut. Pârghiile pe care le tragem:

• Cache de pagină + cache de obiect (Redis). Paginile se servesc în milisecunde, iar pentru zonele dinamice (coș, cont) Redis taie timpul de răspuns cu 40–75% și interogările în baza de date cu 50–80%.
• Imagini optimizate. Convertim în formate moderne (WebP/AVIF), dimensionăm corect și activăm lazy-load — acolo e jumătate din greutatea paginii.
• Curățenie de plugin-uri. Mai puține extensii înseamnă mai puțin JavaScript și mai puține scripturi care blochează pagina.
• Găzduire bună + PHP la zi. O găzduire rapidă și o versiune recentă de PHP scad TTFB-ul — fundația pe care stă tot restul.
• CDN, compresie și încărcare inteligentă. Conținut servit de aproape, comprimat (Brotli), cu CSS-ul critic încărcat primul și JavaScript-ul neesențial amânat.

Tot aici intră și mentenanța regulată: un site lăsat fără actualizări și fără curățarea bazei de date încetinește pe nesimțite.

Ce facem pentru site-uri PHP la comandă

Când construim noi aplicația, avem control total asupra codului — așa că putem ținti constant 1–2 secunde:

• OPcache + reglaj PHP. Activarea cache-ului de cod (OPcache) crește de 2–5 ori numărul de cereri pe care le poate duce serverul, eliminând recompilarea la fiecare request.
• Interogări și indexuri optimizate. Eliminăm interogările repetate și lente, adăugăm indexuri și punem un cache pe rezultatele grele.
• Cache de pagină și de fragmente. O pagină din cache se servește în sub 10 ms, față de 500 ms+ când e generată din zero.
• Cod livrat curat. Comprimare Brotli/gzip, HTTP/2 și HTTP/3, fișiere unite și minificate, JavaScript amânat și încărcat doar unde e nevoie.
• Măsurăm, nu ghicim. Profilăm aplicația, găsim punctele reale care încetinesc și le reparăm pe acelea — nu optimizăm la întâmplare.

Despre asta e, de fapt, software-ul la comandă: un site care nu cară greutatea inutilă a zeci de module de care nu ai nevoie.

Ce facem la nivel de server

Fundația contează cel mai mult. La nivel de infrastructură și găzduire:

• Găzduire pe măsură. E cea mai mare pârghie pentru TTFB: pe găzduire performantă, ~85% din site-uri au timp de răspuns bun, față de doar ~29% pe găzduirea ieftină, supraaglomerată. Ținta noastră: sub 800 ms, ideal mult mai jos.
• Cache la nivel de server. Full-page cache (Varnish / micro-cache Nginx) pentru vizitatorii anonimi, plus Redis pentru datele dinamice.
• Stocare rapidă (NVMe). Pentru site-urile cu baze de date mari, discurile NVMe duc de câteva ori mai multe operații pe secundă decât SSD-urile clasice.
• Protocoale și compresie moderne. HTTP/2 și HTTP/3, Brotli, plus PHP-FPM reglat pentru traficul real.
• Monitorizare continuă. Urmărim viteza și disponibilitatea non-stop, ca să prindem o încetinire înainte s-o simtă clienții.

Concluzii

• Viteza e venit, nu cosmetică. O zecime de secundă poate însemna +8% conversii; o pagină lentă pierde clienți tăcut.
• Google o măsoară concret — LCP, INP, CLS — și peste jumătate dintre site-urile mobile încă pică testul. E un avantaj real pentru cine îl trece.
• Cele mai mari pârghii sunt cache-ul și găzduirea, nu trucurile mici. Serverul lent și JavaScript-ul în exces fac diferența.
• Indiferent de platformă — WordPress, PHP la comandă sau server — viteza se poate măsura și repara. Asta facem.

Surse

• Deloitte & Google — Milliseconds Make Millions (2020)
• Portent — Site Speed & Conversion Rate (2022) și web.dev — Rakuten 24 (2023)
• web.dev (Google) — Core Web Vitals (2024)
• HTTP Archive Web Almanac — Performance (2025) și Page Weight / CMS (2024)
• web.dev — Misconcepții despre optimizarea LCP și Kinsta — PHP Benchmarks (2025)