Core Web Vitals pentru magazine online: LCP, INP și CLS pe înțeles

Ce măsoară LCP, INP și CLS, pragurile bun și slab la percentila 75, date de laborator vs. date de teren și soluțiile uzuale pe Shopify și WooCommerce.

Echipa editorială FixReports13 min de lectură

Core Web Vitals sunt trei indicatori Google care descriu cum percep vizitatorii reali o pagină: Largest Contentful Paint (LCP) pentru încărcare, Interaction to Next Paint (INP) pentru capacitatea de răspuns și Cumulative Layout Shift (CLS) pentru stabilitatea vizuală. O pagină trece evaluarea când cel puțin 75% dintre vizite se încadrează în intervalul „bun”: LCP de cel mult 2,5 secunde, INP de cel mult 200 de milisecunde și CLS de cel mult 0,1, măsurați separat pentru mobil și desktop. În magazinele online, scorurile slabe provin de obicei din imagini hero și de produs prea mari sau încărcate cu lazy loading, din scripturile aplicațiilor și de tracking, din fonturile web și din bannere sau widgeturi de recenzii care împing conținutul în jos după ce pagina apare.

Puncte-cheie

Care sunt pragurile Core Web Vitals?

O pagină îndeplinește Core Web Vitals când percentila 75 a încărcărilor sale se încadrează în intervalul bun pentru toți cei trei indicatori.

IndicatorCe măsoarăBunNecesită îmbunătățiriSlab
LCPTimpul până la afișarea celei mai mari imagini, a celui mai mare videoclip sau bloc de text din zona vizibilă2,5 s sau mai puținPeste 2,5 s, până la 4,0 sPeste 4,0 s
INPTimpul de la un clic, o atingere sau o apăsare de tastă până la afișarea cadrului următor200 ms sau mai puținPeste 200 ms, până la 500 msPeste 500 ms
CLSCât de mult se mișcă neașteptat conținutul vizibil0,1 sau mai puținPeste 0,1, până la 0,25Peste 0,25

Pragurile provin din ghidurile web.dev pentru LCP (se deschide într-o filă nouă), INP (se deschide într-o filă nouă) și CLS (se deschide într-o filă nouă), valabile în octombrie 2026.

Percentila 75 înseamnă că rezultatul reflectă majoritatea vizitatorilor, nu doar pe cei mai rapizi, iar Google segmentează separat mobilul și desktopul (se deschide într-o filă nouă). PageSpeed Insights consideră că o pagină trece evaluarea când toți cei trei indicatori sunt buni; fără suficiente date INP, evaluează doar LCP și CLS (documentația PageSpeed Insights (se deschide într-o filă nouă)). Google afirmă că indicatorii Core Web Vitals stabili nu se vor schimba mai des de o dată pe an.

Într-un magazin, elementul LCP este adesea bannerul hero sau imaginea principală a produsului, de aceea felul în care sunt gestionate imaginile contează atât de mult.

De ce a înlocuit INP indicatorul FID în martie 2024?

INP a înlocuit FID pentru că FID măsura doar prima interacțiune și doar o parte din întârzierea acesteia, în timp ce INP analizează interacțiunile de pe parcursul întregii vizite.

Google a anunțat în mai 2023 că INP va deveni indicator Core Web Vitals, iar schimbarea a intrat în vigoare pe 12 martie 2024 (se deschide într-o filă nouă). FID raporta doar prima interacțiune și doar întârzierea la intrare (input delay), nu și timpul petrecut cu rularea handlerelor de evenimente sau cu afișarea rezultatului. INP observă clicurile, atingerile și apăsările de taste pe toată durata vizitei și raportează cea mai lungă interacțiune, ignorând valorile extreme; derularea și trecerea cu mouse-ul peste elemente nu se iau în calcul. Utilizatorii API-urilor CrUX și PageSpeed Insights au avut timp până pe 9 septembrie 2024 să facă trecerea (web.dev (se deschide într-o filă nouă)).

Fiecare interacțiune are trei părți: întârzierea la intrare (așteptarea scripturilor care țin procesorul ocupat), durata de procesare (rularea handlerelor) și întârzierea de prezentare (afișarea cadrului următor) (web.dev (se deschide într-o filă nouă)).

Într-un magazin, aceste interacțiuni sunt selectorul de variante, butoanele de cantitate, adăugarea în coș, sertarul coșului, filtrele și meniurile. O pagină putea trece de FID datorită unei prime atingeri rapide și totuși să pară lentă când cineva deschidea filtrele mai târziu.

