100 punti su PageSpeed: che cosa abbiamo cambiato

Il valore di partenza era 58 su 100 su telefono. Non è un valore scadente per un sito con un effetto 3D nell'intestazione, ma è un valore che Google penalizza in modo percepibile nella ricerca da mobile. Alla fine siamo arrivati a 100 punti su computer e 98 su telefono, con 100 anche per l'accessibilità.

Quello che segue non è una lista di controllo generica, ma il percorso reale, compresi i punti in cui ci siamo sbagliati.

Il punto di partenza

I cinque interventi che hanno contato davvero

1. Sostituire la libreria, non ottimizzarla

L'intestazione mostra una nuvola di particelle in 3D. Per farlo girava una nota libreria grafica: 458 KB dopo la minimizzazione. La misurazione indicava che 51 KB di quel codice non venivano nemmeno mai eseguiti.

Lo sguardo decisivo è stato la domanda su quanto ce ne servisse davvero. Erano undici componenti: renderer, scena, camera, geometria, materiale e qualche classe di supporto. Tutto questo si può programmare direttamente contro l'interfaccia grafica del browser.

Risultato: 458 KB sono diventati 6 KB. La resa visiva è identica: abbiamo ripreso gli stessi shader.

2. La compressione era attiva solo a metà

Nella configurazione del server la compressione era su «attiva», ma la riga che indica quali tipi di file comprimere era commentata. È l'impostazione predefinita di molte distribuzioni. Risultato: veniva compresso esclusivamente l'HTML.

La libreria grafica passava quindi sulla linea senza compressione. Dopo l'attivazione: 1243 KB sono diventati 251 KB. In più teniamo ora accanto le versioni compresse precalcolate, così il server non ricalcola a ogni richiesta.

Impegno: due righe di configurazione. Effetto: quasi un megabyte per ogni primo accesso.

3. Rimuovere del tutto la libreria di animazione

Per le comparse allo scorrimento girava un'altra libreria, 114 KB. La misurazione la indicava anche come causa di ricalcoli forzati del layout: durante lo scorrimento interrogava la geometria e costringeva il browser a ricalcolare l'impaginazione nel mezzo del movimento.

Sostituita con un IntersectionObserver che si limita ad assegnare una classe. Il movimento vero lo fa il CSS. 114 KB in meno, nessun ricalcolo, circa 40 righe di codice proprio.

4. La favicon pesava 205 KB

Un dettaglio con un effetto sorprendente, perché viene caricata molto presto. Sostituita con un file SVG da 6 KB, generato dal logo esistente.

5. Interrogare la geometria dentro il frame di animazione

Uno script leggeva l'altezza complessiva del documento a ogni evento di scorrimento. Questa proprietà il browser non può ricavarla dalla memoria: deve ricalcolare l'impaginazione dell'intera pagina, nel mezzo dello scorrimento.

La regola che ne deriva e che vale ovunque: leggere nell'evento, scrivere nel fotogramma successivo. Mai il contrario. Da allora l'altezza della pagina viene misurata una volta e memorizzata, invece di essere richiesta sessanta volte al secondo.

L'errore che è costato 24 punti

Che cosa ha reso poco

Per completezza, le misure che compaiono in ogni guida e che da noi sono state a malapena misurabili:

Formati delle immagini. La nostra pagina iniziale ha poche immagini: il logo è un file SVG. Dove ci sono immagini la conversione conviene, naturalmente; come leva principale funziona solo su pagine ricche di immagini.

Ridurre ulteriormente i caratteri. Ospitiamo due famiglie di caratteri in proprio e precarichiamo quelle necessarie nell'area visibile. Un'ulteriore ottimizzazione sarebbe possibile, ma non muove il valore.

Posizione del server. Consigliata spesso, nel nostro caso irrilevante: il tempo fino al primo byte era già di 20 millisecondi. Chi è già a posto lì non guadagna nulla da una rete di distribuzione.

Il procedimento da rifare

1. Misurare prima di cambiare qualsiasi cosa. Mobile e desktop separati, annotando i valori.
2. Cercare il file trasferito più grande. Quasi sempre è JavaScript. La domanda non è come rimpicciolirlo, ma se serva.
3. Verificare la compressione. Non se è attiva, ma per quali tipi di file.
4. Contare le richieste bloccanti. Ogni file di foglio di stile nell'intestazione trattiene la prima resa a video.
5. Verificare gli spostamenti di layout senza rallentamenti. L'unico test che a noi è mancato.
6. Rimisurare dopo ogni modifica. Altrimenti alla fine non si sa che cosa ha funzionato.

Aiutami a tradurre il rapporto PageSpeed della mia pagina in un
ordine di priorità. Sii severo; non lodare nulla.

I miei valori:
- Mobile: [punteggio], desktop: [punteggio]
- LCP, TBT, CLS per dispositivo: [valori]
- File trasferiti più grandi con dimensione: [elenco]
- Richieste che bloccano la resa: [elenco]
- Segnalazioni dal rapporto: [inserire testo]

Sulla pagina:
- Come è costruita: [CMS / statica / costruttore]
- Serve JavaScript per il contenuto visibile? [sì/no]
- Come viene servito il CSS? [esterno / in anticipo /
  parzialmente in anticipo]

Compiti:
1. Assegna ogni segnalazione a una causa e di' quale metrica
   influenza: LCP, TBT o CLS.
2. Ordina le misure per effetto rapportato all'impegno. Per
   ciascuna indica quanti punti muove realisticamente e perché.
3. Indica le misure del rapporto che con la mia struttura non
   portano praticamente nulla, e motivalo invece di ometterle.
4. Per ogni file JavaScript grande chiedi prima se serve, prima
   di proporre la minimizzazione.
5. Segnala se il CSS viene servito in anticipo solo in parte, e
   spiega perché per il CLS questo può essere peggio che non
   farlo affatto.
6. Indica che cosa dovrei rimisurare dopo ogni modifica.

Non inventare valori misurati.

Conclusione

Il punteggio in sé non è l'obiettivo: è un valore misurato, non un risultato aziendale. Ciò che conta è l'esperienza dietro di esso: una pagina leggibile dopo 1,4 secondi viene letta da più persone di una che ne impiega sei. Per i visitatori da mobile su rete cellulare la differenza è maggiore di qualsiasi ottimizzazione del testo.

La strada per arrivarci è passata nel nostro caso da un'unica domanda ricorrente: ci serve? Cinque interventi su sei sono consistiti nel togliere qualcosa, non nell'aggiungerla.

Domande frequenti