Test di ottimizzazione mobile 2026: tool gratuiti e API PSI

Google ha ritirato il Test di ottimizzazione mobile autonomo a dicembre 2023, ma puoi ancora verificare gratis l’usabilità mobile. Usa PageSpeed Insights e Lighthouse per la diagnostica delle prestazioni, Chrome DevTools per i controlli di layout e uno smartphone vero per navigazione e moduli. Questi controlli rispondono a domande diverse. Una pagina veloce può comunque avere pulsanti irraggiungibili, e una pagina facile da usare può comunque caricarsi lentamente.

Vuoi il verdetto in 20 secondi? Usa il nostro Test di ottimizzazione mobile gratuito: incolla un URL e ottieni il punteggio di viewport, larghezza fissa, testo troppo piccolo, peso della pagina e scansione, con la correzione per ciascuno. Senza email.

Quali strumenti per l’ottimizzazione mobile funzionano ancora nel 2026

Il consiglio di “eseguire il Test di ottimizzazione mobile di Google” non vale più. Google ha annunciato che avrebbe dismesso il report Usabilità su dispositivi mobili di Search Console, lo strumento Test di ottimizzazione mobile e la relativa API a partire dal 1° dicembre 2023, e la dismissione è stata confermata pubblicamente il 4 dicembre 2023. Il motivo dichiarato da Google in quell’annuncio: l’usabilità mobile resta parte delle linee guida sull’esperienza sulla pagina, ma dal 2015 sono nate altre risorse, “including Lighthouse from Chrome”.

Google ha anche eliminato ogni menzione dello strumento dalla guida della Ricerca il 1° dicembre 2023 e ha reindirizzato gli URL sull’usabilità mobile di Search Console alla panoramica della proprietà. Nell’annuncio di aprile 2023, Google indica Lighthouse come sostituto. Una guida che propone ancora lo strumento ritirato come opzione attiva è superata.

Resta disponibile un controllo separato: il Mobile Friendliness Test Tool di Bing. Verifica come Bing vede la pagina su mobile, compresi configurazione del viewport, larghezza dei contenuti, leggibilità e spaziatura dei target di tocco. Il suo verdetto non dice come Google o un assistente IA classificheranno o citeranno la pagina.

Usabilità mobile e indicizzazione mobile-first sono controlli diversi

Google usa la versione mobile dei contenuti di una pagina per indicizzazione e ranking. Le sue linee guida sull’indicizzazione mobile-first supportano design responsive, pubblicazione dinamica e URL mobili separati. Il design responsive è l’opzione consigliata perché è più facile da implementare e mantenere.

Verifica che Googlebot possa accedere a contenuti, immagini e metadati su mobile. Poi verifica quanto facilmente una persona può usarli. Una pagina mobile bloccata è un problema di scansione; un pulsante troppo stretto è un problema di usabilità. Né un punteggio di Lighthouse né una misura dei target di tocco, da soli, ti dicono se una pagina verrà indicizzata.

Preferisci uno sguardo esperto sul tuo sito invece di un’altra scheda di audit? Scopri i nostri servizi di ottimizzazione dei siti web.

Un audit mobile con PageSpeed Insights e Lighthouse

Parti da PageSpeed Insights. Incolla un URL, avvia l’analisi e leggi la scheda Mobile prima della scheda Desktop.

Il report si divide in due metà che vengono confuse di continuo:

• Dati sul campo in alto: misurazioni di utenti reali di Chrome dal Chrome UX Report, aggiornate ogni giorno su una finestra mobile di 28 giorni. Sono questi i dati che usano davvero i segnali di esperienza sulla pagina di Google.
• Dati di laboratorio sotto: una singola esecuzione simulata di Lighthouse sui server di Google. Utili per la diagnostica, non un verdetto sugli utenti reali.

Per superare una valutazione completa dei Core Web Vitals con tutte e tre le metriche, una pagina deve rispettare la soglia “buono” al 75° percentile per tutte e tre le metriche. Se mancano i dati sul campo, il report non può fornire quella valutazione completa; non è la prova che la pagina sia stata bocciata. Lighthouse non può misurare l’INP sul campo con una singola esecuzione di navigazione.

