Va funcționa Magento 2 cu șablonul Hyvä întotdeauna mai rapid decât cu orice alt șablon?

Imaginează-ți două magazine Magento. Primul folosește Hyvä, dar la intrare pornește peste zece instrumente de marketing, încarcă imagini foarte mari și generează pagina de la zero de fiecare dată. Al doilea are o altă temă, optimizată cu atenție, un cache eficient și doar scripturile de care clientul are nevoie.

Care va fi mai rapid? Numele șablonului nu este suficient pentru a răspunde.

Hyvä oferă Magento un punct de plecare foarte bun pentru construirea unui magazin rapid. Nu oferă însă un avantaj necondiționat față de orice altă implementare. Rezultatul depinde de întregul traseu dintre clickul pe link și momentul în care clientul vede produsul și îl poate cumpăra.

De aceea, implementarea Hyvä merită combinată cu o verificare a serverului, modulelor, imaginilor și designului interfeței. Atunci se poate lucra la un obiectiv ambițios: 95–100 de puncte în Google PageSpeed Insights, păstrând funcțiile necesare pentru vânzare.

Ce înseamnă de fapt un scor de 95–100 în PageSpeed?

În limbaj uzual vorbim despre 100% în PageSpeed, dar instrumentul prezintă puncte pe o scară de la 0 la 100. În partea bazată pe Lighthouse, acesta evaluează patru arii diferite:

Aceste evaluări nu se înlocuiesc una pe alta. Un magazin rapid poate avea butoane greu de citit. Un magazin corect din punct de vedere tehnic poate încărca prea mult JavaScript. Lighthouse este un instrument de diagnosticare, iar aria auditurilor sale nu acoperă întreaga calitate a magazinului. Descrierea Lighthouse.

Scorul Performance provine dintr-o măsurare de laborator și se poate modifica între teste. PageSpeed afișează, de asemenea, dacă sunt disponibile, date ale utilizatorilor reali din CrUX, colectate pe o perioadă mobilă de 28 de zile. O implementare nouă nu va schimba imediat întregul set de date. Cum funcționează PageSpeed Insights.

În practică avem nevoie de două obiective: teste repetabil bune și experiențe bune pentru clienți. Pentru Core Web Vitals, aceasta înseamnă:

• LCP până la 2,5 s — apariția rapidă a celui mai mare element din zona vizibilă;
• INP până la 200 ms — reacție eficientă la interacțiuni;
• CLS până la 0,1 — layout stabil al paginii.

Aceste praguri sunt evaluate la percentila 75, separat pentru dispozitive mobile și desktop. Testul standard de încărcare Lighthouse nu măsoară INP; pentru diagnosticarea blocării browserului folosește, printre altele, TBT. Un TBT scăzut nu este o confirmare automată a unui INP bun. Core Web Vitals.

Cum ajută Hyvä la accelerarea Magento?

Hyvä reduce greutatea frontendului în comparație cu Luma standard. Folosește Alpine.js pentru interacțiuni și Tailwind CSS pentru stilizare. Mai puțin cod de descărcat și executat oferă browserului mai mult spațiu pentru a afișa rapid oferta. Documentația Hyvä indică reducerea JavaScriptului și CSS ca parte importantă a acestei arhitecturi. Performanța Hyvä.

Totuși, beneficiul poate fi redus ușor. Este suficient să adaugi la un frontend ușor un slider complex, chat, câteva trackere și module care transferă dependențe vechi din tema anterioară.

Hyvä nu va remedia nici o interogare lentă către baza de date, un cache care nu funcționează sau un server ocupat cu importuri. De aceea, întrebarea înainte de implementare ar trebui să fie: ce întârzie astăzi achiziția și care dintre aceste probleme va fi rezolvată prin schimbarea frontendului?

1. Serverul: nginx și Varnish trebuie să facă munca potrivită

Înainte ca browserul să afișeze produsul, trebuie să primească documentul HTML. Dacă așteaptă mult primul byte al răspunsului, chiar și o temă ușoară începe cu întârziere.

Nginx: livrarea eficientă a resurselor

