Otimizando o cache de arquivos e o HTTP2

Nosso site está pensando em fazer a mudança para http2.

Meu entendimento é que http2 processa técnicas de otimização como concatenação de arquivos obsoletas , já que um servidor usando http2 apenas envia uma solicitação.

Em vez disso, o conselho que estou vendo é que é melhor manter os tamanhos dos arquivos menores, para que eles fiquem mais propensos a serem armazenados em cache por um navegador.

Isso provavelmente depende do tamanho de um site, mas quão pequenos os arquivos de um site devem ser se ele usar http2 e quiser se concentrar no cache?

No nosso caso, nossos muitos arquivos js e css individuais estão no intervalo de 1kb a 180kb. Jquery e bootstrap podem ser mais. Cumulativamente, um novo download de uma página em nosso site é geralmente inferior a 900 kb.

Então eu tenho duas perguntas:

Esses tamanhos de arquivo são pequenos o suficiente para serem armazenados em cache pelos navegadores?

Se eles são pequenos o suficiente para serem armazenados em cache, é bom concatenar arquivos de qualquer maneira para usuários que usam navegadores que não suportam http2.

Dificaria ter tamanhos maiores de arquivos neste caso E usar HTTP2? Dessa forma, isso beneficiaria os usuários que executam o protocolo porque um site pode ser otimizado para http e http2.

Vamos esclarecer algumas coisas:

Meu entendimento é que http2 processa técnicas de otimização como concatenação de arquivos obsoletas, já que um servidor usando http2 apenas envia uma solicitação.

O HTTP / 2 renderiza técnicas de otimização, como a concatenação de arquivos, um pouco obsoleta, pois o HTTP / 2 permite que muitos arquivos sejam baixados em paralelo na mesma conexão. Anteriormente, no HTTP / 1.1, o navegador poderia solicitar um arquivo e, em seguida, tinha que esperar até que o arquivo fosse baixado completamente antes de poder solicitar o próximo arquivo. Isso leva a soluções alternativas como concatenação de arquivos (para reduzir o número de arquivos necessários) e várias conexões (um hack para permitir downloads em paralelo).

No entanto, há um contra-argumento de que ainda existem overheads com vários arquivos, inclusive solicitando-os, armazenando-os em cache, lendo-os do cache … etc. Ele é muito reduzido em HTTP / 2, mas não foi completamente eliminado. Além disso, gzipar arquivos de texto funciona melhor em arquivos maiores do que compactar vários arquivos menores separadamente. Pessoalmente, no entanto, acho que as desvantagens superam essas preocupações, e acho que a concatenação vai se extinguir uma vez que o HTTP / 2 é onipresente.

Em vez disso, o conselho que estou vendo é que é melhor manter os tamanhos dos arquivos menores, para que eles fiquem mais propensos a serem armazenados em cache por um navegador.

Isso provavelmente depende do tamanho de um site, mas quão pequenos os arquivos de um site devem ser se ele usar http2 e quiser se concentrar no cache?

O tamanho do arquivo não tem relação se ele seria armazenado em cache ou não (a menos que estejamos falando de arquivos realmente grandes e maiores que o próprio cache). A razão pela qual a divisão de arquivos em partes menores é melhor para o armazenamento em cache é, portanto, se você fizer alguma alteração, qualquer arquivo que não tenha sido tocado ainda poderá ser usado a partir do cache. Se você tiver todo o seu javascript (por exemplo) em um grande arquivo .js e alterar uma linha de código, o arquivo inteiro precisará ser baixado novamente, mesmo que já esteja no cache.

Da mesma forma, se você tiver um mapa de sprites de imagem, isso é ótimo para reduzir downloads de imagens em separado em HTTP / 1.1, mas requer que o arquivo sprite inteiro seja baixado novamente se você precisar editá-lo para adicionar uma imagem extra, por exemplo. Sem mencionar que a coisa toda é baixada – mesmo para páginas que usam apenas um desses sprites de imagem.