Fonte: soglie dei Core Web Vitals su web.dev, aggiornate al 2026. L’INP ha sostituito il First Input Delay (FID) come Core Web Vital il 12 marzo 2024, quindi ignora qualsiasi checklist che ti dica ancora di ottimizzare il FID.

Due modifiche a PageSpeed Insights che hanno spostato l’asticella

Il 5 dicembre 2024 PageSpeed Insights ha modificato quanto rallenta la CPU (il processore), e in genere questo ha aumentato il Total Blocking Time nelle esecuzioni di laboratorio su mobile. I risultati sul campo e su desktop non sono stati toccati. Se il tuo punteggio di laboratorio su mobile è sceso senza che sia stato pubblicato nulla, questa è una causa plausibile.

PageSpeed Insights (PSI) e la sua API sono passati a Lighthouse 13.0 il 20 ottobre 2025. Le versioni possono cambiare la diagnostica che vedi, quindi registra la versione di Lighthouse con ogni risultato. Per il monitoraggio continuo degli utenti reali, Google consiglia la CrUX API o la CrUX History API: Google prevede di smettere di includere i dati sul campo di CrUX nell’API di PSI.

Esiste un sostituto per l’API del Test di ottimizzazione mobile?

La vecchia API del Test di ottimizzazione mobile è stata ritirata insieme allo strumento. L’API di PageSpeed Insights può automatizzare un’esecuzione mobile di Lighthouse, ma non riproduce il vecchio esito superato o non superato. Servono ancora i controlli di layout e interazione.

Questa richiesta chiede la diagnostica di prestazioni, accessibilità e SEO su mobile. Sostituisci l’URL di esempio con una pagina pubblica che vuoi testare:

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'

La guida introduttiva di Google permette di provare l’API senza chiave e consiglia una chiave per le richieste automatiche frequenti. Controlla la quota attuale del tuo progetto prima di pianificare un lotto. Se la risposta è HTTP 429, indaga sulla quota invece di trattarla come un risultato della pagina testata. Il riferimento dell’API documenta parametri e campi della risposta.

Leggi lighthouseResult.categories per i punteggi per categoria e lighthouseResult.audits per i singoli risultati. I punteggi usano una scala da zero a uno; 0,92 corrisponde a 92 su 100. Salva fetchTime e lighthouseVersion insieme all’URL testato, così i confronti successivi si basano su un’esecuzione nota. Gestisci gli errori HTTP e runtimeError prima di trattare una risposta come un audit.

Per le prestazioni sul campo usa la CrUX API o la CrUX History API. Un URL può non avere abbastanza dati di utenti reali. Tieni questo stato separato da un risultato scarso, e non presentare mai un punteggio di laboratorio come superamento dei Core Web Vitals sul campo.

Eseguire Lighthouse in locale

Lighthouse è integrato in Chrome DevTools. Apri la pagina, fai clic con il tasto destro, scegli Ispeziona, apri il pannello Lighthouse, seleziona Mobile e fai clic su Genera report. Lighthouse funziona nel Chrome installato e non invia mai i risultati a un server remoto, quindi puoi fare l’audit di versioni di staging e protette da password che PSI non raggiunge.

La preimpostazione mobile non è un’ipotesi. Lighthouse applica un moltiplicatore di rallentamento della CPU di 4x per portare una CPU desktop al livello di uno smartphone di fascia media, più una preimpostazione di rete “Slow 4G” che rappresenta il quartile più lento delle connessioni 4G. L’emulazione del dispositivo usa un profilo Moto G Power con un viewport di 412 per 823 e un fattore di scala di 1,75, con modalità mobile e tocco attive, secondo il file constants.js di Lighthouse (una versione precedente di questo articolo citava 2,625, il fattore di scala del vecchio profilo Moto G4 ritirato da Lighthouse, non il valore attuale).

Lighthouse 13 ha sostituito molti audit sulle prestazioni con insight allineati a DevTools, mantenendo unsized-images e non-composited-animations come diagnostica. Ha anche rimosso il vecchio audit sulla dimensione dei caratteri. Una diagnostica rimossa non rende accettabile un testo illeggibile; controlla il testo reale della pagina su uno smartphone.

