INP și Core Web Vitals într-un magazin WooCommerce: ce măsori și ce repari

Un magazin lent nu pierde doar vizitatori nerăbdători, ci și comenzi: butoane care răspund cu întârziere, un coș care se actualizează greu, un checkout care „îngheață” după ce completezi un câmp. Google măsoară aceste lucruri prin trei metrici numite Core Web Vitals, iar cea mai recentă dintre ele, INP, e adesea cea mai dificilă pentru un magazin WooCommerce, pentru că depinde de cât JavaScript rulează în pagină.

Ghidul explică ce înseamnă fiecare metrică, cum le măsori pe date reale, nu doar într-un test de laborator, și în ce ordine repari problemele tipice dintr-un magazin WooCommerce, de la scripturile terților la coș și checkout. Pentru o evaluare completă a unui site, vezi serviciul nostru de optimizare a vitezei.

Cele trei metrici și pragurile lor

Între „bun” și „slab” e zona „necesită îmbunătățiri”. Evaluarea se face la percentila 75: pentru ca o pagină să treacă, cel puțin 75% din vizitele reale trebuie să se încadreze în pragul „bun”. INP a înlocuit metrica FID în martie 2024 și e mai exigentă, pentru că ia în calcul toate interacțiunile din timpul vizitei, nu doar prima.

De ce INP e problema principală într-un magazin WooCommerce

Un magazin WooCommerce rulează mult JavaScript: tema, pluginurile, widget-urile de coș, filtrele de produse, scripturile de analytics și de marketing, chat-ul, recenziile. Fiecare interacțiune a clientului (un clic pe „Adaugă în coș”, deschiderea meniului, completarea unui câmp la checkout) rulează în același fir de execuție ca restul codului. Dacă firul e ocupat cu alt script, interfața nu reacționează până nu se termină, iar asta e exact ce măsoară INP.

De aceea o pagină poate încărca rapid și totuși să „se simtă” lentă: LCP e bun, dar INP e slab. Un test de laborator nu o prinde ușor, pentru că Lighthouse nu măsoară INP direct, ci folosește un indicator apropiat (timpul total de blocare), iar adevărata măsurătoare vine din datele reale de la utilizatori.

Cum măsori corect

Pornești de la date reale, apoi mergi spre cauze:

1. Raportul Core Web Vitals din Search Console. Îți arată grupuri de URL-uri cu probleme, separat pe mobil și pe desktop. De aici afli care tip de pagină are nevoie de atenție: produs, categorie, coș sau checkout.
2. PageSpeed Insights. Pentru o pagină concretă îți arată datele reale (dacă are destul trafic), plus un test de laborator cu recomandări. Dă prioritate datelor reale.
3. Panoul Performance din Chrome DevTools. Aici vezi ce rulează în firul principal în timpul unei interacțiuni, ce script blochează și cât durează fiecare sarcină.
4. O măsurătoare proprie, în producție. Biblioteca web-vitals îți dă valorile reale, cu detalii despre elementul și scriptul responsabil:

import { onINP, onLCP, onCLS } from 'web-vitals/attribution';

function raporteaza({ name, value, attribution }) {
  console.log(name, Math.round(value), attribution);
}

onINP(raporteaza);
onLCP(raporteaza);
onCLS(raporteaza);

În loc de console.log, poți trimite valorile către analytics, ca să vezi evoluția pe pagini și pe dispozitive.

Ce repari, în ordinea impactului

Din experiența noastră pe propriul site, doi pași mici au avut efect clar: încărcarea neblocantă a fonturilor Google (preîncărcare, apoi aplicare după încărcare) și prioritatea de încărcare pe logo-ul din header, care e elementul din partea de sus a paginii. Nu sunt rețete universale, dar arată tipul de intervenție care contează: nu o schimbare spectaculoasă, ci eliminarea unui lucru care blocează afișarea.

Scripturile terților și consimțământul

Cele mai grele scripturi dintr-un magazin sunt, de obicei, cele de marketing și analytics. Ele au și o legătură directă cu consimțământul: pixelii de marketing nu ar trebui să se încarce înainte de acord, ceea ce îți ia și greutatea de pe prima încărcare. Dacă îți configurezi corect banner-ul, câștigi atât conformitate, cât și viteză; am descris cum, pas cu pas, în ghidul despre Consent Mode v2.

Coșul și checkout-ul, zona cu cele mai multe comenzi pierdute

Pe o pagină de produs, o întârziere de câteva sute de milisecunde enervează. În checkout, costă comenzi. Fiecare plugin care atinge formularul (livrare, facturare, câmpuri personalizate, validări) adaugă cod care rulează la interacțiunea clientului. De aceea, după fiecare schimbare, testează checkout-ul pe un telefon mediu, nu pe laptopul tău de dezvoltare. Dacă ai trecut sau urmează să treci pe checkout cu blocuri, interfața e construită diferit, iar performanța trebuie măsurată din nou, așa cum e explicat în ghidul despre checkout cu blocuri sau clasic. Pentru ideile de UX care țin de rata de conversie, vezi și checklist-ul de UX pentru ecommerce.

Hosting și server

Nicio optimizare de front-end nu compensează un server care răspunde lent. Verifică timpul de răspuns al serverului, folosește cache de pagină unde se poate (paginile de produs și de categorie, nu coșul și checkout-ul) și asigură-te că hostingul are resurse pentru un magazin, nu doar pentru un blog. Dacă te gândești să schimbi infrastructura, vezi cum arată un hosting optimizat pentru WordPress și WooCommerce.

Un plan simplu pentru prima lună

1. Săptămâna 1: citește raportul din Search Console și alege grupul de pagini cu cele mai multe URL-uri slabe.
2. Săptămâna 2: inventariază scriptele de pe acele pagini și elimină sau amână ce nu e esențial.
3. Săptămâna 3: tratează imaginea principală, fonturile și dimensiunile imaginilor.
4. Săptămâna 4: testează coșul și checkout-ul pe telefon și măsoară din nou.

După fiecare pas, așteaptă să se acumuleze date noi: datele reale se actualizează cu întârziere, pentru că se calculează pe o fereastră de câteva săptămâni.

Întrebări frecvente

Dacă vrei un audit al vitezei magazinului tău, cu priorități și estimări, vezi cum lucrăm la optimizarea vitezei.