Firefox pretende encerrar o suporte a HTTP/2 Push

 (groups.google.com)
1 pontos por GN⁺ 2024-09-08 | 1 comentários | Compartilhar no WhatsApp
  • O Firefox pretende desativar o HTTP/2 Push em todas as plataformas nos próximos dias, devido ao baixo uso e ao aumento da carga de compatibilidade, e manterá o código de implementação na árvore por enquanto
  • No ecossistema de navegadores, o suporte já diminuiu: o Chrome 106 desativou isso em setembro de 2022, e a versão mais recente do Safari também rejeita push streams em testes locais
  • O Chrome citou o baixo uso do HTTP/2 Push e recomendou rel="preload" e 103 Early Hints como alternativas
  • O Firefox manteve o suporte porque o custo de manutenção não era alto, mas nos últimos meses surgiram bugs de compatibilidade web que acontecem só no Firefox por causa do HTTP/2 Push
  • Quando servidores e sites usam push e deixam de testar no Firefox, determinados sites podem não funcionar apenas no Firefox

Plano do Firefox para desativar o HTTP/2 Push

  • O Firefox pretende desativar o HTTP/2 Push em todas as plataformas
  • O trabalho de remoção está sendo acompanhado no Bugzilla em 1915848 - Pref off HTTP/2 push
  • Por enquanto, ele será desativado via preference, e o código de implementação permanecerá na árvore por algum tempo
  • A remoção completa provavelmente ocorrerá antes do branch ESR 140 na primavera do próximo ano