Guida passo passo all’emulazione dei dispositivi in Chrome DevTools

I punteggi ti parlano di velocità. L’emulazione ti dice se la pagina è utilizzabile. Fai entrambe le cose.

1. Apri la pagina in Chrome, usa la scorciatoia di Ispeziona e attiva la Barra degli strumenti dispositivo.
2. Scegli prima un viewport stretto. Prova a 360 per 800 e a 390 per 844, poi sali fino alle larghezze dei tablet.
3. Imposta la limitazione su Mid-tier mobile oppure applica a mano Slow 4G più CPU 4x, come nel profilo di Lighthouse.
4. Ruota in orizzontale. In ogni orientamento apri il menu principale, un modulo e un passaggio di checkout o di contatto.
5. Osserva il pannello Elements mentre ridimensioni per trovare il contenitore che trabocca.

Cosa trova l’emulazione e un punteggio non troverà mai:

• Target di tocco piccoli schiacciati contro un elemento vicino, compresi i casi coperti dall’audit sui target di tocco di Lighthouse
• Scorrimento orizzontale causato da una tabella a larghezza fissa, un embed o un’immagine troppo grande
• Intestazioni fisse e banner dei cookie che occupano metà del viewport su uno schermo basso
• Finestre modali con il pulsante di chiusura spinto fuori dallo schermo
• Campi che aprono la tastiera sbagliata o attivano lo zoom quando ricevono il focus

Per controlli touch comodi, punta a 48 per 48 pixel CSS dove il layout lo permette. La regola documentata di Lighthouse considera sia la dimensione del target sia la sovrapposizione con i target vicini; non boccia ogni controllo più piccolo. Il criterio sulla dimensione del target delle WCAG 2.2 AA, che è separato, usa 24 per 24 pixel CSS con spaziatura e altre eccezioni. Nessuno dei due è una soglia di ranking universale di Google.

Conosci il limite. L’emulazione ridimensiona un browser desktop e simula una CPU lenta. Non riproduce la vera latenza del tocco, le peculiarità di Safari su iOS, la portata del pollice o il comportamento di un Android di fascia media con uno script pesante sotto limitazione termica. Chiudi ogni audit su uno smartphone vero.

Leggere i dati mobili dei Core Web Vitals in Search Console

Il vecchio report Usabilità su dispositivi mobili non c’è più. Usa il report Core Web Vitals di Search Console per le prestazioni con utenti reali, poi controlla layout e interazioni separatamente.

Apri Search Console, vai su Core Web Vitals e lavora sul report per dispositivi mobili. Google divide la panoramica per dispositivo, raggruppa gli URL che offrono esperienze simili e assegna a ogni gruppo lo stato della sua metrica peggiore. Quindi una sola metrica scarsa in un template trascina in Scarso ogni URL di quel template.

Come lo leggiamo:

• Fai clic su Apri report accanto al grafico per dispositivi mobili, poi passa tra le schede Scarso, Da migliorare e Buono.
• Leggi la tabella “Perché gli URL non sono considerati buoni”. Indica la metrica bocciata e la soglia superata.
• Correggi il template, non l’URL. Lo stato a livello di gruppo significa che una correzione al template sposta molte pagine.
• Usa Inizia monitoraggio dopo la pubblicazione. Google avvia una sessione di monitoraggio di 28 giorni e segna il problema come risolto solo se resta assente per tutta la finestra.

Due avvertenze. I dati sono un aggregato mobile di 28 giorni, quindi una correzione pubblicata martedì non si vede mercoledì. E Google dice chiaramente che i dati di PageSpeed Insights potrebbero differire dal report Core Web Vitals, perché uno è un’esecuzione di laboratorio su un solo profilo di dispositivo e l’altro sono migliaia di sessioni reali. Quando non concordano, fidati dei dati sul campo e usa l’esecuzione di laboratorio per trovare la causa. web.dev spiega la differenza tra laboratorio e campo in modo più approfondito. Le stesse metriche fanno parte del nostro approccio all’ottimizzazione dei siti web.

