Con il template Hyvä Magento 2 funzionerà sempre più velocemente rispetto a qualsiasi altro template?

Immagina due negozi Magento. Il primo usa Hyvä, ma all’ingresso avvia una dozzina di strumenti di marketing, scarica immagini molto pesanti e ogni volta genera la pagina da zero. Il secondo ha un altro tema, ottimizzato con cura, una cache efficiente e solo gli script di cui il cliente ha bisogno.

Quale sarà più veloce? Il nome del template non basta per rispondere.

Hyvä offre a Magento un ottimo punto di partenza per costruire uno store veloce. Tuttavia, non garantisce un vantaggio incondizionato rispetto a qualsiasi altra implementazione. Il risultato dipende dall’intero percorso tra il clic sul link e il momento in cui il cliente vede il prodotto e può acquistarlo.

Per questo conviene abbinare l’implementazione di Hyvä a una revisione del server, dei moduli, delle immagini e del progetto dell’interfaccia. Solo così si può lavorare verso un obiettivo ambizioso: 95–100 punti in Google PageSpeed Insights, mantenendo le funzionalità necessarie alla vendita.

Che cosa significa davvero un punteggio 95–100 in PageSpeed?

Nel linguaggio comune si parla di 100% in PageSpeed, ma lo strumento presenta punti su una scala da 0 a 100. Nella parte basata su Lighthouse valuta quattro aree diverse:

Queste valutazioni non si sostituiscono a vicenda. Uno store veloce può avere pulsanti poco leggibili. Uno store tecnicamente corretto può scaricare troppo JavaScript. Lighthouse è uno strumento diagnostico e il perimetro dei suoi audit non copre l’intera qualità dello store. Descrizione di Lighthouse.

Il punteggio Performance deriva da una misurazione di laboratorio e può variare tra un test e l’altro. PageSpeed mostra anche, quando disponibili, i dati degli utenti reali provenienti da CrUX, raccolti in un periodo mobile di 28 giorni. Una nuova implementazione non cambia subito l’intero set di dati. Come funziona PageSpeed Insights.

Nella pratica servono due obiettivi: test ripetibilmente buoni e una buona esperienza per i clienti. Per i Core Web Vitals significa:

• LCP fino a 2,5 s — comparsa rapida dell’elemento più grande nell’area visibile;
• INP fino a 200 ms — risposta efficiente alle interazioni;
• CLS fino a 0,1 — layout della pagina stabile.

Queste soglie vengono valutate al 75° percentile, separatamente per dispositivi mobili e desktop. Il test standard di caricamento Lighthouse non misura l’INP; per diagnosticare il blocco del browser utilizza, tra gli altri, il TBT. Un TBT basso non è una conferma automatica di un buon INP. Core Web Vitals.

In che modo Hyvä aiuta ad accelerare Magento?

Hyvä riduce il peso del frontend rispetto alla Luma standard. Utilizza Alpine.js per le interazioni e Tailwind CSS per lo stile. Meno codice da scaricare ed eseguire lascia al browser più spazio per mostrare rapidamente l’offerta. La documentazione Hyvä indica la riduzione di JavaScript e CSS come una parte importante di questa architettura. Prestazioni di Hyvä.

Il vantaggio, però, può ridursi facilmente. Basta aggiungere a un frontend leggero uno slider complesso, una chat, diversi tracker e moduli che portano con sé le vecchie dipendenze del tema precedente.

Hyvä non risolverà nemmeno una query lenta al database, una cache non funzionante o un server impegnato con un import. Per questo, prima dell’implementazione, la domanda dovrebbe essere: che cosa oggi rallenta l’acquisto e quali di questi problemi saranno risolti dal cambio del frontend?

1. Server: nginx e Varnish devono svolgere il lavoro corretto

Prima che il browser mostri il prodotto, deve ricevere il documento HTML. Se attende a lungo il primo byte della risposta, anche un tema leggero parte in ritardo.

Nginx: distribuzione efficiente delle risorse

In una tipica architettura Magento, nginx gestisce tra l’altro HTTPS, file statici e inoltro delle richieste ai servizi successivi. Vale la pena verificare la compressione delle risposte testuali, HTTP/2 e gli header di cache per i file CSS e JS versionati. Adobe fornisce una configurazione nginx di esempio come punto di partenza per un’implementazione con Varnish. Configurazione di Varnish in Adobe Commerce.

