Aggiornato a giugno 2026, le note di implementazione valgono per PrestaShop 1.7, 8 e 9. Il tema Classic predefinito continua a non includere un pulsante Torna su; il codice qui sotto è in vanilla JS con un’area di tocco da 44px su mobile.

Il pulsante Torna su è uno di quei dettagli che nessuno nota finché manca: una piccola freccia nell’angolo che riporta il cliente all’intestazione dopo che è arrivato in fondo a una pagina lunga. Sembra troppo marginale per dedicarci attenzione. Ma in un negozio PrestaShop, dove le pagine di categoria e prodotto arrivano facilmente a diverse migliaia di pixel di altezza, averlo o non averlo fa la differenza tra un cliente a un tocco dalla barra di ricerca e un cliente che continua a scorrere col pollice sullo schermo del telefono finché rinuncia. Questo articolo spiega come aggiungere quel pulsante al tuo negozio nel modo corretto, specificamente su PrestaShop: dove vive nel tema, come inserirlo senza creare fork di file di cui ti pentirai al prossimo aggiornamento, e quali errori trasformano un pulsante utile in qualcosa che copre il tuo “Aggiungi al carrello”.

Se ti interessa il perché il pulsante incide davvero, dati sul coinvolgimento, impatto sull’abbandono, ne abbiamo parlato in pulsante Torna su: piccolo miglioramento UX, impatto sorprendente. Qui restiamo sul lato pratico: implementazione, meccanismi di PrestaShop e decisioni che fanno funzionare o fallire il risultato.

Il tuo tema ne ha già uno? Controlla prima di crearne un altro

La prima cosa da sapere, specifica di PrestaShop, è questa: molti temi moderni includono già un pulsante Torna su, e potresti stare per aggiungerne un secondo. Il tema Classic predefinito di PrestaShop 1.7, 8 e 9 non ne include uno di serie, quindi un’installazione Classic standard va integrata. Ma la maggior parte dei temi a pagamento (e dei temi derivati da Warehouse) lo include, di solito attivabile dalla pagina di configurazione del tema in Design → Tema & logo o dentro il modulo impostazioni del tema. Prima di scrivere una riga di codice, scorri fino in fondo una lunga pagina di categoria nel tuo negozio online e osserva l’angolo. Se un pulsante appare già con una dissolvenza, il tuo lavoro è configurazione, non sviluppo.

Per verificare da dove arriva un pulsante esistente, visualizza il sorgente e cerca marker comuni: un elemento #back-to-top o .scroll-to-top, oppure un frammento di template nel tuo tema sotto themes/<yourtheme>/templates/ (spesso in _partials/footer.tpl o in un file dedicato scroll-top.tpl). Se è presente ma non appare, l’opzione del tema è semplicemente disattivata. È una casella nel back office, non un ticket per uno sviluppatore.

I tre modi per aggiungerlo a PrestaShop, e quale scegliere

Se il tuo tema davvero non ha un pulsante Torna su, hai tre strade realistiche. Differiscono soprattutto per un aspetto che su PrestaShop conta più della comodità: se la modifica sopravvive a un aggiornamento del tema o del core.

PercorsoDove risiedeSopravvive agli aggiornamenti?Ideale quando…
Opzione del temaImpostazioni del tema, senza codiceSì (è una funzionalità nativa del tema)Il tuo tema la include già: devi solo attivarla.
Modulo blocco HTML/JSUn blocco HTML/modulo personalizzato su un hook supportato (per es. displayFooter)Sì, non viene modificato nulla nel temaLo vuoi su un tema standard senza toccare i file del tema.
custom.js / custom.cssIl file del tema assets/js/custom.jsPerlopiù sì, ma resta legato a quel temaTi trovi a tuo agio con i file asset del tema e vuoi pieno controllo.
Modifica diretta di footer.tplTemplate del tema padreNo, viene sovrascritto all’aggiornamento del temaMai. Usa invece un tema child (vedi sotto).

La strada da evitare è quella più invitante: aprire footer.tpl nel tema attivo e incollarci dentro il markup. Funziona esattamente fino al momento in cui l’autore del tema rilascia un aggiornamento; a quel punto la tua modifica sparisce e non sai perché. Se devi proprio toccare i template, fallo in un tema child. Spieghiamo perché questa regola non è negoziabile in temi child: perché non dovresti mai modificare il tema padre. Per gli approcci più puliti, senza modificare template, continua a leggere.

