Come Aggiungere il Virtual Try-On a BigCommerce

I merchant BigCommerce non possono semplicemente inserire un app-block stile Shopify in un tema e considerare il lavoro finito — la struttura dei template di Stencil fa sì che il posizionamento dello script e gli agganciamenti della pagina prodotto contino davvero. Se il collegamento è sbagliato, il pulsante del try-on non si mostra mai oppure si rompe sul template prodotto più venduto. Questa guida ripercorre le modifiche Stencil reali, in ordine, così il giorno del lancio non si trasforma in una sessione di debug.

Il framework Stencil di BigCommerce separa le responsabilità in un modo che confonde i team abituati a editor di tema più monolitici: i template Handlebars renderizzano il markup, theme.js (o il vostro bundle personalizzato) gestisce il comportamento, e il livello widget di Page Builder si sovrappone a entrambi. Il virtual try-on ha bisogno di un aggancio in tutti e tre se deve sopravvivere a un aggiornamento del tema. Di seguito la sequenza che consigliamo ai merchant che integrano YourSizer o strumenti di try-on simili su BigCommerce.

Perché l'integrazione BigCommerce non è solo "incollare un tag script"

Uno script di embed generico inserito in header.html si caricherà tecnicamente, ma non saprà quale prodotto sta visualizzando l'acquirente, quali immagini sono disponibili, o dove renderizzare il trigger del try-on rispetto al pulsante "Aggiungi al carrello". Le pagine prodotto BigCommerce passano dati strutturati tramite il contesto Handlebars product e la variabile globale window.BCData, e un widget di try-on ben collegato dovrebbe leggere da entrambi invece di fare scraping del DOM.

Questo conta perché i temi Stencil (Cornerstone e i suoi fork) vengono aggiornati periodicamente, e gli script che fanno scraping del DOM si rompono silenziosamente quando l'autore del tema riordina gli elementi. Leggere da BCData.product_attributes o dal JSON del prodotto incorporato nella pagina è molto più resiliente. È un piccolo passaggio extra durante la configurazione che vi risparmia un ticket di supporto tre mesi dopo, quando il vostro fornitore di temi rilascia un aggiornamento.

Preparare il tema Stencil prima di toccare il codice

Prima di modificare qualsiasi cosa, scaricate una copia locale del vostro tema con la Stencil CLI (stencil pull) invece di modificare direttamente nell'editor di tema BigCommerce. Questo vi dà controllo di versione e un percorso di rollback se una modifica al template rompe la pagina prodotto.

Due file contano di più per un'integrazione di try-on:

Vorrete anche confermare quale variante di template prodotto usa il vostro negozio — Cornerstone offre più di un layout product-view, e i temi personalizzati spesso fanno il fork di questo file. Controllate config.json per il nome del tema attivo prima di assumere che si applichino i percorsi predefiniti di Cornerstone.

Posizionamento dello script: dove si carica davvero il bundle del try-on

Aggiungete lo script di caricamento del try-on in templates/layout/base.html, appena prima del tag di chiusura </body>, condizionato per caricarsi solo sulle pagine prodotto:

