DiscourseフォーラムへのGoogle 5月4日コアアップデートの影響

本日早些頃、当社の Google 検索結果を調査していたところ、5 月 4 日以降、検索結果から Discourse インスタンス(discourse.julialang.org)へのトラフィックが約 30% 減少していることを確認しました。Discourse がページビューの半分程度しか占めておらず、サイトの残りの部分は今回のアップデートでトラフィックが増加していたため、全体としてはわずかにマイナスに留まっており、そのことに気づきませんでした。しかし、同じドメイン内で Discourse と非 Discourse のデータを分けて見ると、その影響が非常に明確になります。現在はゆっくりと回復しつつありますが、回復の速度はサイト全体の成長率と同程度です。LCP(Largest Contentful Paint)の問題に対して何か対策は取れるでしょうか?これは Google によってペナルティの対象となっている要因の有力な候補のように思われます(実際、検索コンソールでも数万件もの LCP に関する警告を確認しています)。Google の指標によると、多くの Discourse ページでモバイル LCP が約 3 秒と報告されており、これはかなり高い値です。これは Discourse 全体に共通する問題のようです。例えば、このスレッド自体をレポートで確認すると、LCP は 3.3 秒となります。残念ながら私はウェブ開発者ではないため、具体的な提案はできませんが、この分野に詳しい方から何かアドバイスがあれば幸いです。あの 30% のトラフィックを取り戻せたら本当にうれしいのですが :slight_smile:

「いいね!」 10

週次平滑化を適用した検索インプレッションのグラフを、Discourse とドメインの残部(ドメイン全体の信頼評価が同じであると想定)で分割して表示します。5 月の更新は非常に顕著です。皮肉なことに、同じ週にサイト全体で無関係なトラフィック急増がありましたが、全体的な傾向としては、Discourse のインプレッションが明確に減少し、サイト残部のインプレッションは(無関係なトラフィック急増を除き)ほぼ安定していると判断できます。

「いいね!」 5

それがまさに数ヶ月間私が不満を述べていた点です。しかし、管理者たちは真剣に受け止めていないようです @Keno

私たちは Vue.js での実験も始め、Discourse のプリレンダリングパフォーマンスを向上させるために、一部コンテンツを Nuxt 経由で提供しています。その結果、更新が公開されてからわずか 1 ヶ月未満で、ここ 2〜3 日のインプレッション数が 5 月の更新前の水準まで 2 倍に回復していることが確認できました。

これが偶然なのかどうかはわかりませんが、LCP(最大コンテンツペイント)に関連しているかもしれません。結論を出す前に、数週間さらにモニタリングを続けたいと思います。

「いいね!」 3

このブログ記事を読んだところ、内容は…非常に一般的なものですね。要するに「質の高いコンテンツを持て」ということです。このブログ記事を踏まえて、Discourse で具体的に何を変更できるのかさえわかりません :thinking:

「いいね!」 3

コンテンツの品質だけが問題なのかどうかはわかりませんが、おそらく Ember で修正できると思われる高い LCP 時間に関連している可能性もあります。しかし、実際にはまだ確信が持てず、他の解決策も試して検討中です…

「いいね!」 4

私は、あなたがここで一つの指標に少しばかり集中しすぎていると思います。あなたは Google 以上にそれに取り組んでいます。

彼らは 5 月 28 日に LCP について発表し、「これらの変更を実装する前に 6 ヶ月の通知を提供します」と述べています。その通知は今日に至るまで提供されていません。

「いいね!」 7

先ほどもお話しした通り、私は証拠を持っていませんし、それに集中しているわけでもありません。現在、他の要素を実験中で、昨日からインプレッション数が再び増加傾向にあります。今後数週間の推移を見守りたいと思います。

「いいね!」 2

はい、LCP が完全に原因かどうかはわかりませんが、検索コンソールで特に目立つのはこれです。当社の場合、LCP が大きいページで約2万件のエラーが検出されています。SEO への影響の有無にかかわらず、LCP の改善は有意義な目標だと思われます。もちろん、Google の指標が実際に現実を反映しているかどうかは疑問ですが、もし反映しているなら、5秒という初期読み込み時間はかなり長く、もっと改善できる方法があるはずです。特に、Google からアクセスしてサインアウト状態のユーザーにとって、CDN からプリレンダリングされたページを提供することは非常に有用だと考えられます。

「いいね!」 4