Non bisogna assegnare a tutte le risposte lo stesso tempo di conservazione. Un foglio CSS versionato può essere utilizzato a lungo dalla cache del browser. Prezzo, contenuto del carrello e risposta relativa al cliente autenticato richiedono un trattamento diverso.

Se il server sceglie WebP in base all’header Accept, occorre verificare anche la chiave di cache e l’header Vary: Accept. Il browser e i livelli intermedi di cache devono distinguere le varianti dell’immagine.

Varnish: verifichiamo gli hit in cache, non solo l’installazione del servizio

Varnish consente di servire le pagine pubbliche dalla cache senza far rieseguire a Magento tutto il lavoro. Adobe ne raccomanda l’utilizzo nell’ambiente di produzione. Gestione della cache Magento.

Il test pratico è semplice: apriamo più volte lo stesso indirizzo pubblico e verifichiamo se, dopo la prima risposta, compaiono hit HIT. Poi confrontiamo il tempo di risposta dalla cache con il tempo di generazione della pagina con MISS.

Se una categoria popolare bypassa costantemente la cache, bisogna trovare la causa: configurazione, cookies, parametri dell’indirizzo, personalizzazione o modalità di funzionamento del modulo. Acquistare un server più potente può allora solo mascherare il problema.

È importante anche la correttezza. La cache non può rendere disponibili il carrello o i dati di un cliente a un altro utente. Bisogna testare varianti dello store, valute e gruppi cliente, oltre all’aggiornamento dei contenuti dopo una modifica del prodotto. Un prezzo veloce ma non aggiornato non è un successo dell’ottimizzazione.

Oltre a nginx e Varnish, verifichiamo PHP-FPM, OPcache, backend cache compatibile con la versione Magento, database, cron e indicizzazione. Il numero di processi PHP dovrebbe derivare dalla memoria disponibile e dal carico reale. Aumentarlo senza misurazioni può peggiorare la situazione.

2. Moduli per Hyvä: la compatibilità è solo l’inizio

Un modulo può funzionare correttamente con Hyvä e continuare comunque a svolgere troppo lavoro all’ingresso nella pagina. Una buona ottimizzazione comprende quindi sia la funzione sia il costo del suo avvio.

In kowal.store adattiamo i nostri moduli a Hyvä e li sviluppiamo pensando a preservare le prestazioni di questo tema dopo l’installazione. Facciamo in modo che le nuove funzioni non appesantiscano inutilmente il frontend — limitando le dipendenze e scegliendo un modo adeguato di caricare JavaScript e CSS. Scopri i nostri moduli Magento 2 e scegli le estensioni per il tuo store. L’effetto di una specifica implementazione va confermato con una misurazione, perché dipende anche dalla configurazione e dalle altre integrazioni.

Prendiamo la chat. All’inizio, un cliente che consulta una categoria ha bisogno del pulsante per aprire la conversazione. L’interfaccia completa della chat e le sue librerie possono essere scaricate al momento dell’apertura. Allo stesso modo, i suggerimenti completi della ricerca possono essere preparati quando si entra nel campo di ricerca, lasciando subito visibile e funzionante il modulo.

Questo approccio è descritto anche da Hyvä nelle raccomandazioni relative al caricamento di JavaScript esterno.

defer, async e il rinvio del componente sono cose diverse

defer consente di eseguire uno script classico esterno dopo l’elaborazione del documento e di mantenere l’ordine degli script di questo tipo. async esegue lo script quando è pronto, senza garanzia di ordine rispetto agli altri. Nessuno di questi attributi, da solo, significa che il file verrà scaricato solo dopo il clic.

Hyvä mette a disposizione anche x-defer, con cui è possibile ritardare l’inizializzazione di un componente Alpine, per esempio fino all’avvicinamento all’area visibile. Non è un rinvio automatico del download di tutti i suoi file. Bisogna inoltre ricordare gli eventi che il componente potrebbe perdere prima dell’inizializzazione, per esempio quelli legati ai dati del cliente. Documentazione x-defer.

Le modifiche vanno verificate su carrello, filtri, moduli ed eventi di analytics. La sola presenza dell’attributo defer non dimostra che il modulo sia ottimizzato correttamente.

CSS: l’aspetto necessario deve essere pronto prima del primo rendering