{{#if type "product"}}
  <script src="https://cdn.yoursizer.com/widget/loader.js" defer></script>
{{/if}}

Caricarlo su tutto il negozio con un attributo defer di solito va bene comunque — l'impronta dello script è piccola e un caricamento globale dà al widget un aggancio anche sulle pagine di collezione se in seguito aggiungete un'anteprima "try-on rapido" dalle griglie di categoria. Ma se state ottimizzando in modo aggressivo i Core Web Vitals, la condizione {{#if type "product"}} mantiene tutto limitato a dove viene effettivamente usato.

Non posizionate lo script nell'<head> a meno che non sia esplicitamente costruito per un caricamento asincrono, non bloccante per il rendering — un tag script sincrono nell'<head> di una pagina prodotto è una causa comune di un Largest Contentful Paint ritardato, che i report di performance di Page Builder di BigCommerce segnaleranno da soli.

Collegare il widget al template della pagina prodotto

Questo è il passaggio in cui la maggior parte delle integrazioni sbaglia: il pulsante trigger deve stare vicino ai selettori di taglia/variante, non fluttuare scollegato in alto o in basso nella pagina. In product-view.html, individuate il blocco che renderizza product.options o il form "Aggiungi al carrello", e inserite un div contenitore subito dopo:

<div id="yoursizer-tryon-root"
     data-product-id="{{product.id}}"
     data-product-images="{{product.images}}">
</div>

Poi, in product-details.js, collegate la chiamata di mount del widget allo stesso ciclo di vita che BigCommerce usa per aggiornare la pagina quando un acquirente cambia opzione variante/colore — tipicamente updateProductAttributes della vista ProductDetails o equivalente. Questo è critico: se un acquirente passa da "Rosso" a "Blu", l'anteprima del try-on deve ri-renderizzarsi con le nuove immagini del prodotto, non continuare a mostrare il vecchio colore. Saltare questo passaggio è il bug singolo più comune che vediamo nei primi tentativi di integrazione — il widget funziona al caricamento della pagina, poi mostra silenziosamente il capo sbagliato dopo un cambio variante.

QA in staging prima di toccare la produzione

BigCommerce vi permette di visualizzare in anteprima le modifiche al tema su un URL di staging prima di pubblicare, e questo passaggio non è opzionale per un'integrazione di try-on — è qui che intercettate il bug di sincronizzazione della variante sopra descritto, insieme ai problemi di layout mobile. Eseguite questa checklist in staging:

• Caricate un prodotto con più varianti colore/taglia e confermate che l'anteprima del try-on si aggiorna al cambio variante.
• Testate su un dispositivo mobile reale, non solo un browser desktop ridimensionato — il template prodotto mobile di Stencil può differire strutturalmente da quello desktop.
• Confermate che il widget non sposti il pulsante "Aggiungi al carrello" sotto la piega su schermi più piccoli.
• Controllate un prodotto con una sola variante e nessuna immagine, per assicurarvi che il widget fallisca in modo controllato invece di lanciare un errore in console.
• Verificate che il caricamento dello script non peggiori il vostro punteggio di performance Page Builder.

Solo dopo che questi test passano dovreste pubblicare la modifica al tema sul vostro negozio live. Poiché le modifiche basate su Stencil sono a livello file e non un'installazione di app attivabile con un toggle, annullare un deploy sbagliato significa ripubblicare la versione precedente del tema — quindi la QA in staging è la vostra vera rete di sicurezza, non un hotfix rapido in produzione.

Il ruolo di YourSizer

L'integrazione BigCommerce di YourSizer è costruita per leggere i dati di prodotto e variante direttamente dal contesto prodotto Stencil invece di fare scraping dell'HTML renderizzato, colmando il divario di resilienza descritto sopra. Lo script di caricamento si monta nel div contenitore che posizionate in product-view.html, e il widget ascolta gli stessi eventi di cambio variante che BigCommerce genera nativamente, così cambi di colore e taglia restano sincronizzati senza cablaggio di eventi personalizzato da parte vostra. Per i team che vogliono il livello di raccomandazione taglia insieme al try-on invece che al suo posto, i due funzionano dallo stesso script e contenitore — un contesto utile se state valutando anche come scegliere una soluzione di raccomandazione taglia per lo stesso catalogo prodotti. La configurazione in sé non richiede una ricostruzione completa del tema; la maggior parte dei merchant completa la modifica al template e il passaggio di QA in staging descritti sopra in un pomeriggio.

Domande Frequenti

Aggiungere il virtual try-on a BigCommerce richiede un'app personalizzata, o si può fare solo con una modifica al tema?

Esistono entrambi gli approcci. Un'integrazione a livello di tema — modificando direttamente product-view.html e base.html, come descritto sopra — offre il massimo controllo sul posizionamento ed è quella che la maggior parte dei team esperti di Stencil usa per il lancio. Alcuni fornitori di try-on offrono anche una scheda sul BigCommerce App Marketplace che si installa via OAuth e inietta lo script automaticamente, scambiando un po' di controllo sul posizionamento con una configurazione più veloce senza modifiche al codice. Se il vostro team gestisce già un tema Stencil personalizzato, la via manuale è di solito più facile da mantenere allineata al vostro design system.

Il virtual try-on rallenterà le mie pagine prodotto BigCommerce?

Può succedere, se lo script si carica in modo sincrono nell'<head> o il bundle non è ottimizzato per il lazy loading. Caricare lo script con defer e limitarlo ai template di pagina prodotto, come mostrato sopra, mantiene l'impatto minimo — tipicamente simile ad aggiungere un widget di chat o un plugin di recensioni. Vale la pena controllare il vostro report Page Builder o Core Web Vitals prima e dopo il go-live dell'integrazione, dato che BigCommerce mostra questi dati nativamente ed è il modo più affidabile per confermare che nulla sia peggiorato.

In cosa il virtual try-on è diverso da una standard size chart su una pagina prodotto BigCommerce?

Una size chart è una tabella di riferimento statica che l'acquirente deve interpretare rispetto alle proprie misure, mentre il virtual try-on genera un'anteprima visiva di come un capo specifico appare su un corpo o un avatar. Risolvono problemi sovrapposti ma distinti — uno affronta "questo mi andrà bene", l'altro "questo mi starà bene addosso" — e molti merchant fanno funzionare entrambi fianco a fianco invece di sostituire uno con l'altro. Se state valutando quale dare priorità con un budget di sviluppo limitato, virtual try-on vs raccomandazione taglia analizza questo compromesso più in profondità.

Conclusione

Fare bene il virtual try-on su BigCommerce si riduce a rispettare come Stencil renderizza e aggiorna davvero una pagina prodotto — posizionamento dello script, aggancio agli eventi di cambio variante e un vero passaggio in staging contano più di quale fornitore di try-on scegliete. Fate il collegamento del template correttamente una volta, e reggera attraverso aggiornamenti del tema e cambi di catalogo senza trasformarsi in lavoro di manutenzione ricorrente; saltate il passaggio di QA in staging, e probabilmente scoprirete il bug di sincronizzazione della variante da un cliente invece che da un test.