No Singular, somos grandes incentivadores do uso cada vez maior de HTTP/2: Para a internet tão diversa como na América Latina, as vantagens desse novo protocolo são imensas em termos de velocidade maior e reaproveitamento de recursos computacionais.

Logo que foi lançado, algumas vantagens já foram explicitadas como obviamente superiores ao antigo (e ainda muito usado) HTTP/1.1 e a adoção já é praticamente universal:

Multiplexação em HTTP/2

  1. Utilização de somente 1 conexão TCP para várias requisições (multiplexação)
  2. Browser poder dar prioridade a um conteúdo em detrimento do outro para agilizar a renderização;
  3. Possibilidade do servidor enviar que recursos que já sabe que o cliente vai precisar sem ele mesmo pedir;

O item (3) é também conhecido como HTTP/2 Push. A ideia é razoavelmente simples:

- Cliente pediu index.html;
- Obviamente, ele vai precisar do CSS (folha de estilo) e dessa fonte, né? Manda tudo junto!

Como pode ser visto página inicial do Singular, o browser vai mostrar assim:

Quando o browser for processar o index.html e se dar conta que precisa do tal CSS, ele ve que já está ali, junto com as fontes.

Para fazer isso funcionar, bastou que fosse colocado no cabeçalho Link do backend do cliente para o Singular, no exemplo acima seria:

link: </assets/css/arquivo.css> rel=preload; as=style

Como já vimos antes, isso pode significar ganhos significativos para determinado grupos de clientes.

Legal, né? Inteligência maior! Mas nem sempre é assim

HTTP/2 Push padrão: Abordagem ingênua

Muita gente relatou ótimos ganhos com HTTP/2 inicialmente, porém depois relatou o seguinte problema: E quando o cliente faz um refresh da página? Ele já tinha o CSS e as fontes, e agora vai vir tudo de novo.

Aí que o HTTP/2 Push fica burro: Ele vai enviar o conteúdo independente se o cliente pediu ou não, e sem saber se ele já enviou antes ou não.

Dica: Num mundo perfeito, tente fazer com que o conteúdo TOTAL que está sendo feito PUSH tenha sempre bem menos que 1448 bytes, para poder caber em 1 único pacote de rede. Como ainda tem os cabeçalhos HTTP/2 e camada TLS por cima, o ideal seria 1000 bytes. Parece pouco, mas é o absoluto melhor cenário.

Caching Digests

Foi aí que surgiu a ideia caching digests: O servidor guarda a informação de quando o PUSH já foi feito e evita fazer novamente quando sabe o cliente no fundo não precisa.

Isso não é uma violação do cabeçalho Link, mas uma otimização extra para evitar mandar conteúdo inútil.

Não vou entrar aqui como funciona exatamente a implementação, mas é basicamente por gerência de um Cookie exclusivo para isso, onde é enviado a assinatura de conteúdo que foi feito feito Push antes. Se aparecer de novo, indica que não precisa ser refeito.

Isso inclui também PUSHs parciais, onde um arquivo não precisa ser reenviado, mas o outro precisa.

No Singular, essa funcionalidade pode ser habilitada via API ou pedindo diretamente para o nosso suporte técnico! Vale a pena.

Na nossa rede anycast, esse tipo de solução sempre funciona pois o cliente vai sempre utilizar o nodo melhor para ele em termos de latência e saltos de rede, garantindo que o Digest possa ser revalidado pelo nodo. O CDN tem que ter inteligência sempre na ponta.

Com isso, finalmente o ganho com HTTP/2 Push aparece para todos os casos, tanto onde o browser é novo e não tem conteúdo, quando ele tem conteúdo.