Ottimizza la codifica e le dimensioni di trasferimento degli asset basati su testo

Ilya Grigorik

Jeremy Wagner

Oltre a eliminare i download di risorse non necessarie, la cosa migliore che puoi fare per migliorare la velocità di caricamento della pagina è ridurre al minimo le dimensioni complessive del download ottimizzando e comprimendo le risorse rimanenti.

Guida introduttiva alla compressione dei dati

Una volta configurato il sito web per evitare il download di risorse inutilizzate, il passaggio successivo consiste nel comprimere le risorse idonee rimanenti che il browser deve scaricare. A seconda del tipo di risorsa (testo, immagini, caratteri e così via), esistono molte tecniche diverse tra cui scegliere: strumenti generici che possono essere attivati sul server web, ottimizzazioni di pre-elaborazione per tipi di contenuti specifici e ottimizzazioni specifiche per le risorse che richiedono l'input dello sviluppatore.

Per ottenere il miglior rendimento è necessaria una combinazione di tutte le seguenti tecniche:

• La compressione è il processo di codifica delle informazioni utilizzando meno bit.
• L'eliminazione dei dati non necessari produce sempre i risultati migliori.
• Esistono molte tecniche e algoritmi di compressione diversi.
• Per ottenere la migliore compressione, avrai bisogno di una serie di tecniche.

Il processo di riduzione delle dimensioni dei dati è la compressione dei dati. Molte persone hanno contribuito con algoritmi, tecniche e ottimizzazioni per migliorare i tassi di compressione, la velocità di compressione e la memoria richiesta da vari algoritmi di compressione.

Una discussione completa sulla compressione dei dati va ben oltre lo scopo di questa guida. Tuttavia, è importante capire, a livello generale, come funziona la compressione e le tecniche che puoi utilizzare per ridurre le dimensioni dei vari asset richiesti dalle tue pagine.

Per illustrare i principi fondamentali di queste tecniche, considera la procedura di ottimizzazione di un semplice formato di messaggio di testo inventato appositamente per questo esempio:

# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA

1. I messaggi possono contenere annotazioni arbitrarie, a volte chiamate commenti, indicate dal prefisso "#". Le annotazioni non influiscono sul significato del messaggio o sul suo comportamento.
2. I messaggi possono contenere intestazioni, ovvero coppie chiave-valore (separate da ":" nell'esempio precedente) che vengono visualizzate all'inizio del messaggio.
3. I messaggi contengono payload di testo.

Cosa si può fare per ridurre le dimensioni del messaggio precedente, che inizia con 200 caratteri?

1. Il commento è interessante, ma non influisce sul significato del messaggio. Eliminalo durante la trasmissione del messaggio.
2. Esistono tecniche efficaci per codificare le intestazioni in modo efficiente. Ad esempio, se sai che tutti i messaggi hanno "formato" e "data", puoi convertirli in ID interi brevi e inviarli. Tuttavia, potrebbe non essere vero, quindi è meglio lasciarlo stare per ora.
3. Il payload è solo testuale. Anche se non sappiamo quali siano i contenuti reali di questo testo (a quanto pare, utilizza un "secret-cipher"), la sola lettura mostra che contiene molte ridondanze. Forse, invece di inviare lettere ripetute, puoi semplicemente contare il numero di lettere ripetute e codificarle in modo più efficiente. Ad esempio, "AAA" diventa "3A", che rappresenta una sequenza di tre A.

La combinazione di queste tecniche produce il seguente risultato:

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

Il nuovo messaggio è lungo 56 caratteri, il che significa che hai compresso il messaggio originale del 72%. Si tratta di una riduzione significativa.

Questo è un esempio giocattolo di come gli algoritmi di compressione possono ridurre efficacemente le dimensioni del trasferimento delle risorse basate su testo. In pratica, gli algoritmi di compressione sono molto più sofisticati di quanto illustrato nell'esempio precedente e sul web possono essere utilizzati per ridurre significativamente i tempi di download delle risorse. Applicando la compressione agli asset basati su testo, una pagina web può impiegare meno tempo per caricare le risorse, in modo che gli utenti possano vedere gli effetti di queste risorse prima di quanto farebbero senza compressione.

Minificazione: pre-elaborazione e ottimizzazioni specifiche per il contesto

La prima tecnica discussa qui è la riduzione. Sebbene la minificazione non sia un algoritmo di compressione vero e proprio, è un modo per rimuovere i caratteri non necessari e ridondanti utilizzati nel codice sorgente per rendere le risorse più leggibili per gli utenti. Tuttavia, questa leggibilità non è necessaria per mantenere la funzionalità del codice sorgente sui siti web di produzione e può ritardare il caricamento delle risorse sul web.

La minimizzazione è un tipo di ottimizzazione specifico per i contenuti che può ridurre significativamente le dimensioni delle risorse pubblicate e queste ottimizzazioni vengono applicate al meglio nell'ambito del processo di build e deployment. Ad esempio, i bundler sono un tipo di software di uso comune che può ridurre automaticamente le risorse poco prima del deployment di un nuovo codice di produzione su un sito web.

Il modo migliore per comprimere i dati ridondanti o superflui è eliminarli. Tuttavia, non puoi eliminare dati arbitrari. Tuttavia, in alcuni contesti in cui abbiamo conoscenze specifiche dei contenuti sul formato dei dati e sulle relative proprietà, è possibile ridurre significativamente le dimensioni del payload senza influire sul suo significato o sulle sue funzionalità.

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }

      .awesome-container {
        width: 50%;
      }
    </style>
  </head>
  <body>
    <!-- awesome container content: START -->
    <div>
      This is my awesome container, and it is <em>so</em> awesome.
    </div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // Beacon conversion metrics
    </script>
  </body>