Care este diferența dintre datele de laborator și datele de teren?

Datele de laborator provin dintr-un singur test în condiții fixe, în timp ce datele de teren sunt colectate în timp de la vizitatori reali, iar Google recomandă folosirea datelor de teren pentru a decide ce corectați mai întâi (web.dev (se deschide într-o filă nouă)).

Date de laboratorDate de teren
SursăO singură încărcare simulată a paginii (Lighthouse, Chrome DevTools, secțiunea de laborator din PageSpeed Insights)Vizitatori reali din Chrome (Chrome UX Report) sau propria monitorizare a utilizatorilor reali (RUM)
CondițiiDispozitiv și rețea fixe. Testul mobil implicit Lighthouse (se deschide într-o filă nouă) folosește „Slow 4G” (150 ms dus-întors, 1,6 Mbps la descărcare) și o încetinire a procesorului de 4xOrice dispozitive, rețele și locații au vizitatorii dumneavoastră
INPNu se măsoară la o simplă încărcare a paginii. Total Blocking Time (TBT) este un indicator aproximativMăsurat din interacțiuni reale
Cel mai potrivit pentruDepanare și verificarea unei modificări înainte de lansareA afla ce primesc efectiv vizitatorii

TBT însumează partea din fiecare sarcină a firului principal care depășește 50 ms; web.dev recomandă sub 200 ms pe hardware mobil obișnuit, dar precizează că TBT nu înlocuiește INP (web.dev (se deschide într-o filă nouă)).

Trei detalii ale Chrome UX Report (CrUX) contează pentru magazine:

  • Este o medie mobilă pe 28 de zile (se deschide într-o filă nouă), actualizată zilnic.
  • Acoperă Chrome pe desktop și pe Android, pentru utilizatorii care îndeplinesc condițiile de raportare ale Chrome. Chrome pe iOS este exclus, așa că un magazin cu cumpărători veniți mai ales de pe iPhone vede date de teren doar de la o parte a publicului (metodologie (se deschide într-o filă nouă)).
  • Paginile și originile apar doar dacă pot fi descoperite public și sunt suficient de populare, așa că un magazin cu trafic redus poate avea doar date la nivel de origine sau deloc.

Tabloul de bord pentru performanța web (se deschide într-o filă nouă) din Shopify raportează și el LCP, INP și CLS de la utilizatori reali, la percentila 75, dar pe 30 de zile în loc de 28, așa că vă puteți aștepta la unele diferențe față de CrUX.

Ce încetinește LCP pe paginile magazinului?

LCP este de obicei lent în magazine pentru că imaginea principală este prea mare, este descoperită târziu sau este întârziată intenționat prin lazy loading sau printr-o animație.

  • Lazy loading pentru imaginea LCP. web.dev spune să nu faceți niciodată acest lucru (web.dev (se deschide într-o filă nouă)). Analiza sa asupra paginilor WordPress a găsit un LCP mai lent la percentila 75 pe site-urile care foloseau lazy loading nativ, iar renunțarea la lazy loading pentru imaginile din partea vizibilă inițial (above the fold) a eliminat regresia (web.dev (se deschide într-o filă nouă)).
  • O imagine descoperită târziu. O imagine hero setată ca background-image în CSS sau injectată de scriptul unui slider nu se află în HTML-ul pe care browserul îl scanează mai întâi. Shopify recomandă să evitați fundalurile CSS pentru conținutul hero și efectele de apariție treptată (fade-in) pe imaginea LCP (Shopify (se deschide într-o filă nouă)).
  • Prioritate scăzută. Imaginile se încarcă cu prioritate scăzută până la finalizarea layoutului, așa că Shopify recomandă fetchpriority="high" pe imaginea LCP (Shopify (se deschide într-o filă nouă)). web.dev observă că setarea acestui atribut pe mai mult de una sau două imagini îi reduce utilitatea (web.dev (se deschide într-o filă nouă)).
  • CSS și scripturi care blochează randarea. Foile de stil mari și scripturile sincrone din <head> întârzie randarea chiar și după ce imaginea a sosit (web.dev (se deschide într-o filă nouă)).
  • Dimensiunea fișierelor și fonturile. Folosiți formate moderne, srcset și sizes, precum și un CDN. Pentru fonturile web, folosiți o valoare font-display diferită de auto sau block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Ce face INP lent pe paginile magazinului?

Un INP lent în magazine înseamnă de obicei prea mult JavaScript pe firul principal, în mare parte de la aplicații, etichete de tracking și funcții ale temei, așa că atingerile trebuie să aștepte.

