Luna trecuta am preluat un site cu scor Lighthouse de 34. Se incarca in 7.2 secunde pe mobil. Dupa o zi de optimizari, scorul era 96. Incarcare sub 0.9 secunde.
Nu am rescris nimic de la zero. Am aplicat aceleasi 6 optimizari pe care le facem pe fiecare proiect. Si nu e vorba de trucuri tehnice ascunse — e vorba de lucruri pe care orice site ar trebui sa le aiba din prima zi.
Daca ai un site care se incarca greu, pierzi vizitatori, pierzi clienti si pierzi pozitii in Google. In articolul asta iti arat exact ce am facut si cum poti aplica aceleasi lucruri.
Raspuns scurt
Un site rapid inseamna imagini in WebP cu lazy loading, fonturi optimizate cu font-display swap, JavaScript taiat la minimum prin code splitting, CDN pentru fisiere statice, server-side rendering in loc de SPA si compresie brotli/gzip activata. Aceste 6 optimizari au transformat un site cu Lighthouse 34 si 7.2 secunde pe mobil in Lighthouse 96 si 0.9 secunde. Niciuna nu a durat mai mult de o ora. Impreuna, diferenta e enorma.
Pentru cine este acest articol
- Antreprenori al caror site se incarca in mai mult de 3 secunde pe mobil
- Proprietari de e-commerce care pierd conversii din cauza vitezei
- Dezvoltatori care vor un checklist practic de optimizare a performantei
- Oricine are un scor Lighthouse sub 70 si nu stie de unde sa inceapa
De unde vine problema
Majoritatea site-urilor lente nu au o singura problema mare. Au 10 probleme mici care se aduna. Imagini prea mari, fonturi prea multe, JavaScript prea greu, lipsa cache-ului, lipsa CDN-ului. Fiecare adauga 500ms-1s. Rezultatul: un site care se incarca in 5-7 secunde si pierde jumatate din vizitatori.
Fiecare secunda de incarcare in plus scade conversiile cu aproximativ 7%. Un site de 7 secunde pierde peste jumatate din vizitatori inainte sa vada prima linie de text. Am explicat impactul complet in cat te costa viteza lenta a site-ului.
1. Imaginile — de unde pierzi cel mai mult
Pe site-ul pe care l-am preluat, prima pagina avea 4.2 MB de imagini. Un hero banner de 2.8 MB in JPEG. Fotografii de produs la rezolutie 4000x3000 afisate la 400x300.
Ce am facut:
Convertit totul in WebP — de la 2.8 MB la 180 KB pentru acelasi hero banner, cu calitate vizuala identica. Diferenta de incarcare: 3 secunde. WebP e suportat de toate browserele moderne si comprima de 3-5 ori mai bine decat JPEG.
Responsive sizes. Nu servesti aceeasi imagine de 2000px si pe desktop si pe mobil. Cu atributul `srcset` ii spui browserului: pe ecran mic, ia varianta de 600px. Pe desktop, ia varianta de 1200px.
Lazy loading. Imaginile de sub fold nu se incarca pana nu scrollezi catre ele. Un singur atribut: `loading="lazy"`. Gratuit, nativ in browser, zero JavaScript.
Rezultat dupa imaginile optimizate: de la 4.2 MB la 320 KB. Prima pagina.
2. Fonturile — ucigasul invizibil
Site-ul incarca 4 variante de Google Fonts. Regular, bold, italic, bold-italic. Fiecare varianta e un request HTTP separat care blocheaza renderingul. Utilizatorul vede un ecran gol pana se descarca fonturile.
Doua schimbari:
`font-display: swap` — browserul afiseaza textul imediat cu un font de sistem, apoi il inlocuieste cand fontul custom se incarca. Utilizatorul nu mai asteapta.
Preload fontul principal. Un singur `` in `
` pentru varianta Regular. Browserul stie din prima secunda ca are nevoie de el. Restul variantelor le incarca lazy.Am redus fonturile de la 4 la 2 variante. Regular si Bold. Italic l-am simulat cu CSS. Nimeni nu a observat diferenta vizual. Dar pagina s-a incarcat cu 400ms mai repede.
---
Vrei sa vezi cum sta site-ul tau? Trimite-ne link-ul — primesti audit de performanta gratuit, cu scor actual, probleme principale si recomandari concrete. Programeaza o discutie de 30 minute sau trimite-ne un mesaj.
---
3. JavaScript — mai putin inseamna mai rapid
Bundle-ul JavaScript era 680 KB. Am analizat cu `source-map-explorer`. Rezultatul: 40% din bundle era o librarie de charting pe care o foloseau pe o singura pagina. 15% era moment.js — 72 KB pentru a formata o data.
Code splitting. Libraria de charting se incarca doar pe pagina care o foloseste. Nu pe homepage.
Inlocuit moment.js cu date-fns. De la 72 KB la 3 KB pentru formatarea unei date.
Eliminat jQuery. Site-ul il incarca pentru un singur efect de smooth scroll. Am inlocuit cu 3 linii de JavaScript vanilla: `element.scrollIntoView({ behavior: 'smooth' })`.
Bundle final: de la 680 KB la 140 KB. Minus 80%. Aceeasi mentalitate de "mai putin, mai bine" am aplicat-o si cand am explicat de ce nu folosim WordPress — fiecare kilobyte in plus e un cost pentru utilizator.
4. CDN — serveste de aproape
Fisierele statice (imagini, CSS, JS, fonturi) le servim prin Cloudflare. Gratuit. Utilizatorul din Bucuresti primeste fisierele de la un server din Bucuresti, nu de la unul din Frankfurt.
Diferenta masurabila: TTFB (Time to First Byte) scazut de la 320ms la 45ms pentru utilizatori din Romania.
Setarea dureaza 10 minute. Schimbi nameserver-ele domeniului la Cloudflare si activezi proxy-ul. Atat.
5. Server-Side Rendering vs Client-Side
Site-ul original era un SPA (Single Page Application). Browserul descarca JavaScript-ul, il executa, apoi face request-uri API, apoi randeaza pagina. Utilizatorul vede continut dupa 3-4 secunde.
Am mutat la server-side rendering. Serverul genereaza HTML-ul complet si il trimite direct. Browserul il afiseaza imediat. JavaScript-ul se incarca in background pentru interactivitate. Aceasta schimbare de arhitectura e si o parte din motivul pentru care am reusit sa reducem costurile de hosting cu 80%.
First Contentful Paint a scazut de la 2.8 secunde la 0.4 secunde. Utilizatorul vede ceva util aproape instant.
Pentru site-uri de prezentare si bloguri, mergem si mai departe — generare statica la build time. Pagina e un fisier HTML gata facut. Serverul doar il trimite. Zero procesare.
6. Micile detalii care conteaza
Compresia. nginx cu gzip sau brotli activat. Un fisier CSS de 45 KB devine 8 KB in transfer. Setare de 2 linii in config.
Cache headers. Fisierele cu hash in nume (style.a1b2c3.css) primesc `Cache-Control: immutable, max-age=31536000`. Browserul nu le mai cere niciodata a doua oara.
Preconnect. Daca faci request-uri catre domenii externe (Google Fonts, analytics, API-uri), un `` in head salveaza 100-200ms per domeniu.
Rezultate concrete
| Metrica | Inainte | Dupa | Diferenta |
|---------|---------|------|-----------|
| Lighthouse Performance | 34 | 96 | +62 puncte |
| First Contentful Paint | 2.8s | 0.4s | -2.4s |
| Total page weight | 5.1 MB | 480 KB | -90% |
| JS bundle size | 680 KB | 140 KB | -80% |
| TTFB | 320ms | 45ms | -86% |
| Incarcare completa mobil | 7.2s | 0.9s | -88% |
Fiecare optimizare e simpla individual. Niciuna nu a durat mai mult de o ora. Dar impreuna transforma un site lent intr-unul rapid.
Checklist rapid
- [ ] Imaginile sunt in WebP/AVIF, nu JPEG/PNG
- [ ] Imaginile au srcset cu dimensiuni responsive
- [ ] Imaginile sub fold au loading="lazy"
- [ ] Fonturile au font-display: swap
- [ ] Fontul principal are preload in head
- [ ] JavaScript-ul e sub 200 KB (bundle principal)
- [ ] CDN activ pentru fisiere statice
- [ ] Compresie brotli/gzip activata pe server
- [ ] Cache headers configurate pe fisierele cu hash
Cand merita sa optimizezi viteza
Merita:
- Scorul Lighthouse e sub 70
- Pagina se incarca in peste 3 secunde pe mobil
- Ai bounce rate mare pe pagini de landing
- Vinzi online si pierzi conversii
- Ai trafic organic dar oamenii pleaca repede
Nu merita (inca):
- Site-ul abia a fost lansat si nu are trafic
- Scorul Lighthouse e deja peste 90
- Problema reala nu e viteza, ci lipsa continutului sau a ofertei
- Vrei sa rescrii totul de la zero doar pentru viteza (optimizeaza intai ce ai)
Obiectii frecvente
"Dar site-ul meu e pe WordPress, nu se poate optimiza."
Se poate, dar cu limite. Cu caching agresiv, CDN si imagini optimizate ajungi la 1.5-2 secunde. Sub 1 secunda pe WordPress e extrem de dificil fara generare statica. Daca ai nevoie de viteza sub 1 secunda, mergi pe o arhitectura fara WordPress.
"Am incercat sa optimizez, dar nu s-a schimbat nimic."
De obicei inseamna ca ai optimizat ceva minor (minificare CSS) si ai ignorat elefantul din camera (imagini de 4 MB sau JavaScript de 700 KB). Incepe cu cele mai mari fisiere — acolo e impactul.
"Nu merita efortul, oricum nu am trafic."
Viteza e un factor de ranking in Google. Un site lent nu va primi trafic organic. E un cerc vicios: nu ai trafic pentru ca esti lent, esti lent pentru ca nu ti se pare ca merita. Repara viteza si SEO-ul incepe sa functioneze.
"Costa prea mult sa optimizez."
Optimizarile de baza (imagini, fonturi, compresie) se fac in cateva ore. Majoritatea sunt gratuite — WebP, lazy loading, font-display swap. Investitia serioasa apare doar daca trebuie schimbata arhitectura (de la SPA la SSR).
Intrebari frecvente
Cat de rapid ar trebui sa se incarce un site in 2026?
Sub 2 secunde pe mobil e minimul acceptabil. Sub 1 secunda e tinta pentru site-uri de prezentare si e-commerce. Google foloseste viteza ca factor de ranking, iar utilizatorii parasesc site-urile care se incarca in mai mult de 3 secunde.
Ce scor Lighthouse e considerat bun?
Peste 90 e bun. Peste 95 e excelent. Sub 50 inseamna probleme serioase. Majoritatea site-urilor romanesti au scoruri intre 30 si 60. Un scor de 90+ e realizabil pentru orice site cu optimizarile din acest articol.
Cat costa optimizarea vitezei unui site?
Depinde de starea curenta. Optimizarile de baza (imagini, fonturi, compresie) se fac in 1-2 zile si costa intre 500 si 1.000 EUR. O refacere completa a arhitecturii (migrare de la SPA la SSR, eliminare framework-uri grele) poate dura 1-2 saptamani si costa 2.000-4.000 EUR.
Pot optimiza un site WordPress sa se incarce sub 1 secunda?
Teoretic da, dar in practica e foarte dificil. WordPress vine cu overhead structural (PHP, baza de date la fiecare request, plugin-uri). Cu caching agresiv, CDN si optimizare de imagini poti ajunge la 1.5-2 secunde. Sub 1 secunda necesita de obicei migrarea la generare statica.
Ce e LCP si de ce conteaza?
LCP (Largest Contentful Paint) masoara cat dureaza pana se incarca cel mai mare element vizibil din viewport — de obicei un hero image sau un heading mare. E una din cele 3 metrici Core Web Vitals pe care Google le foloseste pentru ranking. Tinta: sub 2.5 secunde.
Merita sa refac site-ul de la zero pentru viteza?
Doar daca site-ul actual e construit pe o arhitectura fundamental gresita (SPA greu fara SSR, WordPress cu 20+ plugin-uri). Daca problema e doar imagini neoptimizate si lipsa cache-ului, optimizarile punctuale sunt suficiente si mult mai ieftine.
Cum masor viteza site-ului meu?
Trei instrumente gratuite: Google Lighthouse (in Chrome DevTools), PageSpeed Insights (online, de la Google) si WebPageTest (testare avansata cu locatii multiple). Testeaza pe mobil, nu pe desktop — acolo e standardul Google.
Urmatorul pas
Nu ai timp sa faci toate optimizarile singur? E normal — sunt multe si unele sunt tehnice.
Trimite-ne link-ul site-ului tau si primesti un audit de performanta gratuit — cu scor actual, probleme principale si recomandari concrete.
Programeaza o discutie de 30 minute sau trimite-ne un mesaj prin formularul de contact.
Daca scorul e deja bun, iti spunem. Daca nu, iti aratam exact ce trebuie reparat si cat dureaza.