La risposta in breve
L’ottimizzazione di un sito per mobile deve partire dall’attività che il visitatore deve completare e unire i test del percorso su dispositivi reali ai dati sulle prestazioni sul campo. Proteggete i contenuti principali, rendete comodi i controlli, eliminate i ritardi nelle interazioni e definite criteri di accettazione misurabili prima di approvare il rifacimento.
- Testate l’intero percorso di richiesta su telefoni rappresentativi, non soltanto tramite schermate responsive.
- Utilizzate dati sul campo e le soglie attuali dei Core Web Vitals di Google per definire criteri misurabili sulle prestazioni.
- Prima di iniziare lo sviluppo, assegnate a ogni problema un responsabile e un test di accettazione osservabile.
- Mantenete contenuti importanti, metadati e dati strutturati per mobile equivalenti all’esperienza desktop.
In questa pagina
La risposta diretta
Un buon sito per mobile permette al visitatore giusto di comprendere l’offerta, scegliere il percorso pertinente e inviare una richiesta senza lottare con l’interfaccia. L’ottimizzazione mobile è quindi un esercizio di qualità commerciale, non una rifinitura visiva finale. Esaminate l’intero percorso, misurate le prestazioni degli utenti reali e concordate che cosa significhi superare i controlli prima di approvare il rifacimento.
Partite da un’attività critica, come richiedere una consulenza. Testatela su telefoni rappresentativi, con contenuti e integrazioni realistici. Annotate dove il visitatore esita, tocca l’elemento sbagliato, attende, perde informazioni o non capisce se l’azione sia riuscita. Queste osservazioni formano un elenco di interventi utile.
Google utilizza i contenuti per mobile per l’indicizzazione e il posizionamento. Consiglia il responsive web design perché, in genere, è più semplice da mantenere. La completezza della versione mobile incide quindi sia sull’esperienza dei clienti sia sulla visibilità nella ricerca.
- Scegliete innanzitutto un percorso mobile di grande valore da esaminare.
- Testate comprensione, navigazione, interazioni, compilazione del modulo e conferma.
- Unite i problemi osservati ai dati sulle prestazioni sul campo.
- Assegnate a ogni priorità un responsabile e un test di accettazione.
Iniziate dal percorso di richiesta su mobile
Una pagina può apparire curata su uno schermo stretto e perdere comunque richieste. Il visitatore potrebbe arrivare su una pagina di servizio anziché sulla homepage, aprire un menu, confrontare le prove, tornare alle informazioni sui prezzi, compilare un modulo e attendere la conferma. La vostra verifica deve seguire questa sequenza anziché valutare schermate isolate.
Definite l’attività in termini commerciali. Per un’ipotetica società di consulenza ingegneristica di Berna, potrebbe essere questa: un responsabile degli impianti alle prese con un problema di produzione riesce a individuare il servizio pertinente, verificare che l’azienda operi in Svizzera e richiedere una telefonata mentre si trova sul posto. L’enunciato chiarisce quali informazioni devono rimanere visibili e quali interruzioni contano, senza presupporre un aumento delle conversioni.
Includete gli stati problematici che spesso mancano nei mockup: una ragione sociale lunga, errori di convalida, la tastiera software aperta, una ricezione debole, i controlli del consenso, un’etichetta tradotta e un calendario esterno lento. Il test termina con successo soltanto quando la richiesta raggiunge la destinazione prevista e il visitatore vede una conferma chiara.
- Ingresso: il visitatore riconosce rapidamente il servizio e il pubblico a cui è destinato?
- Orientamento: il menu mostra la destinazione utile successiva senza coprire i controlli essenziali?
- Prove: il visitatore può esaminare le prove pertinenti senza aprire documenti illeggibili?
- Azione: campi, etichette, errori e pulsanti sono utilizzabili con il pollice e la tastiera software?
- Completamento: il messaggio arriva nella casella di posta o nel CRM e il visitatore sa che cosa accadrà?
| Fase del percorso | Problema da cercare | Conseguenza commerciale | Prova di accettazione |
|---|---|---|---|
| Arrivo | Titolo generico o contesto del servizio nascosto | I visitatori qualificati abbandonano o scelgono il percorso sbagliato | Un partecipante al test sa spiegare offerta e destinatari |
| Navigazione | Il menu copre i contenuti o usa etichette ambigue | I visitatori non raggiungono il servizio pertinente | La pagina desiderata viene raggiunta senza tornare indietro |
| Richiesta | La tastiera copre i campi o gli errori cancellano i dati inseriti | Il contatto potenziale abbandona | Il modulo viene completato conservando i dati dopo la correzione |
| Conferma | Manca uno stato di riuscita chiaro oppure la consegna fallisce | Tentativi duplicati o contatti persi | Conferma visibile e ricezione verificata nel sistema di destinazione |
Individuate gli ostacoli sui dispositivi reali
Ridimensionare il browser è utile durante il design, ma non riproduce l’intera esperienza mobile. I telefoni reali introducono aree di sicurezza, controlli del browser, input tattile, tastiere software, ridimensionamento del testo e prestazioni specifiche del dispositivo. Testate un gruppo ristretto e mirato di dispositivi che rispecchi i dati di analisi e il contesto dei clienti, invece di tentare ogni modello.
Iniziate dalla viewport comune più piccola, un iPhone recente, un telefono Android rappresentativo ed eventuali dispositivi meno recenti ancora rilevanti nelle vostre analisi. Usate il Wi-Fi e un profilo di rete limitato. Ruotate lo schermo, ingrandite il testo, aprite e chiudete la tastiera, seguite i link per telefono e mappe, provocate ogni errore del modulo e tornate da un’applicazione esterna. Testate sia con il consenso accettato sia con il consenso rifiutato, perché strumenti di analisi, mappe, video o calendari possono comportarsi diversamente.
Osservate alcuni utenti probabili mentre svolgono l’attività senza guidarli. Chiedete che cosa si aspettano prima di ogni tocco e che cosa credono sia accaduto dopo. Una pausa non dimostra automaticamente un difetto di design, ma un’esitazione ripetuta davanti alla stessa etichetta è una prova forte che l’informazione o l’interazione vada rivista.
- Registrate dispositivo, browser, condizioni della rete e data del test.
- Testate con il testo al 200 per cento e in orientamento verticale e orizzontale.
- Controllate le aree di tocco vicino ai bordi dello schermo e agli elementi fissi dell’interfaccia.
- Verificate sul dispositivo le azioni relative a telefono, e-mail, mappe, caricamenti e calendario.
- Ripetete i test dei problemi corretti nelle stesse condizioni.
| Test | Metodo | Condizione per il superamento |
|---|---|---|
| Menu | Raggiungere ogni destinazione principale con tocco e tastiera | Le etichette restano visibili, il focus è chiaro e nessun controllo rimane intrappolato |
| Modulo | Inviare una volta con errori e una volta con successo | I dati inseriti restano disponibili, gli errori indicano una soluzione e la consegna è verificata |
| Zoom e testo | Aumentare le dimensioni del testo e lo zoom nelle pagine principali | I contenuti restano leggibili, senza azioni nascoste o testi sovrapposti |
| Servizi esterni | Usare mappe, video, chat o calendari con entrambi gli stati del consenso | L’attività principale resta possibile e in caso di errore esiste un’alternativa utile |
Definite criteri utili per accettare le prestazioni
La misurazione delle prestazioni richiede una fonte, un insieme di pagine e un percentile. Un singolo punteggio di laboratorio sul portatile di uno sviluppatore non descrive l’esperienza dei clienti. I dati sul campo rispecchiano nel tempo le visite idonee, mentre gli strumenti di laboratorio aiutano a riprodurre e diagnosticare un problema. Usate entrambi e indicate quale determina l’accettazione.
I Core Web Vitals di Google sono Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift. Le soglie attuali considerate buone sono LCP pari o inferiore a 2,5 secondi, INP pari o inferiore a 200 millisecondi e CLS pari o inferiore a 0,1. Google le valuta al 75° percentile delle visualizzazioni di pagina. Un brief realistico deve indicare come obiettivo modelli rappresentativi e dati sul campo per mobile, usando controlli di laboratorio finché i dati sul campo non sono sufficienti.
Non promettete in modo generico che ogni URL rispetterà sempre una soglia. Volume del traffico, gamma dei dispositivi, servizi esterni e nuovi contenuti incidono sui risultati. Chiedete al fornitore di dichiarare quali modelli ha testato, quale fonte di dati ha utilizzato, quali servizi esterni erano attivi e come controllerà eventuali peggioramenti.
- Indicate i gruppi di pagine: homepage, servizio principale, articolo, contatti ed eventuali modelli per campagne.
- Specificate come risultato atteso dati sul campo per mobile al 75° percentile.
- Definite un metodo di laboratorio temporaneo per le pagine nuove prive di osservazioni sufficienti sul campo.
- Includete nei test gli strumenti per il consenso, le analisi e gli altri script di produzione.
- Concordate chi esamina un peggioramento dopo modifiche ai contenuti o alle integrazioni.
| Metrica | Che cosa rappresenta | Soglia buona | Formulazione per l’accettazione |
|---|---|---|---|
| LCP | Il momento probabile in cui appare il contenuto visibile principale | 2,5 secondi o meno | I gruppi rappresentativi di pagine per mobile mirano a uno stato buono dei dati sul campo al 75° percentile |
| INP | Reattività nelle interazioni dell’utente | 200 millisecondi o meno | Menu, filtri e moduli rispondono senza ritardi rilevanti nelle interazioni |
| CLS | Spostamento imprevisto dei contenuti visibili | 0,1 o meno | Media, caratteri e avvisi caricati in ritardo non spostano inaspettatamente i controlli |
Diagnosticate LCP, INP e CLS in base ai sintomi
Le metriche diventano utilizzabili quando il team le collega a qualcosa che il visitatore vede. Un LCP lento può dipendere da un’immagine hero troppo pesante, da un carattere caricato in ritardo, da una risposta lenta del server o dal contenuto principale in attesa di codice eseguito sul client. Un INP scarso può manifestarsi con un menu, un configuratore o un modulo che reagisce tardi perché il thread principale è occupato. Il CLS compare spesso quando un’immagine, un livello per il consenso, un widget incorporato o un carattere modifica il layout dopo che il visitatore ha iniziato a leggere.
Individuate il sintomo prima di prescrivere la soluzione. Comprimere ogni immagine non risolverà un ritardo del server, e cambiare hosting non eliminerà un pesante widget per gli appuntamenti. Chiedete allo sviluppatore di identificare, per ogni modello importante, l’elemento o l’interazione rappresentati dalla metrica e di proporre poi la correzione duratura più piccola.
La responsabilità è spesso condivisa. I team dei contenuti controllano la scelta delle immagini e gli incorporamenti, i designer riservano lo spazio e definiscono il comportamento dei componenti, gli sviluppatori gestiscono caricamento ed esecuzione e i responsabili aziendali decidono se uno strumento esterno giustifica il costo misurato in prestazioni. Un verbale di valutazione rende visibile questo compromesso.
- Sintomo LCP: appare il titolo del servizio, ma l’immagine principale o l’offerta arrivano molto più tardi.
- Sintomo INP: il primo tocco sul menu sembra ignorato e induce a toccare una seconda volta.
- Sintomo CLS: un banner tardivo sposta il pulsante di richiesta mentre il visitatore cerca di premerlo.
- Domanda decisionale: il componente aiuta abbastanza clienti da giustificare il costo misurato?
Mantenete completi e scansionabili i contenuti per mobile
L’ottimizzazione mobile non deve ottenere una schermata più pulita eliminando le informazioni necessarie ai clienti o ai sistemi di ricerca. Google consiglia contenuti principali equivalenti su mobile e desktop, compresi titoli chiari. Per risparmiare spazio, i contenuti possono essere inseriti in schede o sezioni espandibili, ma devono restare disponibili e comprensibili.
Google consiglia inoltre di mantenere equivalenti i metadati e i dati strutturati nelle diverse versioni e di consentire l’accesso alle risorse necessarie per visualizzare la pagina. I contenuti principali non devono caricarsi soltanto dopo che il visitatore fa clic, scorre o digita. Nella maggior parte dei rifacimenti, un sito responsive con gli stessi URL e contenuti HTML riduce il rischio legato alla manutenzione di versioni separate.
Esaminate la pagina di produzione così come la ricevono Google e un cliente. Controllate che le regole del consenso, il lazy loading, una rete per la distribuzione dei contenuti o un modello riservato al mobile non eliminino la descrizione del servizio, le prove, il percorso di contatto, le informazioni canoniche o i dati strutturati.
- Confrontate titoli, testi, link, immagini e testi alternativi tra mobile e desktop.
- Verificate titolo, meta description, canonical e dati strutturati pertinenti.
- Assicuratevi che i contenuti principali caricati in modo differito siano disponibili senza un gesto dell’utente.
- Controllate che le regole robots e i controlli della CDN non blocchino le risorse necessarie.
Scrivete un brief per l’ottimizzazione mobile
Un brief solido indica pubblico, attività, prove attuali, modelli interessati e metodo di accettazione. Distingue un requisito aziendale da una soluzione proposta. Per esempio, richiedete che un visitatore possa correggere un modulo senza perdere i dati inseriti. Lasciate che il team incaricato proponga il componente e l’approccio tecnico.
Includete i dati di analisi soltanto quando aiutano a definire le priorità. Distribuzione dei dispositivi, pagine di destinazione, errori dei moduli e dati di completamento possono indicare dove cercare, ma non spiegano ogni causa. Abbinateli all’osservazione delle sessioni, alle domande ricevute dall’assistenza e ai test diretti. Tutelate la privacy durante la raccolta delle prove.
Chiedete a ogni fornitore di rispondere agli stessi criteri. La schermata di un progetto precedente non dimostra che i moduli consegnino i dati, che le interazioni restino reattive o che i contenuti siano completi su mobile. Richiedete prove ricavate da una versione rappresentativa e un piano chiaro per la verifica in produzione.
- Pubblico e contesto: chi usa il sito, dove e per quale attività?
- Ambito del percorso: quali pagine di ingresso, decisioni, azioni e sistemi sono inclusi?
- Prove: quali dati sul campo, analisi o ostacoli osservati giustificano la priorità?
- Accettazione: quali dispositivi, gruppi di pagine, metriche e risultati delle attività definiscono il superamento?
- Responsabilità: chi fornisce contenuti, integrazioni, test, monitoraggio e correzioni successive alla pubblicazione?
Decidete cosa deve cambiare prima della pubblicazione
Date priorità ai difetti in base all’impatto sull’attività, alla diffusione e alla possibilità di recupero. Un modulo di contatto che non funziona o un pulsante di invio coperto impedisce il risultato e deve bloccare la pubblicazione. Una piccola incoerenza negli spazi può entrare nell’elenco dei miglioramenti. I problemi di prestazioni richiedono un giudizio analogo: un’azione principale ritardata nel modello del servizio principale comporta un rischio commerciale maggiore di un problema minore in un archivio usato raramente.
Ripetete il percorso di accettazione in produzione, comprese le impostazioni reali del consenso e le integrazioni. Verificate che l’invio arrivi, che le azioni telefoniche ed e-mail funzionino, che le pagine principali conservino i contenuti e che il monitoraggio sia attivo. Registrate le prove accanto al requisito, affinché l’approvazione si basi su un risultato osservato.
Se il percorso mobile attuale non è chiaro, un concept personalizzato della homepage può rendere concrete le priorità prima di decidere sull’intera realizzazione. Il concept deve mostrare il messaggio principale, la direzione per mobile e l’azione successiva, mentre hosting, realizzazione e attività continuative restano oggetto di un preventivo separato.
- Bloccate la pubblicazione se attività critiche non funzionano, si perdono dati, i controlli sono inaccessibili o mancano contenuti principali.
- Pianificate i miglioramenti visivi ed editoriali di minore impatto assegnando responsabili e date.
- Ripetete i test in produzione anziché affidarvi all’approvazione dell’ambiente di prova.
- Monitorate richieste e prestazioni sul campo dopo la pubblicazione senza promettere un aumento prestabilito.
LE VOSTRE DOMANDE, LE RISPOSTE
Domande frequenti
Che cos’è l’ottimizzazione mobile di un sito?
È il miglioramento sistematico di contenuti, navigazione, interazioni, moduli e prestazioni su mobile in funzione delle attività reali dei visitatori. Un processo utile unisce test osservati del percorso, dati sul campo e criteri di accettazione espliciti.
Quali sono buoni valori per i Core Web Vitals?
Le soglie attuali considerate buone da Google sono LCP pari o inferiore a 2,5 secondi, INP pari o inferiore a 200 millisecondi e CLS pari o inferiore a 0,1, valutate al 75° percentile. Sono obiettivi di accettazione utili, non una garanzia di posizionamento o richieste.
Un’anteprima responsive è sufficiente per testare un sito mobile?
No. I dispositivi reali evidenziano input tattile, tastiere software, controlli del browser, ridimensionamento del testo, passaggi ad applicazioni esterne e prestazioni del dispositivo. Testate l’intera attività su telefoni rappresentativi.
Le pagine per mobile devono contenere meno informazioni?
Possono presentarle diversamente, anche con schede o sezioni espandibili, ma i contenuti importanti devono restare equivalenti e accessibili. Google utilizza i contenuti per mobile per l’indicizzazione e il posizionamento.
Quando un problema su mobile deve bloccare la pubblicazione?
Bloccate la pubblicazione quando un’attività critica non funziona, si perdono dati, i controlli non sono utilizzabili o mancano contenuti principali. Inserite i problemi di minore impatto in un elenco di interventi successivi.
PER APPROFONDIRE