Gli stili dell’header, della lista prodotti e del layout mobile sono necessari fin dall’inizio. Un loro caricamento troppo tardivo può causare sfarfallii della pagina e spostamenti degli elementi. Allo stesso tempo, una categoria prodotti non deve scaricare tutti gli stili di ogni modulo installato.

Vale la pena limitare i fogli di stile globali, rimuovere i residui del vecchio tema e controllare la build di produzione di Tailwind. Con classi create dinamicamente, bisogna assicurarsi che le regole necessarie finiscano nel CSS risultante. Il CSS critico incorporato nell’HTML può aiutare, ma richiede manutenzione e test; non dovrebbe essere la prima risposta a ogni problema. Risorse che bloccano il rendering.

Anche analytics e dati SEO hanno un costo

Lavorando all’ottimizzazione di uno store su Magento 2, abbiamo verificato il carico degli analytics sulla pagina di categoria. GTM e gtag rappresentavano circa 304 KB, cioè il 44% del trasferimento registrato nella prima misurazione mobile. È un buon motivo per rivedere tag e trigger. Non significa però che si debba rinviare tutta l’analytics senza riflettere: una modifica del genere può cambiare il numero di visite ed eventi registrati.

Vale la pena guardare anche all’HTML stesso. Dati JSON-LD estesi, informazioni di prodotto duplicate e configurazioni dei moduli aumentano la risposta del server. JSON-LD non viene eseguito come un normale programma JavaScript, ma deve comunque essere trasferito. I dati strutturati della categoria dovrebbero corrispondere alla lista visibile, alla sua paginazione e al suo ordine.

3. Immagini: contano formato, dimensione e momento del download

Un’immagine sorgente larga diverse migliaia di pixel non dovrebbe finire senza motivo in una piccola tessera prodotto. Prepariamo varianti adatte alla dimensione di visualizzazione e alla densità dello schermo, mentre srcset e sizes aiutano il browser a scegliere il file corretto. WebP o AVIF vanno confrontati in termini di qualità e peso sulle immagini specifiche.

La distinzione più importante riguarda le immagini visibili subito e quelle più in basso. L’immagine che costituisce l’LCP dovrebbe essere facile da individuare nell’HTML, senza loading='lazy'; può essere giustificato fetchpriority='high'. Le immagini fuori dalla prima schermata sono buone candidate al lazy loading. Dimensioni o proporzioni riservano loro spazio nel layout. Immagini responsive.

Non assegniamo però priorità alta a ogni immagine. Il browser ha bisogno di sapere che cosa è davvero più importante. Fetch Priority.

Controlliamo anche banner CMS, logo, favicon, miniature dei video e grafiche dei popup. L’ottimizzazione deve includere il processo di aggiunta di nuovi file, altrimenti la campagna successiva riporterà immagini pesanti.

Il solo indirizzo che termina con .png non determina che cosa scarica il browser. Il server può fornire WebP a quell’indirizzo. Verifichiamo Content-Type e trasferimento nella scheda Network.

4. Colori: il loro impatto maggiore si vede nell’accessibilità

Cambiare un pulsante blu in verde non renderà Magento più veloce. Il colore, però, ha grande importanza per la leggibilità e per il punteggio Accessibility.

Più spesso i problemi sono causati da descrizioni grigio chiaro, pulsanti pastello con testo bianco, etichette promozionali e testo sulle immagini. Secondo le WCAG, il contrasto del testo normale dovrebbe essere almeno 4,5:1, mentre quello del testo grande 3:1. Per testo grande si intende almeno 18 pt, cioè circa 24 px, oppure 14 pt in grassetto, cioè circa 18,7 px. Requisiti di contrasto del testo.

Per gli elementi visivi importanti dei controlli e delle indicazioni del loro stato vale anche il requisito di contrasto 3:1 rispetto ai colori adiacenti, con le eccezioni descritte nello standard. Contrasto degli elementi non testuali.

Conviene definire la palette in modo centralizzato, per esempio tramite variabili CSS o configurazione del modulo colori. In questo modo la modifica del colore del testo o dei pulsanti interessa l’intero store. Bisogna controllare anche stati hover, focus, errori dei form e filtri selezionati. Un bordo rosso non dovrebbe essere l’unica informazione che indica che un campo contiene un errore.

