Ottimizzazione di Cache di file e HTTP2

Il nostro sito sta valutando la possibilità di passare a http2.

La mia comprensione è che http2 rende obsolete le tecniche di ottimizzazione come la concatenazione di file , dal momento che un server che utilizza http2 invia solo una richiesta.

Invece, il consiglio che sto vedendo è che è meglio mantenere le dimensioni dei file più piccole in modo che siano più probabilità di essere memorizzate nella cache da un browser.

Probabilmente dipende dalle dimensioni di un sito Web, ma quanto dovrebbero essere piccoli i file di un sito Web se utilizza http2 e vuole concentrarsi sulla memorizzazione nella cache?

Nel nostro caso, i nostri numerosi file js e css rientrano nell’intervallo da 1kb a 180kb. Jquery e bootstrap potrebbero essere di più. Cumulativamente, un nuovo download di una pagina sul nostro sito è in genere inferiore a 900 kb.

Quindi ho due domande:

Queste dimensioni dei file sono abbastanza piccole da essere memorizzate nella cache dai browser?

Se sono abbastanza piccoli da essere memorizzati nella cache, è bene concatenare file comunque per gli utenti che utilizzano browser che non supportano http2.

Farebbe male avere dimensioni di file più grandi in questo caso E usare HTTP2? In questo modo, sarebbe vantaggioso per gli utenti che eseguono entrambi i protocolli perché un sito potrebbe essere ottimizzato sia per http che per http2.

Cerchiamo di chiarire alcune cose:

La mia comprensione è che http2 rende obsolete le tecniche di ottimizzazione come la concatenazione di file, dal momento che un server che utilizza http2 invia solo una richiesta.

HTTP / 2 rende le tecniche di ottimizzazione come la concatenazione di file in qualche modo obsolete poiché HTTP / 2 consente a molti file di scaricarsi in parallelo attraverso la stessa connessione. Precedentemente, in HTTP / 1.1, il browser poteva richiedere un file e quindi doveva attendere il completamento del download del file prima che potesse richiedere il file successivo. Ciò ha portato a soluzioni alternative come la concatenazione di file (per ridurre il numero di file richiesti) e più connessioni (un trucco per consentire download in parallelo).

Tuttavia c’è una contro-argomentazione che ci sono ancora sovraccarichi con più file, inclusa la richiesta, il loro salvataggio nella cache, la lettura dalla cache … ecc. È molto ridotto in HTTP / 2 ma non è andato completamente. Inoltre, i file di testo di gzipping funzionano meglio su file più grandi, piuttosto che su un sacco di file più piccoli separatamente. Personalmente, comunque penso che gli svantaggi superino queste preoccupazioni e penso che la concatenazione si estinguerà una volta che HTTP / 2 è onnipresente.

Invece, il consiglio che sto vedendo è che è meglio mantenere le dimensioni dei file più piccole in modo che siano più probabilità di essere memorizzate nella cache da un browser.

Probabilmente dipende dalle dimensioni di un sito Web, ma quanto dovrebbero essere piccoli i file di un sito Web se utilizza http2 e vuole concentrarsi sulla memorizzazione nella cache?

Le dimensioni del file non influiscono sulla memorizzazione o meno della cache (a meno che non stiamo parlando di file veramente voluminosi più grandi della cache stessa). Il motivo per cui suddividere i file in blocchi più piccoli è preferibile per il caching in modo tale che se si apportano modifiche, qualsiasi file che non è stato ancora toccato può ancora essere utilizzato dalla cache. Se hai tutto il tuo javascript (per esempio) in un grande file .js e cambi una riga di codice, allora tutto il file deve essere scaricato di nuovo, anche se era già nella cache.

Allo stesso modo, se si dispone di una mappa immagine sprite, è ottimo per ridurre i download di immagini separate in HTTP / 1.1, ma è necessario scaricare nuovamente l’intero file sprite se è necessario modificarlo per aggiungere un’immagine aggiuntiva, ad esempio. Senza contare che tutto viene scaricato – anche per le pagine che usano solo uno di quegli sprite di immagini.

