Quando uno store sembra lento, di solito diamo prima la colpa alle immagini pesanti o a un tema troppo carico. Ma c’è una cosa che in pochi notano: come un’app per menu influisce sulla velocità di caricamento delle pagine. Il menu si trova proprio in cima alla pagina, quindi è una delle prime cose che il browser deve gestire. Un’app di navigazione non costruita con attenzione può trascinare giù l’intero store.
Questo articolo è diviso in due parti. La prima riguarda i meccanismi: perché un’app per menu rallenta le cose. La seconda riguarda i segnali d’allarme, così puoi controllare il tuo store invece di tirare a indovinare.
Perché un’app per menu influisce sulla velocità dello store
In apparenza, un’app per menu è solo qualche pulsante. Ma dietro le quinte di solito carica JavaScript, font, icone e immagini. Ognuno di questi ha un costo in termini di velocità. Ecco le quattro cause più comuni.
JavaScript pesante che deve essere eseguito prima che il menu appaia
Molte app per menu costruiscono la propria interfaccia con JavaScript. Quando un cliente apre la pagina, il browser deve scaricare il file, analizzarlo (parsing), poi eseguirlo — solo a quel punto compare il menu.
Più pesante è il JavaScript, più lungo è questo passaggio. Su un computer potente lo noti a malapena. Ma la maggior parte degli acquirenti compra dal telefono, e gli smartphone di fascia media elaborano il JavaScript molto più lentamente. Un file di qualche centinaio di KB richiede un istante su un desktop, ma su un Android economico può richiedere un secondo intero.
Per uno store, quel secondo è tempo che il cliente passa fissando uno schermo vuoto, senza alcun menu da toccare.
Render blocking: l’app blocca l’intera pagina mentre aspetta il menu
Questo aspetto viene spesso trascurato. Secondo la documentazione di Google, il JavaScript blocca il parser per impostazione predefinita: mentre il browser sta costruendo la pagina e incontra un tag script, deve fermarsi, terminare l’esecuzione di quello script e solo allora proseguire la costruzione.
Questo si chiama render blocking. Un’app per menu che colloca il proprio script in un punto sbagliato e non usa gli attributi async o defer può bloccare il rendering dell’intera pagina, non solo del menu.
Il risultato concreto: un cliente clicca sul link di un prodotto, ma la pagina si blocca per un momento perché sta aspettando che lo script del menu finisca. Non vede ancora l’immagine, il prezzo, niente. Nel frattempo, la cosa che davvero deve caricarsi in fretta è il contenuto che vende, non la barra del menu.
Ogni icona, font e immagine è una richiesta HTTP
Un bel menu spesso include icone da un font personalizzato, a volte persino un’immagine di sfondo o un logo per ogni voce. Ogni risorsa è una richiesta HTTP — un viaggio di andata e ritorno in cui il browser chiede al server di inviare un file.
Ogni richiesta richiede tempo per stabilire la connessione e attendere una risposta. Dieci icone significano dieci viaggi di andata e ritorno. Aggiungi un font personalizzato solo per il menu e la lista si allunga. Ognuna è piccola, ma insieme si sommano — soprattutto per i clienti con una connessione 3G/4G debole in una zona con scarsa copertura.
Un menu snello che usa icone SVG inline o il font di sistema già presente sul dispositivo può ridurre parecchie di queste richieste.
CLS: un menu che si carica in ritardo sposta il layout
Il CLS (Cumulative Layout Shift) è una delle metriche dei Core Web Vitals di Google. Misura quanto l’interfaccia si sposta mentre la pagina si carica. Secondo Google, una buona soglia è un CLS inferiore a 0,1.
Sempre secondo Google, il CLS si verifica spesso quando il JavaScript inserisce contenuti nella pagina in ritardo, spingendo verso il basso gli elementi esistenti. Una barra del menu o un banner di navigazione che si carica dopo il contenuto principale è un esempio classico: appare, occupa spazio e spinge giù tutto ciò che sta sotto.
Probabilmente ti è già capitato durante lo shopping: stai per toccare “Aggiungi al carrello”, ma proprio in quel momento il menu compare, il layout si sposta e tocchi la cosa sbagliata. Quello è il CLS — fastidioso e un motivo per cui i clienti se ne vanno.
Segnali che il tuo menu sta rallentando lo store
Ora che capisci i meccanismi, ecco la parte pratica: come capire se la tua app per menu sta causando problemi. Non servono conoscenze tecniche approfondite, solo qualche strumento gratuito.
Esegui PageSpeed Insights
Vai su pagespeed.web.dev, incolla l’indirizzo del tuo store e premi analizza. Questo strumento di Google assegna un punteggio alla tua pagina ed elenca i problemi sotto due sezioni: Opportunità e Diagnostica.
Fai attenzione alle righe che menzionano risorse che bloccano il rendering (render-blocking) o la riduzione del tempo di esecuzione del JavaScript. Se il nome di un file o una descrizione menziona navigation, menu o drawer, è molto probabile che l’app per menu faccia parte di ciò che rallenta le cose.
Esegui sia la modalità Mobile che Desktop. Il punteggio Mobile è di solito più basso e più vicino all’esperienza reale dei tuoi clienti, dato che la maggior parte compra dal telefono.
Usa la scheda Network in Chrome DevTools
Apri il tuo store in Chrome, premi F12 per aprire i DevTools e scegli la scheda Network. Ricarica la pagina, poi filtra per tipo JS per vedere solo i file JavaScript.
La tabella che compare mostra quanto è pesante ogni file e quanto tempo impiega. Cerca i file con nomi che assomigliano alla tua app di navigazione. Se un file del menu pesa qualche centinaio di KB e impiega un po’ a caricarsi, quella è una prova concreta, non una supposizione.
Un piccolo consiglio: i DevTools hanno opzioni per simulare una rete lenta (throttling) e una CPU debole. Attivale per imitare il dispositivo di un cliente reale, e vedrai numeri molto più vicini alla realtà rispetto a quelli che mostra il tuo computer.
Confronta i punteggi prima e dopo l’installazione dell’app
L’approccio più onesto è misurare prima e dopo. Prima di installare una nuova app per menu, esegui PageSpeed Insights e annota il punteggio insieme alle metriche LCP, INP e CLS. Dopo aver installato l’app e costruito il menu, eseguilo di nuovo e confronta.
Secondo Google, le buone soglie sono LCP sotto i 2,5 secondi, INP sotto i 200 millisecondi e CLS sotto 0,1. Se, dopo aver installato l’app, l’LCP sale o il CLS supera 0,1, quell’app ti sta costando velocità.
Questo conta, perché lo store medio non usa una sola app. Secondo dati citati da molte fonti, un tipico store Shopify ha circa sei app installate, e alcuni store ne usano fino a trenta. Ogni app aggiunge un po’ di zavorra, e insieme arrivano a un numero tutt’altro che piccolo. E la velocità è direttamente legata a quante persone abbandonano la pagina — con il tasso medio di abbandono del carrello già intorno al 70% secondo il Baymard Institute, ogni secondo in più può peggiorare quel numero.
Scegli un’app per menu che si preoccupa della velocità
Non tutte le app per menu rallentano le cose. La domanda è se l’app è stata costruita pensando alla velocità: JavaScript snello, niente render blocking, poche richieste sprecate e spazio riservato per il menu così che non sposti il layout.
Questa è la priorità assoluta per noi quando costruiamo Navi+. Navi+ crea menu senza codice per Shopify e qualsiasi sito web — Tab Bar, Mega Menu, Slide Menu, FAB, Grid Menu — con configurazioni separate per mobile e desktop, ed è ottimizzato per non trascinare giù i tuoi Core Web Vitals. Dovresti comunque misurare di persona seguendo i passaggi qui sopra, prima e dopo l’installazione; è il modo più affidabile per verificare.
In breve, l’app per menu è parte dell’esperienza, ma non lasciare che rallenti silenziosamente l’intero store. Bastano pochi minuti con PageSpeed Insights e la scheda Network per avere una risposta chiara.
Questo articolo fa parte della guida più ampia su Navigazione e velocità di caricamento — Scegliere un’app per menu che non danneggi i Core Web Vitals.