Într-o arhitectură Magento tipică, nginx gestionează, printre altele, HTTPS, fișiere statice și redirecționarea cererilor către serviciile următoare. Merită verificate compresia răspunsurilor text, HTTP/2 și anteturile cache pentru fișierele CSS și JS versionate. Adobe oferă o configurație nginx exemplificativă ca punct de plecare pentru o implementare cu Varnish. Configurarea Varnish în Adobe Commerce.

Nu trebuie atribuit același timp de stocare tuturor răspunsurilor. O foaie CSS versionată poate fi utilizată mult timp din memoria browserului. Prețul, conținutul coșului și răspunsul referitor la clientul autentificat necesită o abordare diferită.

Dacă serverul selectează WebP pe baza antetului Accept, trebuie verificate și cheia cache și antetul Vary: Accept. Browserul și straturile intermediare de cache trebuie să distingă variantele imaginii.

Varnish: verificăm hiturile în cache, nu doar instalarea serviciului

Varnish permite servirea paginilor publice din cache fără ca Magento să refacă întreaga muncă. Adobe recomandă utilizarea lui în mediul de producție. Gestionarea cache Magento.

Testul practic este simplu: deschidem aceeași adresă publică de câteva ori și verificăm dacă după primul răspuns apar hituri HIT. Apoi comparăm timpul de răspuns din cache cu timpul de generare a paginii la MISS.

Dacă o categorie populară ocolește constant cache-ul, trebuie găsită cauza: configurația, cookies, parametrii adresei, personalizarea sau modul de funcționare al modulului. Cumpărarea unui server mai mare poate atunci doar să mascheze problema.

Corectitudinea este, de asemenea, importantă. Cache-ul nu poate pune la dispoziția altui utilizator coșul sau datele unui client. Trebuie testate variantele de magazin, monedele și grupurile de clienți, precum și reîmprospătarea conținutului după modificarea produsului. Un preț rapid, dar neactualizat, nu este un succes al optimizării.

În afară de nginx și Varnish, verificăm PHP-FPM, OPcache, backend cache compatibil cu versiunea Magento, baza de date, cron și indexarea. Numărul de procese PHP ar trebui să rezulte din memoria disponibilă și din încărcarea reală. Creșterea lui fără măsurare poate înrăutăți situația.

2. Module pentru Hyvä: compatibilitatea este doar începutul

Un modul poate funcționa corect cu Hyvä și totuși poate executa prea multă muncă la intrarea pe pagină. O optimizare bună include așadar atât funcția, cât și costul pornirii ei.

În kowal.store adaptăm modulele noastre la Hyvä și le dezvoltăm având în vedere păstrarea performanței acestei teme după instalare. Avem grijă ca funcțiile noi să nu încarce inutil frontendul — prin limitarea dependențelor și printr-un mod adecvat de încărcare a JavaScriptului și CSS. Vezi modulele noastre Magento 2 și alege extensii pentru magazinul tău. Efectul unei implementări concrete merită confirmat prin măsurare, deoarece depinde și de configurație și de celelalte integrări.

Să luăm chatul. Clientul care navighează într-o categorie are nevoie la început de un buton care deschide conversația. Interfața complexă a chatului și bibliotecile sale pot fi descărcate la deschidere. În mod similar, sugestiile complete ale motorului de căutare pot fi pregătite la intrarea în câmpul de căutare, lăsând de la început vizibil și funcțional formularul.

O astfel de abordare este descrisă și de Hyvä în recomandările privind încărcarea JavaScriptului extern.

defer, async și întârzierea componentei sunt lucruri diferite

defer permite executarea unui script clasic extern după procesarea documentului și păstrarea ordinii scripturilor de acest tip. async pornește scriptul când este gata, fără garanția ordinii față de altele. Niciunul dintre aceste atribute nu înseamnă în sine că fișierul va fi descărcat abia după click.

Hyvä pune la dispoziție și x-defer, cu care se poate întârzia inițializarea componentei Alpine, de exemplu până când se apropie de zona vizibilă. Aceasta nu este o amânare automată a descărcării tuturor fișierelor sale. Trebuie reținute și evenimentele pe care componenta le poate rata înainte de inițializare, de exemplu cele legate de datele clientului. Documentația x-defer.

Modificările trebuie verificate pe coș, filtre, formulare și evenimente analitice. Simpla prezență a atributului defer nu dovedește că modulul este bine optimizat.

CSS: aspectul necesar ar trebui să fie pregătit înainte de prima randare

