De ce e site-ul meu atat de încet pe mobil? (Ghid 2026)

Luna trecută ai rulat campanii pe Google Ads. Ai cheltuit bugetul, ai primit clickuri, și apoi ai văzut cifrele de conversie. Dezamăgitoare. Ai deschis site-ul pe telefon în birou, arăta bine. Apoi un client ți-a zis în treacăt că site-ul e „cam lent." Ai deschis PageSpeed Insights pentru prima dată și ai văzut un scor de 38 pe mobil.

Nu ești singurul. Și problema nu e pachetul de hosting. Nu e viteza conexiunii tale. E felul în care a fost construit site-ul. S-au luat decizii concrete în timp ce se construia: despre imagini, despre cod, despre cum ajunge pagina pe telefonul unui om. Nimeni nu ți le-a explicat. Asta vrem să lămurim acum.

Ce înseamnă „lent pe mobil" și de ce îți afectează direct veniturile?

Viteza e o problemă de business înainte să fie o problemă tehnică.

53% dintre vizitatorii de pe mobil abandonează pagina dacă nu se încarcă în 3 secunde. Cercetare Google, trafic real, la scară mare. Ce înseamnă asta concret pentru un business care rulează Google Ads: dacă pagina ta de destinație se încarcă greu pe mobil, mai mult de jumătate din oamenii care au dat click pe anunțul tău pleacă înainte să vadă ce oferi.

Cifrele de conversie sunt la fel de clare. Site-urile care se încarcă în 1 secundă convertesc în medie la 3%. La 5 secunde, rata scade la 0,6%. De cinci ori mai puține conversii pentru același număr de vizitatori. Pentru o clinică care plătește €15 pe lead în Google Ads, o pagină lentă pe mobil mănâncă tăcut 7-20% din leaduri în fiecare lună. Reclamele funcționează. Site-ul pierde leadurile după click.

Dacă rulezi campanii plătite, e și mai grav. Viteza paginii pe mobil intră direct în Quality Score prin componenta Landing Page Experience. O pagină lentă îți scade Quality Score-ul, ceea ce îți crește costul pe click. Un business cu €5.000/lună în Google Ads și un Quality Score de 4 poate plăti cu 25-50% mai mult pe click decât un competitor cu aceleași cuvinte cheie și un site mai rapid. Același buget. Mai puține leaduri.

Google măsoară toate astea prin Core Web Vitals, trei metrici care reflectă exact ce simte vizitatorul în timp ce pagina se încarcă.

Metric	Ce măsoară	Bun	Slab
LCP (Largest Contentful Paint)	Cât de repede apare conținutul principal	Sub 2,5s	Peste 4s
CLS (Cumulative Layout Shift)	Cât sare pagina în timp ce se încarcă	Sub 0,1	Peste 0,25
INP (Interaction to Next Paint)	Cât de repede răspunde pagina la un click	Sub 200ms	Peste 500ms

Doar 47% dintre site-uri trec toate trei (Web Almanac 2025). Dacă al tău pică, nu ești excepția.

De ce agenția testează pe laptop și tu plătești pe Samsung Galaxy A34

Există o diferență reală între cum ți-a fost livrat site-ul și cum îl folosesc clienții tăi.

Când agenția a revizuit site-ul înainte de livrare, probabil era pe un MacBook M3, conectat la fibra de 1 Gbps din birou, cu cache-ul browserului deja încălzit de la vizitele anterioare. Clienții tăi sunt pe un Samsung Galaxy A34 sau ceva similar, pe Digi 4G în trafic, pe un telefon cu doi sau trei ani vechime. Diferența dintre cele două situații nu e mică.

Procesoarele mobile au de trei până la cinci ori mai puțină putere de calcul decât un chip modern de laptop. O sarcină JavaScript care durează 30 milisecunde pe calculatorul agenției durează 100-150 milisecunde pe telefonul clientului tău. Și 4G-ul în practică, cu latența și variația reală a semnalului, se comportă diferit față de cifrele pe care le vezi în teste.

Același site care scorează 95 în tab-ul desktop al PageSpeed poate scora 38 pe mobil. Nu e un caz excepțional. Se întâmplă frecvent pe site-uri construite cu page buildere populare și teme pre-ambalate, pentru că acele instrumente sunt proiectate să arate bine în demo-uri, nu să se încarce rapid pe telefoane de gamă medie.

Site-ul era lent din ziua în care a fost livrat. Pur și simplu nu aveai un număr pentru asta până acum.

Cauza 1: Imagini nepregătite pentru mobil

