Un scor PageSpeed mai mare nu intră în contul firmei. Oamenii intră. Ei trebuie să vadă produsul, să poată folosi filtrul, să adauge în coș și să finalizeze fără ca interfața să înghețe sau să se mute sub deget. Viteza pe mobil afectează conversia prin aceste momente concrete, nu prin culoarea unui cadran dintr-un instrument.
De aceea nu există o regulă credibilă de forma „fiecare secundă înseamnă exact X% conversii pierdute” pentru orice site. Relația depinde de intenția traficului, dispozitiv, rețea, pagină, preț și obstacolul întâlnit. Un vizitator poate accepta trei secunde pentru o comparație complexă, dar poate abandona un buton de plată care nu răspunde nici după o jumătate de secundă. Invers, un homepage rapid nu salvează un checkout lent.
Scopul este să localizezi întârzierea în traseul comercial, să o repari și să verifici dacă schimbarea produce mai multe acțiuni utile. Asta leagă munca tehnică de optimizarea conversiilor, iar măsurarea pe utilizatori reali o leagă de serviciul de măsurare. Pornim de la experiență, nu de la promisiuni de benchmark.
Viteza mobilă este o succesiune de momente, nu un scor unic
„Se încarcă în trei secunde” este o descriere incompletă. Prima parte a paginii poate apărea repede, imaginea principală poate veni târziu, iar butoanele pot rămâne blocate de JavaScript. O pagină poate părea gata și totuși să răspundă lent la prima căutare. Alta poate afișa imediat conținutul, apoi un banner împinge butonul exact când utilizatorul îl atinge.
Descompune experiența în patru întrebări:
- Când apare ceva care îi confirmă utilizatorului că a ajuns unde trebuie?
- Când este vizibil conținutul principal pentru decizie?
- Cât durează până când o atingere produce feedback vizual?
- Rămâne interfața stabilă în timp ce se încarcă resurse și apar elemente noi?
Core Web Vitals oferă trei repere pentru ultimele trei întrebări. Documentația web.dev definește LCP, INP și CLS ca metrici pentru încărcarea conținutului principal, răspunsul la interacțiuni și stabilitatea vizuală. Ele nu măsoară însă valoarea ofertei, claritatea mesajului, încrederea sau funcționarea procesatorului de plăți. De aceea un site poate trece toate pragurile și totuși converti slab.
Pe mobil, aceeași pagină rulează pe procesoare, memorie și conexiuni foarte diferite. Nu testa doar pe telefonul nou al echipei, conectat la Wi-Fi-ul biroului. Include dispozitive medii sau slabe, rețea limitată, cache gol și trasee reale: landing page din reclamă, categorie, produs, coș și checkout. Păstrează desktopul separat; media celor două ascunde exact publicul pe care vrei să îl repari.
Cercetarea din 2021 a Universității Transilvania din Brașov a evaluat pe smartphone 16 magazine certificate din România, nu doar homepage-ul, ci și punctele intermediare până la coș. Rezultatul relevant pentru metodă este variația între touchpointuri: performanța unei pagini nu descrie întregul parcurs. Studiul este vechi și are un eșantion pilot, deci nu îl folosim ca benchmark al pieței din 2026; îl folosim ca dovadă că trebuie măsurat traseul.
Datele din teren răspund la „ce trăiesc oamenii”; laboratorul răspunde la „de ce”
PageSpeed Insights poate afișa două familii de date. Datele din teren provin din experiențe reale agregate, când URL-ul sau originea are suficient trafic eligibil. Datele de laborator provin dintr-un test controlat rulat la cerere. Dacă nu le separi, poți celebra un test verde în timp ce utilizatorii reali continuă să primească o experiență slabă.
Chrome UX Report, prescurtat CrUX, raportează date reale agregate pentru LCP, INP și CLS și poate fi interogat pe tipul de dispozitiv. Setul public nu include toate site-urile și toate URL-urile; paginile cu trafic redus pot să nu aibă date. În plus, fereastra CrUX este o medie mobilă de 28 de zile, actualizată zilnic. O remediere lansată astăzi nu va schimba instantaneu indicatorul agregat.
Laboratorul este bun pentru reproducere. Rulezi aceeași pagină în condiții apropiate, citești waterfall-ul, identifici resurse care blochează randarea, taskuri lungi, imagini prea mari și mutări de layout. Poți compara înainte și după, dar un singur run este sensibil la variații. Fă mai multe rulări, păstrează mediana și notează configurația.
Datele de teren sunt bune pentru prioritate și impact. Instalează Real User Monitoring, dacă este justificat, și trimite metricile împreună cu tipul paginii, dispozitivul, țara sau regiunea, sursa de trafic și etapa traseului. Nu trimite email, telefon, termeni de căutare sensibili sau alte date personale în câmpuri tehnice. Pentru un site cu volum suficient, raportează percentile și distribuții, nu doar media.
Fluxul recomandat de web.dev începe cu experiența utilizatorilor reali și folosește laboratorul pentru diagnostic. Acolo PageSpeed Insights este descris cu date CrUX pe ultimele 28 de zile, la percentila 75. Aceasta este și explicația unei diferențe aparent ciudate: poți repara complet un caz de laborator fără să muți imediat percentila din teren, sau poți avea un laborator verde care nu reproduce o interacțiune rară, dar costisitoare.
Compară cel puțin aceste vizualizări: URL versus origine, mobil versus desktop, pagină de intrare versus pagină internă și perioada dinainte versus după release. Dacă URL-ul de produs este slab, iar originea pare bună, nu încheia proiectul pe baza scorului agregat. Dacă doar traficul din reclame are LCP mare, verifică landing page-ul, parametrii, scripturile de tracking și cache-ul rece.
LCP, INP și CLS devin utile când le legi de un gest comercial
Largest Contentful Paint (LCP) estimează momentul în care cel mai mare bloc de text, imagine sau video vizibil în viewport a fost randat. Pragul „bun” recomandat este cel mult 2,5 secunde la percentila 75; peste 4 secunde este „slab”. Explicația oficială a LCP amintește că valoarea din teren include și timpul de la navigare, conexiunea, redirecturile și TTFB. Nu spune automat că imaginea este de vină.
În traseu, LCP poate fi fotografia și numele produsului, titlul unei pagini de serviciu sau blocul principal al unei categorii. Dacă acestea apar târziu, utilizatorul nu poate confirma rapid că reclama și pagina se potrivesc. Măsoară rata de continuare după landing page, vizualizarea produsului și accesarea unei categorii, segmentate după LCP. Nu concluziona cauzalitate doar pentru că grupul lent convertește mai slab: conexiunile și dispozitivele slabe pot fi asociate și cu alte diferențe.
LCP are patru componente care cer remedii diferite: TTFB, întârzierea până la descoperirea resursei LCP, durata descărcării ei și întârzierea de randare. Ghidul de optimizare LCP avertizează că simpla compresie a unei imagini poate muta timpul economisit în întârzierea de randare, fără un câștig final. Waterfall-ul decide dacă lucrezi la server, markup, prioritate, fișier sau codul care ascunde elementul.
Interaction to Next Paint (INP) măsoară timpul de la o atingere, un click sau o apăsare de tastă până la următorul update vizual pentru interacțiunile paginii. Pragul bun este cel mult 200 milisecunde la percentila 75; peste 500 milisecunde este slab. Într-un magazin, INP se vede când deschizi meniul, aplici filtrul, selectezi varianta, schimbi cantitatea sau apeși „Adaugă în coș”. În servicii, apare la calculator, formular ori selector de programare.
Un INP slab poate produce apăsări repetate, adăugări duble sau impresia că funcția nu merge. Transcriptul Chrome arată situația în care utilizatorul apasă din nou meniul fiindcă prima acțiune nu a oferit feedback, iar a doua îl închide. Leagă INP de rata de succes a acelei acțiuni, erori, rage clicks și progresul către pasul următor. Dacă filtrul are INP mare, dar checkoutul nu, prioritatea este categoria, nu serverul de plată.
Cumulative Layout Shift (CLS) măsoară mutările neașteptate ale elementelor vizibile. Pragul bun este cel mult 0,1 la percentila 75, iar peste 0,25 este slab. Un banner de cookie, un font, o imagine fără dimensiuni sau o recomandare injectată poate împinge butonul de sub deget. Pe mobil, spațiul mic face mutarea mai vizibilă și poate transforma intenția într-un click greșit.
Nu orice mișcare este rea. O secțiune deschisă imediat după atingerea utilizatorului este așteptată. Problema este conținutul care apare târziu și deplasează acțiuni deja vizibile. Urmărește CLS pe paginile cu reclame, bannere, carusele, recenzii și widgeturi de chat. În laborator, interacționează și derulează; unele deplasări nu apar la încărcarea inițială.
Localizează pierderea pe șablon, segment și etapă
Începe cu o matrice, nu cu o listă de pluginuri. Pe rânduri pui șabloanele: landing, categorie, produs, articol, coș, checkout. Pe coloane pui LCP, INP, CLS, rata către pasul următor, erorile și valoarea sesiunilor afectate. Adaugi filtre pentru mobil, browser, sistem de operare, sursă și conexiune. Astfel vezi unde performanța și pierderea comercială se întâlnesc.
Pentru fiecare celulă notează patru elemente: percentila 75, proporția experiențelor bune, volumul și evenimentul comercial. Un LCP slab pe o pagină rară poate avea impact mic. Un INP moderat pe selectorul de variante al celor mai vândute produse poate afecta mult mai mult venit. Prioritizează volum afectat × pierdere observată × încredere / efort.
Construiește cohorte de performanță: bun, necesită îmbunătățire și slab, folosind pragurile oficiale. Compară rata de trecere către pasul următor, nu doar rata finală de cumpărare. Pentru produs măsori view_item → add_to_cart; pentru categorie, view_item_list → select_item; pentru coș, view_cart → begin_checkout. Păstrează aceeași fereastră, excluderi și definiții.
Analiza este observațională. Utilizatorii cu telefon vechi sau rețea slabă pot avea altă intenție, altă zonă geografică și altă putere de cumpărare. Nu spune „LCP a cauzat diferența” doar din cohorte. Spune că ai identificat un segment cu experiență și conversie mai slabe, apoi confirmă printr-o remediere sau un experiment.
Verifică release-urile. Notează ora lansării, bundle-urile schimbate, tagurile de marketing, tema și serviciile terțe. Compară suficient timp înainte și după, controlând promoțiile și traficul. O scădere a conversiei în aceeași zi cu o campanie poate veni din mixul de public, nu din cod. Un grafic comun pentru INP, rata pasului și erorile îți arată ordinea evenimentelor.
Remediul potrivit pornește din componenta lentă
Pentru LCP, deschide elementul indicat de DevTools sau Lighthouse și waterfall-ul. Dacă TTFB ocupă mult, verifică redirecturile, cache-ul de pagină, interogările backend, CDN-ul și răspunsul API. Dacă resursa principală este descoperită târziu, pune-o în HTML și evită să o ascunzi în JavaScript sau într-un background CSS greu de anticipat. Folosește preload sau prioritate ridicată numai pentru resursa cu adevărat critică; preîncărcarea multor fișiere creează concurență.
Livrează imagini cu dimensiuni potrivite, srcset, formate moderne unde sunt acceptate și compresie controlată vizual. Nu aplica lazy loading imaginii LCP din primul ecran. Pentru imaginile de sub fold, MDN descrie lazy loading ca amânare a resurselor până când sunt necesare, reducând munca inițială. Definește lățime și înălțime pentru a rezerva spațiul și a evita CLS.
Pentru INP, găsește interacțiunea lentă și separă întârzierea de input, procesarea handlerului și randarea. Taskurile JavaScript lungi trebuie împărțite astfel încât browserul să poată răspunde. Mută munca neesențială după feedback, debounțează calculele repetitive, virtualizează listele mari și evită recalculările de layout provocate de citiri și scrieri alternante. Un skeleton sau o stare „se procesează” nu reduce mereu timpul total, dar confirmă acțiunea și previne apăsarea repetată.
Pentru CLS, rezervă spațiul imaginilor, reclamelor, bannerelor și widgeturilor. Nu injecta conținut deasupra elementului pe care utilizatorul îl citește. Alege font fallback cu dimensiuni apropiate și încarcă fontul fără să schimbi dramatic geometria. Animă transform și opacity când este potrivit, nu proprietăți care repoziționează întregul layout. Testează bannerul de consimțământ în toate stările, inclusiv revenirea utilizatorului.
Audită scripturile terțe: tag manager, chat, heatmap, recenzii, personalizare, A/B testing și rețele publicitare. Pentru fiecare cere proprietar, scop, pagini, greutate, timp de execuție și dată de expirare. Elimină dublurile și tagurile fără utilizare. Nu amâna orbește scriptul care înregistrează consimțământul sau comanda; ordinea trebuie validată funcțional și juridic.
Nu reconstrui site-ul înainte să epuizezi cauzele localizate. Un template poate fi reparat cu o resursă prioritară, un bundle redus sau un widget eliminat. În același timp, nu instala un plugin de „viteză” fără rollback și test complet: cache-ul agresiv poate servi preț greșit, poate rupe personalizarea sau poate dubla evenimentele.
Dovedește impactul asupra conversiei printr-o schimbare controlată
Cel mai curat test schimbă performanța fără să modifice simultan oferta, copy-ul sau ordinea elementelor. De exemplu, optimizezi livrarea imaginii principale pe un grup de pagini comparabile, păstrând designul. Sau înlocuiești un filtru care blochează threadul cu o versiune care împarte calculul, fără să schimbi opțiunile.
Definește înainte metrica tehnică, evenimentul comercial și gardurile. Pentru o pagină de produs poți urmări LCP p75, rata view_item → add_to_cart, erorile, valoarea coșului și bounce-ul. Pentru filtru urmărești INP p75, rata de selectare a unui rezultat, căutări repetate și progresul către produs. Gardurile includ erori JavaScript, anulări, venit per sesiune și comportamentul desktop.
Dacă rulezi A/B, asigură-te că instrumentul de testare nu produce el însuși flicker, CLS sau JavaScript suplimentar diferit între variante. Alocarea trebuie să fie persistentă, iar testul suficient de lung pentru ciclul săptămânal. Nu opri la primul grafic favorabil. Raportează mărimea eșantionului, diferența, intervalul de incertitudine și orice incident.
Când A/B nu este posibil, folosește rollout treptat pe șabloane sau un before/after cu control. Compară pagini similare neatinse și ajustează pentru sursa traficului, promoții și sezonalitate. Această metodă este mai slabă decât randomizarea, deci formulează concluzia prudent: „după remediere, metricile și trecerea către pas au evoluat împreună”, nu „viteza a produs exact X lei”.
Shopify oferă un audit comercial al vitezei și spune că folosește date din tranzacțiile platformei pentru comparații. Poate fi o sursă de ipoteze pentru magazine Shopify, dar metodologia proprietară și diferențele dintre magazine nu înlocuiesc experimentul propriu. Nu importa promisiunea „orice milisecundă crește conversia” într-un business case.
Calculează valoarea astfel: câștig incremental = sesiuni eligibile × creșterea ratei pasului × rata de finalizare ulterioară × contribuția medie, apoi scazi costul implementării și mentenanței. Folosește scenariu conservator, de bază și optimist. Business case-ul trebuie să arate ce presupunere vine din date, ce este estimare și când se validează.
Tabel de lucru: indicator, măsurare, prag și efect observabil
| Element | Cum îl măsori | Prag de referință | Efect observabil în traseu |
|---|---|---|---|
| TTFB | date RUM și waterfall, pe URL și regiune | nu este Core Web Vital; îl raportezi ca parte din LCP | întârzie primul HTML și toate resursele descoperite după el |
| LCP | CrUX/RUM p75 pe mobil; laborator pentru element și subpărți | bun ≤ 2,5 s; slab > 4 s | conținutul principal apare târziu; urmărești continuarea din landing și produs |
| INP | RUM p75 și trace pe interacțiunea concretă | bun ≤ 200 ms; slab > 500 ms | meniu, filtru, variantă sau buton răspund târziu; apar rage clicks și abandon de pas |
| CLS | RUM p75, sesiuni și laborator cu scroll/interacțiuni | bun ≤ 0,1; slab > 0,25 | elementele se mută, apar clickuri greșite și ezitare |
| Resursă LCP | waterfall: descoperire, download, render | fără prag universal; compari componentele înainte/după | alegi între server, prioritate, fișier și randare |
| JavaScript pe main thread | long tasks și trace pentru interacțiune | fără buget universal; stabilești buget pe dispozitive reale | blochează feedbackul și poate deteriora INP |
| Imagine sub fold | bytes inițiali, request timing, scroll | se amână dacă nu este necesară primului ecran | reduce concurența inițială fără a ascunde conținutul critic |
| Script terț | transfer, execuție, pagini și scop | buget contractual intern | poate afecta simultan LCP, INP și stabilitatea |
Pragurile Core Web Vitals se evaluează la percentila 75. Google explică metodologia pragurilor și păstrează aceleași valori recomandate pentru mobil și desktop, chiar dacă atingerea lor este mai dificilă pe dispozitive constrânse. Tabelul nu transformă „verde” în obiectiv unic; fiecare rând trebuie completat cu evenimentul comercial și volumul afectat.
Brief-ul pentru dezvoltator trebuie să poată fi acceptat sau respins
Un task „crește PageSpeed la 90” este slab. Scorul poate varia și nu spune ce utilizator sau ce pagină contează. Scrie: „Pe șablonul produs, mobil, LCP p75 este 3,8 secunde; în laborator, imaginea principală este descoperită după bundle-ul JavaScript. Obiectiv: imaginea să fie descoperită din HTML, fără regresie CLS, iar LCP de laborator median să scadă cu minimum 600 ms în configurația documentată.”
Adaugă URL-urile reprezentative, capturile waterfall, elementul LCP, interacțiunea INP, dispozitivele, condiția de rețea, rezultatele mai multor rulări și pașii de reproducere. Definește criteriul funcțional: variantele, prețurile, coșul, consimțământul și evenimentele analytics trebuie să rămână corecte. Include rollback, proprietar și monitorizare după lansare.
Bugetul de performanță poate limita imaginea principală, JavaScriptul inițial, numărul de requesturi critice și taskurile lungi. El se stabilește după măsurare, nu copiat din alt site. Integrează-l în review și în procesul de release. O pagină reparată astăzi va regresa dacă fiecare campanie adaugă un nou tag fără proprietar.
Munca are și o componentă de performanță SEO, dar Google spune explicit că scorurile bune Core Web Vitals nu garantează poziții de top. Nu vinde proiectul doar ca „factor de ranking”. Argumentul solid este o experiență mai bună, erori mai puține, măsurare verificabilă și protejarea conversiei; beneficiul organic este contextual.
Încheie taskul numai după trei verificări: laboratorul confirmă cauza remediată, datele de teren se deplasează după fereastra necesară, iar indicatorul comercial nu se deteriorează. Dacă doar scorul s-a schimbat, proiectul este tehnic finalizat, dar ipoteza de business rămâne deschisă.
Întrebări frecvente
Cum afectează viteza conversiile?
Viteza afectează conversia când întârzie conținutul necesar deciziei, blochează o interacțiune sau mută elementele sub deget. Efectul nu are un procent universal. Măsoară LCP, INP și CLS pe mobil, leagă-le de pasul următor din traseu, segmentează experiențele și confirmă printr-o remediere controlată. Un scor PageSpeed mai bun este o dovadă tehnică intermediară; dovada comercială este creșterea acțiunilor utile sau reducerea erorilor fără pierdere de marjă și calitate.
O analiză corectă spune: „Pe pagina X, utilizatorii cu problema Y pierd pasul Z; remedierea A a redus timpul B și diferența de comportament a fost C.” Această propoziție poate fi auditată, bugetată și repetată. „Site-ul rapid convertește mai bine” este doar punctul de pornire.