LCP(largest contentful paint)を指摘していますが、問題は FCP(first contentful paint)ではないでしょうか… 時間が同じに注意してください。

Discourse の最初の読み込みは、その最初のページだけでなくアプリ全体を読み込むため、その後の読み込みよりも遅くなります。そのため、モバイル端末で Google が求める「良好」なレベル(FCP 1 秒未満)に達するために初期読み込み時間を短縮するのは、言うは易く行うは難しな状況だと思います。

「いいね!」 10

技術的なハードな要素に焦点を当てすぎているように思います。Google は教えてくれませんが、彼らは実際にはウェブサイトの「知覚される」パフォーマンスも測定しています。

Discourse は「知覚されるパフォーマンス」を向上させる可能性を秘めており、そうあるべきです。

https://thepathforward.io/web-performance-how-to-affect-perceived-performance/

これを実現する方法はたくさんあります。例えば、フルアプリが読み込まれる前のスケルトンプリレンダリングなどです。

基本的には、アプリが完全に読み込まれる前に表示されるものは何でも、知覚されるパフォーマンスの向上に役立ちます。例えば、フルアプリが利用可能になる前に、ヘッダー(中身ではなく、正しい色のみ)と、ページの読み込みスピナー付きの背景をレンダリングするだけでも、初期のページビューで役立ちます。ユーザーに「何か起こっている」ということがわかるように、段階的に構築されるものであれば、低速なデバイスでも効果があります。

例えば、Meta のような場合、フルアプリがブラウザで利用可能になる前に、以下のようなものが瞬時にレンダリングされるべきです(単純なクリティカル CSS で実現可能):

シングルウェブアプリの知覚されるパフォーマンスを向上させるための記事は数百件あります。@team が検討すべき課題かもしれません。

「いいね!」 3

「読み込み」ページは、必要に応じてテーマコンポーネントで実装できます。ぜひ試して、サイトにどのような変化があるか報告していただけませんか?

「いいね!」 8

単純なテーマコンポーネントでは、目的の成果を達成できないと思います。そのためには、他のスクリプトやCSSメタタグよりも前に配置される、重要なインラインCSSブロックをヘッダーに含める必要があります。また、<body>はアプリ全体が読み込まれた後にのみレンダリングされます。テーマコンポーネントを使用して、ヘッダーに重要なCSSブロックを含め、アプリの完全な読み込み前に少なくともいくつかの<div>をボディにレンダリングするという目的を達成する方法がわかりません。

「いいね!」 4

これにより、ローダーがわずかに早く表示されるようになります…

検索順位に影響する知覚パフォーマンスに関する情報源はありますか?それとも FCP/LCP のことをおっしゃっていますか?FCP や LCP は知覚に基づく概念ですが、具体的な定義と技術的な要件を持っています。また、FCP は Google の「Core Web Vitals」には含まれていません(LCP は含まれます)。

Largest Contentful Paint (LCP)  |  Articles  |  web.dev からの詳細情報:

現在、Largest Contentful Paint API で指定されている Largest Contentful Paint に含まれる要素の種類は以下の通りです:

  • <img> 要素
  • <svg> 要素内の <image> 要素
  • <video> 要素(ポスター画像が使用されます)
  • url() 関数で読み込まれた背景画像を持つ要素(CSS グラデーション ではなく)
  • テキストノードまたは他のインラインレベルのテキスト要素の子を持つ ブロックレベル 要素。

ページが DOM から要素を削除した場合、その要素はもはや考慮されなくなります。同様に、要素に関連する画像リソースが変更された場合(例:JavaScript を介して img.src を変更)、新しい画像が読み込まれるまで、その要素は考慮されなくなります。

これらの要件により少し複雑になりますが、DOM から削除するのではなく、別の方法で非表示にすれば、大きな画像やテキストを含むローダー要素が機能するかもしれません?上記のスピンナーは z-index を使用して自身を非表示にしているため、これが機能するかもしれません… ただし、スピンナー自体では不十分です。なぜなら、それは画像でもテキストでもない(CSS)ためです。

低速回線のユーザーにとって何らかのローダーが有用であることに同意しますが、Google に対しては特定の条件を満たす必要があります(また、それが OP が提起した問題を解決するかどうかは不明です)。

「いいね!」 7

Discourse をボトムアップで書き直す必要があるため、これを期待するのは難しいでしょう。

「いいね!」 4