La strada pulita: un blocco HTML personalizzato più poche righe di JS

L’approccio che ti tiene lontano dai file del tema consiste nell’iniettare il markup del pulsante tramite un blocco di contenuto HTML e caricare il comportamento tramite il custom.js del tema. Il tema Classic include themes/<yourtheme>/assets/js/custom.js (e accanto custom.css) per il JavaScript a livello di sito. Attenzione però: l’esistenza di questi file e il loro comportamento durante gli aggiornamenti dipendono dal tema. Modificarli nel tema padre attivo significa comunque modificare file del tema, e un aggiornamento può sovrascriverli se il tema o il fornitore non li preserva. Per una reale sicurezza negli aggiornamenti, preferisci un tema child o asset registrati tramite un modulo. La disciplina completa per usarli in modo sicuro, e il motivo per cui sono meglio delle modifiche ai bundle compilati del tema. È spiegata in CSS e JavaScript personalizzati in PrestaShop senza rompere gli aggiornamenti.

Per il markup in sé, non vuoi inserire a mano un <div> dentro un template. Un blocco HTML/modulo personalizzato dedicato, posizionato nell’area del footer, fa il suo lavoro: usane uno che supporti l’hook di destinazione (per un pulsante ancorato al footer, un modulo collegato a displayFooter o displayBeforeBodyClosingTag), oppure crea un piccolo modulo tuo. Tieni presente che il markup può essere iniettato solo negli hook supportati da un modulo e realmente renderizzati dal tema, non letteralmente ovunque nel negozio: i meccanismi per posizionare blocchi personalizzati sono spiegati in blocchi HTML: aggiungere contenuti personalizzati ovunque nel tuo negozio PrestaShop. Il pulsante è semplicemente un elemento ancora o pulsante accessibile; il JavaScript gestisce quando appare e lo scorrimento fluido.

Un’implementazione minima e accessibile richiede davvero circa quindici righe: non è un problema di prestazioni, e dovrebbe essere in vanilla JS (il tema Classic include ancora jQuery, ma basarsi su di esso è fragile: molti temi di terze parti più leggeri lo rimuovono o lo caricano in modo differito, quindi non dare per scontato che $() sia disponibile):

  • Markup: un vero <button type="button" id="back-to-top" aria-label="Back to top"> con una freccia o un SVG all’interno, mai un semplice <div>, perché un div non è focalizzabile né annunciato dai lettori di schermo.
  • Mostra dopo lo scorrimento: un listener di scroll che aggiunge una classe visible quando window.scrollY supera circa 300–500px (più o meno una viewport). Applica un throttle al listener, così non scatta a ogni pixel.
  • Ritorno fluido: window.scrollTo({ top: 0, behavior: 'smooth' }) al click, una sola riga, nativa, senza librerie di animazione.

Ecco l’intero blocco: markup, mostra/nascondi con throttle e scorrimento fluido nativo. È vanilla, non dipende da nulla e rispetta la preferenza di movimento del visitatore:

<!-- markup: a real button, focusable and announced -->
<button type="button" id="back-to-top" aria-label="Back to top"></button>
#back-to-top {
  position: fixed;
  right: 1rem;
  bottom: 1rem;           /* raise this if a cookie bar / chat sits here */
  width: 48px;
  height: 48px;          /* 44px+ tap target on mobile */
  opacity: 0;
  visibility: hidden;
  transition: opacity .2s ease;
  z-index: 1030;       /* deliberate, below banner/chat – test it */
}
#back-to-top.is-visible { opacity: 1; visibility: visible; }
const btn = document.getElementById('back-to-top');
let ticking = false;

window.addEventListener('scroll', () => {
  if (ticking) return;            // throttle to one check per frame
  ticking = true;
  window.requestAnimationFrame(() => {
    btn.classList.toggle('is-visible', window.scrollY > 400);
    ticking = false;
  });
}, { passive: true });

btn.addEventListener('click', () => {
  const reduce = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
  window.scrollTo({ top: 0, behavior: reduce ? 'auto' : 'smooth' });
});

