Ottimizzare i Core Web Vitals per i dispositivi di fascia bassa

Ottimizzare i Core Web Vitals per i dispositivi di fascia bassa

I Core Web Vitals dovrebbero far parte di un benchmark oggettivo per la qualità dei siti. In pratica, non lo sono! Le metriche sono strettamente legate ai dispositivi che gli utenti utilizzano. Se un'azienda vende prodotti o servizi di fascia alta, i suoi clienti tendono a possedere telefoni veloci, desktop e connessioni affidabili.
Al contrario, le aziende che si rivolgono ad acquirenti attenti ai costi o ai mercati emergenti hanno un pubblico che si affida a telefoni datati, processori deboli o condizioni di rete precarie.
Lo stesso sito web che supera agevolmente un test su un iPhone di punta fa fatica a caricarsi in modo accettabile su un Android di fascia media o in paesi con connettività a bassa larghezza di banda.

Ultima revisione di Arjen Karel a marzo 2026

I numeri raccontano la storia

Secondo il Web Almanac 2025, solo il 48% delle origini mobile supera i Core Web Vitals contro il 56% su desktop. Il divario più netto è l'INP: il 97% delle origini desktop lo supera, ma solo il 77% su mobile. Quel divario di 20 punti percentuali è causato quasi interamente dalle CPU più lente sui dispositivi Android.

Il Total Blocking Time mediano su mobile è di 1.916 millisecondi. Su desktop? 92 millisecondi. È un rapporto di 20:1. Se i tuoi script funzionano bene sul tuo MacBook, non funzionano assolutamente bene su un telefono economico.

Secondo la ricerca di Alex Russell, circa il 30% dei dispositivi in circolazione è di fascia bassa (4 core o meno, 4 GB di RAM o meno). Questi dispositivi hanno prestazioni single-core che sono fino a 9 volte più lente rispetto a un iPhone attuale. Nei dati RUM di CoreDash, vediamo che i siti ottimizzati per i dispositivi di fascia bassa superano i CWV nel 62% dei caricamenti di pagina su mobile, rispetto a solo il 41% per i siti che testano solo su hardware di fascia alta.

Passaggio 1: Generare un Client Capability Score