Gli errori mobili più comuni e come correggerli

Questi sono gli errori che gli strumenti qui sopra sono fatti per trovare, con la soglia o la regola che usa ciascuno.

Nota quale strumento rileva cosa. Nessun singolo strumento copre l’elenco, ed è proprio per questo che il vecchio badge superato o non superato non è mai bastato.

L’audit che facciamo, passo per passo

Questa è la sequenza che usiamo sul nostro sito e su quelli dei clienti, in quest’ordine.

1. Scegli tre URL, non uno. La homepage, una pagina importante di servizio o prodotto e un articolo del blog. I template falliscono in modi diversi.
2. Prima Search Console. Core Web Vitals, vista per dispositivi mobili. Annota quali gruppi di URL sono in Scarso o Da migliorare e quale metrica viene indicata. Sono utenti reali, quindi questo stabilisce la priorità.
3. PSI su un URL di ogni gruppo bocciato. Confronta i dati sul campo con quelli di laboratorio. Se il campo dice Scarso e il laboratorio dice che va bene, cerca script di terze parti, stati con accesso effettuato o server di origine lenti che un’esecuzione di laboratorio pulita non vede mai.
4. Lighthouse in locale sugli stessi tre URL. Preimpostazione mobile. Leggi la diagnostica su target di tocco e unsized-images, e il pannello Accessibilità per i problemi di contrasto.
5. Modalità dispositivo di DevTools a 360 per 800. Apri il menu, un modulo e il passaggio di conversione principale. Ruota. Cerca overflow e contenuti bloccati.
6. Il Mobile Friendliness Test di Bing sugli stessi URL, per il verdetto di un secondo crawler su viewport, larghezza, leggibilità e spaziatura dei tocchi.
7. Uno smartphone vero, se possibile un Android di fascia media. Carica con la rete cellulare, non con il wifi dell’ufficio. Completa l’azione di conversione dall’inizio alla fine.
8. Pubblica le correzioni ai template, poi usa Inizia monitoraggio in Search Console e conta 28 giorni prima che la convalida si concluda.

Perché dati sul campo e dati di laboratorio non concordano

Google è esplicita: i dati di PageSpeed Insights potrebbero differire dal report Core Web Vitals. I dati di laboratorio sono un’esecuzione simulata su un solo profilo di dispositivo. I dati sul campo sono un aggregato mobile di 28 giorni di utenti reali di Chrome. La guida di web.dev ai dati di laboratorio e sul campo elenca le cause abituali: dispositivi e reti reali variano più del laboratorio, gli script di terze parti si comportano diversamente con gli utenti reali, la cache e la cache avanti-indietro cambiano le visite di ritorno, e CrUX riporta solo gli URL con abbastanza traffico. Quando non concordano, tratta i dati sul campo come verdetto e l’esecuzione di laboratorio come diagnostica.

Quando esaminiamo un sito guardiamo prima i dati sul campo di Search Console, poi usiamo PSI e Lighthouse per individuare l’elemento o lo script. Le guide di ottimizzazione di Google sono il manuale:

• LCP lento: ottimizzare il Largest Contentful Paint. Comprimi l’immagine principale, usa un formato moderno, precarica l’elemento LCP e non caricarlo in lazy loading.
• INP alto: ottimizzare l’Interaction to Next Paint. Spezza i task lunghi e rimanda o elimina il JavaScript di terze parti che blocca il thread principale.
• CLS alto: ottimizzare il Cumulative Layout Shift. Imposta larghezza, altezza o aspect-ratio su immagini ed embed, così il layout non salta quando si caricano.

Search Console raggruppa gli URL che offrono esperienze simili e assegna a ogni gruppo lo stato della sua metrica peggiore. Una sola correzione al template, come le dimensioni delle immagini in un componente card condiviso, può spostare molti URL insieme. Dopo la pubblicazione usa Inizia monitoraggio e attendi l’intera finestra di 28 giorni prima che Google segni il problema come risolto.

