2015-10-16 9 views
12

HTTP/2 rende possibile il multiplex delle connessioni, eliminando la necessità di più di una connessione a un server. Su una singola connessione, molte immagini individuali possono essere inviate al cliente. Ciò ovvia al vecchio modello di immagine sprite di combinare molte immagini in una sola e usando CSS per separarlo.In quali circostanze il caricamento delle immagini singolarmente con HTTP/2 è più lento del caricamento di tutte le immagini contemporaneamente con uno sprite a HTTP/1.1?

Sono curioso di sapere se gli sprite sarebbero ancora più veloci in un mondo HTTP/2. Se sì, in quali circostanze?

risposta

9

Gli sprite, come saprete, vengono utilizzati per evitare l'accodamento di più richieste, quindi con un carico utile è possibile ottenere tutti gli sprite per il sito.

Ma con gli sprite si tende a ottenere molte icone aggiuntive che vengono utilizzate in tutto il sito Web che non sono tutte necessarie su una singola pagina.

Quindi con multiplexing http/2, le risorse di accodamento non sono più un problema. Ottieni il vantaggio in termini di velocità quando scarichi solo i file necessari per ogni pagina.

Tuttavia, è possibile ottenere una compressione migliore combinando alcune immagini in un singolo file, riducendo le dimensioni complessive dei trasferimenti di file.

I test di velocità eseguiti da Benoît Béraud e Alexandre Masselot hanno fornito un esempio di caricamento di un foglio di sprite più veloce rispetto ai singoli sprite. Essi hanno concluso che i set di sprite possono ancora essere utilizzati per ottimizzare le prestazioni del sito quando si utilizza http/2 http://blog.octo.com/en/http2-arrives-but-sprite-sets-aint-no-dead/

scrittura esteso su circa http/2 da Rachel Andrew può essere trovato qui: https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/

+1

Questa non è una cattiva ipotesi, ma è difficile immaginare una compressione che faccia sì che una grande differenza superi il beneficio del caricamento delle immagini singolarmente su H2. Se lo fa, sospetto che sarà in circostanze molto artificiose. Sarebbe un buon argomento di ricerca. –

+0

Per i test della velocità dello sprite potresti essere interessato a leggere: http://blog.octo.com/en/http2-arrives-but-sprite-sets-aint-no-dead/ – Sarcoma

0

con HTTP/2 multiplexing, il server leggerà un sacco di piccoli file invece di leggere un singolo file di grandi dimensioni. Se il server è limitato da risorse (ad esempio un aggeggio di Internet delle cose, per esempio), allora potresti essere in grado di trovare una situazione in cui è meglio fare in modo che la singola, grande lettura invece di molte piccole, poiché ogni lettura fa sì che il sistema operativo del server esegua potenzialmente molte operazioni relative all'accesso ai file.

Sul lato client, il browser gestirà un sacco di piccoli file, invece di uno grande. Posso immaginare che il percorso del codice utilizzato per il flusso di lavoro corrente dello sprite sia ben massaggiato e ottimizzato, poiché è così comunemente usato. Quindi potrebbe accadere che il nuovo caso di avere un sacco di piccoli file potrebbe essere più lento, almeno per un periodo.

Problemi correlati