Hyvä, PWA o restare su Luma? Un quadro decisionale per il front-end Magento con costi reali

Se gestisce uno store Magento 2, qualcuno le avrà già detto che il problema è il front end. Spesso è vero. Luma — il tema predefinito di Magento — invia RequireJS e Knockout.js a ogni visitatore, e su uno smartphone Android di fascia media solo questo stack può costare due secondi prima che appaia la prima immagine prodotto.

Ma il front end è lento è un sintomo, non una soluzione. Le tre opzioni sul tavolo — migrare a Hyvä, costruire uno storefront PWA o ottimizzare il tema Luma esistente — differiscono di circa un ordine di grandezza sia per costi che per rischio. Scegliere male è uno degli errori più costosi per un merchant Magento, e chi le propone una soluzione di solito vende solo una delle tre.

Noi realizziamo tutte e tre le soluzioni. Questo è il framework che usiamo internamente prima di qualsiasi preventivo, anche nei casi in cui consigliamo di non spendere nulla.

Le tre opzioni, descritte senza filtri

Opzione 1: ottimizzare il tema Luma esistente

L'opzione che nessuno propone, perché è la fattura più bassa. Luma è lento soprattutto per ciò che vi è stato aggiunto: estensioni di terze parti che iniettano JavaScript, moduli RequireJS non raggruppati, media non ottimizzati, una cache di pagina intera che manca più spesso di quanto si pensi e una configurazione Varnish valida tre anni fa.

Un'ottimizzazione disciplinata — audit delle estensioni, CSS critico, JavaScript differito, pipeline immagini, cache warming, tuning di database e Redis — porta regolarmente uno store Luma da un Core Web Vitals insufficiente a uno sufficiente. Non a un punteggio Lighthouse di 100. A uno sufficiente, che è ciò che incide davvero su ranking e conversioni.

• Costo tipico: £8.000–£25.000 a seconda del debito da estensioni
• Durata tipica: 4–8 settimane, con rilascio incrementale su store attivo
• Rischio: basso — ogni modifica è reversibile e la struttura dello storefront non cambia
• Limite superiore: reale. Esiste un limite alla velocità raggiungibile con Luma, e le pagine categoria pesanti resteranno tali

Questo è il lavoro che svolgiamo nell'ambito di ottimizzazione della velocità, ed è il punto di partenza nella maggior parte degli incarichi — anche in quelli che poi portano a una migrazione completa del front end. Capire quali problemi dipendono dal tema e quali dalle estensioni conviene prima di spendere dieci volte tanto.

Opzione 2: migrare a Hyvä

Hyvä sostituisce il layer tema di Luma con Tailwind CSS e Alpine.js. Catalogo, prezzi, carrello, checkout e amministrazione restano invariati — si tratta di una sostituzione del front end, non di una migrazione di piattaforma. In genere elimina la maggior parte del JavaScript di Luma e produce uno storefront che esegue il rendering server-side veloce di default, non solo dopo ottimizzazione.

Il punto critico, e lo è davvero: ogni estensione con interfaccia storefront va rivista. Hyvä offre un ecosistema di moduli di compatibilità per i vendor più diffusi, ma la coda lunga — il configuratore personalizzato, il metodo di pagamento regionale, il widget loyalty di un vendor fermo al 2023 — rappresenta il vero perimetro del progetto. Abbiamo visto lo stesso store preventivato a prezzi molto diversi da agenzie diverse solo perché una ha contato le estensioni e l'altra no.

• Costo tipico: £30.000–£90.000 per un catalogo medio, più la licenza Hyvä
• Durata tipica: 10–20 settimane
• Rischio: moderato — il frontend viene ricostruito, quindi occorre testare nuovamente l’intero percorso cliente.
• Limite superiore: elevato. Questa è la massima velocità raggiungibile da un frontend Magento tradizionale.

Abbiamo effettuato questa conversione abbastanza volte da poterne valutare gli esiti. Nella nostra conversione di Shirt Tuning da Luma a Hyvä, il catalogo, la logica dei prezzi e del checkout sono rimasti invariati, mentre il frontend è stato sostituito integralmente — questa separazione è ciò che rende la migrazione gestibile. Su PriceGuru abbiamo lavorato direttamente su Hyvä, un progetto sensibilmente più semplice rispetto alla conversione di uno store già avviato.

Opzione 3: realizzare uno storefront PWA

Un’architettura headless: Magento diventa un’API e il frontend è un’applicazione JavaScript separata — PWA Studio, oppure sempre più spesso un frontend Next.js personalizzato che dialoga con GraphQL. Si ottiene piena libertà progettuale, navigazione simile a un’app e la possibilità di collegare il frontend a più backend e-commerce.