Stilurile headerului, listei de produse și layoutului mobil sunt necesare de la început. Încărcarea lor prea târzie poate provoca clipirea paginii și deplasarea elementelor. În același timp, categoria de produse nu trebuie să încarce toate stilurile fiecărui modul instalat.

Merită limitate foile globale, eliminate resturile temei vechi și verificat buildul de producție Tailwind. În cazul claselor create dinamic, trebuie avut grijă ca regulile necesare să se regăsească în CSS-ul rezultat. CSS-ul critic inserat în HTML poate ajuta, dar necesită întreținere și teste; nu ar trebui să fie primul răspuns la fiecare problemă. Resurse care blochează randarea.

Analitica și datele SEO au și ele costul lor

Lucrând la optimizarea unui magazin pe Magento 2, am verificat încărcarea generată de analytics pe pagina de categorie. GTM și gtag au reprezentat aproximativ 304 KB, adică 44% din transferul înregistrat în prima măsurare mobilă. Acesta este un motiv bun pentru a revizui tagurile și trigger-ele. Nu înseamnă că trebuie întârziată fără discernământ întreaga analiză: o astfel de schimbare poate modifica numărul de vizite și evenimente înregistrate.

Merită analizat și HTML-ul în sine. Datele JSON-LD extinse, informațiile duplicate despre produse și configurațiile modulelor măresc răspunsul serverului. JSON-LD nu se execută ca un program JavaScript obișnuit, dar tot trebuie transmis. Datele structurate ale categoriei ar trebui să corespundă listei vizibile, paginării și ordinii acesteia.

3. Imaginile: contează formatul, dimensiunea și momentul descărcării

O imagine sursă cu lățimea de câteva mii de pixeli nu ar trebui să ajungă inutil într-un card mic de produs. Pregătim variante adaptate la dimensiunea de afișare și densitatea ecranului, iar srcset și sizes ajută browserul să aleagă fișierul potrivit. WebP sau AVIF merită comparate din punctul de vedere al calității și greutății pe imagini concrete.

Cea mai importantă diferențiere privește imaginile vizibile imediat și cele aflate mai jos. Imaginea care este LCP ar trebui să fie ușor de descoperit în HTML, fără loading='lazy'; fetchpriority='high' poate fi justificat. Imaginile din afara primului ecran sunt candidați buni pentru lazy loading. Dimensiunile sau proporțiile le rezervă spațiu în layout. Imagini responsive.

Totuși, nu setăm prioritate ridicată pentru fiecare imagine. Browserul are nevoie de informații despre ce este cu adevărat cel mai important. Fetch Priority.

Verificăm și bannerele CMS, logo-ul, favicon, miniaturile video și grafica popup-urilor. Optimizarea trebuie să includă procesul de adăugare a fișierelor noi, altfel următoarea campanie va readuce imaginile grele.

Adresa care se termină cu .png nu stabilește singură ce descarcă browserul. Serverul poate livra WebP la acea adresă. Verificăm Content-Type și transferul în fila Network.

4. Cromatica: cel mai mare impact îl vei vedea în accesibilitate

Schimbarea unui buton albastru în verde nu va accelera Magento. Culoarea are însă o importanță mare pentru lizibilitate și scorul Accessibility.

Cel mai des, problemele sunt provocate de descrieri gri deschis, butoane pastel cu text alb, etichete promoționale și text pe imagini. Conform WCAG, contrastul textului obișnuit ar trebui să fie de cel puțin 4,5:1, iar al textului mare 3:1. Textul mare înseamnă cel puțin 18 pt, adică aproximativ 24 px, sau 14 pt dacă este bold, adică aproximativ 18,7 px. Cerințe privind contrastul textului.

Pentru elementele vizuale importante ale controalelor și marcajelor de stare se aplică și cerința unui contrast de 3:1 față de culorile învecinate, cu excepțiile descrise în standard. Contrastul elementelor non-text.

Paleta merită definită centralizat, de exemplu prin variabile CSS sau prin configurația modulului de culori. Astfel, schimbarea culorii textului sau a butoanelor acoperă întregul magazin. Trebuie verificate și stările hover, focus, erorile formularului și filtrele selectate. Un contur roșu nu ar trebui să fie singura informație că un câmp conține o eroare.