Sulle prestazioni può incidere il modo in cui l’aspetto viene implementato: fogli di stile aggiuntivi, uno script che modifica i colori dopo il caricamento oppure effetti visivi pesanti. La palette in sé, però, non sostituisce l’ottimizzazione di JS, immagini e server.

Perché un solo buon risultato non basta?

Ottimizzando uno store su Magento 2 con Hyvä, abbiamo eseguito due misurazioni Lighthouse locali per la stessa pagina di categoria. Su mobile abbiamo ottenuto 94 e 73 punti. LCP è stato rispettivamente di 2,5 e 5,7 s, anche se in entrambi i casi riguardava la stessa immagine del primo prodotto. Desktop ha raggiunto 100 punti.

Tutte queste esecuzioni hanno segnalato il superamento del tempo massimo di caricamento, quindi abbiamo trattato i risultati come diagnostici e potenzialmente incompleti. Non erano risultati PageSpeed Insights confermati né dati CrUX. Non si tratta nemmeno di un confronto tra Hyvä e un altro tema.

Nel test peggiore l’immagine è stata scaricata rapidamente, ma la sua visualizzazione è avvenuta più tardi. Questo mostra perché bisogna separare il tempo di download dal tempo di rendering. Comprimere ulteriormente il file, da solo, non spiega un problema del genere. Analisi delle fasi LCP.

Nel lavoro sullo store confrontiamo diversi test, mediana e dispersione, mantenendo le stesse condizioni. Non trattiamo i report con errori come riferimento stabile. Verifichiamo anche il comportamento dopo l’accettazione dei cookies, dopo l’apertura della ricerca e dopo l’aggiunta di un prodotto al carrello.

Checklist Magento e Hyvä: il percorso verso 95–100 punti

La lista seguente aiuta a pianificare audit e accettazione dei lavori. Non è una garanzia di quattro risultati 100/100. La valutazione dipende dalla pagina, dalla configurazione, dalle condizioni del test e dalla versione di Lighthouse. Un risultato verde non sostituisce nemmeno i test manuali di accessibilità, l’audit di sicurezza o la strategia SEO.

Misurazione e punto di riferimento

• Sono stati analizzati homepage, categoria, prodotto, ricerca e passaggi d’acquisto chiave.
• Sono state eseguite misurazioni separate mobile e desktop, in più prove comparabili.
• Sono stati registrati versione dello strumento, profilo del dispositivo, stato dei consensi e intervallo dei risultati; i timeout sono stati spiegati.
• Sono stati verificati LCP, INP e CLS da CrUX o dal monitoraggio interno, se disponibili.
• Sono stati distinti i dati di un singolo URL dai dati dell’intero dominio.
• Sono stati testati prima visita, ritorno dell’utente e funzionamento dopo l’interazione.

Server, nginx e Varnish — Performance

• Magento funziona in modalità produzione, con risorse statiche preparate correttamente.
• Le pagine pubbliche raggiungono Varnish HIT; è stato verificato anche il tempo di risposta con MISS.
• La cache distingue correttamente le varianti dello store e i dati privati non finiscono in una risposta condivisa.
• La modifica di prodotto, prezzo o contenuto invalida correttamente la cache appropriata.
• Nginx comprime le risorse testuali adeguate e supporta un protocollo HTTP moderno.
• I file versionati hanno header di cache adeguati; HTML e risposte private hanno una policy separata.
• PHP-FPM, OPcache e backend cache sono configurati in base alla versione Magento e alle risorse del server.
• Cron, indicizzazione, import e bot non causano picchi del tempo di risposta.

Moduli, JavaScript e CSS — Performance

• Ogni modulo attivo ha una giustificazione di business; sono stati rimossi duplicati funzionali non necessari.
• Le integrazioni Hyvä non ripristinano senza necessità pesanti dipendenze del frontend precedente.
• JS e CSS dei moduli arrivano solo sulle pagine che usano le loro funzioni.
• Gli script sono stati rinviati mantenendo dipendenze, ordine ed eventi di inizializzazione.
• Sono stati testati x-defer selettivo e caricamento dei componenti all’uso.
• Gli stili critici sono disponibili prima del primo rendering; non compare sfarfallio del layout.
• GTM, pixel, chat e widget hanno trigger e costo di avvio verificati.
• Le modifiche all’analytics mantengono il comportamento dei consensi concordato e gli eventi e-commerce corretti.
• HTML, DOM e JSON-LD non contengono dati inutili o duplicati.
• Carrello, filtri, ordinamento, paginazione e checkout funzionano dopo l’ottimizzazione.