Estado do suporte por navegador e motivos para a desativação

  • Chrome

    • O Chrome 106 desativou o HTTP/2 Push em setembro de 2022
    • O status relacionado pode ser consultado em Chrome Platform Status
    • O Chrome citou o baixo uso como motivo e recomendou rel="preload" e 103 Early Hints como alternativas

  • Safari

    • Não foi possível confirmar material oficial de depreciação, mas a versão atual rejeita push streams em testes locais com servidor Node.js

  • Firefox

    • Até agora, o Firefox vinha mantendo o suporte ao HTTP/2 Push porque a carga de manutenção não era grande
    • Nos últimos meses, surgiram problemas de compatibilidade web causados pelo HTTP/2 Push que afetam apenas o Firefox
      • Um caso relacionado é o bug 1915830
      • Quando servidores e sites usam push sem testar no Firefox, o site pode travar apenas no Firefox; um exemplo é o bug 1913100

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-08
Opiniões no Hacker News

  • É irritante que, mesmo depois da “descoberta repentina” de que o HTTP/2 Push acabou não dando certo, não haja nenhum pedido de desculpas às pessoas que vinham explicando há tempos por que ele não funcionaria e foram ignoradas.
    Durante anos houve um clima de “as pessoas mais inteligentes do Google dizem que isso é necessário, então vamos enfiar na especificação”, mas especificações deveriam ser tratadas de forma muito mais conservadora. É preciso parar de continuar incluindo metas especulativas de extensão que uma parte do Google acha boas

    • Melhorar o HTTP e a performance da web parece não significar muita coisa. Já temos largura de banda suficiente para streaming de vídeo em 1080p, latência baixa o bastante para jogar em tempo real, e CPUs 1000 vezes mais poderosas do que quando entrei online pela primeira vez.
      O que deixa os navegadores lentos é, em grande parte, só a publicidade, os rastreadores e a tralha que sobrecarregam os sites; e o que usamos para corrigir isso não é uma invenção do Google, é o uBlock Origin. Hoje em dia, as coisas que o Google empurra para os padrões da web parecem não ser para desenvolvedores comuns, mas para colocar mais anúncios ou economizar 0,1% nos custos de datacenter
    • Há muito tempo, quando eu dizia no HN que, para uso não gráfico da web — por exemplo, busca rápida e não interativa de informações —, o pipelining do HTTP/1.1 era mais satisfatório que o HTTP/2, recebia downvotes e respostas sarcásticas.
      O HTTP/2 parece um exemplo de uma empresa tentando continuar controlando, em benefício próprio, o acesso à www, que é um recurso público. Se você usa o Chrome, ele tenta usar HTTP/2; a mesma empresa controla o mecanismo de busca, o hardware, o navegador e agora até o protocolo de rede. Na prática, dá para ver o HTTP/2 como HTTP/Chrome
    • Entenda que aquelas pessoas realmente precisavam de material para a promoção anual
    • Acertar cedo demais é o mesmo que estar errado

  • Nunca achei convincentes as explicações apresentadas para o fracasso do HTTP/2 Push. O Google normalmente aponta para o texto do Jake Archibald, mas esse texto parece mais uma lista de quão precárias eram as implementações nos navegadores do que um motivo para o protocolo em si não funcionar.
    Os navegadores já dão suporte a links de preload, que deveriam cumprir praticamente o mesmo papel que o cabeçalho Push. Dificuldades de implementação de 2017, como cache ou cabeçalhos de autenticação, também levantam a dúvida de por que não foi possível reutilizar o código existente de tratamento de preload.
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • O cabeçalho Preload não pode ser considerado “praticamente igual” ao HTTP/2 Push. Os resultados podem ser parecidos, mas o modo de funcionamento é diferente; fora o detalhe bem superficial de usar a palavra “Preload”, eles são bem distintos.
      O HTTP/2 Push é um mecanismo em que o servidor envia preventivamente recursos que julga necessários ao cliente, reduzindo uma ida e volta; o objetivo é diminuir a latência enviando recursos independentemente do pipeline DOM→renderização. O cabeçalho Preload é uma forma de o servidor informar, junto com o corpo, quais recursos devem ser carregados em paralelo, para que sejam buscados antes do parsing ou da avaliação de JS. O 103 Early Hints envia dicas de Preload antes de a geração da resposta terminar, antes do primeiro byte do corpo, antecipando ainda mais a etapa de busca.
      A diferença central está em ser conduzido pelo servidor ou pelo cliente, e em vir junto com o corpo ou antes do primeiro byte. O motivo mais simples pelo qual o HTTP/2 Push é fraco para atingir seu objetivo é o cache. O navegador não solicita recursos que já possui, mas o servidor não sabe o que há no cache do cliente. Com Push, há um grande risco de enviar recursos desnecessários; com 103/Preload, se estiver errado, desperdiçam-se apenas alguns bytes de cabeçalhos inúteis, então a implementação é mais fácil e o custo é menor
    • Minha compreensão da especificação de Push estava tão enferrujada quanto a própria especificação. Eu tinha esquecido que o servidor de fato empurra para o cliente o conteúdo completo que prevê ser necessário, e tinha imaginado, por engano, que apenas cabeçalhos insinuando dependências, como links de preload, seriam incluídos na requisição
    • Por motivos de segurança, os recursos enviados por Push precisam ser tratados como casos especiais até que a página os busque, e uma dessas exigências é um cache separado
    • A desculpa para remover o Push é particularmente ridícula porque os desenvolvedores quase nunca tiveram uma oportunidade real de usá-lo direito. Não dava para ver o Push chegando nem reagir a ele.
      https://github.com/whatwg/fetch/issues/51
      Parece que ainda havia muitas oportunidades até no caso de uso de entrega de conteúdo em que todos estavam focados. Também não houve muitas tentativas visíveis publicamente, e quase ninguém teve acesso a bibliotecas ou pontos de partida para experimentar o que deveria ser enviado por Push

  • Com o início 0-RTT do HTTP/3, é possível recuperar parte da velocidade, e com 103 Early Hints o navegador pode pré-carregar assets mais cedo. Essa combinação também tem a vantagem de ser semanticamente retrocompatível com HTTP/1. Também é mais fácil de lidar em proxies reversos e balanceadores de carga

  • Fico um pouco triste em ver que o HTTP/2 Push vai acabar desaparecendo. A ideia era elegante, mas a adoção por frameworks foi fraca, e era um recurso que teria sido bom se tivesse recebido mais atenção.
    No lado do .NET, ele acabou nunca sendo lançado, e no nginx havia uma implementação básica. A ausência de cache digest também continuou atrapalhando. O Chrome o removeu citando, em parte, algo como “ninguém vai perceber mesmo”, e aparentemente era mais importante reprojetar tudo em cima de UDP, que sempre funciona maravilhosamente atrás de NAT

    • Nunca tive problemas com UDP e NAT, mas, se isso irritar as pessoas e induzir a migração para IPv6, vou ficar rindo discretamente

  • Quando conversei com Mike Belshe antes de o HTTP/2 ser padronizado, já havia uma tendência a remover esse recurso do H2, porque era difícil concretizar seus benefícios e havia muitos problemas e armadilhas.
    Um dos maiores problemas era o Push excessivo: enviar coisas que já estavam no cache do navegador ou enviar conteúdo demais que não era importante. Vi casos muito ruins em que o Push realmente deixava o carregamento da página mais lento. Também houve propostas para o navegador informar ao servidor o que havia em seu cache local, mas elas esbarraram em vários problemas. HTTP Early Hints e Resource Hints substituíram em grande parte a necessidade do H2 Push; são muito mais fáceis de implementar, evitam buscas desnecessárias e são mais fáceis de entender

  • Também é possível interpretar como “se servidores web e sites usarem Push sem testar no Firefox, o site pode travar apenas no Firefox”, mas há outras interpretações possíveis.
    Enquanto outros navegadores rejeitam o HTTP/2 Push e o ignoram silenciosamente, o Firefox cai feio em alguns casos de borda. Por exemplo, a ideia é que “o Firefox parece redefinir a conexão ao encontrar letras maiúsculas no nome de um cabeçalho”.

    • Essa interpretação não se encaixa bem. Os outros navegadores é que não implementaram a especificação, e o Firefox implementa a especificação. A especificação é muito clara sobre como essa violação deve ser tratada, e o que está quebrado são essas implementações de servidores web e sites. Se tivessem testado com um cliente em conformidade com a especificação, teriam percebido que estava quebrado.
    • O texto diz isso claramente. O Firefox continuou oferecendo suporte porque o custo de manter o HTTP/2 Push não era alto até recentemente, mas nos últimos meses surgiram bugs de compatibilidade web que afetam apenas o Firefox por meio do HTTP/2 Push.
      O texto parece explicar exatamente essa medida de rejeitar o H2 Push e ignorá-lo silenciosamente, como os outros navegadores fazem, e não parece que estejam escondendo algo.
    • Isso também poderia ter acontecido perfeitamente no sentido inverso. Uma nova especificação é implementada em apenas um navegador — geralmente o Chrome lança primeiro algo incompleto —, e servidores a implementam de forma errada, causando o mesmo tipo de problema.

  • Fico curioso por que o Push não foi adotado de forma mais ampla. Apesar de seus grandes defeitos, era um dos principais motivos pelos quais o HTTP/2 era visto como uma funcionalidade capaz de mudar o jogo.
    Não sei se foi falta de suporte dos navegadores ou se simplesmente não combinava bem com CDNs.

    • O motivo de o Server Push não ter sido implantado em grande escala é que ele pode ser prejudicial. O servidor empurra ativos de que o cliente talvez precise, mas esses ativos já podem estar no cache do cliente.
      Nesse último caso, isso vira um peso prejudicial, especialmente em dispositivos móveis. O servidor nunca consegue saber com precisão se aquele ativo é realmente necessário para o cliente. Early Hints provavelmente é melhor: o servidor informa rapidamente quais ativos serão necessários, e o cliente decide se deve buscá-los ou se já os tem.
    • Cheguei a considerar usar, mas mudei de ideia. Quando chega uma requisição para Index.html, normalmente você vai querer empurrar script.js e style.css, mas isso significa enviar centenas de kbit.
      Se o usuário solicitar index.html de novo, devemos enviar tudo novamente? É bem provável que os recursos já estejam no cache do usuário. Se não for para enviar, como saber o que enviar? Só o navegador sabe o que está ou não no cache. No fim, as opções são acelerar a primeira visita desperdiçando largura de banda em visitas repetidas, ou deixar a primeira visita mais lenta e acelerar as visitas seguintes.
    • Talvez fosse mesmo uma funcionalidade capaz de mudar o jogo, mas isso vale para empresas na escala de Google/Amazon/Meta, ou um pouco menores.
      Para a maioria das demais, foi um enorme aumento de complexidade e, na prática, acabou sendo ignorada.
    • Pode ser útil ver a análise mais detalhada que o Chrome publicou quando decidiu encerrar o suporte a Push.
      https://developer.chrome.com/blog/removing-push/
    • Acho que não houve tempo suficiente. Só em 2015, quando a RFC do HTTP/2 foi finalizada, saiu a primeira versão do Apache com suporte a HTTP/2, e em 2017 ainda havia inconsistências entre navegadores sobre como lidar com Server Push.
      Pelo que consta na Wikipédia, o suporte a Push no nginx parece ter entrado por volta de 2018. Leva tempo para esse tipo de mudança chegar às versões das distribuições estáveis e às configurações padrão. No meu servidor Apache, só ativei HTTP/2 pela primeira vez em 2020, e é bem possível que em 2024 ainda existam servidores de aplicação sem suporte direto.

  • … no Firefox, no caso.

    • Parece que já foi removido de todos os outros lugares.

  • Parece ser um post relacionado. Será que há mais?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - agosto de 2022, 201 comentários
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - julho de 2022, 2 comentários
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - dezembro de 2020, 168 comentários
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - novembro de 2020, 133 comentários
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - setembro de 2020, 2 comentários
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - janeiro de 2020, 71 comentários
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - outubro de 2018, 16 comentários
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - fevereiro de 2018, 63 comentários
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - julho de 2017, 23 comentários
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - maio de 2017, 20 comentários
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - abril de 2017, 59 comentários
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - março de 2017, 2 comentários
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - fevereiro de 2017, 9 comentários
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - agosto de 2016, 6 comentários
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - agosto de 2016, 25 comentários
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - agosto de 2016, 2 comentários
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - fevereiro de 2016, 13 comentários

  • Não surpreende. Quando se acrescenta, sobre um protocolo existente criado para um propósito específico, um recurso que quase não tem relação com o objetivo original de design, geralmente é isso que acontece
    Na maioria dos casos, é melhor começar por um protocolo de baixo nível e ajustá-lo diretamente ao caso de uso; nesse sentido, vejo que WebSockets já resolveu de forma elegante o problema da comunicação bidirecional. Para reduzir a latência ao carregar hierarquias profundas de arquivos/scripts, as tags rel="preload" ou rel="modulepreload" são uma estrutura excelente e simples

    • HTTP/2 Push teria servido exatamente ao mesmo caso de uso dos links de preload que reduzem a latência
      A ideia era o servidor enviar, nos headers, o conteúdo que deveria ser pré-carregado, para que o pré-carregamento começasse antes mesmo de a tag de link ser transmitida ou analisada. Seria menos útil para páginas que suportam streaming, mas, quando a requisição ficava parada até a página HTML inteira ser renderizada no servidor, poderia ter havido um ganho perceptível
    • HTTP/2 era um novo protocolo de baixo nível, e HTTP Push, para começo de conversa, não era um recurso de comunicação bidirecional
    • HTTP também não é comunicação bidirecional?