Come testare un sito su mobile

Per verificare che il sito funzioni su mobile, affiancate un rapporto sulle prestazioni a una prova concreta del percorso del visitatore. Una pagina veloce può avere un pulsante di invio irraggiungibile. Un layout responsive può comunque perdere i dati di un modulo.

Google ha ritirato il Test di ottimizzazione mobile e la relativa API a dicembre 2023. PageSpeed Insights, Lighthouse, l’emulazione del browser e uno smartphone reale coprono aspetti diversi. Nessuno certifica da solo che un sito sia utilizzabile, accessibile o destinato a buoni posizionamenti.

Scegliete pagine e azioni importanti

Partite dalla homepage, da una pagina principale di prodotto o servizio e da un articolo. Includete il percorso effettivo di contatto, prenotazione o acquisto, anche se passa per un altro dominio. Provate le lingue pertinenti e diversi stati: prima visita con banner del consenso, visita successiva, menu aperto e modulo con un errore.

Il nostro controllo mobile gratuito può servire come verifica preliminare. Esamina l’HTML recuperato e le informazioni della risposta per individuare indizi quali un tag viewport mancante, larghezze fisse o caratteri molto piccoli definiti con stili in linea. Non renderizza la pagina, non esegue JavaScript e non calcola il layout dai fogli di stile esterni. Le dimensioni dell’HTML non sono il peso totale scaricato; il tempo di recupero non è il tempo di caricamento su telefono. Confermate le segnalazioni in un browser.

Distinguete i due risultati di PageSpeed

Aprite PageSpeed Insights, inserite l’URL pubblico e selezionate Mobile.

I dati sul campo provengono dal Chrome UX Report e coprono i 28 giorni precedenti. Controllate se il rapporto riguarda «Questo URL» oppure «Origine». Se i dati dell’URL non bastano, PageSpeed può usare l’origine, che comprende pagine con lo stesso protocollo, nome host e porta. Un’origine che supera la valutazione non dimostra che la singola pagina la superi. Se mancano dati a entrambi i livelli, l’assenza di valutazione non è una bocciatura.

La sezione di laboratorio è un nuovo test Lighthouse in condizioni simulate. Serve a indagare una risorsa lenta o uno script bloccante. Il suo punteggio prestazionale è distinto dalla valutazione sul campo. Una singola prova di navigazione non misura l’INP dei visitatori. Google spiega queste differenze.

Apri a grandezza naturale il rapporto mobile salvato del 4 agosto 2026 (Origine selezionata; Core Web Vitals superati)

Questo esempio salvato mostra dati sul campo dell’origine: LCP 2,4 secondi, INP 112 millisecondi e CLS 0. Non contiene un punteggio prestazionale Lighthouse. Illustra l’ambito del rapporto; non è una misurazione attuale della nostra homepage.

Cosa significano le soglie Core Web Vitals

La classificazione usa il 75° percentile delle misurazioni sul campo pertinenti, non la media:

Per superare la valutazione completa, tutte e tre devono essere buone. Se i dati INP sono insufficienti, PageSpeed può comunque indicare il superamento quando LCP e CLS sono buoni. Dati LCP o CLS insufficienti impediscono la valutazione. Questa regola documentata di PageSpeed non sostituisce le prove delle interazioni.

Confrontate Search Console a parità di ambito

In Search Console aprite Core Web Vitals e il rapporto mobile. Esaminate il gruppo interessato, la metrica peggiore e gli URL di esempio. Google raggruppa pagine con esperienze simili; questi gruppi non coincidono necessariamente con i vostri template. Riproducete il problema prima di attribuirlo a un componente condiviso.

PageSpeed e Search Console possono divergere anche confrontando soltanto dati sul campo. Controllate URL, origine o gruppo, dispositivo, periodo e trattamento degli URL. Search Console distingue i parametri degli URL; i dati sul campo di PageSpeed vengono aggregati senza tali parametri. Non ogni differenza è quindi «laboratorio contro utenti reali». La documentazione del rapporto descrive le distinzioni.

Dopo aver pubblicato una correzione, ripetete subito gli stessi passaggi nel browser e le stesse impostazioni di laboratorio. I dati sul campo cambiano con l’ingresso di nuove visite nella finestra mobile. «Inizia monitoraggio» apre una convalida di 28 giorni, senza forzare scansione o reindicizzazione. I dati visualizzati possono cambiare prima dei 28 giorni, mentre la convalida richiede comunque il periodo di monitoraggio e dati sufficienti.

Registrate le impostazioni di Lighthouse

Aprite la pagina in Chrome, poi DevTools, scegliete Lighthouse e selezionate Mobile prima dell’audit. Lighthouse locale può verificare pagine con accesso autenticato che una richiesta pubblica di PageSpeed non raggiunge. La documentazione di Lighthouse illustra le possibilità.

Salvate rapporto, data, URL, versione di Lighthouse, profilo dispositivo, limitazioni di velocità e versione della pagina. Mantenete costanti queste condizioni per confrontare una modifica e ripetete i risultati sorprendenti. Computer, browser, stato del consenso e configurazione possono alterare le misure. Rallentare manualmente il processore in DevTools non garantisce di riprodurre la simulazione di PageSpeed.

