Resumo

  • O RFC 7540 permitiu que servidores HTTP/2 anunciassem e enviassem recursos antes do pedido seguinte do cliente. O navegador podia bloquear ou recusar o envio.
  • O RFC 9113 manteve Server Push em 2022 e descreveu os prejuízos de uma previsão errada. A nota do Chrome 106 anunciou a remoção da capacidade de receber, guardar e usar os fluxos antecipados.

A encomenda sai antes do pedido

O servidor entrega uma página HTML que aponta para um arquivo de estilos. Ele conhece o endereço do arquivo antes que o navegador leia a página. Se o mandar imediatamente, o navegador talvez economize uma nova ida e volta pela rede. O HTTP/2 de 2015 organizou essa aposta com um quadro PUSH_PROMISE: o servidor prometia uma requisição que imaginava em nome do cliente e depois enviava a resposta por outro fluxo.

A aposta vinha cercada por regras. O envio precisava estar associado a um pedido real do cliente, tratar de conteúdo seguro e armazenável em cache e respeitar a autoridade da origem. O navegador podia definir SETTINGS_ENABLE_PUSH=0 ou cancelar um fluxo indesejado. O protocolo dava ao servidor a iniciativa de oferecer; não lhe dava conhecimento da necessidade real do destinatário.

É aí que a promessa de velocidade encontrava o limite. O servidor via a página, mas não sabia com certeza o que o navegador já tinha em cache nem qual variante do recurso seria usada. Também não sabia se o usuário continuaria ali. Um arquivo inútil ocupa capacidade ao lado de respostas efetivamente solicitadas. O atalho pode atrasar justamente o pacote que deveria passar primeiro.

O próprio padrão descreve a falha

O RFC 9113, publicado em junho de 2022, ainda reservava uma seção para Server Push. Ela mantinha a hipótese de economizar uma viagem para scripts e estilos previsíveis. Mas dizia que a eficácia exigia adivinhar cache, negociação de conteúdo e comportamento do usuário. Quando o palpite falhava, dados extras podiam disputar espaço com respostas mais importantes e reduzir o desempenho. O ajuste para o cliente desativar o envio continuava lá.

Dois meses depois, o Chrome anunciou que desligaria a função por padrão na versão 106. Sua explicação apontava benefícios difíceis de realizar e resultados mistos, inclusive perdas. A lista de mudanças do Chrome 106 afirmou que o navegador havia retirado a capacidade de receber, manter na memória e usar os fluxos de Server Push. O RFC seguia descrevendo uma troca possível; o software usado para navegar tinha outra decisão operacional.

O detalhe é histórico porque padrão e produto costumam aparecer juntos em narrativas de tecnologia. Aqui a revisão de HTTP/2 não revogou a função. Ela a descreveu com seus riscos. A retirada ocorreu na ponta que precisava armazenar, coordenar e aproveitar os arquivos enviados sem pedido.

Avisar em vez de entregar

O texto de remoção do Chrome citou 103 Early Hints e pré-carregamento como alternativas. Early Hints envia uma indicação; o navegador decide se pede o recurso, inclusive verificando seu cache. A diferença revela o custo específico da antiga escolha: em Server Push, a resposta vinha inteira porque o servidor acreditava saber o próximo passo.

Em 2015, essa crença ganhou um mecanismo no protocolo. Em 2022, o RFC ainda a aceitava, enquanto Chrome fechava a recepção. O padrão preservou a possibilidade; a experiência de um navegador deixou de pagá-la.