Forse sospetta già che il Suo sito WordPress non sia veloce come potrebbe. Ma lo ha verificato su mobile?
Prenda il telefono adesso e carichi il suo sito. Conti i secondi. Osservi il layout che salta. Noti le immagini che si caricano nelle dimensioni sbagliate. Questa è l'esperienza che vede il 60% dei suoi visitatori, perché questa è la quota del traffico web che proviene da dispositivi mobili nel 2026.
Anche Google sta guardando.
Mobile-First Indexing: Perché le Prestazioni Mobile Pesano di Più
Dal 2021, Google utilizza il mobile-first indexing per tutti i siti. Questo significa che il posizionamento dipende dalle prestazioni su mobile, non su desktop.
Le prestazioni desktop contano ancora per molti percorsi B2B, ma l'indice di Google è mobile-first: la velocità su mobile ha più peso SEO. Se il punteggio mobile PageSpeed è 45, è quel numero che il crawler di Google considera prioritario. È un fattore determinante per apparire in prima o in terza pagina.
Molti siti WordPress ottengono 35-55 su mobile PageSpeed senza un lavoro dedicato alle prestazioni. Questo è al di sotto della soglia raccomandata da Google e può diventare un problema concreto per il business.
Perché i Siti WordPress Faticano su Mobile
I temi non sono stati progettati per il mobile-first
La maggior parte dei temi WordPress è progettata per desktop e poi "resa responsive" con le media query CSS. Il risultato: il telefono scarica gli stessi asset pesanti di un browser desktop, per poi nascondere ciò che non serve. I dati vengono trasferiti lo stesso. Il JavaScript viene eseguito lo stesso. Semplicemente non si vede.
Un sito realmente mobile-first invia solo ciò di cui il dispositivo ha bisogno. La maggior parte dei temi WordPress non lo fa di default, anche se è possibile con un'attenta selezione e configurazione del tema.
CSS e JavaScript che bloccano il rendering
Un sito WordPress medio carica 15-25 file CSS e JavaScript separati prima che appaia qualsiasi cosa sullo schermo. Ogni file è un round-trip verso il server. Sulle reti mobile, anche con il 4G veloce, questo può aggiungere 2-4 secondi di attesa pura prima che si visualizzi un singolo pixel.
I plugin di caching tentano di combinare e minimizzare questi file. Ma non possono risolvere il problema fondamentale: WordPress carica tutto in anticipo perché i plugin non si coordinano tra loro.
Le immagini sono il problema principale
WordPress genera più dimensioni di immagine, ma raramente serve quella giusta per il dispositivo. Un'immagine hero da 2000px viene inviata a uno schermo da 390px. Anche con i plugin di lazy loading, WordPress non serve formati moderni come WebP o AVIF di default, né utilizza un nodo CDN vicino al visitatore.
Su mobile, le immagini rappresentano spesso il 60-80% del peso totale della pagina. Se questo aspetto è trascurato, tutto il resto diventa irrilevante.
I page builder aggiungono un overhead enorme
Elementor, Divi, WPBakery: questi strumenti semplificano la progettazione con WordPress. Il JavaScript dei page builder può aggiungere 500kb-1.5MB per pagina; i siti con più page builder si caricano spesso in 5-8 secondi su dispositivi mobile di fascia media in 4G. Su desktop con una connessione veloce, la differenza è quasi impercettibile.
L'hosting condiviso non regge i picchi di traffico mobile
Gli utenti mobile sono impazienti e si aspettano pagine in meno di 2 secondi. I server di hosting condiviso che impiegano 800ms solo per rispondere alla richiesta iniziale hanno già consumato metà di quel budget prima che si carichi un singolo asset.
Numeri Reali: WordPress vs Next.js su Mobile
Dopo decine di migrazioni da WordPress a Next.js, i numeri mobile di solito si presentano così:
| Metrica | WordPress (senza ottimizzazione) | Next.js su Vercel |
|---|---|---|
| Mobile PageSpeed | 35-55 | 90-99 |
| First Contentful Paint | 3.0-5.5s | 0.3-0.8s |
| Largest Contentful Paint | 4.0-8.0s | 0.6-1.2s |
| Cumulative Layout Shift | 0.15-0.35 | 0.01-0.05 |
| Peso totale della pagina | 2-5mb | 200-500kb |
Stesso contenuto. Stesso brand. La differenza è nell'architettura.
Cosa Significa Davvero un'Architettura "Mobile-First"
I siti Next.js sono costruiti in modo fondamentalmente diverso:
Generazione statica. Le pagine sono pre-costruite come file HTML al momento del deploy. Quando un utente mobile visita il sito, riceve un file statico da un CDN: nessuna elaborazione server, nessuna query al database, nessuna esecuzione PHP. Tempo di risposta: circa 50ms a livello globale.
Immagini responsive di default. Next.js include un componente Image integrato che serve automaticamente la dimensione corretta, nel formato WebP/AVIF, con lazy loading, dall'edge. Un utente mobile su uno schermo da 390px riceve un'immagine da 390px, non un'immagine da 2000px compressa in un viewport ridotto.
Deploy su edge CDN. Vercel distribuisce il sito da oltre 100 location edge globali. Un utente mobile a Milano riceve la pagina da un nodo vicino, non da un server condiviso a Dallas. La distanza fisica da sola può risparmiare 200-400ms.
JavaScript minimale. Niente jQuery. Nessuna catena di plugin. Nessun runtime di page builder. Un tipico sito business Next.js distribuisce 50-100kb di JavaScript totale, molto meno rispetto alle build WordPress tipiche (spesso 500kb-1.5MB).
Cosa Può Fare al Riguardo
Prima di tutto, verifichi il punteggio mobile. Se non conosce il suo attuale punteggio mobile PageSpeed, sta operando alla cieca. Ottenga un WordPress Health Report gratuito su webvise.io/wp-health-report: mostra il punteggio mobile reale, i flag di sicurezza e cosa otterrebbe il sito dopo una ricostruzione.
Valuti se un'ulteriore ottimizzazione WordPress può portare dove ha bisogno. Se il punteggio mobile è sotto 60, raggiungere 90+ solo tramite plugin può essere molto difficile. Si rischia di spendere in plugin di caching, ottimizzatori di immagini e abbonamenti CDN per poi stabilizzarsi comunque attorno ai 60. A un certo punto, l'architettura diventa il fattore limitante.
Consideri una ricostruzione. Una migrazione da WordPress a Next.js viene definita in base alla complessità del sito, al volume di contenuti, al rischio SEO e alle integrazioni, e affronta le cause architetturali dei problemi di velocità mobile. I siti costruiti correttamente ottengono tipicamente 90+ su mobile al lancio. Nessuna pipeline di manutenzione dei plugin: le prestazioni non degradano per aggiornamenti di plugin o temi, anche se gli aggiornamenti di framework e dipendenze restano necessari.
I visitatori mobile e il crawler mobile di Google vedono la differenza.
Vuole sapere cosa ottiene il suo sito su mobile? Riceva il suo WordPress Health Report gratuito su webvise.io/wp-health-report: bastano 60 secondi. Nessuna registrazione richiesta.