Dacă un cumpărător atinge „Adaugă în coș” în timp ce scripturile de recenzii, chat și analiză încă rulează, atingerea așteaptă. Un selector de variante care redesenează întregul formular de produs adaugă timp de procesare. Mega-meniurile uriașe și grilele de colecție cu multe mostre de culoare (swatches) adaugă întârziere de prezentare.

web.dev recomandă împărțirea sarcinilor lungi și cedarea controlului către firul principal, actualizarea ecranului mai întâi și amânarea restului, precum și menținerea unui DOM mai mic (web.dev (se deschide într-o filă nouă)). Shopify adaugă pași specifici magazinelor: auditați fiecare aplicație, pixel și script al temei, amânați ce nu este critic, încărcați funcțiile abia la interacțiune și dezactivați fragmentele anti-flicker pentru testele A/B când nu rulează niciun test (Shopify (se deschide într-o filă nouă)).

Ce cauzează deplasările de layout pe paginile de produs și de colecție?

Deplasările de layout din magazine provin mai ales din conținut care apare sau își schimbă dimensiunea după prima randare: imagini fără dimensiuni, bare de anunțuri și de cookie-uri, widgeturi de recenzii, blocuri de aplicații și înlocuiri de fonturi.

web.dev enumeră drept cauze frecvente elementele media cu dimensiuni necunoscute, conținutul adăugat deasupra conținutului existent, widgeturile terților care își schimbă singure dimensiunea și fonturile web care diferă ca mărime de fontul de rezervă (web.dev (se deschide într-o filă nouă)). În magazine, asta înseamnă o bară de livrare gratuită inserată în partea de sus, evaluări cu stele care se încarcă după titlu, mesaje despre plata în rate sub preț și caruseluri de recomandări. Shopify observă că și conținutul pop-up poate provoca deplasări (Shopify (se deschide într-o filă nouă)).

Deplasările care au loc în cel mult 500 ms de la o acțiune a utilizatorului nu se iau în calcul, dar cele din timpul derulării da, iar instrumentele de laborator le ratează adesea (web.dev (se deschide într-o filă nouă)). Dați imaginilor width și height sau un aspect-ratio în CSS, rezervați spațiu pentru widgeturi, afișați bannerele ca suprapuneri (overlay), reduceți deplasările cauzate de înlocuirea fonturilor cu size-adjust și animați cu transform în loc de top sau left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Cum îmbunătățiți Core Web Vitals pe Shopify?

Pe Shopify, cele mai mari câștiguri vin din încărcarea imediată a primei imagini, cu prioritate ridicată, din reducerea scripturilor aplicațiilor și din verificarea rezultatului în rapoartele de performanță web din panoul de administrare.

Verificați datele din panoul de administrare

Un rezumat apare pe pagina Online Store > Themes (Magazin online > Teme), iar rapoartele complete pentru LCP, INP și CLS se află la Analytics > Reports (Analiză > Rapoarte). Datele pot întârzia până la 36 de ore, iar modul privat trebuie să fie dezactivat (Shopify Help Center (se deschide într-o filă nouă)).

Controlați încărcarea imaginilor în Liquid

Filtrul image_tag aplică lazy loading imaginilor din secțiunile aflate mai jos în pagină, dacă nu setați preload (referința image_tag (se deschide într-o filă nouă)): încărcare imediată pentru secțiunile 1 până la 3, lazy loading începând cu secțiunea 4. Deoarece section.index este nil în editorul de teme, testați cu > 3 în loc de <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

În grilele de produse, Shopify sugerează încărcarea imediată doar pentru primele câteva carduri (de exemplu forloop.index <= 4) (Shopify (se deschide într-o filă nouă)). Folosiți preload: true cu moderație; Shopify recomandă preîncărcarea a doar una sau două resurse descoperite târziu.

Eliminați ce lasă în urmă aplicațiile

Dezactivați încorporările de aplicații (app embeds) nefolosite din Online Store > Edit theme > App embeds (Magazin online > Editare temă > Încorporări de aplicații) (Shopify Help Center (se deschide într-o filă nouă)). Dezinstalarea unei aplicații îi elimină blocurile, dar aplicațiile care au modificat direct fișierele temei pot lăsa în urmă „cod fantomă” (ghost code) care, potrivit Shopify, poate cauza probleme de calitate și de performanță (Shopify (se deschide într-o filă nouă)). Shopify mai precizează că script tags nu vor mai rula de la 1 martie 2027. Pentru fonturi, Shopify recomandă propriul CDN sau fonturile de sistem în locul serviciilor externe de fonturi (Shopify (se deschide într-o filă nouă)).