Si introduce però una seconda applicazione da gestire, con hosting, pipeline di deployment, monitoraggio, aggiornamenti delle dipendenze e — aspetto critico — una propria superficie SEO che va gestita manualmente invece di essere ereditata. Ogni comportamento nativo del frontend Magento diventa ora una responsabilità diretta. I merchandiser che potevano modificare una pagina dal pannello spesso non possono più farlo.

• Costo tipico: £80.000–£250.000+
• Durata tipica: 5–9 mesi
• Rischio: elevato — si tratta di una nuova applicazione, non di un tema, e cambia il modo di lavorare del team
• Limite superiore: il più alto, ed è l’unica opzione che consente anche l’integrazione futura con backend non-Magento

Il quadro decisionale

Proceda in quest’ordine. Il primo sì onesto è di solito la risposta.

1. Ha davvero misurato o sta reagendo a un punteggio Lighthouse?

Un singolo test Lighthouse sul proprio portatile non è una misurazione. Occorre consultare i dati field di Core Web Vitals in Search Console — visitatori reali, dispositivi reali — e segmentarli per template. La maggior parte degli store Magento che analizziamo ha una homepage che supera i test e pagine categoria che falliscono nettamente: il problema è mirato, non riguarda l’intero frontend.

Se i dati field mostrano LCP fuori soglia nel 60% delle visualizzazioni delle pagine categoria ma le pagine prodotto sono a posto, il problema è nelle pagine categoria. Conviene diagnosticarlo prima che diventi una migrazione.

2. Quanto della lentezza dipende dalle estensioni?

Disattivi le estensioni di terze parti su una copia di staging, un gruppo alla volta, e misuri di nuovo. Troviamo spesso che un singolo tag manager, widget recensioni o script di personalizzazione generi più tempo di blocco dell’intero framework Luma. Se è il caso del suo store, una migrazione a Hyvä la deluderà: pagherà per un nuovo layer grafico e poi caricherà lo stesso script problematico.

3. Sta già pianificando un cambio di design?

Se un rebranding o un redesign completo sono già finanziati, l’equazione cambia radicalmente. Ricostruire i template Luma su un nuovo design costa una frazione rilevante rispetto a realizzarli direttamente in Hyvä, e si resta comunque con uno stack lento. Quando il design è già in roadmap, Hyvä è quasi sempre la scelta corretta anche se la sola performance non lo giustificherebbe.

4. Qual è la situazione del Suo inventario di estensioni?

Conti ogni estensione che mostra qualcosa al cliente. Per ciascuna, verifichi se esiste una versione compatibile con Hyvä, se il fornitore è ancora attivo e se la funzionalità è effettivamente utilizzata. In base alla nostra esperienza, uno store con meno di quindici estensioni rivolte al cliente migra senza problemi; oltre trenta, il lavoro di compatibilità diventa predominante e il preventivo deve rifletterlo.

5. Serve davvero un front end separato?

Una PWA è giustificata da requisiti che il templating di Magento non può soddisfare — frontend su più backend, esperienza app e web con lo stesso codice, percorso cliente realmente applicativo e non da catalogo, o una roadmap che prevede l’uscita da Magento. Desiderare uno stack JavaScript moderno non è un requisito, ma una preferenza — e una preferenza costosa da finanziare con il budget frontend.

Se l’architettura headless è davvero la direzione scelta, conviene confrontare ciò che si costruirebbe su Magento con una piattaforma headless nativa — presentiamo questo confronto nel nostro lavoro di selezione piattaforma.

6. Può permettersi la risposta sbagliata?

Un’ottimizzazione Luma fallita costa qualche settimana. Una migrazione Hyvä fallita costa un trimestre e molta fiducia. Un progetto PWA fallito ha compromesso carriere. Valuti le opzioni in base alle conseguenze di un esito negativo, non solo a quelle di un successo.

Quando consigliamo ai clienti di restare su Luma

Questa è la parte della discussione che le presentazioni commerciali saltano, quindi la riportiamo in modo diretto. Consigliamo di restare su Luma quando:

• I Core Web Vitals field sono già superati e la pressione arriva da un punteggio sintetico, non dai visitatori reali
• Lo store è su una versione Magento da aggiornare prima — esegua prima l’upgrade della piattaforma, poi misuri di nuovo e decida
• Una replatform è prevista nella roadmap a due anni — non investa sei cifre in un frontend che prevede già di dismettere
• L’insieme delle estensioni è enorme e in gran parte personalizzato, e il lavoro di compatibilità supererebbe il valore del guadagno in velocità
• Il vero collo di bottiglia è lato server — un TTFB lento dovuto a un database sottodimensionato o a una cache fredda non è un problema di tema, e nessun frontend lo maschererà
• Le condizioni di mercato rendono il rischio inaccettabile in questo momento — nessuno dovrebbe migrare il frontend a sei settimane dall’alta stagione

