この変更（すべての匿名ユーザーにHTMLビューを表示）を行うことは確かに可能ですが、匿名ユーザーの使いやすさに大きな悪影響を及ぼします。確かにコンテンツはより高速に表示されるようになりますが、匿名ユーザー向けに動作していた膨大な機能が使えなくなり、サイトが匿名ユーザーに対して「正しい見た目」にならなくなります。
これを何らかのサイト設定として実装し、実験できるようにすることは可能かもしれません。しかし、「無限読み込み」のような機能が匿名ユーザーで動作しなくなるなど、非常に高いコストがかかります。また、ユーザーが実際に登録やログインできるようにするため、/login ルートへのバイパスを実装するよう、少なくとも一部のエンジニアリングリソースを投じる必要があります。
匿名ユーザーが最初にアクセスした際に HTML ビューを表示し、その後も閲覧を続ければすべての機能を有効にするという方法は可能でしょうか？それは良い解決策のように思えます（ただし、検索エンジンにとって受け入れられるかどうかはわかりませんが）。
それは理想とは程遠い状況のようですね。静的なコンテンツを提供した上で、動的な部分を「埋め込む」ような方法はありますか？おそらく大規模なアーキテクチャの見直しが必要になるでしょうから、現実的ではないかもしれません。主に、5 月以降に当サイトで 49,000 件の LCP エラーが発生し、同時に検索トラフィックが減少しました。現在の LCP スコアの平均は 5.3 秒です。この数値を下げるためのアイデアを探しています。
プラグインの追加や削除、カテゴリ数の増減、静的アセットを CDN に配置するなどの方法は如何でしょうか？昨冬は Cloudflare の導入を試みましたが成功しませんでした。もう一度試すことも可能です。Discourse のアーキテクチャについては詳しくないため、ヒントとなるような情報をお待ちしています。
まさにその通りでした。すべてのプラグインを削除し、広告まで取り除いて実験しています（現在は当社のWebサイトに広告はなく、画像の最適化なども実施済みです）。その結果、LCP（最大コンテンツペイント）を低下させることができましたが、わずかに黄色ゾーンに届く程度です。現在はエラーではなく警告レベルですが、それでも当社のWebサイトに影響を及ぼしています。それ以降、わずかな増加が見られますが、これを確定させるにはもう少し時間が必要です。
正直なところ、Discourseのオープンソース版であるNuxt+Vue.jsのクローンを作成するか、その上にラッパーを構築することを本気で検討しています。現時点ではそれが唯一の現実的な選択肢のように思えます！
はい、Discourse アプリ全体をダウンロードしているため、大規模なエンジニアリング対策を講じない限り、その初期読み込みを軽減する方法はありません。
さらに追い打ちをかけるように、Android 上の JavaScript パフォーマンスは一般的に iPhone よりも劣ります。また、Google は「実世界」のモバイル指標において Android デバイスのみをカウントしているようです。Meta の iOS は、モバイルトラフィックの約 40% を占めています。
ここで言えるのは、FCP と LCP の遅延を認識しており、それらを改善するための長期的な計画を持っているということです。
具体的には、@eviltrout が Ember CLI へのアップグレードを進めています。それが完了すれば、コードスプリッティングやその他のテクニックについて考え、場合によっては実験することも可能になります。
簡単な解決策はありません。CDN を使用しており、リソースの読み込み方法には細心の注意を払っています。ここには無数の時間をかけて最適化を行ってきましたが、根本的には JavaScript を使用してページをレンダリングしており、JavaScript の配信・パース・実行には初回読み込み時に時間がかかります。
古いトピックを持ち上げてすみませんが、ここ数ヶ月テストを行なった結果、さらにデータが集まりました。
今回テスト対象としたのは以下の2つのウェブサイトです。1つ目は、Discourse（EmberJs）から、VueとNuxtで独自構築したフロントエンドへ移行したサイトです。
2つ目は、Discourseのままですが、広告、カスタムフォント、そして軽量化のために取り外せるものをすべて除去したものです（これにより、LCPのエラーレベルが「エラー」から「警告」に改善されました）。
ご覧の通り、5月のアップデート後にキーワードランキングが50%下落しました。10月に変更を開始したところ、一時的にわずかな上昇が見られましたが、その後再び低下しました。まるで何らかの抵抗（つまり、Googleからのペナルティ）があるかのようです。
上記の画像をご覧いただくと、行った変更（余分なものをすべて除去）により、URLが「Poor URLs（性能が悪いURL）」から「改善が必要なURL」へと移行したことがわかります。しかし、それさえも効果は限定的でした。
このサイトについては、1ヶ月前に気づいた通り、5月4日以前の最高値まで回復傾向にあります。
はい、GoogleはLCPを重視しています！
Discourseチームがこの件をより真剣に受け止めてくれることを願っています。Emberからの移行を検討する価値があるかもしれません。私は大規模プロジェクトで実際に移行しましたが、確かに移行コストは高額でしたが、それだけの価値がありました。
LCP も関連するペナルティであることに私も同意します。このスレッドは長らく追跡してきましたが、この問題についてはまだ具体的な推奨事項はありません。
ご報告ありがとうございます！この点は引き続き該当すると考えられます：
Ember CLI への移行は現在進行中で、順調に進んでいます。ただし、Ember からの完全な脱却を待っている場合は、他のプラットフォームを検討し、1 年後に LCP の状況を確認することをお勧めします。
Discourse が Ember CLI にアップグレードする価値があるかどうかはわかりませんが、他のプロジェクトでも同様の経験をして、結局は完全に廃止せざるを得なかったこともあります。Ember CLI へのアップグレードは、Vue など他の技術へのアップグレードとほぼ同じ程度の労力を要します。
いずれにせよ、私の調査は単にその問題を示し、結論を導き出すために行いました。初期の頃には、LCP（最大のコンテンツペイント）が検索順位に関係するという事実を否定する人がほとんどだったのです。
私たちはその作業の約 90% を完了しています。これは、開発者の利便性を大幅に向上させ、Ember の最新状態を維持するため、長期的なロードマップに当初から含まれていました。詳細については、この取り組みを主導している @eviltrout にお尋ねください。
はい、しかしだからといって、すべてのサイトが静的 HTML 描画に切り替え、魔法のような SEO と超高速なページ読み込みの力でウェブを支配するようになるわけではありません。実は、ランキングにはページの実際の コンテンツ も非常に重要なのです 
このような 1 つの メトリクスへの過度な焦点が、どれほど多くのトラウマと誤ったエンジニアリング作業を生むかを知るには、Google AMP の歴史をご覧ください。
まさに私が私の投稿で覆そうとしている点です。Google にはすでに質の高いコンテンツが大量に存在しています。もしユーザーの満足度に基づいて判断するとしたら、LCP（Largest Contentful Paint）は彼らが基準とする最低限のものだと私は考えます。結局のところ、Google はこのアップデートの数ヶ月前から警告を発していました。
正直に言うと、Ember CLI には多くの経験がありますが、以前と同様にひどいままです。さらにアップグレードの労力を考えると、本当に価値があるのか疑問です。しかし、どのように進むか見てみましょう。@eviltrout が速度の向上が見られたかどうかについて何か知見を持っていることを願っています。
残念ながら、上記の私の調査結果から明らかなように、Google は実際にはユーザー体験と LCP に非常に重点を置いています。私たちは他のあらゆる対策を試みました。そして、2 番目のウェブサイトをご覧いただければわかる通り、LCP エラーを解消する以外のことは何もしていませんが、それだけですべてのランキングを取り戻す軌道に乗りました（実際、現時点ですでに完了しています）。
これが役立つことを願っています。
Ember CLIのどの点が気に入らないのか、具体的に教えていただけますか？例を挙げて説明してください。
私たちはスタートアップで Ember CLI の採用を開始しましたが、その理由の一つは、Discourse でも使用されていることを知ったことです（それが私たちの注目を集めました）。試してみましたが、始めやすく、作業もしやすかったです。しかし、それは非常に肥大化していました（他の理由 aside）。
Ember CLI は最近のアップデートを導入し、バージョン 3 以前のアプリで書かれたものはすべて書き換えが必要になるため、その時点で完全に廃止することを決めました。
はい、Ember CLI には遅延読み込み機能がありますが、少なくとも私たちのテストでは全く効率的ではありませんでした。また、Ember CLI 向けに書かれたライブラリは、ほとんどが古くなっていたり、非常にバグが多かったりして、多くの機能を自分で実装するか、古いリポジトリをクローンして自分でメンテナンスする必要がありました。
Ember CLI かどうかに関わらず、レンダリング時間が常に悪いのも問題です（ここで議論している LCP 問題の解決には役立ちません）。
それ以外に、Ember の仕組み自体がアプリの肥大化を招きやすいという点もあります。
乗り換えを決断する前に行っていた古い分析データがまだ手元に残っていれば良いのですが、数か月前にようやく Ember から Vue への移行を完了し、アプリのパフォーマンスと開発速度にはこれ以上ないほど満足しています。
PS. Discourse のリポジトリをチェックする機会はまだありませんが、Ember CLI へのアップグレードはさらにトラブルを招く可能性があります。なぜなら、Ember Octane へのアップグレードを再度行う必要があり、それもまだ安定しておらず、全く異なる構文を使用しているからです…など、正直言って最悪な状況です。以前 Ember を選んだ際に使われた論拠が、現在も有効かどうかはわかりません @Jeff。
これが何かの参考になれば幸いです。
「真剣に受け止める」とはどういう意味でしょうか？私たちのエコシステム全体を焼き尽くして、ゼロからやり直すことですか？
Discourse は成長中のプロジェクトであり、この問題を十分に認識しており、Fastboot やより積極的なコード分割などの対策を検討しています。これらすべては、Ember CLI のアップグレードが完了するまで保留となっています。
この代替フロントエンドがどのようなものか興味深いです。リンクを PM でお送りいただけますか？本質的に、カスタマイズ不可能な HTML のみの実装は容易です。私たちは HTML のみのビューを提供しており、samsaffron.com の LCP が非常に良好であることが確認できます。これは単に HTML をレンダリングする Discourse プラグインに過ぎません。
ヤシン様
一般的に、LCP と Google SEO に関するご意見には同意しており、またあなたの分析と洞察には深く感謝しています。
もし Google があなたが推奨しているほど LCP を重視しているなら、なぜ私が Discourse フォーラムに投稿した 2 つのトピック（Google によると LCP が非常に悪い）が、3,580,000 件のエントリーの中でそれぞれ第 1 位と第 2 位にランクインしているのか、その理由をご説明いただけますでしょうか。
参照：
Discourse SPA の LCP 問題があなたが主張しているほど深刻だとすれば（私は対立的な意図は全くなく、あなたの専門知識に基づいた純粋な好奇心からです）、なぜ CDN を一切使用しておらず LCP が非常に悪い私たちのような低速サイトが、投稿からわずか 11 日と 13 日しか経っていないトピックで、約 350 万件の他の投稿の中でトップ 2 の座を維持できているのでしょうか。
Google の LCP があなたが提示しているほど影響力があるなら、なぜ LCP パフォーマンスが非常に悪い私たちのサイトが、これほど素晴らしい SERP 結果を得ているのか、正直なところ疑問に思っています。
ありがとうございます！
あなたの例からすると、答えは非常に明確です。あなたは LCP が優れている競合がほとんど存在しない、かなり具体的な用語で検索しています。競争相手が一人もいなければ、「最善」であることは簡単です。上記の投稿にある通り、コンテンツが依然として最も重要な要素ですが、検索結果に大量のコンテンツが存在する場合には、他の要素も重要になってきます。むしろ、あなたの主張は彼らの意見を裏付ける結果になっているかもしれません。
これはすでに上記で触れられていますが、フォーラムの高速な静的 HTML のみバージョンを生成し、検索エンジンにこれを提供することはできないでしょうか？（登録ユーザーが閲覧し投稿する実際のフォーラムのクロールは禁止する形で）。
静的ビューを生成するプラグインがあるとおっしゃっていましたが、これは誰でも利用可能なのでしょうか？
これはまだ「推測」に過ぎず、事実として証明されていないということでしょうか？
Google や他の情報源によれば、LCP は現在ランキングの要素として使用されておらず、2021 年 5 月までランキングシグナルとして採用されないとのことですが、これは正しいでしょうか？
LCP が SEO に影響を与えていると主張するごく少数の人々の分析やグラフに基づいて、Discourse チームに対してエコシステムに大幅な変更を迫るのは、少しやりすぎではないでしょうか。Google はこのシグナルはまだ有効ではないと明言しています。
LCP シグナルは現在有効でしょうか？
Google は、LCP が SEO のシグナルとしてまだ使用されていないと述べています。
念のため申し上げますが、私は EmberJS のファンではありませんし、LCP が重要であることには同意します。単に、証拠や確固たるデータに基づいた事実を求めているだけです。
私の唯一の「主張」は、このスレッドを読むと、Google や他の SEO 専門家によればまだ SEO シグナルとして使用されていないものを根拠に、Discourse メタに対して構造的な大規模変更を強く迫っているように見えるということです。
皆さんは、Google が一般市民に対して正直ではないと言っているのでしょうか？
参考までに、上場企業である Google が一般市民を欺くことは極めて考えにくいです。それは Google に莫大な潜在的な金銭的責任を負わせることになります。
なるほど。私も LCP については詳しくありません。それを認めます。私はこのトピックで語られている内容に基づいていただけで、あなたが仰る通り、それが正確かどうかはわかりません（ここで提示された証拠を除いて）。ですから、私の投稿は「LCP の件が正しいという前提で」お読みください。
あなたの結論（おそらくLCPはGoogleが検索順位を決定する際に使用されていない、ということでしょう）は正しいかもしれません。しかし、あなたがたどり着こうとした道筋では、その結論には至りません。
これらはLCPについて何も述べておらず、証明もしていません。これは興味深いトピックであり、その継続を楽しみにしています。個人的には、Discourseの速さに満足しています。