Performanța poate fi influențată de modul de implementare a aspectului: foi suplimentare, un script care schimbă culorile după încărcare sau efecte vizuale grele. Paleta în sine nu este însă un substitut pentru optimizarea JS, imaginilor și serverului.

De ce nu este suficient un singur scor bun?

Optimizând un magazin pe Magento 2 cu Hyvä, am efectuat două măsurări locale Lighthouse pentru aceeași pagină de categorie. Pe mobile am obținut 94 și 73 de puncte. LCP a fost de 2,5 și respectiv 5,7 s, deși în ambele cazuri se referea la aceeași imagine a primului produs. Desktop a atins 100 de puncte.

Toate aceste rulări au raportat depășirea limitei de timp de încărcare, așa că am tratat rezultatele ca diagnostice și potențial incomplete. Nu au fost rezultate confirmate PageSpeed Insights și nici date CrUX. Nu este nici o comparație între Hyvä și o altă temă.

În testul mai slab, imaginea s-a descărcat rapid, dar afișarea ei a avut loc mai târziu. Aceasta arată de ce trebuie separat timpul de descărcare de timpul de randare. Simpla comprimare suplimentară a fișierului nu explică o astfel de problemă. Analiza etapelor LCP.

În lucrul la magazin comparăm mai multe teste, mediana și variația, păstrând aceleași condiții. Nu tratăm rapoartele cu erori ca punct de referință stabil. Verificăm și comportamentul după acceptarea cookies, după deschiderea căutării și după adăugarea produsului în coș.

Checklist Magento și Hyvä: drumul către 95–100 de puncte

Lista de mai jos ajută la planificarea auditului și recepției lucrărilor. Nu este o garanție a patru scoruri 100/100. Evaluarea depinde de pagină, configurație, condițiile testului și versiunea Lighthouse. Un rezultat verde nu înlocuiește nici testele manuale de accesibilitate, nici auditul de securitate, nici strategia SEO.

Măsurare și punct de referință

• Au fost analizate pagina principală, categoria, produsul, căutarea și pașii cheie de cumpărare.
• Au fost efectuate măsurări separate pentru mobile și desktop, în mai multe teste comparabile.
• Au fost salvate versiunea instrumentului, profilul dispozitivului, starea consimțămintelor și intervalul rezultatelor; timeout-urile au fost explicate.
• Au fost verificate LCP, INP și CLS din CrUX sau din monitorizarea proprie, dacă sunt disponibile.
• Au fost diferențiate datele unui singur URL de datele întregului domeniu.
• Au fost testate prima vizită, revenirea utilizatorului și funcționarea după interacțiune.

Server, nginx și Varnish — Performance

• Magento funcționează în modul producție, cu resurse statice pregătite corect.
• Paginile publice obțin Varnish HIT; a fost verificat și timpul de răspuns la MISS.
• Cache-ul diferențiază corect variantele de magazin, iar datele private nu ajung în răspunsul comun.
• Modificarea produsului, prețului sau conținutului invalidează corect cache-ul corespunzător.
• Nginx comprimă resursele text adecvate și deservește un protocol HTTP modern.
• Fișierele versionate au anteturi cache adecvate; HTML-ul și răspunsurile private au o politică separată.
• PHP-FPM, OPcache și backend cache sunt configurate conform versiunii Magento și resurselor serverului.
• Cron, indexarea, importurile și boții nu provoacă vârfuri ale timpului de răspuns.

Module, JavaScript și CSS — Performance

• Fiecare modul activ are o justificare de business; au fost eliminate duplicările inutile de funcții.
• Integrările Hyvä nu readuc inutil dependențele grele ale frontendului anterior.
• JS și CSS ale modulelor ajung doar pe paginile care le folosesc funcțiile.
• Scripturile au fost amânate păstrând dependențele, ordinea și evenimentele de inițializare.
• Au fost testate selectiv x-defer și încărcarea componentelor la utilizare.
• Stilurile critice sunt disponibile înainte de prima randare; nu apare clipirea layoutului.
• GTM, pixelii, chatul și widgeturile au trigger-ele și costul de pornire revizuite.
• Modificările analytics păstrează comportamentul agreat al consimțămintelor și evenimentele e-commerce corecte.
• HTML, DOM și JSON-LD nu conțin date inutile, duplicate.
• Coșul, filtrele, sortarea, paginarea și checkout funcționează după optimizare.