Cum îmbunătățiți Core Web Vitals pe WooCommerce?

Pe WooCommerce, asigurați-vă că pluginurile nu suprascriu prioritizarea imaginilor din WordPress, puneți în cache totul în afară de coș și checkout și eliminați scripturile care se încarcă peste tot fără să fie nevoie.

  • Păstrați gestionarea imaginilor din nucleu. Începând cu WordPress 6.3 (lansat pe 8 august 2023), nucleul adaugă fetchpriority="high" imaginii care este probabil elementul LCP (implicit, de cel puțin 50.000 de pixeli pătrați) și omite lazy loading pentru primele trei imagini din conținut (Make WordPress Core (se deschide într-o filă nouă)). Dacă un plugin de optimizare adaugă propriul lazy loading, verificați că exclude imaginea hero și imaginea principală a produsului.
  • Puneți în cache paginile, nu coșurile. Ghidul WooCommerce recomandă cache de pagină pe server sau printr-un plugin și un CDN, păstrând paginile de coș și de checkout în afara cache-ului (documentația pentru dezvoltatori WooCommerce (se deschide într-o filă nouă)).
  • Verificați cart fragments. Începând cu WooCommerce 7.8, scriptul cart fragments se încarcă doar acolo unde există un widget Cart, dar unele teme includ acest widget direct în cod. Blocul Mini-Cart nu folosește cart fragments (blogul pentru dezvoltatori WooCommerce (se deschide într-o filă nouă)).
  • Găsiți pluginurile grele. WooCommerce sugerează Query Monitor pentru identificarea pluginurilor lente, precum și amânarea JavaScriptului care nu este critic.

Dacă layoutul dumneavoastră afișează mai mult de trei imagini în partea vizibilă inițial, puteți ridica pragul din WordPress:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Cât durează până se văd efectele corecturilor?

Testele de laborator arată imediat efectul unei corecturi, dar datele de teren au nevoie de până la aproximativ patru săptămâni ca să îl reflecte complet, pentru că CrUX face media ultimelor 28 de zile.

Rulați testul de laborator de mai multe ori înainte și după o modificare, pentru că rezultatele individuale variază, apoi urmăriți valorile de teren în PageSpeed Insights, în raportul Core Web Vitals din Search Console sau în rapoartele Shopify. Scanarea gratuită vă oferă o primă imagine în aproximativ un minut. Raportul de performanță rulează un test de laborator pe mobil, cu limitare a vitezei (slow 4G, procesor încetinit de 4x), și adaugă date de teren din Chrome UX Report, inclusiv INP atunci când Google are suficiente date pentru magazinul dumneavoastră.

Întrebări frecvente

Influențează Core Web Vitals clasamentul în Google?

Google afirmă că sistemele sale de clasare folosesc Core Web Vitals, dar că scorurile bune nu garantează pozițiile de top și că afișează în continuare conținutul cel mai relevant chiar și atunci când experiența oferită de pagină este slabă (Google Search Central (se deschide într-o filă nouă)).

De ce PageSpeed Insights nu afișează date de teren pentru magazinul meu?

CrUX include doar paginile și originile care pot fi descoperite public și au suficienți vizitatori Chrome eligibili. Un magazin cu trafic redus poate avea doar date la nivel de origine sau deloc, așa că bazați-vă pe testele de laborator și pe rapoartele propriei platforme.

Am nevoie de un scor Lighthouse de 90 sau mai mult ca să trec evaluarea?

Nu. Scorul de performanță Lighthouse este un rezultat de laborator, în timp ce evaluarea Core Web Vitals folosește date de teren la percentila 75, așa că o pagină poate trece cu un scor Lighthouse modest și poate pica cu unul ridicat.

Ar trebui să folosesc lazy loading pentru toate imaginile de produs?

Nu. Folosiți lazy loading pentru imaginile de sub primul ecran, dar încărcați imediat imaginea hero și imaginea principală a produsului, cu fetchpriority="high" pe una dintre ele.

De ce rezultatele pe mobil sunt mai slabe decât pe desktop?

Google măsoară separat mobilul și desktopul, iar telefoanele au procesoare și rețele mai lente. Testul mobil Lighthouse simulează acest lucru cu un profil Slow 4G și o încetinire a procesorului de 4x.

Surse

Toate ghidurile