Immagini e stabilità del layout — Performance

• Le grafiche hanno dimensioni, qualità e formato adeguati; il trasferimento reale è stato verificato.
• Le varianti responsive delle immagini corrispondono alle dimensioni di visualizzazione.
• L’elemento LCP è stato identificato separatamente per mobile e desktop.
• L’immagine LCP non è ritardata da lazy loading o da inizializzazione JS superflua.
• La priorità alta è stata assegnata solo a risorse giustificate.
• Immagini, banner e contenuti incorporati hanno spazio riservato nel layout.
• Sono stati verificati logo, favicon, grafiche CMS e immagini aggiunte dai moduli.
• Il processo di pubblicazione di nuove immagini include la generazione di varianti ottimizzate.

Colori e gestione dell’interfaccia — Accessibility

• Testo, prezzi, pulsanti e messaggi hanno il contrasto richiesto sugli sfondi reali.
• Sono stati verificati il contrasto dei controlli importanti e la visibilità del focus da tastiera.
• Errore, promozione e selezione non sono comunicati solo tramite colore.
• Link e pulsanti hanno nomi accessibili comprensibili; i form hanno etichette.
• Le immagini informative hanno un testo alternativo adeguato e quelle decorative un alt vuoto.
• Menu, filtri, popup e carrello possono essere gestiti da tastiera.
• Sono stati verificati ingrandimento della pagina, schermo piccolo e uso di base con screen reader.

Qualità tecnica — Best Practices

• La pagina e le sue risorse funzionano tramite HTTPS, senza mixed content.
• Sono stati spiegati errori di console, richieste non riuscite e avvisi indicati dall’audit.
• Librerie e moduli sono mantenuti; le vulnerabilità segnalate sono state esaminate.
• Le immagini mantengono le proporzioni e le funzioni non usano inutilmente API obsolete.
• Il punteggio alto è stato confermato insieme al corretto funzionamento di pagamenti, form e consensi.

Visibilità tecnica — SEO

• Le pagine destinate all’indicizzazione restituiscono lo stato corretto e non hanno noindex accidentale.
• robots.txt non blocca pagine o risorse necessarie.
• Title e meta description corrispondono al contenuto della pagina.
• Il canonical è corretto; versioni linguistiche e hreflang sono stati esaminati separatamente.
• I link di navigazione sono leggibili dai crawler e la paginazione funziona correttamente.
• I dati strutturati sono stati verificati con uno strumento separato e corrispondono al contenuto visibile.
• Sono stati esaminati sitemap e indicizzazione in Search Console, anche al di fuori del punteggio Lighthouse.

I test automatici di accessibilità coprono solo una parte dei possibili problemi. Anche un punteggio 100 richiede l’integrazione con un test manuale. Come viene calcolata l’accessibilità in Lighthouse.

Da dove iniziare a lavorare sul proprio store?

Per prima cosa stabiliamo che cosa sta aspettando il cliente. Se aspetta la risposta del server — iniziamo da backend e cache. Se aspetta un’immagine — verifichiamo individuazione, download e visualizzazione. Se la pagina è visibile ma risponde in ritardo — analizziamo il lavoro di JavaScript e dei componenti.

Poi implementiamo un gruppo logico di correzioni e ripetiamo misurazioni e test di acquisto. Così sappiamo che cosa ha aiutato e se il costo della modifica era giustificato. Il solo raggiungimento delle soglie Core Web Vitals non garantisce un risultato di 95: Performance viene calcolato da diverse metriche ponderate. Regole di punteggio Lighthouse.

Hyvä permette di partire da un frontend leggero. Mantenere questo vantaggio richiede decisioni consapevoli a ogni nuovo modulo, banner e strumento di marketing. Conviene quindi trattare le prestazioni come criterio di accettazione delle implementazioni successive, non come un progetto una tantum concluso con uno screenshot dal risultato verde.

Se stai pianificando un’implementazione Hyvä o vuoi accelerare uno store esistente, contatta il team kowal.store. Il punto di partenza dovrebbe essere un audit di pagine specifiche e del percorso d’acquisto — con un elenco di cause, priorità e misurazioni prima e dopo le modifiche.