Automatizzare un test con l’API PageSpeed

Questo comando Bash richiede diagnosi mobili di prestazioni, accessibilità e SEO. Sostituite l’URL di esempio con una pagina pubblica:

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Su Windows usate un terminale Bash per questa sintassi su più righe. La guida introduttiva documenta l’accesso e raccomanda una chiave per interrogazioni automatiche frequenti. Verificate la quota del progetto prima di programmare serie di richieste. Un errore HTTP, compreso un errore di quota, non è una bocciatura della pagina.

Dentro lighthouseResult, leggete categories e audits; un punteggio di categoria 0.92 equivale a 92 su 100. Conservate fetchTime, lighthouseVersion, requestedUrl, finalUrl e configSettings, e gestite runtimeError prima di accettare il risultato. Consultate il riferimento della risposta. Per monitorare il campo nel tempo, Google consiglia CrUX API o CrUX History API perché prevede di rimuovere i dati CrUX dall’API PageSpeed.

Provate l’azione nel browser e sul telefono

Attivate la barra dispositivi di DevTools e iniziate con 360 × 800 e 390 × 844 pixel CSS. Variate gradualmente la larghezza, poi provate l’orientamento orizzontale. La modalità dispositivo è un’approssimazione: terminate su dispositivi fisici e browser pertinenti per il pubblico, incluso Safari su iPhone quando necessario.

• Aprite e chiudete navigazione, controlli del consenso e finestre di dialogo. Intestazioni fisse e banner non devono coprire testo o comandi.
• Leggete titoli lunghi, tabelle e traduzioni. Provate zoom e layout stretto. Il criterio sul ricalcolo del flusso delle linee guida per l’accessibilità web (WCAG) usa 320 pixel CSS per contenuti a scorrimento verticale, equivalenti a una finestra di 1280 pixel con zoom al 400%. Le vere tabelle bidimensionali hanno un’eccezione: preservate leggibilità e scorrimento utilizzabile invece di nascondere ciò che esce dai bordi.
• Toccate comandi adiacenti e usate la tastiera dove supportata. Il criterio WCAG 2.2 AA sulla dimensione del bersaglio usa 24 × 24 pixel CSS, con eccezioni per spaziatura e altri casi. Comandi più grandi, per esempio 48 × 48, possono essere più comodi. Nessuna delle due misure dimostra da sola la conformità di accessibilità.
• Compilate il modulo con la tastiera a schermo aperta. Verificate etichette, focus, errori, conservazione dei dati, invio e conferma. Per acquisti o prenotazioni usate un ambiente di test autorizzato e controllate la ricevuta o il record corrispondente.
• Ripetete su una connessione mobile rappresentativa. Un caricamento lento o una richiesta fallita deve lasciare una modalità chiara per proseguire.

Una segnalazione utile è precisa. Esempio ipotetico: «Sulla prenotazione a 390 × 844, tastiera e banner del consenso coprono Invia. La pagina scorre, ma il pulsante resta irraggiungibile». Aggiungete URL, browser, dispositivo, stato, passaggi, schermata, risultato atteso e responsabile. Una prenotazione bloccata merita attenzione anche con prestazioni in verde.

Correggete la causa misurata

Per un LCP lento, individuate l’elemento principale effettivo e il motivo del ritardo. Se è un’immagine, rendetela individuabile presto ed evitate il caricamento differito. Usate il precaricamento solo quando una risorsa deve essere scoperta prima, non per tutte le immagini e i font. La guida LCP spiega questa distinzione.

Registrate le interazioni lente e cercate il lavoro bloccante. Riducete gli script inutili o suddividete le attività lunghe, mantenendo funzioni necessarie e consenso. Per gli spostamenti del layout, riservate spazio a immagini, elementi incorporati e contenuti inseriti. Le guide INP e CLS aiutano a diagnosticare questi problemi diversi.

Su WordPress o Shopify, provate le modifiche a temi e applicazioni in staging con gli stessi contenuti e percorsi. Misurate l’effetto prima di accusare ogni plugin o proporre una ricostruzione. Alcune correzioni sono impostazioni, altre richiedono un componente diverso. Il nostro servizio di ottimizzazione web aiuta a identificare e realizzare gli interventi, con sviluppo web quando serve modificare il codice.

Separate indicizzazione e usabilità

Google consiglia il responsive per l’indicizzazione mobile-first, ma supporta anche altre configurazioni mobili. Assicuratevi che Googlebot acceda a contenuti, immagini e metadati mobili. Una pagina utilizzabile può avere un problema di indicizzazione che richiede un’indagine SEO distinta.

I Core Web Vitals contribuiscono ai sistemi di ranking, ma buoni punteggi non garantiscono posizioni elevate e un punteggio scarso non dimostra una penalizzazione. Le indicazioni Google sull’esperienza di pagina li collocano nel contesto dell’utilità complessiva della pagina.

Conservate un resoconto pratico: problema trovato, modifica pubblicata, azione riprovata con successo e convalida sul campo ancora in attesa. Ricontrollate i percorsi interessati dopo modifiche a temi, app, moduli o tag. Superare una valutazione e consentire al visitatore di completare l’azione sono verifiche distinte.