1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
---
title: Compressione in HTTP
slug: Web/HTTP/Compressione
translation_of: Web/HTTP/Compression
---
<div>{{HTTPSidebar}}</div>
<p class="summary">La <strong>compressione</strong> è un valido modo per incrementare le performance di un sito web. Per alcuni documenti, infatti, la riduzione del peso fino al 70% permette di dimiuire la larghezza di banda necessaria. Nel corso degli anni, inoltre, gli algoritmi sono diventati più efficienti e allo stesso tempo client e server ne supportano di nuovi.</p>
<p>A livello pratico non è necessario che gli sviluppatori web implementino dei meccanismi di compressione, dato che sia browser che server li hanno già implementati, ma devono tuttavia assicurarsi che il server sia adeguatamente configurato. La compressione avviene a tre livelli differenti:</p>
<ul>
<li>prima alcuni formati di file vengono compressi con specifici metodi ottimizzati,</li>
<li>quindi la crittografia generale può avvenire a livello HTTP (la risorsa viene trasmessa compressa da un capo all'altro),</li>
<li>e infine la compressione può essere definita a livello di connessione, tra due nodi di una connessione HTTP.</li>
</ul>
<h2 id="Formato_di_compressione_dei_file">Formato di compressione dei file</h2>
<p>Ogni tipo di dati ha una certa ridondanza, ovvero uno spreco di spazio. Se il testo può in genere avere una ridondanza fino al 60%, questa percentuale può essere molto più alta per altri media come audio e video. A differenza del testo, questi altri tipi di supporti utilizzano molto spazio per archiviare i dati, di conseguenza la necessità di ottimizzare l'archiviazione e recuperare spazio si manifestò fin da subito. Gli ingegneri hanno progettato l'algoritmo di compressione ottimizzato utilizzato dai formati di file progettati per questo scopo specifico. Gli algoritmi di compressione utilizzati per i file possono essere raggruppati in due grandi categorie:</p>
<ul>
<li><em>Compressione loss-less (senza perdite), in cui il ciclo di compressione-decompressione non altera i dati recuperati, che corrisponderanno (byte per byte) all'originale.<br>
Ad esempio, nel caso delle immagini, gif e png utilizzano la compressione senza perdite.</em></li>
<li><em>Compressione lossy (con perdita), in cui il ciclo altera i dati originali in maniera (auspicabilmente) impercettibile per l'utente.<br>
I formati video sul Web sono con perdite; anche il formato di immagine jpeg è con perdita di dati.</em></li>
</ul>
<p>Alcuni formati possono essere utilizzati sia per la compressione <em>loss-less</em> che <em>lossy</em>, come ad esempio webp, e di solito l'algoritmo di compressione con perdita può essere configurato per comprimere più o meno, il che ovviamente porta a una qualità inferiore o superiore. Per migliorare le prestazioni di un sito Web l'ideale è comprimerlo il più possibile, mantenendo allo stesso tempo un livello di qualità accettabile. Per le immagini, un'immagine generata da uno strumento potrebbe non essere sufficientemente ottimizzata per il Web; si consiglia di utilizzare strumenti che comprimeranno il più possibile con la qualità richiesta. Esistono <a href="https://www.creativebloq.com/design/image-compression-tools-1132865">numerosi strumenti</a> specializzati per questo.</p>
<p>Gli algoritmi di compressione lossy sono generalmente più efficienti di quelli lossless.</p>
<div class="note">
<p>Poiché la compressione funziona meglio su un tipo specifico di file, di solito non fornisce nulla per comprimerli una seconda volta. In effetti, questo è spesso controproducente in quanto il costo del sovraccarico (gli algoritmi di solito richiedono un dizionario che si aggiunge alla dimensione iniziale) può essere superiore al guadagno extra nella compressione risultando in un file più grande. Non utilizzare le due seguenti tecniche per i file in un formato compresso.</p>
</div>
<h2 id="Compression_End-to-end">Compression End-to-end</h2>
<p>Per la compressione, la compressione end-to-end è il luogo in cui risiedono i maggiori miglioramenti delle prestazioni dei siti Web. La compressione end-to-end si riferisce a una compressione del corpo di un messaggio che viene eseguita dal server e durerà inalterata fino a quando non raggiunge il client. Qualunque siano i nodi intermedi, lasciano il corpo intatto.</p>
<p><img alt="" src="https://mdn.mozillademos.org/files/13801/HTTPEnco1.png" style="height: 307px; width: 955px;"></p>
<p>Tutti i browser e server moderni lo supportano e l'unica cosa da negoziare è l'algoritmo di compressione da utilizzare. Questi algoritmi sono ottimizzati per il testo. Negli anni '90, la tecnologia di compressione stava avanzando a un ritmo rapido e numerosi algoritmi successivi sono stati aggiunti alla serie di scelte possibili. Al giorno d'oggi, solo due sono rilevanti: gzip, il più comune, e br il nuovo sfidante.</p>
<p>Per selezionare l'algoritmo da utilizzare, i browser e i server utilizzano la negoziazione proattiva dei contenuti. Il browser invia un'intestazione {{HTTPHeader ("Accept-Encoding")}} con l'algoritmo che supporta e il suo ordine di precedenza, il server ne sceglie uno, lo utilizza per comprimere il corpo della risposta e utilizza {{HTTPHeader (" Content-Encoding ")}} per indicare al browser l'algoritmo che ha scelto. Poiché la negoziazione del contenuto è stata utilizzata per scegliere una rappresentazione basata sulla sua codifica, il server deve inviare un'intestazione {{HTTPHeader ("Vary")}} contenente almeno {{HTTPHeader ("Accept-Encoding")}} accanto a questa intestazione in la risposta; in questo modo, le cache saranno in grado di memorizzare nella cache le diverse rappresentazioni della risorsa.</p>
<p><img alt="" src="https://mdn.mozillademos.org/files/13811/HTTPCompression1.png" style="height: 307px; width: 771px;"></p>
<p>Poiché la compressione apporta miglioramenti significativi alle prestazioni, si consiglia di attivarla per tutti i file, ma già compressi come immagini, file audio e video.</p>
<p>Apache supporta la compressione e utilizza mod_deflate; per nginx c'è ngx_http_gzip_module; per IIS, l'elemento <httpCompression>.</p>
<h2 id="Hop-by-hop_compression">Hop-by-hop compression</h2>
<p>La compressione hop-by-hop, sebbene simile alla compressione end-to-end, differisce per un elemento fondamentale: la compressione non avviene sulla risorsa nel server, creando una rappresentazione specifica che viene poi trasmessa, ma sul corpo di il messaggio tra due nodi qualsiasi sul percorso tra il client e il server. Le connessioni tra i nodi intermedi successivi possono applicare una compressione diversa.</p>
<p><img alt="" src="https://mdn.mozillademos.org/files/13807/HTTPTE1.png"></p>
<p>Per fare ciò, HTTP utilizza un meccanismo simile alla negoziazione del contenuto per la compressione end-to-end: il nodo che trasmette la richiesta annuncia la sua volontà utilizzando l'intestazione {{HTTPHeader ("TE")}} e l'altro nodo sceglie il metodo adeguato , lo applica e indica la sua scelta con l'intestazione {{HTTPHeader ("Transfer-Encoding")}}.</p>
<p><img alt="" src="https://mdn.mozillademos.org/files/13809/HTTPComp2.png"></p>
<p>I</p>
<p>In pratica, la compressione hop-by-hop è trasparente per il server e il client ed è usata raramente. {{HTTPHeader ("TE")}} e {{HTTPHeader ("Transfer-Encoding")}} sono usati principalmente per inviare una risposta a blocchi, consentendo di iniziare a trasmettere una risorsa senza conoscerne la lunghezza.</p>
<p>Si noti che l'utilizzo di {{HTTPHeader ("Transfer-Encoding")}} e la compressione a livello di hop è così raro che la maggior parte dei server, come Apache, nginx o IIS, non ha un modo semplice per configurarlo. Tale configurazione di solito avviene a livello di proxy.</p>
|