Il passive: true sul listener di scroll e il throttle con requestAnimationFrame sono i due dettagli che tengono questa logica lontana dal main thread del negozio; il controllo sul movimento ridotto al click è un’attenzione all’accessibilità che costa una riga. Registra quel JS come file esterno tramite un hook di modulo invece di incollarlo inline.

Racchiudere tutto in un piccolo modulo dedicato, invece che in file sparsi, ha un vantaggio che merita di essere citato: ti segue da un negozio all’altro e non resta legato al ciclo di vita di un singolo tema. È lo stesso ragionamento per cui conviene gestire le animazioni allo scroll come livello controllato, invece che come script inline disseminati: il pulsante e i movimenti sottili allo scroll appartengono alla stessa famiglia di “rifiniture frontend che non dovrebbero creare fork del tema”.

Le insidie specifiche di PrestaShop che colpiscono davvero

Un pulsante circolare per tornare in alto con una freccia verso l'alto nell'angolo in basso a destra di una pagina prodotto del negozio

Un pulsante circolare di ritorno in cima si trova nell'angolo in basso a destra di una pagina prodotto del negozio.

Il pulsante in sé è banale. Ciò che si rompe nei veri negozi PrestaShop è tutto ciò con cui condivide l’angolo in basso a destra. Le installazioni PrestaShop accumulano widget flottanti, e tutti vogliono lo stesso spazio.

  • Consenso cookie e banner GDPR. I moduli di consenso e cookie law comuni nei negozi PrestaShop, che siano add-on di conformità legale o CMP di terze parti, di solito si agganciano al fondo della viewport. Un pulsante Torna su che li ignora finisce nascosto dietro il banner o sopra il pulsante “Accetta”. Posiziona il pulsante in basso a destra e assegna al banner la fascia inferiore a tutta larghezza, oppure alza il pulsante oltre l’altezza del banner mentre è visibile.
  • Widget di live chat (Crisp, Messenger, tawk.to). Quasi sempre si fissano in basso a destra, esattamente dove la convenzione colloca il pulsante Torna su. Non combatterli: impila il pulsante sopra la bolla della chat con un offset bottom extra, così un cliente non deve mai scegliere tra “parla con noi” e “torna su”.
  • La guerra degli z-index. È il difetto più comune in assoluto. Widget di chat e moduli di consenso spesso impostano valori z-index molto alti, e il tuo pulsante può finire renderizzato sotto di essi: visibile ma non cliccabile, peggio che assente. Imposta uno z-index deliberato e testa cliccando davvero il pulsante su mobile con banner cookie e chat entrambi attivi, non su una pagina di staging pulita dove non esiste nessuno dei due.
  • Gli header sticky cambiano il calcolo. Molti temi PrestaShop (e le opzioni di header sticky nei temi a pagamento) mantengono navigazione, ricerca e carrello fissati in alto mentre il cliente scorre. Se il tuo lo fa, il pulsante è meno essenziale, ricerca e carrello sono già raggiungibili, ma continua a essere utile per tornare all’hero, ai filtri in cima a una categoria o all’inizio di un lungo articolo del blog. Su un tema con header sticky, rendi il pulsante un po’ più piccolo e discreto: è una comodità, non un salvagente.

Dove rende davvero in un negozio PrestaShop

Non tutte le pagine ne hanno lo stesso bisogno. Il pulsante dà il massimo proprio dove le pagine PrestaShop diventano più lunghe, e vale la pena sapere quali sono per controllarlo nei punti che contano:

  • Mobile, prima di tutto. La viewport più piccola significa più scorrimento per lo stesso contenuto, quindi un utente da telefono percorre molte più schermate rispetto a un utente desktop sulla stessa identica pagina di categoria. Se devi farlo bene su un solo dispositivo, fallo bene su mobile, e rispetta lì il target di tocco minimo di 44–48px.
  • Pagine di categoria lunghe con oltre 30 prodotti, filtri di ricerca sfaccettata, scroll infinito o paginazione profonda. Quando un cliente arriva al prodotto n. 35, l’header è davvero a migliaia di pixel di distanza.
  • Pagine prodotto ricche di contenuti con descrizioni lunghe, tabelle tecniche, recensioni e caroselli di cross-selling: superano abitualmente i 5.000px.
  • Blog e pagine CMS. I contenuti statici ed editoriali spesso hanno lo scroll più profondo di tutto il sito. Mentre migliori queste pagine, vale la pena sistemare anche la navigazione CMS: etichette di menu più chiare per le pagine statiche aiutano i clienti che tornano in alto a capire davvero dove andare dopo. Ne parliamo in nomi visualizzati delle pagine CMS: navigazione migliore per le tue pagine statiche.

