In questa pagina
Gli acquirenti vogliono vedere come appare davvero una taglia su un corpo simile al proprio prima di acquistare, e un'anteprima corporea 3D guidata da altezza e peso e uno dei modi piu rapidi per costruire questa fiducia. Il problema e che la maggior parte delle esperienze 3D sul web e stata costruita per demo desktop, non per un telefono con un chip Android di fascia media e una connessione 4G instabile — e un asset 3D pesante sulla pagina prodotto puo distruggere silenziosamente le metriche di velocita di caricamento da cui dipendono sia Google che il tasso di conversione.
Perche l'anteprima corporea 3D mobile e un campo minato di performance
Il mobile rappresenta ormai la maggioranza delle sessioni e-commerce moda, e i segnali di ranking e user experience di Google si basano sui Core Web Vitals misurati principalmente su dispositivi mobili. Un'anteprima corporea 3D tipicamente invia una mesh, un set di texture e un runtime di rendering (WebGL o WebGPU), e se uno qualsiasi di questi si carica in modo eager al caricamento della pagina, compete direttamente con il tuo elemento largest contentful paint (LCP) — di solito l'immagine hero del prodotto — per banda e tempo del thread principale.
Il risultato e uno schema familiare: una bella funzionalita 3D che si testa bene su un MacBook connesso al Wi-Fi in ufficio e poi affossa la conversione mobile in produzione perche gli acquirenti reali sono su reti reali. Le linee guida di Google su Core Web Vitals ed esperienza di pagina chiariscono che LCP, INP e CLS sono misurati sul campo, non in laboratorio — quindi un'anteprima che "sembra a posto" al team puo comunque fallire la metrica che Search Console segnala e che la ricerca sul commercio mobile collega costantemente a una conversione piu bassa.
I tre asset che fanno esplodere il budget
La maggior parte dei fallimenti dell'anteprima corporea 3D mobile risale a tre colpevoli:
- Complessita della mesh — modelli corporei ad alto numero di poligoni esportati direttamente da uno strumento di modellazione, spesso 5-10 volte piu densi di cio che uno schermo di telefono puo effettivamente risolvere.
- Risoluzione delle texture — mappe texture 2K o 4K applicate a un'anteprima renderizzata in una card larga poche centinaia di pixel.
- Peso del runtime — un bundle motore 3D completo caricato a ogni visita della pagina prodotto, anche per gli acquirenti che non interagiscono mai con l'anteprima.
Impostare un budget di asset prima di costruire
La soluzione inizia con un budget, non con una scelta di libreria. Un obiettivo mobile realizzabile e una mesh decimata sotto i 150k triangoli (spesso molto meno per una silhouette corporea stilizzata), texture limitate a 512-1024px con compressione aggressiva (Basis/KTX2 invece di PNG grezzo), e un payload 3D totale — mesh, texture e runtime combinati — sotto 1,5MB gzippato per la vista interattiva iniziale. Tutto cio che supera questo budget deve giustificarsi rispetto al costo LCP e INP che introduce.
| Tipo di asset | Tipico desktop | Budget mobile | Tecnica |
|---|---|---|---|
| Mesh corporea | 300k+ triangoli | Sotto 150k triangoli | Decimazione, cambio LOD allo zoom |
| Mappe texture | PNG 2K-4K | 512-1024px, compresso | KTX2/Basis, atlas singolo |
| Bundle runtime | Motore completo, caricamento eager | Chunk differito, sotto 300KB gz | Code splitting |
| Payload iniziale | 3-8MB | Sotto 1,5MB gz | Caricamento progressivo |
Carica l'anteprima in modo differito, non la pagina
La correzione a piu alto impatto e rimandare l'anteprima 3D fino a quando non e effettivamente necessaria. Renderizza un placeholder 2D leggero — una silhouette statica o un'illustrazione legata all'altezza e al peso inseriti dall'acquirente — come stato iniziale, e recupera mesh, texture e runtime solo quando l'acquirente tocca "Vedi in 3D" o scorre l'anteprima nella viewport con un intersection observer. Questo mantiene il payload 3D completamente fuori dal percorso critico per l'LCP, poiche l'immagine hero e il placeholder possono essere dipinti senza attendere l'inizializzazione di WebGL.
Questo stesso schema conta su tutta la pagina prodotto mobile, non solo per il 3D: vedi progettare il camerino virtuale per schermi piccoli per i compromessi di layout e interazione piu ampi che si applicano una volta che l'anteprima e a schermo, e velocizzare il tuo negozio moda per la disciplina di performance dell'intero sito in cui questo si inserisce.
Strategia di rendering: fallback WebGL e dettaglio progressivo
Non tutti i dispositivi dovrebbero ricevere lo stesso percorso di rendering. Un approccio pragmatico a livelli:
- Livello 1 (fascia bassa/rete lenta): anteprima corporea illustrata statica generata dagli input altezza/peso, nessun WebGL.
- Livello 2 (fascia media): mesh 3D a basso numero di poligoni, singola texture a bassa risoluzione, frame rate limitato.
- Livello 3 (fascia alta/Wi-Fi): mesh e texture ad alto dettaglio, rotazione e zoom fluidi.
Rilevare il livello del dispositivo puo essere semplice quanto controllare il tipo di connessione effettiva tramite la Network Information API dove disponibile, combinato con un controllo approssimativo della memoria del dispositivo, con un fallback elegante quando manca un segnale. L'obiettivo e che nessun acquirente sia mai bloccato in attesa di asset 3D che comunque non potrebbe renderizzare bene — ottiene subito un segnale di vestibilita utile, con dettaglio piu ricco aggiunto opportunisticamente.
Perche la logica di vestibilita sottostante conta ancora piu del rendering
Un'anteprima 3D nitida e veloce non vale nulla se la forma corporea che renderizza non corrisponde a come il capo si adatta realmente. Il livello visivo dovrebbe basarsi sulla stessa logica statistica di vestibilita che guida la tua raccomandazione di taglia, non su un modello cosmetico separato. Per la relazione di dati da cui questo dipende, vedi come altezza e peso predicono la vestibilita dei capi — l'anteprima e affidabile solo quanto il modello di vestibilita che la alimenta.
Misurare il compromesso: l'anteprima 3D aiuta o danneggia la conversione
Prima di lanciare ampiamente un'anteprima 3D, strumentala come un esperimento a se, non come una funzionalita lanciata e dimenticata. Traccia tre cose insieme: il delta Core Web Vitals sulle pagine prodotto con anteprima attiva rispetto a un gruppo di controllo, il tasso di accettazione della raccomandazione di taglia, e il tasso di reso legato a taglia o vestibilita sugli ordini in cui l'acquirente ha aperto l'anteprima 3D rispetto a quelli in cui non l'ha fatto. La ricerca retail collega costantemente esperienze di pagina piu lente a tassi piu bassi di aggiunta al carrello e checkout, quindi una funzionalita 3D che aggiunge una regressione significativa di LCP o INP puo cancellare i guadagni sul tasso di reso che produce — vedi la ricerca McKinsey su performance retail e conversione per il legame piu ampio tra velocita del sito, engagement e ricavi nel retail.
Una regola utile: se l'anteprima 3D aggiunge piu di 200-300ms all'INP all'interazione o spinge l'LCP oltre la soglia "necessita miglioramento" per una quota significativa di sessioni mobili, ha bisogno di ulteriore ottimizzazione prima di un rollout ampio, indipendentemente da quanto gli acquirenti dicano di apprezzarla nel feedback qualitativo.
Una checklist di rollout
- Il placeholder si renderizza istantaneamente, senza dipendenza dagli asset 3D.
- Mesh e texture si caricano solo su interazione esplicita o ingresso in viewport.
- Il payload degli asset e misurato e budgetizzato per livello di dispositivo.
- I Core Web Vitals sono monitorati sul campo (non solo con strumenti da laboratorio) dopo il lancio.
- La logica di vestibilita dietro l'anteprima corrisponde al motore di raccomandazione taglia principale del negozio.
- L'impatto su tasso di reso e conversione e tracciato come confronto controllato, non solo entusiasmo da lancio.
Domande Frequenti
Un'anteprima corporea 3D danneggia sempre i Core Web Vitals?
No, ma solo se non e progettata con un budget di asset rigoroso e caricata in modo differito cosi da non trovarsi mai sul percorso di rendering critico per l'LCP. La modalita di fallimento e caricare in modo eager un runtime 3D completo e asset ad alta risoluzione a ogni visita della pagina prodotto, indipendentemente dal fatto che l'acquirente interagisca con l'anteprima.
Quali dimensioni di mesh e texture sono sicure per le anteprime 3D mobili?
Un budget di partenza ragionevole e una mesh decimata sotto i 150.000 triangoli e texture compresse limitate a circa 512-1024 pixel, mantenendo il payload 3D iniziale totale sotto circa 1,5MB gzippato. Questi numeri vanno validati rispetto al mix reale di dispositivi, poiche un negozio con un pubblico di telefoni piu giovane e di fascia alta puo spingere il tetto leggermente piu in alto.
Ogni acquirente dovrebbe vedere la stessa qualita di anteprima 3D?
No. Scaglionare la qualita di rendering in base alla capacita del dispositivo e alla condizione di rete — un placeholder statico per il livello piu basso, un rendering a basso poligono per dispositivi di fascia media e dettaglio completo per dispositivi di fascia alta su connessione veloce — mantiene la funzionalita utilizzabile ovunque invece che inutilizzabile per una quota significativa del traffico mobile.
Come faccio a sapere se l'anteprima 3D sta davvero riducendo i resi?
Eseguila come confronto controllato piuttosto che come rollout generale: confronta i tassi di reso legati alla taglia e il tasso di accettazione della raccomandazione taglia tra acquirenti che hanno interagito con l'anteprima 3D e un gruppo abbinato che non l'ha fatto, monitorando al contempo il costo Core Web Vitals. Se i resi diminuiscono ma anche la conversione diminuisce a causa di un caricamento piu lento, l'effetto netto puo comunque essere negativo.