HTMLページのほとんどがキャッシュされていないため、ETagを導入すればページ読み込みのパフォーマンスに大きなプラスの影響があると感じます。これにより、クライアントが既にページをダウンロード済みの場合、サーバーが再度ページを提供する必要がなくなります。
これについて検討されたことはありますか？
もしかしたら間違っているかもしれませんが、Discourse はすでにクライアントサイドの JavaScript に大きく依存しているため、クライアントがダウンロードするのは最小限のデータです。ほぼすべてのものが初回訪問時に読み込まれ、その後キャッシュされます。ETags がそのキャッシュプロセスをどの程度改善する可能性があるのか、正直よくわかりません。
例えば、私のページの初回読み込みは約 800KB ですが、2 回目の読み込みは約 40KB です。
「いいね！」 2
Discourse はもともとキャッシュ設定が非常に良く設計されています。
ほとんどのサイトアセット（JS、CSS）は、サイトを更新するたびにアセットのハッシュ値を含む一意の URL を生成するため、長いキャッシュ期間を設定できます。
サイトへのアップロード（画像、アバターなど）も、同様に一意の URL を使用していると思います。
表示されるほとんどの完全なページは動的であり、過剰にキャッシュすべきではありません。ETag キャッシュのような仕組みを導入し、ページ読み込みごとに新しい投稿や編集された投稿がないか確認することは可能だとは思いますが、なぜチームがこの実装を見送ったのかはわかりません。
「いいね！」 3
補足しておきますが、アセットのキャッシュは確かに適切に機能しています。私が言及しているのは、HTML ドキュメント（最初のリクエスト）のことです。
表示されている大部分のフルページは動的であり、過度にキャッシュすべきではありません。おそらく、すべてのページ読み込み時に新しい投稿や編集された投稿がないかを確認するような ETag キャッシュを実現することは可能でしょう。なぜチームがこの方法を採用しなかったのか、私は確信が持てません。
はい、まさにこれが私が言いたい点です。ただし、ETag は手動で生成されるものではないと思います。提供される生 HTML を基に生成され、クライアントに対して「これは以前表示されたものと全く同じです。それを使用してください」と伝えることができます。
私の理解では、これはすでにクライアント側の JS で起こっています。つまり、HTML が往復することはありません。
「いいね！」 1
HTML はサーバーから JSON を読み込みますが、その JSON リクエストでは ETag を活用できる可能性があります。現在はまだ活用されていませんが、チームがその理由をどう考えているかは確信が持てません。
「いいね！」 1
ページへの最初のリクエストでは、XHR を介してサーバーから JSON が読み込まれる前に、確実にコンテンツがレンダリングされています。ご指摘の通り、これも同時に発生しています。
Chrome デバッガーの「Document」タイプのネットワークリクエストを確認すると、少なくとも私のケースでは、カテゴリがすでにレンダリングされていることが確認できます。
以下は、ドキュメントリクエストからレンダリングされた内容の例です：
Discourse は JavaScript アプリであり、HTML を取得しないため、ご要望は意味をなさないものです。すべての「ページ」は、実行可能な JavaScript コードによってリアルタイムに構築されます。
「いいね！」 1
ご要望は意味をなしていません。Discourse は JavaScript アプリであり、HTML を取得しないためです。
ここでのご経験と専門知識を心から尊重しますが、私は ETag をルートレスポンスで使用する（コンテンツが再利用可能な場合）数十の JavaScript レンダリング Web アプリケーションを実稼働させてきました。
すべての「ページ」は、実行可能な JavaScript コードによってリアルタイムに構築されます。
上記で投稿したスクリーンショットは、クライアントサイドコードが実行される前に返される HTML です。したがって、このルートを処理するバックエンド（おそらく Rails）に何らかの仕組みが存在することは間違いありません。
このコミュニティを除き、私が確認した Discourse コミュニティのすべては、まずコンテンツがレンダリングされた JavaScript なしバージョンのサイトを返します。これはおそらくクローラー向けです。
もし私の認識が大幅に誤っているならお詫びしますが、私が「意味をなしていない」と言っているわけではないと思います。単に「間違っている」だけかもしれません。
「いいね！」 1
クローラーのユーザーエージェントのみを対象としているため、これは有用な観察結果ではありません。
クローラーユーザーエージェントのみ向け
しかし、これを実行すると以下のようになります：
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/
これはクローラーユーザーエージェントではなく、上記のペイロードを返しています。
いずれにせよ、ETag に関する私のリクエストへの回答は「不可」のようです。フィードバックをいただきありがとうございます。将来的に再検討されるかもしれません。
その通りです。哲学的および技術的な理由の両方から、明確な「ノー」が正解です。
（アセットは別の問題ですが、GUID を使用した一意のファイル名を使用する方がはるかに優れたアプローチであるため、Etag は一般的にやや時代遅れとなっています。）
API の場合でもそうでしょうか？小さなリクエストならコストに見合わないのも理解できますが、トピックの表示データは最大で 20KB になることもあり、それが積み重なると大きくなります。とはいえ、新しい投稿がない限り、トピックを繰り返し閲覧する人は多くないでしょうしね。
まさにそこがポイントです。全く同じコンテンツを繰り返し表示する場合、オフラインであれば、すでにブラウザのキャッシュからすべてのコンテンツをレンダリングし、サーバーにはアクセスしません。
オンライン時でも読み込むようにアップグレードするには、キャッシュの無効化が必要になるため、当然ながら難しいのです。
「いいね！」 2
ああ、動作しているとのことで何よりです。cache-control: no-cache, no-store ヘッダーは、API レスポンスがブラウザのキャッシュに一切保存されないことを意味すると私は考えていました。
いいえ、そうではありません。ええと、少し複雑です。複数のキャッシュが関わっています 
これは、誰もが知っている一般的なブラウザのキャッシュには入りません。しかし、JavaScript からブラウザに公開されている Cache Web API があり、これを使用してレスポンスをキャッシュし、以前に読んだコンテンツのオフラインでの閲覧を可能にしています。
「いいね！」 5