Imagini și stabilitatea layoutului — Performance

• Grafica are dimensiuni, calitate și format adecvate; transferul real a fost verificat.
• Variantele responsive ale imaginilor corespund dimensiunilor de afișare.
• Elementul LCP a fost identificat separat pentru mobile și desktop.
• Imaginea LCP nu este întârziată de lazy loading sau de inițializare JS inutilă.
• Prioritate ridicată a fost acordată doar resurselor justificate.
• Imaginile, bannerele și conținutul încorporat au spațiu rezervat în layout.
• Au fost verificate logo-ul, favicon, grafica CMS și imaginile adăugate de module.
• Procesul de publicare a imaginilor noi include generarea variantelor optimizate.

Culori și operarea interfeței — Accessibility

• Textul, prețurile, butoanele și mesajele au contrastul necesar pe fundalurile reale.
• A fost verificat contrastul controalelor importante și vizibilitatea focusului de la tastatură.
• Eroarea, promoția și selecția nu sunt comunicate exclusiv prin culoare.
• Linkurile și butoanele au nume accesibile inteligibile; formularele au etichete.
• Imaginile informative au text alternativ adecvat, iar cele decorative au alt gol.
• Meniul, filtrele, popup-urile și coșul pot fi operate de la tastatură.
• Au fost verificate mărirea paginii, ecranul mic și utilizarea de bază cu un cititor de ecran.

Calitate tehnică — Best Practices

• Pagina și resursele sale funcționează prin HTTPS, fără mixed content.
• Au fost explicate erorile din consolă, cererile eșuate și avertismentele indicate de audit.
• Bibliotecile și modulele sunt întreținute; vulnerabilitățile raportate au fost revizuite.
• Imaginile își păstrează proporțiile, iar funcțiile nu folosesc inutil API-uri învechite.
• Scorul ridicat a fost confirmat împreună cu plăți, formulare și consimțăminte funcționale.

Vizibilitate tehnică — SEO

• Paginile destinate indexării returnează statusul corect și nu au noindex accidental.
• robots.txt nu blochează paginile sau resursele necesare.
• Titlul și meta description corespund conținutului paginii.
• Canonical este corect; versiunile lingvistice și hreflang au fost revizuite separat.
• Linkurile de navigare pot fi citite de roboți, iar paginarea funcționează corect.
• Datele structurate au fost verificate cu un instrument separat și corespund conținutului vizibil.
• Au fost revizuite sitemap-ul și indexarea în Search Console — și în afara scorului Lighthouse.

Testele automate de accesibilitate acoperă doar o parte dintre problemele posibile. Chiar și un scor 100 necesită completare cu un test manual. Cum se calculează accesibilitatea în Lighthouse.

De unde să începi lucrările în magazinul tău?

Mai întâi stabilim ce așteaptă clientul. Dacă așteaptă răspunsul serverului — începem cu backendul și cache-ul. Dacă așteaptă imaginea — verificăm detectarea, descărcarea și afișarea acesteia. Dacă pagina este vizibilă, dar reacționează cu întârziere — analizăm activitatea JavaScriptului și componentelor.

Apoi implementăm un grup logic de îmbunătățiri și repetăm măsurările și testele de cumpărare. Astfel se știe ce a ajutat și dacă efortul schimbării a fost justificat. Simpla atingere a pragurilor Core Web Vitals nu garantează un scor de 95: Performance este calculat din mai multe metrici ponderate. Regulile de punctare Lighthouse.

Hyvä permite să începi de la un frontend ușor. Menținerea acestui avantaj necesită decizii conștiente la fiecare modul, banner și instrument de marketing următor. De aceea, merită să tratezi performanța ca pe un criteriu de recepție a implementărilor ulterioare, nu ca pe un proiect punctual încheiat cu o captură de ecran cu un rezultat verde.

Dacă planifici o implementare Hyvä sau vrei să accelerezi un magazin existent, contactează echipa kowal.store. Punctul de plecare ar trebui să fie un audit al paginilor concrete și al parcursului de cumpărare — cu o listă de cauze, priorități și măsurări înainte și după modificări.