Sinto que os ETags teriam um grande impacto positivo no desempenho do carregamento de páginas, já que a maioria das páginas HTML não está em cache. Isso evitaria que o servidor precisasse servir a página se o cliente já a tivesse baixado.
Houve alguma reflexão sobre isso?
Posso estar errado, mas o Discourse já depende fortemente de JavaScript no lado do cliente, então o que o cliente baixa são dados mínimos. Quase tudo é carregado na primeira visita e depois armazenado em cache. Não sei realmente o quanto os ETags podem melhorar esse processo de cache.
Por exemplo, o primeiro carregamento da minha página é de ~800Kb, e o segundo é de ~40Kb
O Discourse já é bastante bem projetado e configurado para cache.
A maioria dos ativos do site (JS, CSS) possui URLs exclusivas que são geradas a cada atualização do site com um hash do ativo, permitindo que tenham tempos de cache longos.
Acredito que os uploads do site (imagens, avatares etc.) também usem URLs exclusivas.
A maioria das páginas completas que você pode visualizar é dinâmica e não deve ser armazenada em cache de forma agressiva. Seria possível, suponho, implementar um tipo de cache com ETag, que verifica a cada carregamento da página se há novas postagens ou postagens editadas. Não tenho certeza do motivo pelo qual a equipe decidiu não fazer isso.
Deveria ter esclarecido: os assets são de fato bem cacheados — o que estou falando é do documento HTML (primeira solicitação).
A maioria das páginas completas que você vê é dinâmica e não deve ser cacheada de forma agressiva. Seria possível, imagino, ter um tipo de cache ETag que verifica a cada carregamento da página se não há posts novos ou editados. Não tenho certeza do motivo pelo qual a equipe decidiu não fazer isso.
Sim, é essencialmente disso que estou falando, mas não acho que os ETags sejam gerados manualmente dessa forma — eles podem ser baseados no HTML bruto que está sendo servido e podem informar ao cliente: “ei, isso é exatamente o que você viu antes, basta usar isso”.
O fato é que, pelo que entendi, isso já acontece com o JS no lado do cliente. Então, você não tem HTML indo e voltando.
O HTML carrega JSON do servidor, e essa solicitação de JSON poderia usar ETags. Atualmente não o faz, embora eu não tenha certeza do argumento da equipe sobre o motivo.
A primeira solicitação para uma página certamente renderiza o conteúdo antes de carregar o JSON do servidor via XHR, o que você tem razão, também está acontecendo.
Você pode verificar isso examinando a solicitação de rede do tipo “Document” no Chrome Debugger; ela deve ter (pelo menos no meu caso) as categorias já renderizadas.
Aqui está um exemplo do que é renderizado a partir da solicitação do documento:
Sua solicitação não faz sentido, pois o Discourse é um aplicativo JavaScript que não recupera HTML; todas as “páginas” são construídas por meio de código JavaScript executável em tempo real.
Sua solicitação não faz sentido porque o Discourse é um aplicativo JavaScript que não recupera HTML.
Respeito totalmente sua experiência e expertise aqui, mas já executei dezenas de aplicativos web renderizados em JavaScript que usam ETags na resposta raiz (se o conteúdo puder ser reutilizado).
todas as “páginas” são construídas por meio de código JavaScript executável em tempo real.
A captura de tela que postei acima é o HTML retornado antes que qualquer código no lado do cliente seja executado, então certamente há algo no backend (assumo que seja Rails) servindo essa rota.
Todas as comunidades do Discourse que analisei (exceto esta) inicialmente retornam uma versão do site sem JavaScript, com todo o conteúdo renderizado, presumivelmente para crawlers.
Peço desculpas se estou muito equivocado, mas não acho que estou sendo “sem sentido”; talvez eu esteja apenas errado.
Apenas para agentes de usuário de rastreadores, então essa não é uma observação útil.
Apenas para agentes de usuário de rastreador
Isso não é o que vejo ao executar este comando:
curl -H "User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36" https://community.midi.city/
Isso não é um agente de usuário de rastreador e ainda assim está retornando o payload acima.
De qualquer forma, acho que a resposta ao meu pedido de ETags é “não”, então obrigado pelo feedback e talvez seja reconsiderado em algum momento.
Correto, a resposta é um não firme e definitivo para ambas as razões, filosóficas e técnicas.
(Ativos são uma questão diferente, mas usar nomes de arquivo únicos com um GUID é uma abordagem muito superior, então os etags estão, de certa forma, obsoletos em geral.)
Mesmo para a API? Eu entenderia que, para solicitações menores, provavelmente não vale a pena, mas as visualizações de tópicos podem chegar a 20 KB, o que acabaria somando. Mas, por outro lado, não são muitas pessoas que visualizam tópicos repetidamente, a menos que haja novas postagens..
Esse é o ponto. Para visualizações repetidas do mesmo conteúdo exato, se você estiver offline, já renderizamos todo o conteúdo a partir do cache do navegador, sem tocar no servidor.
Atualizar isso para carregar mesmo quando você estiver online envolve invalidação de cache, então, naturalmente, é difícil.
Ótimo, é bom saber que isso funciona. Eu teria pensado que o cabeçalho cache-control: no-cache, no-store significasse que as respostas da API nunca entrariam no cache do navegador.
Eles não. Bem, é complicado. Há vários caches em ação 
Ele não entra no cache convencional do navegador que todos conhecem e amam. Mas existe uma Cache Web API exposta aos navegadores em JS, usada para armazenar respostas em cache a fim de fornecer navegação offline de conteúdo lido anteriormente.