Tuttavia, dicendo tutto ciò, c’è un filo di pensiero che dice che il vantaggio del caching a lungo termine è troppo alto. Vedi questo articolo e in particolare la sezione sulla memorizzazione nella cache HTTP che mostra che la cache del browser della maggior parte delle persone è più piccola di quanto si pensi e quindi è improbabile che le risorse vengano memorizzate nella cache per molto tempo. Questo non vuol dire che il caching non è importante, ma più che è utile per navigare in quella sessione piuttosto che a lungo termine. Pertanto, ogni visita al tuo sito scaricherà probabilmente tutti i tuoi file di nuovo, a meno che non siano un visitatore molto frequente, abbiano una cache molto big o non navigino molto sul Web.

è bene concatenare file comunque per gli utenti che utilizzano browser che non supportano http2.

Possibilmente. Tuttavia, oltre che su Android, il supporto del browser HTTP / 2 è in realtà molto buono, quindi è probabile che la maggior parte dei tuoi visitatori sia già abilitata per HTTP / 2.

Dicendo questo, non ci sono altri aspetti negativi nel concatenare file sotto HTTP / 2 che non erano già in HTTP / 1.1. Ok, si potrebbe sostenere che un numero di piccoli file può essere scaricato in parallelo su HTTP / 2, mentre un file più grande deve essere scaricato come una richiesta, ma non comprarlo che ne rallenta molto. Nessuna prova di questo, ma l’intuito suggerisce che i dati devono ancora essere inviati, quindi hai un problema di larghezza di banda in entrambi i casi, o non lo fai. Inoltre il sovraccarico di richiedere molte risorse, anche se molto ridotto in HTTP / 2 è ancora lì. La latenza è ancora il problema più grande per la maggior parte degli utenti e dei siti, non per la larghezza di banda. A meno che le tue risorse siano davvero enormi, dubito che potresti notare la differenza tra il download di 1 grande risorsa in I’ve go, o la stessa suddivisione dei dati in 10 piccoli file scaricati in parallelo in HTTP / 2 (anche se lo faresti in HTTP / 1.1) . Per non parlare dei problemi di gzipping discussi sopra.

Quindi, secondo me, non c’è nulla di male da mantenere in concatenazione ancora per un po ‘. A un certo punto dovrai chiamare se i lati negativi superano i benefici dati dal tuo profilo utente.

Farebbe male avere dimensioni di file più grandi in questo caso E usare HTTP2? In questo modo, sarebbe vantaggioso per gli utenti che eseguono entrambi i protocolli perché un sito potrebbe essere ottimizzato sia per http che per http2.

Assolutamente non farebbe del male a tutti. Come accennato sopra, non ci sono (fondamentalmente) aspetti negativi in ​​più per concatenare file sotto HTTP / 2 che non erano già in HTTP / 1.1. Non è più necessario in HTTP / 2 e ha aspetti negativi (potenzialmente riduce l’uso del caching, richiede un passo di costruzione, rende il debug più difficile in quanto il codice distribuito non è uguale al codice sorgente … ecc.).

Usa HTTP / 2 e vedrai comunque grandi benefici per qualsiasi sito, ad eccezione dei siti più semplici che probabilmente non vedranno miglioramenti, ma non negativi. E, poiché i browser più vecchi possono rimanere con HTTP / 1.1, non ci sono aspetti negativi per loro. Quando, o se, decidi di interrompere l’implementazione delle correzioni delle prestazioni HTTP / 1.1 come la concatenazione è una decisione separata.

In realtà, il solo motivo per cui non si utilizza HTTP / 2 è che le implementazioni sono ancora abbastanza all’avanguardia, quindi potresti non essere a tuo agio nel gestire il tuo sito Web di produzione.

**** Modifica agosto 2016 ****

Questo post da un’immagine pesante, con larghezza di banda limitata, ha recentemente destato interesse nella comunità HTTP / 2 come uno dei primi esempi documentati di dove HTTP / 2 era effettivamente più lento di HTTP / 1.1. Ciò evidenzia il fatto che la tecnologia e la comprensione di HTTP / 2 sono ancora nuove e richiedono alcuni aggiustamenti per alcuni siti. Non esiste un pranzo gratis a quanto pare! Vale la pena una lettura, anche se vale la pena tenere a mente che questo è un esempio estremo e la maggior parte dei siti sono di gran lunga più colpiti, dalle prestazioni, dai problemi di latenza e dai limiti di connessione sotto HTTP / 1.1 piuttosto che dai problemi di larghezza di banda.