Ripeti la sequenza di otto passaggi dopo i cambi di tema, l’installazione di plug-in o app e ogni pubblicazione nel tag manager, più un controllo trimestrale programmato. Gli script di terze parti sono un rischio documentato per l’INP nelle linee guida di Google sull’INP, ed è per questo che il passaggio 3 confronta i dati sul campo con un’esecuzione di laboratorio pulita. Per scansione, indicizzazione e lavoro on-page attorno a questo controllo mobile, vedi il nostro servizio di ottimizzazione per i motori di ricerca.

E se usi WordPress o Shopify

Entrambe le piattaforme ti portano quasi fino in fondo con la configurazione invece del codice:

• Un tema responsive, testato a 360 px prima di sceglierlo
• Lazy loading nativo ovunque tranne che sull’immagine LCP
• Formati di immagine moderni alle dimensioni giuste, non file desktop rimpiccioliti con i CSS (fogli di stile a cascata)
• Template di Shopify Online Store 2.0 e dimensioni delle immagini per sezione
• Un audit delle app e dei plug-in installati, perché ognuno di solito aggiunge JavaScript che blocca il rendering

Riesegui Lighthouse dopo ogni modifica al tema o alle app. È lì che i punteggi mobili calano senza che nessuno se ne accorga. Se il limite è il tema stesso, la soluzione è ricostruire il sito su un framework moderno con prestazioni e SEO progettati fin dall’inizio, ed è quello che offre il nostro servizio di sviluppo di siti web.

Domande frequenti

Come verifico l’ottimizzazione mobile ora che il test di Google non c’è più?

Esegui Lighthouse in Chrome DevTools con la preimpostazione Mobile, controlla la scheda Mobile in PageSpeed Insights, leggi il report mobile dei Core Web Vitals in Search Console, poi conferma su uno smartphone vero. Il Mobile Friendliness Test di Bing dà ancora un verdetto superato o non superato, se ne vuoi uno.

Qual è la differenza tra ottimizzato per il mobile e responsive?

Ottimizzato per il mobile significa che la pagina è utilizzabile su uno smartphone. Il design responsive adatta la stessa pagina a viewport diversi con layout fluidi e media query CSS. Google consiglia il design responsive perché è più facile da mantenere, ma supporta anche la pubblicazione dinamica e gli URL mobili separati.

Mi serve un sito mobile separato?

No. Un unico URL responsive è più semplice da mantenere, evita di gestire contenuti duplicati e offre un solo insieme di segnali per la SEO e per l’ottimizzazione per i motori generativi.

Google penalizza i siti non ottimizzati per il mobile?

Verifica separatamente l’accesso ai contenuti e l’esperienza utente. Google deve poter accedere ai tuoi contenuti mobili e visualizzarli per indicizzarli. I Core Web Vitals sono usati nel ranking, ma Google cerca comunque contenuti pertinenti anche quando l’esperienza sulla pagina è carente. Un punteggio mobile scarso, da solo, non prova una deindicizzazione, una penalizzazione o una specifica perdita di posizioni.

Perché PageSpeed Insights e Search Console non concordano?

Google afferma che i due possono differire. I dati di laboratorio di PSI sono un’esecuzione simulata su un solo profilo di dispositivo. Search Console riporta un aggregato mobile di 28 giorni di utenti reali di Chrome su un intero gruppo di URL. La documentazione di Google sul report Core Web Vitals e l’articolo di web.dev su laboratorio e campo dicono entrambi di trattare i dati sul campo come verdetto e quelli di laboratorio come diagnostica.

Quattro strumenti hanno sostituito un unico badge

Il badge unico superato o non superato non c’è più e non tornerà. Ciò che lo ha sostituito è migliore: la misurazione sul campo degli utenti reali, un audit di laboratorio che puoi eseguire in staging, l’emulazione del viewport per il layout e il verdetto di un secondo crawler, quello di Bing. Costruisci il tuo processo attorno a questi quattro, stabilisci le priorità in base a ciò che Search Console dice degli utenti reali e correggi i template invece dei singoli URL.

Ce ne occupiamo da Vancouver come ottimizzazione dei siti web. Se le prestazioni mobili ti stanno costando posizioni o conversioni, un audit di crescita è il punto di partenza.