Per valutare se un visitatore sta utilizzando un dispositivo di fascia alta o di fascia bassa, è possibile calcolare un Client Capability Score direttamente nel browser. Questo punteggio va da 0 (estremamente limitato) a 100 (hardware di prim'ordine). In pratica, qualsiasi dispositivo con un punteggio inferiore a 40 dovrebbe essere classificato come scarso.

La funzione di seguito calcola il Client Capability Score utilizzando indicatori hardware e di rete che sono fortemente correlati ai dati RUM reali e ai Core Web Vitals di Google. Un punteggio più alto indica che il dispositivo è più in grado di offrire prestazioni di pagina veloci con meno vincoli di risorse.

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Suggerimento sui Core Web Vitals: Queste ottimizzazioni aiutano tutti. Ma se qualcuno ha una connessione lenta o utilizza un dispositivo con memoria limitata, contano molto di più. Gli svantaggi di ignorarle si manifestano più velocemente.
Prendiamo i download delle immagini. Su una connessione normale, di solito costituiscono circa il 10% del tempo di Largest Contentful Paint. Su una lenta, possono raddoppiare senza troppa fatica. Ecco perché non mettiamo l'ottimizzazione delle immagini in cima alla lista per la maggior parte degli utenti, ma quando si tratta di visitatori con larghezza di banda ridotta o limiti di memoria, diventa rapidamente una priorità.

Abilitare HTTP/3 con QUIC e 0-RTT

I visitatori lontani dai tuoi server o bloccati su reti lente affrontano elevati tempi di andata e ritorno (RTT). HTTP/3, insieme a QUIC e 0-RTT, migliora direttamente la velocità di connessione iniziale. Questa è un'ottimizzazione importante per tutti i visitatori, ma particolarmente critica per i visitatori con bassa larghezza di banda. Secondo Cloudflare Radar, HTTP/3 gestisce ora il 21% del traffico web globale. Se usi Cloudflare, puoi abilitare HTTP/3 nella dashboard di Cloudflare.

• Configurazione della connessione più rapida: QUIC unisce gli handshake di trasporto e crittografia in uno solo. 0-RTT va oltre: i visitatori abituali inviano dati immediatamente, bypassando del tutto gli handshake.
• Minore latenza per gli utenti di ritorno: 0-RTT consente ai client di riprendere le sessioni e inviare richieste senza pause. Centinaia di millisecondi risparmiati, particolarmente preziosi per utenti distanti o da mobile.
• Resilienza su lunghe distanze: HTTP/3 (su UDP) aggira l'head-of-line blocking del TCP. QUIC gestisce la perdita di pacchetti e le reti instabili in modo più elegante. Questo fa una vera differenza per le connessioni intercontinentali o mobile instabili.

Comprimere le immagini in modo più aggressivo di quanto piaccia al tuo designer

Le immagini ad alta risoluzione bloccano il LCP, in particolare sui dispositivi con limitata potenza di decompressione della GPU. Il Web Almanac 2025 mostra che l'homepage mobile mediana carica 911 KB di immagini. Si tratta del 42% del peso totale della pagina. Su un dispositivo economico con un downlink P75 di 9 Mbps, queste immagini competono direttamente con le tue risorse critiche.

Invece di cedere all'estetica, punta a immagini più piccole e percettivamente accettabili. WebP e AVIF aiutano, ma il lazy-loading e l'utilizzo di dimensioni responsive contano di più.

Una regola chiara: per le immagini hero sui dispositivi di fascia bassa, resta sotto i 100 KB. Se il designer obietta, dovrebbe testare lo stesso sito su un telefono Android da 100 € prima di discutere oltre.

Ridurre il CSS allo stretto necessario

Quando si tratta di stili c'è solo una regola: fare pulizia. Rimuovi i selettori inutilizzati, riduci la specificità e unifica le regole ridondanti.

Concentrati su layout prevedibili e coerenti con sovrascritture minime. Usa un piccolo set di classi di utilità piuttosto che stili complessi specifici per i componenti. Questo aiuta sia la costruzione del CSSOM del browser che la manutenibilità per gli sviluppatori.

Per i contenuti above-the-fold, incorpora solo ciò che è assolutamente necessario. Carica in lazy-loading il resto, ma mantieni la separazione minima e chiara. Puoi usare il Critical CSS Generator come punto di partenza, ma definisci il tuo CSS critico manualmente e in modo chirurgico per ottenere il miglior risultato.

Sii drastico con gli script

Con un TBT mobile mediano di 1.916 ms (in aumento del 58% anno su anno secondo il Web Almanac 2025), JavaScript è il singolo problema più grande sui dispositivi di fascia bassa. La velocità di rete P75 per i dispositivi economici è di circa 9 Mbps in download con 100 ms di RTT. Ogni kilobyte di JavaScript che distribuisci viene analizzato ed eseguito su una CPU che è 9 volte più lenta rispetto al telefono su cui testi.

• Nessuno script dovrebbe bloccare il rendering: Assicurati che tutti gli script non essenziali non siano bloccanti. Usa gli attributi async o defer nei tuoi tag <script>. Se uno script non è essenziale per il caricamento iniziale della pagina o l'interazione dell'utente, non deve essere sincrono. Per una panoramica completa sulle tecniche di differimento, vedi 16 metodi per differire JavaScript.
• Pianifica gli script non critici: Gli script che non sono richiesti in anticipo dovrebbero essere pianificati. Usa requestIdleCallback per avviare gli script quando il browser è inattivo. Questo ti consente di scaricare le attività pesanti senza interrompere i percorsi di rendering critici.
• Usa il Client Capability Score per caricare selettivamente gli script: Usa il punteggio per decidere cosa caricare. Sui dispositivi di fascia bassa, riduci il numero di script e scegli alternative più leggere. Se l'utente ha una memoria limitata o una CPU più vecchia, non sprecare risorse caricando script pesanti. Dai priorità alle prestazioni rispetto a funzioni puramente estetiche che potrebbero impressionare sui dispositivi di fascia alta ma frustrare su quelli di fascia bassa.

Usa i font di sistema o almeno evita font personalizzati pesanti

Il caricamento di font personalizzati aggiunge latenza e causa blocchi del layout. Sui dispositivi con memoria limitata, possono anche aumentare inutilmente la pressione sulla RAM. Secondo il Web Almanac 2025, l'88% dei siti carica almeno un web font, ma solo il 12% li precarica. L'opzione migliore per le prestazioni, font-display: optional, è usata da appena lo 0,4% dei siti.

I font di sistema vengono renderizzati più velocemente, rispettano le impostazioni dell'utente e riducono i layout shift. Se il branding impone una tipografia personalizzata, esegui il subset in modo aggressivo e carica i font in un secondo momento. Considera di ospitare i tuoi font internamente in modo da controllarne la distribuzione.

Monitorare con hardware reale, non solo con test sintetici

Gli strumenti di test sintetici (come Lighthouse, WebPageTest, ecc.) simulano il throttling ma non imitano tutte le peculiarità dell'hardware di fascia bassa: temperature, throttling sotto carico reale, pause per la garbage collection e colli di bottiglia dello storage. Nota che PageSpeed Insights ha cambiato il suo throttling della CPU da 4x a 1,2x a dicembre 2024, rendendo i punteggi di laboratorio ancora meno rappresentativi delle prestazioni reali dei dispositivi economici.

Compra un telefono Android economico e naviga sul tuo sito. Se non riesci a sopportare di farlo regolarmente, usa uno strumento RUM come CoreDash e segmenta i dati per classe di dispositivo. Se il tuo LCP al 75° percentile va bene su iPhone 15 ma è terribile su Xiaomi Redmi 9, è ora di essere onesti su per chi stai ottimizzando.