Asta e cea mai comună cauză și cea mai ușor de remediat.

Pagina de start mediană pe mobil în 2025 transferă aproximativ 2,56 MB de date, din care circa 900 KB sunt imagini. Numărul e mare pentru că majoritatea agențiilor livrează imaginile exact cum ies din programul de design: JPEG sau PNG la rezoluție maximă, dimensionate pentru un ecran desktop, trimise la orice dispozitiv inclusiv telefoane.

Problema de format o agravează. WebP, cel mai răspândit format modern de imagine, produce fișiere de circa 10 ori mai mici decât JPEG la 80% din calitatea vizuală. Are suport în peste 94% din browsere în 2026. Argumentul că „nu e compatibil" nu mai ține. Și totuși cele mai multe agenții nu au făcut trecerea niciodată.

Diferența e concretă. O singură fotografie 1920×1080:

Format	Dimensiune fișier	Suport browsere	Folosit de agenții
JPEG	~450 KB	100%	Da (implicit)
WebP	~45 KB	~94%	Rar

Pe o pagină cu 20 de imagini, trecerea de la JPEG la WebP taie circa 8 MB de date. Pe 4G, asta înseamnă câteva secunde suplimentare de așteptare în timp ce paginile competitorilor tăi afișează deja rezultate.

Mai e o problemă legată de imagini, dincolo de format. Când imaginile sunt adăugate pe pagină fără atribute explicite de lățime și înălțime, browserul nu știe cât spațiu să rezerve pentru ele în timp ce se încarcă. Pagina sare în timp ce imaginile apar. Asta produce erori de CLS, un metric separat din Core Web Vitals, pe lângă problema de viteză.

Cauza 2: JavaScript care cântărește cât un site întreg

Orice site încarcă JavaScript. Întrebarea e cât, și dacă vreunul din el era cu adevărat necesar.

Explicația simplă: imaginează-ți un instalator care aduce în apartamentul tău toate uneltele din dubă pentru o reparație care necesita o singură cheie. Telefonul vizitatorului tău trebuie să care toate uneltele acelea înainte să poată vedea pagina. Majoritatea nu sunt folosite niciodată. Greutatea există oricum.

Asta se întâmplă în două scenarii frecvente. Primul: site-uri construite pe platforme precum Webflow, unde fiecare interacțiune, slider și animație adaugă la un pachet JavaScript livrat tuturor vizitatorilor pe toate paginile. Al doilea: site-uri unde codul a fost generat de un tool AI sau scris de un developer junior. Codul generat de AI importă de obicei librării întregi când o singură funcție ar fi ajuns. Un singur import neglijent dintr-o librărie de animații poate adăuga 400-600 KB de JavaScript la fiecare încărcare de pagină. Developer-ul a folosit 10% din librărie. Vizitatorul tău descarcă tot.

Ambele scenarii produc același rezultat: un telefon care muncește din greu descărcând cod înainte să poată arăta ceva.

Cauza 3: Animații frumoase, telefoane blocate

Librăriile de animații sunt o problemă separată de JavaScript-ul general și merită propria explicație, pentru că sunt atât de frecvente și atât de invizibile.

Tiparul e acesta: agenția instalează o librărie de animații în template-ul global al site-ului. Rulează pe orice pagină. Un site de clinică cu un singur contor animat pe homepage livrează toată librăria de animații pe pagina de contact, pe pagina de servicii și pe pagina de echipă, niciuna dintre acestea neavând animații. Fiecare vizitator pe fiecare pagină plătește costul de descărcare al codului care nu face nimic pe pagina pe care o vede.

GSAP, o librărie populară de animații, nu suportă încărcare selectivă. Folosind orice parte din ea, importi tot. Cu pluginul ScrollTrigger adăugat, pachetul depășește regulat 400 KB. Webflow a făcut GSAP gratuit în 2024, ceea ce a declanșat un val de agenții care îl includ implicit pe site-uri care nu aveau nevoie de el. Telefonul vizitatorului îl descarcă indiferent.

Animațiile Lottie sunt similare. Fișierele de animație în sine pot fi ușoare, dar agențiile uploadează frecvent versiuni neoptimizate care ajung la 1-5 MB. Librăria player Lottie mai adaugă 60-300 KB pe deasupra.

Librărie	Folosit pentru	Ce descarcă vizitatorul tău
GSAP + ScrollTrigger	O animație la scroll	400-500 KB pe orice pagină
Lottie	O iconiță animată	Player 60-300 KB + fișier animație până la 5 MB
AOS	Un singur fade-in	17 KB pe orice pagină, inclusiv cele fără animații

