Ottimizza i Core Web Vitals per dispositivi di fascia bassa

Ottimizza i Core Web Vitals per dispositivi di fascia bassa

I Core Web Vitals dovrebbero far parte di un benchmark oggettivo per la qualità del sito. 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. 
Confrontalo con le aziende che si rivolgono ad acquirenti attenti ai costi o ai mercati emergenti. Il loro pubblico si affida a telefoni obsoleti, processori deboli o condizioni di rete scarse. 
Lo stesso sito web che supera facilmente 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. Questo articolo esamina come ottimizzare i Core Web Vitals per dispositivi di fascia bassa.

Passaggio 1: Genera 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 varia da 0 (estremamente limitato) a 100 (hardware di altissimo livello). In pratica, qualsiasi dispositivo con un punteggio inferiore a 40 dovrebbe essere classificato come scarso.

La funzione seguente calcola il Client Capability Score utilizzando indicatori hardware e di rete che sono fortemente correlati con i dati RUM del mondo reale e i dati dei Core Web Vitals di Google. Un punteggio più alto indica che il dispositivo è più capace di offrire prestazioni veloci della pagina con meno limitazioni di risorse e può gestire un'interazione più fluida.

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.
Prendi i download di immagini. Su una connessione normale, di solito costituiscono circa il 10% del tempo di LCP (Largest Contentful Paint). Su una lenta, possono raddoppiare senza molto sforzo. Ecco perché non mettiamo l'ottimizzazione delle immagini in cima alla lista per la maggior parte degli utenti, ma quando si ha a che fare con visitatori con larghezza di banda ridotta o memoria limitata, diventa rapidamente una priorità.

Abilita http/3 con QUIC e 0-RTT

• Configurazione della connessione più veloce: QUIC unisce gli handshake di trasporto e crittografia in uno solo. 0-RTT va oltre: i visitatori abituali inviano i 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 prezioso per utenti distanti o mobili.
• Resiliente sulle 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ù fluido — ideale per connessioni intercontinentali o connessioni mobili instabili.

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

Le immagini ad alta risoluzione bloccano l'LCP (Largest Contentful Paint), in particolare sui dispositivi con limitata potenza di decompressione della GPU. Invece di cedere all'estetica, punta a immagini più piccole e percettivamente accettabili. WebP e AVIF aiutano, ma il lazy-loading e servire dimensioni responsive contano di più.

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

Riduci il CSS allo stretto necessario

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

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

Per i contenuti above-the-fold, incorpora solo ciò che è assolutamente necessario. Usa il lazy-load per il resto, ma mantieni la divisione minima e chiara. Evita gli strumenti che indovinano cos'è il "critical CSS", definiscilo manualmente e chirurgicamente.

Sii schietto con gli Script

• 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. Altrimenti, stai solo buttando via millisecondi preziosi.
•  Pianifica gli script non critici Gli script che non sono richiesti in anticipo dovrebbero essere pianificati. Ma non caricarli a casaccio. Usa le funzioni requestIdleCallback per avviare gli script quando il browser è inattivo. Questo ti consente di scaricare attività pesanti senza interrompere i percorsi di rendering critici.
• Usa il Client Capability Score per caricare selettivamente script non essenziali ma utili:  Il Client Capability Score non è solo una metrica ma uno strumento per ottimizzare l'esperienza utente.  Sui dispositivi di fascia bassa, riduci il numero di script caricati e scegli alternative più leggere. Se l'utente ha memoria limitata o una CPU più vecchia, non sprecare risorse caricando script pesanti. Dai priorità alle prestazioni rispetto a funzionalità di vanità 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 jank nel layout. Sui dispositivi con memoria limitata, possono anche aumentare inutilmente la pressione sulla RAM.

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, crea sottoinsiemi in modo aggressivo e carica i font in ritardo.

Monitora con hardware reale, non solo test sintetici

Infine, gli strumenti di test sintetici (come Lighthouse, WebPageTest, ecc.) simulano il throttling ma non riproducono tutte le peculiarità dell'hardware di fascia bassa: surriscaldamento, throttling sotto carico reale, pause della garbage collection e colli di bottiglia dello storage.

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 P75 LCP è ottimo su iPhone 15 ma terribile su Xiaomi Redmi 9, è tempo di essere onesti su per chi stai ottimizzando.