Ai primit un raport cu un scor roșu, sau un client ți-a spus că site-ul „merge greu pe telefon”. Deschizi pagina pe laptop, se încarcă imediat, și nu înțelegi despre ce e vorba. Între timp cineva îți propune un plugin, altcineva un hosting mai scump, iar un al treilea spune că e nevoie de un site nou.
Problema nu e că nu te pricepi la programare. Problema e că „viteză” înseamnă mai multe lucruri, măsurate în feluri diferite, iar cei care îți vând soluții rareori spun la care se referă. Fără un vocabular comun nu poți cere ceva concret și nu poți verifica dacă ai primit ce ai plătit.
Mai jos găsești ce măsoară Google de fapt, de ce raportul pe desktop nu spune nimic despre telefonul unui client, ce strică de obicei viteza și miturile pe care le auzi cel mai des.
Ce măsoară Google când spune că un site e lent
Google folosește pentru poziționare trei măsurători, grupate sub numele Core Web Vitals. Fiecare răspunde la o întrebare pe care și-o pune orice vizitator.
LCP: cât aștept până văd ce am venit să văd
Largest Contentful Paint măsoară timpul până când apare cel mai mare element vizibil din prima porțiune a paginii: de obicei imaginea principală, un titlu mare sau un bloc de text. Nu contează când s-a încărcat tot site-ul, ci când omul vede conținutul pentru care a dat click. Pragul „bun” este sub 2,5 secunde.
INP: cât de repede răspunde pagina când apăs ceva
Interaction to Next Paint măsoară întârzierea dintre o apăsare (pe un buton, un meniu, un câmp de formular) și momentul în care ecranul reacționează vizibil. Dacă apeși „Adaugă în coș” și nu se întâmplă nimic timp de o secundă, asta e INP prost. Pragul „bun” este sub 200 de milisecunde. INP a înlocuit vechea măsurătoare FID în martie 2024, pentru că FID se uita doar la prima apăsare, iar INP la toate.
CLS: cât sare pagina în timp ce se încarcă
Cumulative Layout Shift măsoară cât se mișcă elementele pe ecran după ce au apărut. Exemplul clasic: vrei să apeși un link, se încarcă un banner deasupra, totul coboară și apeși altceva. Valoarea nu e în secunde, ci un număr care adună toate săriturile. Pragul „bun” este sub 0,1.
| Măsurătoare | Ce simte vizitatorul | Prag „bun” |
|---|---|---|
| LCP | Cât așteaptă până vede conținutul principal | sub 2,5 secunde |
| INP | Cât de repede răspunde pagina la apăsări | sub 200 de milisecunde |
| CLS | Cât sare pagina în timpul încărcării | sub 0,1 |
Laborator sau teren: de ce două rapoarte pe același site nu se potrivesc
Când deschizi PageSpeed Insights, primești două seturi de date pentru aceeași adresă, și ele spun lucruri diferite.
Datele de teren sunt în partea de sus a raportului. Vin din Chrome User Experience Report (CrUX): valorile reale, măsurate pe dispozitivele vizitatorilor tăi din ultimele 28 de zile. Acestea sunt datele pe care Google le folosește pentru poziționare. Dacă site-ul are prea puțin trafic, secțiunea lipsește.
Datele de laborator sunt mai jos, cu scorul de la 0 la 100. Vin din Lighthouse, un test rulat o singură dată, pe un dispozitiv simulat, cu o conexiune încetinită artificial. E util ca diagnostic, pentru că îți spune concret ce blochează pagina. Dar e un singur test, într-un singur moment, pe o mașină care nu e a niciunui client de-al tău.
Un scor de 100 în laborator pe desktop nu spune nimic despre telefonul unui client pe 4G. Poți avea 100 pe desktop și datele de teren pe mobil roșii la toate cele trei valori. Când cineva îți arată un scor, întreabă: laborator sau teren, și pe ce dispozitiv.
De ce mobilul e singurul raport care contează cu adevărat
Google indexează versiunea mobilă a site-ului tău. Când evaluează viteza, se uită la ce se întâmplă pe telefon, nu pe laptopul din birou.
Și pe telefon lucrurile stau altfel. Procesorul e mai slab, conexiunea mai instabilă. Cel mai mult suferă JavaScriptul: același cod pe care laptopul îl rulează într-o clipă costă de câteva ori mai mult timp pe un telefon obișnuit. De aceea un site care pare în regulă pe desktop poate pica INP-ul pe mobil, fără ca nimeni din firmă să observe.
Ce strică viteza de obicei, în ordinea impactului
Nu există o rețetă universală, dar în practică aceleași cauze se repetă, cam în aceeași ordine.
1. Imaginile: prea mari, în format vechi, încărcate toate deodată
Cea mai frecventă cauză de LCP prost. O fotografie de 4.000 de pixeli lățime, afișată într-un spațiu de 800, este descărcată întreagă. Formatele moderne, WebP sau AVIF, dau aceeași imagine la o fracțiune din dimensiune. Imaginile de sub prima vizualizare ar trebui încărcate leneș (lazy loading), doar când vizitatorul ajunge la ele. Atenție la o greșeală comună: imaginea principală, cea care determină LCP, nu trebuie încărcată leneș. Ea trebuie să pornească prima.
2. JavaScript prea mult, încărcat prea devreme
Aici se pierde INP-ul și o parte din LCP. Sursele obișnuite: page builderele (constructorii vizuali de pagini) care încarcă tot arsenalul lor pe fiecare pagină, scripturile de marketing (pixeli, tag manager, hărți de căldură) și ferestrele de chat. Fiecare pare mic. Împreună, pe un telefon, blochează pagina secunde întregi. Rezolvarea nu e neapărat să le scoți, ci să le încarci după ce pagina e utilizabilă, și doar acolo unde sunt folosite.
3. Fonturile
Mai multe familii de fonturi, fiecare în mai multe grosimi, înseamnă zeci de fișiere. Textul apare târziu sau apare cu un font, apoi se schimbă cu altul și pagina sare. Contează numărul de fonturi, dacă fontul principal e anunțat din timp (preload) și cum e setat font-display, adică ce face browserul cât timp fontul încă nu a sosit.
4. Timpul de răspuns al serverului
TTFB (Time to First Byte) este cât durează până serverul trimite primul octet din pagină. Dacă e mare, tot ce urmează pornește cu întârziere. Aici ajută cache-ul de pagină (pagina e servită gata construită, nu generată la fiecare vizită), un hosting dimensionat corect și o bază de date curată. Este singura zonă unde hostingul chiar contează.
5. CSS care blochează afișarea
Browserul nu desenează nimic până nu primește stilurile. Dacă tema încarcă un fișier CSS uriaș pentru toate paginile, vizitatorul așteaptă după reguli de care pagina lui nu are nevoie. Soluția obișnuită: stilurile pentru prima porțiune a paginii puse direct în ea, restul încărcat după.
6. Elementele care sar
CLS-ul vine aproape întotdeauna din trei locuri: imagini fără lățime și înălțime declarate, bannere sau bare de consimțământ inserate după încărcare, care împing conținutul, și fonturi care se schimbă din mers. Sunt reparații ieftine, dar trebuie făcute pe fiecare tip de pagină.
Dacă vrei să vezi cum arată această ordine aplicată pe un site WordPress întreținut lunar, pagina despre performanța site-urilor WordPress descrie exact aceste etape.
Miturile pe care le auzi cel mai des
„Scorul 100 e obligatoriu.” Nu. Scorul e din laborator, iar Google folosește terenul. Un site cu scor 78 în laborator și toate valorile de teren verzi pe mobil este în regulă. Unul cu 100 pe desktop și teren roșu pe mobil nu este.
„Un plugin de cache rezolvă tot.” Cache-ul de pagină ajută la TTFB, pentru că serverul nu mai construiește pagina la fiecare vizită. Nu reduce însă niciun octet de JavaScript și nu micșorează nicio imagine. Dacă problema e INP-ul, cache-ul nu o atinge.
„CDN-ul face site-ul rapid.” Un CDN apropie fișierele de vizitator, deci ajută la distanță. Nu ajută la greutate. O pagină de 6 MB rămâne o pagină de 6 MB, doar că vine de mai aproape.
„E vina hostingului.” Uneori, da: un TTFB de câteva secunde e o problemă de server. De cele mai multe ori însă serverul răspunde rezonabil, iar restul timpului se pierde în pagină, pe telefonul vizitatorului. Un hosting mai scump nu schimbă asta.
„Mai multe plugin-uri de optimizare înseamnă mai bine.” Două plugin-uri care amână același JavaScript sau minifică același CSS se calcă în picioare. Rezultatul e des mai lent decât fără niciunul. Un singur instrument, configurat cu grijă, bate trei instalate la întâmplare.
Când un furnizor îți promite „scor 100”, întreabă pe ce dispozitiv, în laborator sau în teren, și pe care pagini. Un scor de laborator pe prima pagină, pe desktop, se obține ușor și nu îți aduce nimic. Pragurile de teren, pe mobil, pe paginile de produs sau de contact, sunt lucrul care contează.
Cum măsori corect, fără să fii programator
Ai nevoie de trei surse, și niciuna nu costă.
PageSpeed Insights, rulat pe paginile importante, nu doar pe prima pagină: pagina de produs, pagina de categorie, formularul de contact, articolul cel mai citit. Notează cele trei valori de teren pe mobil pentru fiecare.
Search Console, raportul Core Web Vitals. Îți arată, pe grupuri de pagini, câte adrese sunt „bune”, „necesită îmbunătățiri” sau „slabe”, tot din date de teren. E singurul loc în care vezi întreg site-ul, nu o pagină pe rând.
Un telefon real, pe date mobile. Ieși din biroul cu Wi-Fi, deschizi site-ul pe 4G, cronometrezi până vezi conținutul și apeși pe un buton. Nu e o măsurătoare științifică, dar e cea mai apropiată de ce simte un client.
Dacă vrei o primă privire rapidă peste viteză, securitate și SEO la un loc, unealta de verificare a site-ului îți dă un punct de plecare în câteva minute.
Ce să ceri de la cine îți întreține site-ul
Nu cere „un site rapid” și nu cere „scor 100”, pentru că primești ce e ușor de livrat. Cere:
- cele trei valori de teren, pe mobil, sub praguri (LCP sub 2,5 s, INP sub 200 ms, CLS sub 0,1);
- pe paginile care aduc bani: produs, categorie, coș, contact, cele mai citite articole;
- verificate în Search Console, nu într-un singur test de laborator;
- cu o listă a ce s-a schimbat, ca să știi ce se păstrează la următoarea modificare de design.
Viteza nu se repară o dată. Fiecare plugin nou, fiecare banner de campanie, fiecare imagine urcată fără comprimare o roade puțin. Datele de teren se recalculează pe ultimele 28 de zile, deci o problemă introdusă azi apare în raport peste câteva săptămâni. Valorile merită verificate lunar, nu doar când se plânge cineva.
Lista de verificare
- Rulează PageSpeed Insights pe 3-5 pagini importante, nu doar pe prima pagină.
- Citește secțiunea de teren, pe mobil; ignoră scorul din laborator la prima trecere.
- Notează LCP, INP și CLS pentru fiecare pagină și compară cu pragurile: 2,5 s, 200 ms, 0,1.
- Deschide raportul Core Web Vitals din Search Console și vezi câte adrese sunt „slabe”.
- Verifică imaginea principală a fiecărei pagini: format modern, dimensiune potrivită, fără încărcare leneșă.
- Fă lista scripturilor de marketing și chat și întreabă care sunt folosite cu adevărat.
- Numără fonturile încărcate; mai mult de două familii merită o discuție.
- Verifică TTFB-ul; dacă e mare pe toate paginile, abia atunci discută despre hosting.
- Asigură-te că ai un singur plugin de optimizare, nu trei.
- Testează pe un telefon real, pe date mobile, o pagină de produs sau de contact.
- Pune în calendar o verificare lunară a valorilor de teren.
Deschide PageSpeed Insights, introdu adresa paginii care îți aduce cei mai mulți clienți (nu prima pagină, ci pagina de produs, de serviciu sau de contact) și notează cele trei valori de teren pe mobil: LCP, INP și CLS. Ai acum un punct de plecare pe care îl poți compara peste o lună, indiferent cine se ocupă de site.