Far funzionare bene il comportamento

Qualunque strada tu scelga, sono gli stessi piccoli dettagli a separare un pulsante che sembra nativo da uno che pare aggiunto a forza:

  • Appare solo dopo lo scorrimento. Mostrarlo in cima alla pagina è rumore inutile. Fallo comparire quando il cliente ha superato più o meno una viewport.
  • Scorrimento fluido, non teletrasporto. Un salto istantaneo all’inizio disorienta: il cliente non capisce se ha semplicemente scorso la pagina o se è atterrato su una nuova pagina. Uno scroll fluido di 300–500 ms preserva il senso dello spazio.
  • Dissolvenza, non rimbalzo. Una dissolvenza discreta di circa 200 ms in entrata e in uscita comunica cura. Animazioni che rimbalzano, scorrono o pulsano attirano un’attenzione che il pulsante non merita: deve essere individuabile, non distraente.
  • Accessibile per costruzione. Un vero <button> o <a> (focalizzabile e annunciato), un aria-label, un focus ring da tastiera visibile e contrasto sufficiente rispetto a qualunque sfondo sopra cui fluttua. Farlo bene in fase di sviluppo non costa nulla; correggerlo dopo è doloroso.

Conviene misurarlo?

Sì, e in un negozio trafficato vale qualche minuto: invia un evento analytics a ogni click sul pulsante. Ti dice quale quota di sessioni sulle pagine lunghe lo usa davvero e quali pagine generano più click: di solito è un indicatore utile per capire “queste sono le mie pagine più profonde e con maggiore coinvolgimento”. Tratta qualunque percentuale letta altrove come orientativa, non come obiettivo; il numero onesto dipende interamente da quanto sono lunghe le tue pagine e da come si comportano i tuoi clienti, quindi leggilo dal tuo negozio invece di fidarti di una cifra trovata in un blog.

Il pulsante Torna su è una rarità nella UX di un negozio: un miglioramento con svantaggi quasi nulli. Costa poche righe, usa risorse trascurabili, aiuta i clienti che ne hanno bisogno e resta invisibile per quelli che non ne hanno. L’unico modo per sbagliarlo su PrestaShop è inserirlo con leggerezza: modificando il tema padre, così sparisce al prossimo aggiornamento, oppure piazzandolo in un angolo già occupato dal banner cookie e dal widget di chat. Aggiungilo nel modo pulito, in un punto che sopravvive agli aggiornamenti, e testalo dove i widget flottanti vivono davvero. Poi dimenticatene: è esattamente ciò che un buon dettaglio UX dovrebbe permetterti di fare.

Domande frequenti

Il tema predefinito di PrestaShop include un pulsante Torna su?

No. Il tema Classic su PrestaShop 1.7, 8 e 9 viene distribuito senza, quindi un’installazione Classic standard deve aggiungerlo. Molti temi a pagamento e derivati da Warehouse lo includono, di solito attivabile dalle impostazioni del tema. Prima di costruire qualsiasi cosa, scorri fino in fondo una lunga pagina di categoria nel tuo negozio online: se un pulsante appare già con una dissolvenza, il tuo lavoro è spuntare una casella nel back office, non scrivere codice.

Qual è il modo più pulito per aggiungerlo senza rompere gli aggiornamenti?

Inserisci il markup in un blocco HTML da back office su un hook del footer come displayFooter o displayBeforeBodyClosingTag, e registra il JavaScript come file esterno tramite un piccolo modulo: non viene modificato nulla nell’albero del tema, quindi un aggiornamento non può cancellarlo. Modificare footer.tpl nel tema padre attivo è la strada da evitare; se devi toccare i template, fallo in un tema child.

Dovrei usare jQuery per la logica di scroll?