このコンポーネントを確認しましたが、アプリの大部分が既に起動した後に読み込まれるため、大きな違いをもたらすとは思えません。Google は、何を基準にしているのかを明確に公開していません。コンテンツ以外にも、主観的な UX も間接的(例えば、検索エンジンへの離脱など)に測定されているはずです。(知覚される)読み込み時間が長いほど、最初のヒットでの離脱率が高まります。また、Google の公式見解によるとこれが 200% SEO に関連するとは限りませんが、UX やトラフィックの観点からは依然として重要です。なぜなら、初回ページ読み込み時の知覚されるパフォーマンスが十分でなければ、ユーザーは離脱するからです。

それは完全に理解しています。そして、正直に言いますが、まだアプリのレンダリングプロセスについては完全に理解できていません。

「いいね!」 1

正直、この指標で勝ちたいなら、Google AMP のような静的に生成されたサイトに行くべきです。

なぜなら、静的ページを持つサイトには常に負けてしまうからです。

「いいね!」 7

私に話しかけてるの?いいえ、Discourse にとても満足しています:+1: 良い UX は最初のページ読み込みだけがすべてではありません。確かに初回読み込みでは多少犠牲になる部分もあるかもしれませんが、一度アプリが読み込まれれば、ユーザーは退屈な静的ページに比べて、より長く滞在し、より頻繁に戻ってきます。それに、Google も何らかの形でこれを考慮しているはずです。

それに、Discourse に切り替えてから、ユーザーから速度に関する不満は一つも出ていません。むしろ、フル HTML キャッシングと Fastly、そしてクリティカル CSS によって「光の速さ」の初回読み込みを実現していた、超最適化された Drupal ページと比較しても、検索からのトラフィックは増加しています。

「いいね!」 4

@codinghorror 皆さん、私が保有する 2 つのドメインでいくつかのテストを行いました。

両方とも 5 月 4 日のアップデートの影響を受けました。

ケーススタディ 1:コンテンツの質に完全に焦点を当てる(多くの人が上記で提案していた通り)

最初のサイトでは、コンテンツの改善、キーワードの最適化、悪質なリンクの削除、内部リンクの構築、可能性に満ちた新しい良質なコンテンツの追加などに注力しました。

上記の通り、すべての努力は無駄に終わりました。新しい記事は適切にインデックスされ、薄いコンテンツは削除され、古い記事も改善されたにもかかわらず、ほとんど改善が見られません。Google はウェブサイトに対して十分なインデックス処理を行い、わずかなトラフィックは得られるものの、それ以上のトラフィックは得られない状態のようです。

ケーススタディ 2:Vue+Nuxt への移行(構造のわずかな改善 + LCP とレンダリング速度の向上)

2 番目のサイトでは、API を通じてわずかに、あるいは構造の変更なしに同じコンテンツを提供する独自の Vue+Nuxt アプリの一部のページを移行しただけでした。他の改善努力は行われませんでした(ただし、この場合、コミュニティを community.example.com からメインのウェブサイトに移行することは、一時的に害の方が利益を上回りましたが)。

上記から何を結論付けられるか確信はありませんが、引き続きテストを続け、その急激なスパイクは興味深いものです。ちなみに、5 月以前とその後、そして最近のスパイクの前後を確認したところ、多くの記事がインプレッションを失った後、ほぼ同じ記事が同じ量のインプレッションを突然取り戻していることに気づきました。つまり、影響を受けたのは 1〜2 記事やページではなく、Google がウェブサイト全体にペナルティを科し、そのペナルティがコンテンツの質向上への努力に関係なくウェブサイト全体に残っているようです。

上記が理解しやすいことを願っています。ご質問があればお気軽にお知らせください。

では、よろしくお願いいたします!

「いいね!」 9

私の記憶が正しければ、Discourse はクローラーに対してページのスナップショット(静的バージョン)を提供しようとしているはずです。そのスナップショットを、ログインしていないすべてのユーザーにも提供することは可能でしょうか?これらの LCP(最大コンテンツペイント)のペナルティは、Google が当フォーラムの非静的バージョンを認識していることを示唆しています。

私たちは数ヶ月にわたり断続的にこの問題に取り組んでおり、外部コンサルタントを雇って調査もしてきましたが、すべてが 5 月 4 日のアップデート以降、Google による LCP 違反の厳しいペナルティが当フォーラムに課されていることに起因するという結論に落ち着いています。

「いいね!」 6