No entanto, dizendo tudo isso, há uma linha de pensamento que diz que o benefício do armazenamento em cache de longo prazo está acima do estabelecido. Veja este artigo e, em particular, a seção sobre HTTP em cache, que mostra que o cache de navegadores da maioria das pessoas é menor do que você pensa e, portanto, é improvável que seus resources sejam armazenados em cache por muito tempo. Isso não quer dizer que o armazenamento em cache não é importante – mas é mais útil para navegar na session do que em longo prazo. Assim, cada visita ao seu site provavelmente fará o download de todos os seus arquivos novamente, a menos que seja um visitante muito frequente, tenha um cache muito grande ou não navegue muito na Web.

é bom concatenar arquivos de qualquer maneira para usuários que usam navegadores que não suportam http2.

Possivelmente. No entanto, além do Android, o suporte ao navegador HTTP / 2 é realmente muito bom, por isso é provável que a maioria dos visitantes já esteja habilitada para HTTP / 2.

Dizendo isso, não há desvantagens extras para concatenar arquivos em HTTP / 2 que não estavam lá em HTTP / 1.1. Ok, pode-se argumentar que vários arquivos pequenos podem ser baixados em paralelo sobre HTTP / 2, enquanto um arquivo maior precisa ser baixado como um pedido, mas eu não acredito que isso reduza muito a velocidade. Nenhuma prova disso, mas o instinto sugere que os dados ainda precisam ser enviados, então você tem um problema de largura de banda de qualquer maneira, ou não. Além disso, a sobrecarga de solicitar muitos resources, embora muito reduzida em HTTP / 2 ainda esteja lá. A latência ainda é o maior problema para a maioria dos usuários e sites – não para a largura de banda. A menos que seus resources sejam realmente enormes, duvido que você notasse a diferença entre baixar um grande recurso ou os mesmos dados divididos em 10 pequenos arquivos baixados em paralelo no HTTP / 2 (embora você usasse HTTP / 1.1) . Sem mencionar os problemas de gzipping discutidos acima.

Então, na minha opinião, não há mal algum em continuar concatenando por mais algum tempo. Em algum momento, você precisará responder se as desvantagens superam os benefícios dados ao seu perfil de usuário.

Dificaria ter tamanhos maiores de arquivos neste caso E usar HTTP2? Dessa forma, isso beneficiaria os usuários que executam o protocolo porque um site pode ser otimizado para http e http2.

Absolutamente não faria mal a todos. Como mencionado acima, há (basicamente) nenhuma desvantagem extra para concatenar arquivos em HTTP / 2 que não estavam lá em HTTP / 1.1. Simplesmente não é mais necessário sob o HTTP / 2 e tem desvantagens (potencialmente reduz o uso do cache, requer uma etapa de compilation, torna a debugging mais difícil, pois o código implementado não é o mesmo do código-fonte … etc.).

Use HTTP / 2 e você ainda verá grandes benefícios para qualquer site – exceto os sites mais simples, que provavelmente não verão nenhuma melhoria, mas também nenhum efeito negativo. E, como navegadores mais antigos podem ficar com HTTP / 1.1, não há desvantagens para eles. Quando, ou se, você decidir parar de implementar os ajustes de desempenho do HTTP / 1.1, como concatenar, é uma decisão separada.

Na verdade, a única razão para não usar o HTTP / 2 é que as implementações ainda são bastante avançadas, então você pode não se sentir confortável em executar o site de produção ainda.

**** Editar agosto de 2016 ****

Esta postagem de uma imagem pesada, com limite de largura de banda, recentemente causou algum interesse na comunidade HTTP / 2 como um dos primeiros exemplos documentados de onde o HTTP / 2 era realmente mais lento que o HTTP / 1.1. Isso destaca o fato de que a tecnologia HTTP / 2 e o entendimento ainda são novos e exigirão alguns ajustes para alguns sites. Não há tal coisa como um almoço grátis parece! Vale a pena ler, embora tenha em mente que esse é um exemplo extremo e a maioria dos sites é muito mais afetada, em termos de desempenho, por problemas de latência e limitações de conexão em HTTP / 1.1, em vez de problemas de largura de banda.

    Intereting Posts