No: scrivila in vanilla JavaScript. Il tema Classic include ancora jQuery, ma molti temi di terze parti più leggeri lo rimuovono o lo caricano in modo differito, quindi non puoi dare per scontato che $() sia disponibile. L’intero pulsante richiede circa quindici righe di JS puro: un listener di scroll con throttle che attiva una classe di visibilità oltre ~400px, e window.scrollTo({ top: 0, behavior: 'smooth' }) al click. Non serve alcuna libreria.

Il mio pulsante è visibile ma non riesco a cliccarlo. Perché?

È il difetto più comune: un conflitto di stacking z-index. Widget di chat e banner di consenso spesso impostano valori z-index molto alti, quindi il tuo pulsante viene renderizzato sotto di essi: visibile ma non cliccabile, peggio che assente. Imposta uno z-index deliberato e testa cliccando davvero su mobile con banner cookie e chat entrambi attivi, non su una pagina di staging pulita dove nessuno dei due esiste.

Tutti e tre vogliono l’angolo in basso a destra. Dai al banner di consenso la fascia inferiore a tutta larghezza e tieni il pulsante nell’angolo, oppure aumenta l’offset bottom del pulsante mentre il banner è visibile. Per una bolla di chat, impila il pulsante sopra di essa con un offset extra, così un cliente non deve mai scegliere tra “parla con noi” e “torna su”. Verifica sempre con entrambi i widget attivi.

Dopo quale distanza di scorrimento dovrebbe apparire il pulsante?

Più o meno dopo una viewport: circa 300–500px più in basso. Mostrarlo proprio in cima alla pagina è rumore inutile; farlo comparire solo dopo che il cliente ha iniziato a scorrere è ciò che lo rende intenzionale. Applica un throttle al listener di scroll (una guardia con requestAnimationFrame più un listener passive) così il controllo viene eseguito al massimo una volta per frame e resta fuori dal main thread.

Deve essere accessibile? E come?

Sì, ed è economico farlo bene in fase di sviluppo. Usa un vero <button> o <a> invece di un <div> stilizzato, così è focalizzabile e annunciato; aggiungi un aria-label="Back to top", mantieni un focus ring da tastiera visibile, assicurati che ci sia abbastanza contrasto con lo sfondo della pagina e rispetta prefers-reduced-motion ricadendo su un salto istantaneo. Correggere tutto questo dopo è molto più faticoso che includerlo dall’inizio.

Vale ancora la pena se il mio tema ha un header sticky?

È meno essenziale, ma resta utile. Un header sticky mantiene ricerca e carrello raggiungibili, quindi il pulsante non è un salvagente; però aiuta comunque il cliente a tornare all’hero, ai filtri in cima a una categoria o all’inizio di un lungo articolo del blog. Su un tema con header sticky, rendi il pulsante un po’ più piccolo e discreto, così viene percepito come una comodità e non come un elemento fisso in competizione.

Guide correlate

Tag: PrestaShop UX
Condividi questo articolo:
David Miller

David Miller

Fondatore, mypresta.rocks

David Miller è uno specialista PrestaShop con oltre dieci anni di esperienza sul campo e fondatore di mypresta.rocks, uno studio di sviluppo con sede a Tychy, in Polonia. Progetta e mantiene un catalogo di 152 moduli PrestaShop, tra cui 21 suite « Revolution » dedicate a SEO, checkout, sicurezza, performance, marketing, ricerca, supporto e gestione del magazzino, che ogni giorno migliorano negozi reali, testati su PrestaShop 1.7.8, 8.x e 9.x. Si occupa inoltre della gestione di negozi in produzione che generano milioni di fatturato annuo, perciò il suo lavoro si misura sulle vendite reali, non sulle demo. La sua esperienza abbraccia l'intero e-commerce, performance, sicurezza, SEO e marketing, e va oltre PrestaShop, fino a WooCommerce, Shopify e sistemi su misura. Sul blog scrive del lato tecnico di PrestaShop: cosa fa davvero la piattaforma, cosa si rompe in produzione e quali soluzioni reggono nel tempo.

Commenti

Ancora nessun commento. Sii il primo!
Ti è piaciuto questo articolo?

Ricevi i nostri ultimi consigli, guide e aggiornamenti dei moduli nella tua casella di posta.

Puoi annullare l'iscrizione in ogni momenti. A questo scopo, cerca le info di contatto nelle note legali.

Caricamento...
Torna su