Un site bine construit încarcă codul de animație doar pe paginile și elementele care îl folosesc efectiv. Cele mai multe site-uri nu fac asta, pentru că necesită decizii deliberate în etapa de development care nu sunt niciodată luate.

Cauza 4: Ecranul alb de 3 secunde pe care nimeni nu ți l-a explicat

Asta e problema cea mai invizibilă și adesea cea mai dăunătoare pe mobil.

Unele site-uri, în special cele construite cu framework-uri JavaScript moderne configurate neglijent sau generate de tool-uri AI, trimit browserului vizitatorului o pagină aproape goală la prima accesare. Niciun conținut, nicio imagine, niciun titlu. Doar un script de încărcare. Browserul descarcă acel script, îl parsează, îl execută, face cereri suplimentare pentru a prelua conținutul real, și abia apoi construiește pagina de la zero. Pe un Android de gamă medie pe 4G, procesul durează 2-4 secunde. Vizitatorul vede un ecran alb tot timpul.

Un site bine construit funcționează diferit. Serverul trimite o pagină completă: titlu, imagine, navigație, conținut lizibil. Vizitatorul vede ceva real în prima secundă. JavaScript se încarcă în fundal și adaugă interactivitate, dar omul citește deja. Nu există ecran alb.

Acel 53% din utilizatori care abandonează se aplică direct aici. Dacă pagina durează mai mult de 3 secunde să afișeze ceva, mai mult de jumătate din vizitatorii tăi pe mobil sunt deja plecați. Nu pentru că conexiunea a fost slabă. Pentru că site-ul a fost construit astfel încât telefonul să facă munca pe care trebuia să o facă serverul.

Abordare	Ce vede vizitatorul la secunda 1	Ce se întâmplă după
Site bine construit	Conținut complet al paginii	JavaScript se încarcă liniștit în fundal
Site modern configurat prost	Ecran alb	Browserul descarcă, parsează și execută JS înainte să afișeze ceva

Cele mai multe site-uri construite cu page buildere drag-and-drop sau generate de AI implicit folosesc a doua abordare. Arată instant pe fibra din demo. Pe 4G, nu arată la fel.

Dacă vrei un site construit corect din start, fără greșeli tehnice și fără surprize, putem discuta. Consultația e gratuită și fără niciun angajament. Scrie-ne la office@uvio.ro sau pe Telegram la @uviodigital.

Întrebări frecvente

Cât de repede trebuie să se încarce un site pe mobil? Pragul Google e clar: conținutul principal trebuie să apară în sub 2,5 secunde pentru a trece testul LCP din Core Web Vitals. Peste 4 secunde, pici și asta îți afectează poziția în căutări. Ține-te sub 2 secunde pentru a avea marjă.

Pot să repar viteza site-ului fără să refac tot? Uneori da. Imaginile și anumite probleme de JavaScript se pot rezolva fără să atingi structura site-ului. Dacă problema fundamentală e o platformă cu defaults grele sau o arhitectură care construiește pagina în browser în loc de server, un patch nu te duce departe. Un diagnostic corect îți spune în care categorie ești înainte să cheltuiești bani.

Afectează viteza site-ului scorul meu în Google Ads? Da, direct. Landing Page Experience e una din cele trei componente care formează Quality Score. O pagină lentă pe mobil îți scade scorul, ceea ce îți crește costul pe click. Poți pierde bani pe reclame nu pentru că targetarea e greșită, ci pentru că pagina se încarcă greu după click.

Cât costă să repari un site lent pe mobil? Depinde de cauză. Compresia imaginilor și trecerea la WebP pot reduce greutatea paginii de până la 10 ori și sunt de obicei rapide și ieftine. Repararea unui site construit pe o arhitectură care nu a fost proiectată pentru performanță pe mobil înseamnă adesea reconstruirea acelor componente. Costul de a nu repara se acumulează în fiecare lună prin buget de reclame risipit și conversii pierdute.

Cum îmi dau seama care e problema? Începe cu PageSpeed Insights. Rulează homepage-ul și paginile tale principale de destinație. Tool-ul îți arată scorul, semnalează problemele specifice și le prioritizează după impact. Pentru o citire detaliată a ce înseamnă acele rezultate pentru site-ul tău concret, merită o discuție cu cineva care poate interpreta raportul.

Dacă scorul tău pe mobil e sub 50, problema e în felul în care a fost construit site-ul. Asta se poate schimba.