Quest’ultimo punto pesa più di quanto i merchant si aspettino. Abbiamo rifiutato lavori di migrazione a settembre più di una volta. Il progetto giusto nel momento sbagliato resta comunque sbagliato.

Costruire il modello di ritorno sull'investimento

Qualunque opzione scelga, il business case si basa sugli stessi numeri. Ne servono quattro, e tre li ha già.

1. Sessioni mensili sui template che intende modificare — non su tutto il sito, solo quelli interessati
2. Tasso di conversione attuale su quei template, suddiviso per dispositivo, perché il divario è quasi sempre sul mobile
3. Valore medio ordine, sempre su quei template
4. Aumento atteso del tasso di conversione — questa è l’unica stima, e deve essere prudente

Su quest’ultimo punto, diffidi di chi le propone una percentuale senza spiegazioni. La posizione corretta è che i miglioramenti di velocità si correlano a un aumento delle conversioni, che l’effetto è maggiore su mobile e su connessioni lente, e che la dimensione dell’effetto varia molto per categoria e valore del carrello. Modelli uno scenario prudente e uno ottimistico, e decida su quello prudente.

Poi divida il costo del progetto per l’aumento mensile del margine lordo nello scenario prudente. Se il payback è inferiore a dodici mesi, il caso è solido. Tra dodici e ventiquattro mesi, è difendibile se il frontend ha altri obiettivi — redesign, canale B2B, nuovo mercato. Oltre ventiquattro mesi nello scenario prudente, sta acquistando altro rispetto a un ritorno economico.

Quanto costa davvero ciascuna opzione

Il costo di realizzazione è il numero che tutti confrontano. Il costo di gestione è quello che determina se la scelta sarà motivo di rimpianto.

Luma non comporta costi aggiuntivi di proprietà, ma tutti quelli di manutenzione: ogni nuova estensione rischia di reintrodurre il peso JavaScript che si era eliminato, quindi il lavoro sulle performance diventa una voce ricorrente e non un progetto una tantum.

Hyvä prevede una licenza annuale e un modesto costo di compatibilità continuativo — le nuove estensioni richiedono versioni compatibili Hyvä, e l’offerta è più limitata. In cambio, le regressioni di performance sono molto più rare, perché la struttura è molto più snella.

Una PWA comporta la gestione di una seconda applicazione in modo permanente: hosting separato, deployment separati, aggiornamenti delle dipendenze separati, patch di sicurezza separate e competenze frontend che il team deve mantenere. Preveda una quota di ingegneria continuativa, non un semplice contratto di manutenzione. Questo è il costo che la maggior parte dei business case PWA omette, ed è quello che pesa dal secondo anno.

Una sequenza ragionevole

Per la maggior parte dei merchant Magento, l’ordine corretto delle operazioni è poco appariscente:

1. Porti lo store su una versione Magento attuale e supportata — tutto il resto è più semplice ed economico su 2.4.9
2. Analizzi e riduca il parco estensioni; dismetta ciò che nessuno utilizza e sostituisca ciò che non può essere reso veloce.
3. Intervenga lato server: ottimizzi il tasso di cache hit, la configurazione del database, la pipeline delle immagini e il profilo di hosting.
4. Rimisuri i Core Web Vitals rilevati sul campo e verifichi cosa resta da risolvere.
5. Solo allora valuti se il divario residuo giustifica una migrazione del front-end.

Chi segue questa sequenza a volte scopre che la migrazione non serve. Chi passa direttamente allo step cinque spesso lo scopre solo dopo averla già pagata.

Se desidera un secondo parere sulla reale situazione del suo store, il nostro team di sviluppo Magento effettuerà le misurazioni e le comunicherà con trasparenza quale delle tre opzioni i dati supportano — anche quando la risposta è nessuna delle tre, per ora. Lo stesso approccio vale per tutti i nostri progetti su piattaforma Magento e, per brand retail, di solito si ripaga già nel primo trimestre dopo il lancio.

Misurare prima di chiedere un preventivo

Prima di investire, la cosa più utile è capire quali problemi dipendono dal tema. Effettueremo questa analisi e le forniremo una risposta onesta, anche quando la risposta è che non ha bisogno di noi. Contatti il nostro team — rispondiamo entro un giorno lavorativo.