- Core Web Vitals, LCP, Performance Shopify, Sviluppo Liquid
- Francesco Guiducci
Page Builder o Liquid su Shopify? Performance e Manutenzione
Risposta diretta: un page builder non rallenta automaticamente Shopify e Liquid non rende automaticamente veloce uno store. La scelta corretta dipende da markup generato, JavaScript, dipendenze, autonomia richiesta al merchant, funzioni necessarie e manutenzione futura. Prima di sostituire una tecnologia misuro la pagina reale e confronto il costo con il valore che quella soluzione porta.
Nel mio lavoro parto quasi sempre dalle possibilità native di Shopify Online Store 2.0 e del tema. Non uso page builder come baseline, ma questo non significa che li considero sempre sbagliati: possono avere senso quando l’autonomia editoriale richiesta supera ciò che il tema offre e il costo tecnico rimane accettabile.
Decisione corretta
Non scegliere tra “builder” e “Liquid” in astratto. Confronta la funzione reale che devi ottenere, le risorse che aggiunge, quanto spesso verrà modificata e chi dovrà mantenerla fra sei mesi.
1. Cosa cambia davvero tra page builder, sezioni native e Liquid custom
| Approccio | Punto forte | Rischio principale | Quando lo considero |
|---|---|---|---|
| Sezioni native del tema | Integrazione e manutenzione più semplici | Limiti di configurabilità | Prima scelta se coprono il requisito |
| Liquid / sezione custom | Controllo su markup, CSS, logica tema e impostazioni | Codice da mantenere e testare | Quando il requisito è stabile e appartiene allo storefront |
| Page builder | Autonomia editoriale e landing complesse | Dipendenze, asset aggiuntivi e lock-in | Quando il team deve produrre frequentemente layout fuori dal tema |
| App / backend | Logica applicativa, dati persistenti, API | Maggiore complessità di sistema | Quando la funzione non è realmente “tema” |
2. Un page builder rallenta Shopify?
Può aggiungere script, fogli di stile, wrapper HTML, font, componenti e dipendenze che il tema non avrebbe caricato da solo. L’impatto però cambia molto in base allo strumento, alle sezioni usate e al modo in cui vengono caricati gli asset. Per questo il nome del builder non è una diagnosi.
Controllo richieste di rete, JavaScript eseguito, CSS, dimensione del DOM, elemento LCP e interazioni principali. Se il problema è un’immagine hero enorme, un’app esterna o uno script di tracking, riscrivere la pagina in Liquid può lasciare intatto il vero collo di bottiglia.
Esempio pratico
Una landing costruita con un builder può risultare lenta perché carica un video above-the-fold e tre widget esterni. Ricostruirla in Liquid senza cambiare video e widget può produrre un miglioramento minimo. Prima si misura la causa, poi si decide se il builder è parte del problema.
3. Quando preferisco le sezioni native del tema
Se il tema offre già una sezione che copre il requisito con impostazioni sufficienti, preferisco riutilizzarla. Significa meno codice proprietario, meno dipendenze e un’esperienza più coerente nel Theme Editor.
Prima di sviluppare una nuova sezione controllo quindi se posso ottenere lo stesso risultato con composizione, blocchi, metafield e impostazioni già disponibili. “Custom” non è automaticamente migliore.
4. Quando preferisco Liquid e sezioni custom
Liquid è adatto quando la funzione appartiene stabilmente allo storefront: una sezione editoriale, una griglia, un componente prodotto, un blocco con metafield, una logica di presentazione o una configurazione che il merchant deve gestire dal Theme Editor.
Una buona sezione custom non dovrebbe essere un pezzo di HTML rigido. La progetto con schema, setting, blocchi, limiti ragionevoli e comportamento responsive, in modo che il merchant possa modificarla senza entrare nel codice.
Una sezione custom è pronta quando
- usa impostazioni coerenti con il Theme Editor;
- non duplica una funzione già disponibile in Shopify o nel tema;
- carica CSS/JS solo quando servono;
- gestisce mobile e contenuti lunghi;
- ha fallback sensati se un campo è vuoto;
- non rompe editor, traduzioni, app block o componenti collegati;
- può essere mantenuta senza ricordare “trucchi” nascosti nel codice.
5. Quando Liquid non è il livello giusto
Se la funzione richiede autenticazione, chiamate API protette, webhook, elaborazione asincrona, dati persistenti, billing o processi esterni, il tema non è il posto corretto. In quel caso valuto un’app Shopify o un servizio backend separato.
Forzare logica applicativa dentro Custom Liquid o JavaScript pubblico crea spesso un sistema fragile e difficile da mettere in sicurezza. Il tema dovrebbe presentare dati e interazioni frontend; non sostituire un backend quando serve davvero un backend.
6. Il costo nascosto: manutenzione e dipendenze
La performance non è l’unico criterio. Una soluzione può essere veloce oggi ma costosa da mantenere, oppure leggermente più pesante ma molto più semplice da gestire per chi pubblica landing ogni settimana.
| Domanda | Perché conta |
|---|---|
| Chi modifica la pagina? | Un merchant non tecnico può avere bisogno di più autonomia rispetto a uno store seguito da uno sviluppatore. |
| Quanto spesso cambia? | Una landing settimanale ha esigenze diverse da una sezione stabile della PDP. |
| Cosa succede se rimuovo l’app? | Devo conoscere asset, template, metafield e contenuti che dipendono dal builder. |
| Gli asset vengono caricati ovunque? | Una funzione usata su una sola pagina non dovrebbe necessariamente pesare su tutto lo store. |
| Il tema può essere aggiornato? | Codice e integrazioni devono restare comprensibili anche dopo modifiche future. |
7. Come confronto due soluzioni senza falsare il test
Non confronto due pagine con immagini, contenuti e funzioni diverse. Cerco di mantenere costante ciò che posso, altrimenti non saprei attribuire la differenza alla tecnologia.
- salvo una baseline della pagina reale su mobile e desktop;
- identifico LCP, INP, CLS, richieste di rete e script principali;
- definisco la stessa funzione da confrontare;
- mantengo contenuti e asset il più possibile equivalenti;
- misuro dipendenze aggiunte e JavaScript eseguito;
- provo il Theme Editor e l’autonomia del merchant;
- faccio regression su menu, varianti, ricerca, carrello, tracking e app;
- valuto il costo futuro di manutenzione, non soltanto il test di laboratorio.
8. Come migro da un page builder a Liquid senza rompere le pagine
La sequenza corretta parte dall’inventario, non dalla disinstallazione.
- Mappo le pagine: quali template e landing dipendono dal builder?
- Inventario le funzioni: quali componenti servono davvero e quali sono residui?
- Controllo dati e dipendenze: metafield, app block, script, asset, snippet.
- Ricostruisco su una copia del tema: sezioni e blocchi necessari.
- Confronto contenuto e funzioni: URL, heading, media, form, tracking, CTA.
- Testo mobile e desktop: inclusi edge case e contenuti lunghi.
- Solo alla fine rimuovo ciò che non serve più.
Errore da evitare
Disinstallare il builder come primo passo e scoprire dopo che alcune pagine, metafield o asset dipendevano ancora da lui.
9. Page builder e SEO: cosa controllo davvero
Non considero un page builder “non SEO” per definizione. Controllo l’output reale: heading, link, contenuto disponibile nell’HTML, immagini, performance, canonical e duplicazioni. Se il builder produce una pagina accessibile, coerente e utile, il nome dello strumento non è il punto.
Il problema nasce quando la tecnologia introduce markup ridondante, contenuti duplicati, dipendenze inutili o rende difficile mantenere una struttura coerente nel tempo. Anche una sezione Liquid scritta male può fare esattamente gli stessi danni.
10. Quale soluzione scelgo nei miei progetti Shopify
La mia baseline è Online Store 2.0 senza page builder: prima sezioni native, poi sviluppo custom quando serve. È la soluzione che mi permette di controllare meglio dipendenze e manutenzione nei progetti che seguo personalmente.
Questo però non diventa una regola assoluta per diagnosticare store esistenti. Se entro in un progetto che usa già un builder, prima verifico se sta causando un problema reale e quanto costerebbe sostituirlo. Rimuovere una tecnologia funzionante solo per uniformarsi alla mia preferenza sarebbe un intervento senza evidenza.
Checklist decisionale
- Il tema copre già la funzione?
- La funzione appartiene allo storefront o richiede backend/API?
- Chi deve modificarla e con quale frequenza?
- Quante risorse aggiunge allo storefront?
- Carica asset anche dove non viene usata?
- Che dipendenza crea da app o fornitore?
- Come si comporta su mobile?
- Cosa succede se la soluzione viene rimossa?
- Come verrà testata dopo un aggiornamento del tema?
- Il beneficio editoriale giustifica il costo tecnico?
Sono Francesco Guiducci, Shopify specialist freelance e sviluppatore di app Shopify. Se devi capire se il problema è davvero nel page builder, nel tema o nelle app, questi controlli rientrano nel mio Audit Shopify.
Aggiornato il 13 settembre 2026.