</html>

Considera lo snippet HTML precedente e i tre diversi tipi di contenuti che contiene:

1. Markup HTML.
2. CSS per personalizzare la presentazione di una pagina.
3. JavaScript per potenziare le interazioni e altre funzionalità avanzate della pagina.

Ciascuno di questi tipi di contenuti ha regole diverse per ciò che costituisce contenuti validi, regole diverse per specificare i commenti e così via. La domanda che rimane, però, è "come si può ridurre le dimensioni di questa pagina?"

• I commenti del codice sono i migliori amici di uno sviluppatore, ma il browser non ne ha bisogno. La rimozione dei commenti CSS (/* ... */), HTML (<!-- ... -->) e JavaScript (// ...) riduce le dimensioni totali del trasferimento della pagina e delle relative risorse secondarie.
• Un compressore CSS "intelligente" potrebbe notare che stiamo utilizzando un modo inefficiente per definire le regole per .awesome-container e comprimere le due dichiarazioni in una sola senza influire su altri stili, risparmiando più byte. In un ampio insieme di regole CSS, la rimozione di questo tipo di ridondanza può fare la differenza, ma potrebbe non essere qualcosa che può essere applicato in modo aggressivo, poiché i selettori vengono spesso duplicati necessariamente in contesti diversi, ad esempio all'interno delle query supporti.
• Spazi e tabulazioni sono utili per gli sviluppatori in HTML, CSS e JavaScript. Un compressore aggiuntivo potrebbe eliminare tutte le tabulazioni e gli spazi. A differenza di altre tecniche di deduplicazione, questo tipo di ottimizzazione può essere applicato in modo abbastanza aggressivo, a condizione che gli spazi o le tabulazioni non siano necessari per la presentazione della pagina. Ad esempio, è consigliabile conservare gli spazi all'interno delle sequenze di testo in un documento HTML, in quanto garantiscono la leggibilità dei contenuti che gli utenti vedranno effettivamente.

<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>

Dopo aver applicato i passaggi precedenti, la pagina passa da 516 a 204 caratteri, il che rappresenta un risparmio di circa il 60%. Certo, non è molto leggibile, ma non è necessario che lo sia per essere utilizzabile. Le pratiche di sviluppo moderne ti consentono anche di mantenere le versioni ben formattate e leggibili del codice sorgente separate dal codice ben ottimizzato che invii alla produzione. In combinazione con le mappe delle origini, che forniscono una rappresentazione leggibile del codice di produzione trasformato, puoi risolvere più facilmente i bug in produzione e avere una buona esperienza di sviluppo ottimizzando al contempo le prestazioni a vantaggio dell'esperienza utente.

Nota: sebbene non rappresentate nell'esempio precedente, le immagini SVG sono un'altra risorsa basata su testo. I file SVG possono essere compressi e ottimizzati in modo lossy utilizzando strumenti come SVGO.

L'esempio precedente illustra un punto importante: un compressore generico, ad esempio uno progettato per comprimere testo arbitrario, potrebbe fare un ottimo lavoro di compressione della pagina nell'esempio precedente, ma non saprebbe mai di dover rimuovere i commenti, comprimere le regole CSS o decine di altre ottimizzazioni specifiche per i contenuti. Ecco perché il pre-elaborazione, la minimizzazione e altre ottimizzazioni sensibili al contesto sono importanti.

Nota: ad esempio, le versioni di sviluppo non compresse dei framework più diffusi sono molto più grandi delle loro versioni equivalenti destinate all'uso in produzione. Ad esempio, la versione di sviluppo di Angular 1.8.3 occupa quasi 1,4 megabyte. La versione di produzione è di 177 kilobyte. Ciò dimostra chiaramente il potenziale di queste ottimizzazioni.

Allo stesso modo, le tecniche descritte sopra possono essere estese oltre gli asset basati sul testo. Immagini, video e altri tipi di contenuti contengono tutti le proprie forme di metadati e vari payload. Ad esempio, ogni volta che scatti una foto con una fotocamera, il file in genere incorpora molte informazioni aggiuntive: impostazioni della fotocamera, posizione e così via. A seconda dell'applicazione, questi dati potrebbero essere fondamentali (ad esempio, un sito di condivisione di foto) o completamente inutili. Valuta se vale la pena rimuoverlo. In pratica, questi metadati possono aggiungere fino a decine di kilobyte per ogni immagine.

In breve, come primo passo per ottimizzare l'efficienza degli asset, crea un inventario dei diversi tipi di contenuti e valuta quali tipi di ottimizzazioni specifiche per i contenuti puoi applicare per ridurne le dimensioni. Una volta identificate, automatizza queste ottimizzazioni aggiungendole ai passaggi di build e rilascio per assicurarti che vengano applicate in modo coerente per ogni nuova uscita in produzione.

Compressione del testo con algoritmi di compressione

Il passaggio successivo per ridurre le dimensioni degli asset basati su testo consiste nell'applicare un algoritmo di compressione. Questo passaggio va oltre, in quanto cerca in modo aggressivo pattern ripetibili nei payload basati su testo prima di inviarli all'utente e li decomprime una volta arrivati nel browser dell'utente. Il risultato è un'ulteriore e significativa riduzione di queste risorse e tempi di download più rapidi.

• gzip e Brotli sono algoritmi di compressione di uso comune che offrono le prestazioni migliori per gli asset basati su testo: CSS, JavaScript, HTML.
• Tutti i browser moderni supportano la compressione gzip e Brotli e pubblicizzano il supporto per entrambi nell'intestazione della richiesta HTTP Accept-Encoding.
• Il server deve essere configurato per attivare la compressione. Il software del server web spesso attiva per impostazione predefinita i moduli per comprimere le risorse basate su testo.
• Sia gzip che Brotli possono essere ottimizzati per migliorare i tassi di compressione regolando il livello di compressione. Per gzip, le impostazioni di compressione vanno da 1 a 9, dove 9 è la migliore. Per Brotli, questo intervallo va da 0 a 11, dove 11 è il valore migliore. Tuttavia, impostazioni di compressione più elevate richiedono più tempo. Per le risorse compresse dinamicamente, ovvero al momento della richiesta, le impostazioni al centro dell'intervallo tendono a offrire il miglior compromesso tra rapporto di compressione e velocità. Tuttavia, è possibile la compressione statica, ovvero la compressione della risposta in anticipo, che può quindi utilizzare le impostazioni di compressione più aggressive disponibili per ogni algoritmo di compressione.
• Le reti CDN (Content Delivery Network) in genere offrono la compressione automatica delle risorse idonee. Le CDN possono anche gestire la compressione dinamica e statica per te, così non dovrai preoccuparti di un altro aspetto della compressione.

gzip e Brotli sono compressori comuni che possono essere applicati a qualsiasi flusso di byte. A livello interno, ricordano alcuni dei contenuti esaminati in precedenza di un file e successivamente tentano di trovare e sostituire i frammenti di dati duplicati in modo efficiente.

Nota: se ti interessa una spiegazione più approfondita del funzionamento della compressione, guarda questo ottimo approfondimento di basso livello su gzip. Se vuoi sperimentare la compressione del testo, prova i nostri codelab gzip e Brotli.

In pratica, sia gzip che Brotli offrono le prestazioni migliori sui contenuti basati su testo, raggiungendo spesso tassi di compressione fino al 70-90% per i file più grandi. Tuttavia, l'esecuzione di queste risorse di algoritmi già compresse utilizzando algoritmi alternativi, ad esempio la maggior parte dei formati di immagine che utilizzano tecniche di compressione lossless o lossy, produce un miglioramento minimo o nullo.

Tutti i browser moderni annunciano il supporto di gzip e Brotli nell'intestazione della richiesta HTTP Accept-Encoding. Tuttavia, è responsabilità del provider di hosting assicurarsi che il server web sia configurato correttamente per pubblicare la risorsa compressa quando il client la richiede.

File	Algoritmo	Dimensioni non compresse	Dimensioni compresse	Rapporto di compressione
angular-1.8.3.js	Brotli	1346 KiB	256 KiB	81%
angular-1.8.3.js	gzip	1346 KiB	329 KiB	76%
angular-1.8.3.min.js	Brotli	173 KiB	53 KiB	69%
angular-1.8.3.min.js	gzip	173 KiB	60 KiB	65%
jquery-3.7.1.js	Brotli	302 KiB	69 KiB	77%
jquery-3.7.1.js	gzip	302 KiB	83 KiB	73%
jquery-3.7.1.min.js	Brotli	85 KiB	27 KiB	68%
jquery-3.7.1.min.js	gzip	85 KiB	30 KiB	65%
lodash-4.17.21.js	Brotli	531 KiB	73 KiB	86%
lodash-4.17.21.js	gzip	531 KiB	94 KiB	82%
lodash-4.17.21.min.js	Brotli	71 KiB	23 KiB	68%
lodash-4.17.21.min.js	gzip	71 KiB	25 KiB	65%

La tabella precedente mostra i risparmi che la compressione Brotli e gzip possono offrire per alcune librerie JavaScript note. Il risparmio varia dal 65% all'86% a seconda del file e dell'algoritmo. Come riferimento, a ogni file è stato applicato il livello di compressione massimo sia per Brotli che per gzip. Ove possibile, preferisci Brotli a gzip.

Importante: la tabella precedente mostra chiaramente come l'applicazione della compressione in aggiunta a ottimizzazioni come la minimizzazione possa fornire un risparmio aggiuntivo. Non sempre la sola compressione rende gli effetti della minimizzazione privi di significato: si tratta di un'ottimizzazione additiva.

L'attivazione della compressione è una delle ottimizzazioni più semplici ed efficaci da implementare. Se il tuo sito web non ne usufruisce, stai perdendo una grande opportunità per migliorare le prestazioni per i tuoi utenti. Fortunatamente, molti server web forniscono configurazioni predefinite che consentono questa importante ottimizzazione e le CDN in particolare sono molto efficaci nell'implementarla in modo da bilanciare velocità e rapporto di compressione.

Un modo rapido per vedere la compressione in azione è aprire Chrome DevTools, aprire il riquadro Rete, caricare una pagina a tua scelta e osservare la parte inferiore del riquadro Rete.

Una rappresentazione delle dimensioni del trasferimento (ovvero compresse) di tutte le risorse della pagina rispetto alle loro dimensioni effettive, come visualizzate nel riquadro Rete di Chrome DevTools.

Come nell'immagine precedente, dovresti vedere una suddivisione di:

• Il numero di richieste, ovvero il numero di risorse caricate per la pagina.
• Le dimensioni del trasferimento di tutte le richieste. Riflette l'efficacia della compressione applicata a una qualsiasi risorsa di una pagina.
• La dimensione della risorsa di tutte le richieste. Riflette le dimensioni delle risorse per la pagina dopo la decompressione.

Nota: a volte gli algoritmi di compressione possono aumentare le dimensioni dell'asset. In genere, questo accade quando l'asset non compresso è molto piccolo e l'overhead dell'algoritmo è superiore al risparmio della compressione oppure quando la risorsa è già ben compressa. Per evitare questo problema, alcuni server ti consentono di specificare una soglia minima per le dimensioni dei file, che in genere è inferiore a quattro o cinque kilobyte.

Effetti sui Core Web Vitals

I miglioramenti del rendimento non possono essere misurati a meno che non esistano metriche che riflettano questi miglioramenti. L'iniziativa Core Web Vitals ha lo scopo di creare e sensibilizzare l'opinione pubblica in merito alle metriche che riflettono l'esperienza utente effettiva. Ciò è in contrasto con le metriche, ad esempio il semplice tempo di caricamento della pagina, che non si traducono chiaramente in qualità dell'esperienza utente.

Quando applichi le ottimizzazioni descritte in questa guida alle risorse del tuo sito web, gli effetti sui Core Web Vitals possono variare in base alle risorse ottimizzate e alle metriche coinvolte. Tuttavia, ecco alcuni casi in cui l'applicazione di queste ottimizzazioni può migliorare i Core Web Vitals del tuo sito web:

• Le risorse HTML ridotte e compresse possono migliorare il caricamento dell'HTML, la rilevabilità delle relative risorse secondarie e, di conseguenza, il caricamento di queste ultime. Ciò può essere utile per la metrica Largest Contentful Paint (LCP) di una pagina. Sebbene i suggerimenti per le risorse come rel="preload" possano essere utilizzati per influire sulla rilevabilità delle risorse, l'utilizzo di un numero eccessivo di suggerimenti può causare problemi di contesa della larghezza di banda. Se la risposta HTML a una richiesta di navigazione è compressa, le risorse al suo interno possono essere rilevate il prima possibile dallo scanner di precaricamento.
• Alcuni candidati LCP possono anche essere caricati prima utilizzando la compressione. Ad esempio, le immagini SVG che sono candidate LCP possono ridurre la durata del caricamento delle risorse tramite la compressione basata su testo. Questo è diverso dalle ottimizzazioni che faresti ad altri tipi di immagini, che sono intrinsecamente compresse tramite altri metodi di compressione, ad esempio il modo in cui le immagini JPEG utilizzano la compressione con perdita di dati.
• Inoltre, i nodi di testo possono essere anche candidati LCP. L'applicazione delle tecniche descritte in questa guida dipende dall'utilizzo o meno di un web font per il testo delle tue pagine web. Se utilizzi un carattere web, si applicano le best practice per l'ottimizzazione dei caratteri web. Tuttavia, se non utilizzi i caratteri web, ma i caratteri di sistema che vengono visualizzati senza comportare alcuna durata di caricamento delle risorse, la minimizzazione e la compressione del CSS riducono questa durata, il che significa che il rendering dei potenziali nodi di testo LCP può avvenire prima.

Conclusione

Il modo in cui ottimizzi la codifica e il trasferimento degli asset basati su testo è un concetto di base delle prestazioni, ma ha un grande impatto. Assicurati di fare tutto il possibile per garantire che le risorse idonee alla minimizzazione e alla compressione beneficino di queste ottimizzazioni.

Ancora più importante, assicurati che questi processi vengano automatizzati. Per la minificazione, utilizza un bundler per applicarla alle risorse idonee. Assicurati che la configurazione del server web supporti la compressione, ma soprattutto utilizza la compressione più efficace disponibile. Per semplificare il più possibile questa operazione, utilizza le CDN per automatizzare la compressione, in quanto non solo possono comprimere le risorse, ma possono farlo anche molto rapidamente.

Se consolidi questi concetti di rendimento di base nell'architettura del tuo sito web, puoi assicurarti che i tuoi sforzi di ottimizzazione del rendimento siano ben avviati e che le ottimizzazioni successive possano basarsi su una solida base di buone pratiche di base.