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

完全に同意します。私の行った簡易検索の結果は本題ではなく、何らかの権威あるテストを行う意図もありませんでした。投稿する際にも、そのような主張は行っていません。単に検索結果に基づいて質問を投げただけです。検索を行う前にログアウトすべきでした。ログアウトすると、同じ「結果のなさ」が表示されるからです(笑)。

私が実際に提示した唯一の「具体的な技術的ポイント」は、Google が 2021 年 5 月から LCP(およびその他の Web バイタル)を使用すると公に発表しているという事実です。

また、ビジネス上の観点から、Google がこのような声明を出して人々を欺くことはあり得ないという点も指摘しました。上場企業にとってそれは大きな過ちになるでしょう。私の推測では、そのような過ちは犯さないでしょう。Google が「現時点では LCP をシグナルとして使用していない」と述べている以上、それを疑う理由はありません。

善意の投稿者たちが「LCP が SEO に影響を与えている」と主張し、「自分の発見」を確信して、Discourse がコードの構造的変更を行うよう提言している場合、もしコードがオープンソースとして誰でも検証可能な形で提供されていれば、その「証拠」はピアレビューを経て説得力を持つものになったかもしれません。

これは個人的な攻撃や敵対的な意図とは全く関係ありません。実際、私たちが目にしたのは数枚のグラフだけであり、コードは存在しません。一方、Google は公的に「現時点では LCP を SEO シグナルとして使用していない」と述べています。

あらゆる「技術的な公平性」の観点から、Google が現在 LCP をシグナルとして使用しているという「証拠」は実際には存在しません。それは単なる推測に過ぎず、それを裏付けるためにレビュー可能なコードもありません。

皆さんは、SEO を最適化し収益を増やすために必要な変更が何かを知りたいと願っています。しかし、Google が実際に LCP をシグナルとして使用しているという確信を持てるためには、検証可能なコードを含む具体的な事実が必要です。

Google は「現時点では LCP をシグナルとして使用していないが、2021 年 5 月から SEO シグナルとして使用を開始する」と主張しています。これまでに、Google の公的な声明を疑う理由は見つかっておらず、それに反する「ピアレビューされた確固たる証拠」も存在しません。

これが何かの助けになれば幸いです。

「いいね!」 4

つまり、2020年5月について不満を言っていた皆さんにとって、それは来年5月に起こりうることに比べれば取るに足らないものだったのでしょうか?:wink: つまり、Discourseコミュニティも来年、検索結果の面で打撃を受ける可能性があると言っているのですね(実際にどうなるかはこれから見ていきましょう)。

「いいね!」 2

はい、LCP と Google の Core Web Vitals が及ぼす影響について懸念を抱いている皆様のご意見に、私も完全に同意します。

加えて、この差し迫った課題に対して解答や解決策を模索しようと奔走している皆様を心から称賛します。

2020 年 5 月の SEO クラッシュについてですが、これは私たちも LAMP サーバー上で同様に経験しました。したがって、これは Discourse 自体の問題というわけではありません。また、もし何が問題でどう修正すべきか高い確信を持って分かっていたなら、私たちは皆その問題を「修正」し「調整」できたはずです。しかし、その具体的な手順については今なお不明な点が残っています。

長年にわたり、Google の AI がもたらす非常に奇妙な結果、Google の AI がコンテンツをどのように分類し、SERP(検索結果ページ)にどのような影響を与えるかを目の当たりにしてきました。

私の以前の指摘は、レビュー可能なコードに基づく確固たる事実ではなく、推測や憶測に基づいて、Discourse Meta チームに対して生態系全体に非常に大規模な構造的変更を迫る発言が、このトピック内で見られたことは根拠が薄弱に思えたという点です。

とはいえ、LCP は瞬く間に極めて重要な要素となるでしょう。

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

「いいね!」 4

それは Discourse が昔から採用している仕組みです :laughing:

新しい点は、LCP(最大コンテンツペイント)が Android スマートフォンからの計測結果として捉えられていることです。Android は私たちが運用するプラットフォームの中で最も遅く、その影響が私たちに不均衡に大きく現れています。

@sam が提案したのは、プラグインを通じて一部の匿名ユーザーに対してそのビューを提供することでしたが、それはすぐには実施する予定はありません。

「いいね!」 7

はい、正確な仕組みについては知識が不足しています(ただし、初期読み込みにまだ時間がかかっているように見え、そこを改善できる可能性があります。それがこのトピック全体が生まれた理由です)。この議論はすでに 10 月 14 日の上記の投稿で概ね行われています。Jeff 氏自身が実際にこのアイデアを提起しました:

なぜコンテンツを取り出して、完全に事前生成された静的サイトを作成しないのでしょうか。可能な限り最速のものです。そして、実際のフォーラムではなく、これを検索エンジンに提出するのはどうでしょうか。アイデアとしては、ここでは体験ではなくコンテンツが最も重要だということです。そして、検索エンジンにとって重要に見えるのは配信の速さであるため、それに焦点を当てます。

無限スクロールは最近非難されていませんが、無限スクロールのない静的な事前生成されたページを作成することになります。そして、レーシングカーのように設計するのです。厳密に必要不可欠でない重量はすべて排除します。ハンバーガーメニューも、ロゴも、投稿者のアバターもありません。コンテンツと速度にのみ専念します。

それは、素敵なレストラン(=Discourse フォーラム)で、テイクアウト注文のドライブインを設置するようなものです。同じ素晴らしい料理(=コンテンツ)ですが、体験は一切伴いません。スピーカーで注文します(=検索エンジンでの検索)と、食料品が梱包された状態で窓から投げ込まれます。全体のアイデアは、求められているのはそれであり、重要なのは料理(=コンテンツ)と配送の速さだけだということです。もし人々がその料理を気に入れば、もしかしたら戻ってきて店内での体験を楽しみに来るかもしれません。

その後、それぞれのオーナー(=管理者)が選択することになります。ドライブインはブランドに悪影響を与えると考えて拒否するのか、それとも多くの人々が店内に来ないかもしれない(すでに多くの人々が来ませんが、さらに悪化する可能性があります。また、そのように提示された場合、あなたのレストランはそれほど素敵に見えなくなるかもしれません)ことを承知で、より多くの人を惹きつけるためにその道を選ぶのか。ただし、有名なレストラン紹介サイトがより多くの人を送り込んでくれるかどうかは、まだ効果があるかどうかは不明です。

必要となるのは、フォーラムにコンテンツが追加されるたびにこれらの静的ページを生成するプラグインまたはモジュールです(過度に複雑ではないと思います)。実際のフォーラムへのリンクを至る所に追加するだけです(検索エンジンに対して「クロールしない」ように設定)。このソリューションを使うかどうかは、各管理者の判断に委ねられます。

上記のことが原則として正しく、この問題が将来さらに悪化する可能性があるなら、これは私にとって受け入れ可能な解決策に思えます。あるいは、私が正しく理解していないだけかもしれません。(注: もちろん、すべて読み取り専用です)

「いいね!」 1

私たちはすでに、クローラーに対してJavaScriptを含まない純粋なHTMLを提供しています:upside_down_face

前述の通り、問題は新しいLCPスコアがクローラーではなく、ユーザーのブラウザから計測される点にあります。

「いいね!」 7

はい、でも私が理解できないのは、この場合誰も優位に立っていないということですよね?なぜ検索結果に影響するのでしょうか?Discourse サイトが他のサイトと同じ程度(「同じ程度」あるいは「同じくらいひどく」 ;))に機能しているなら、他のサイトも Android で開かれますよね?

「いいね!」 2

Android はシングルクコア性能が平均より低く、Discourse のような重たいシングルページアプリケーションに影響を及ぼします。この点については、2015 年の Android における JavaScript の現状は…貧弱 で詳しく解説しています。

Discourse のレンダリングにおいて、最新の iPhone は最新の Pixel よりも 10 倍高速です。Google は iPhone のレンダリングを LCP に反映していません。iOS には実質的な Chrome がないため、反映できないのです。

「いいね!」 9

つまり、検索エンジンに提出するサイトとして「小規模なページ」を生成する方が、その点では確かに有利なのかもしれません。それに見合う価値はないでしょうか?(たぶんないでしょう)。それとも、管理者はユーザーに最新の高性能なスマートフォンを提供する必要があるのでしょうか?:wink: 最新の iPhone に当たったと主張するすべての広告の目的はそれなのですね?:rofl:

解説をありがとうございます、Falco さん!

「いいね!」 1

Overview of CrUX  |  Chrome UX Report  |  Chrome for Developers をざっと見た限り、Google は(許可を得た上で)ユーザーを監視して情報を収集しているようです。そのため、多くの人を説得して、あなた方の「貧乏人の Discourse」を使ってもらう必要がありますね :slight_smile:

「いいね!」 4

どうやらあなたは Ember と Ember CLI を混同されているようです。Ember は私たちがすでに(8 年以上)使用しているフレームワークです。Ember CLI は、Rails のアセットパイプラインの代わりに移行しているコマンドラインツールです。これを指摘したのは、あなたが述べたことの一部(バージョン 3 以前は書き換えが必要という点など)は Ember CLI には当てはまらないが、Ember には当てはまる可能性があるためです。

繰り返しますが、Ember CLI はレンダリングを行いません。レンダリングを行うのは Ember であり、時としてパフォーマンスに問題があります。ただし、これは Ember に特有の問題ではなく、現在のすべてのフレームワークには注意すべきパフォーマンスの落とし穴があります。Ember と長年携わる中で、私たちはパフォーマンス改善が必要な 2 つのホットパス(ヘッダーとトピックビュー)を特定し、仮想 DOM ベースのアプローチへ移行しました。

Glimmer や Ember Octane の成果次第では、常にこの対応が必要とは限りませんが、コードは非常に安定しており、現在では古いモバイルデバイスでも高速に動作します。

Ember Octane はバージョン 3.15 で導入され、それ以来 2 つの LTS リリース(3.16 と 3.21)が提供されています。私たちは段階的にこれへアップグレードする予定です。幸いなことに、Ember チームは使用するフォーマットを選択可能にしています(ファイル単位でも可能です)。


以上を踏まえた上で、Ember には批判すべき点も確かにあります。Discourse にとってパフォーマンスがより大きな問題だった頃、いくつか約束されたリリースが結果的に私たちを助けるどころか傷つけることになりました。それは困難でした。私たちのニーズを満たすために、長期間それに非常に注意を払う必要がありました。

現在でも、React のような新しいフレームワークに比べれば人気は一部に留まっています。ただし、8 年前には React は存在しませんでした!私たちの選択肢は Angular、Ember、Knockout のみでした。Ember のアップグレードが困難だとお考えなら、Angular がバージョン 1 から 2 へ移行する際に経験した苦難(Dart へのサイドクエストも含め)をご覧になってみてください。

長年にわたる Ember のアップグレードには多くの労力が必要でしたが、少なくともその選択肢はありました!他のフレームワークのいずれも、このようなアップグレードパスを提供していませんでした。

Vue、Next、React への書き換えについては、人々は私たちがすでに正常に動作しているコードの量を過小評価していると思います。それは想像を絶するほどの作業量になるでしょう。

「いいね!」 19

はい、その通りです。ユーザーのデバイスが古い場合、一般的にサイトの評価は低くなります。

「いいね!」 6

@justin@awesomerobot の皆さん、検討はしていますが、まずは Ember CLI の詳細について Robin の意見を伺いたいです。

根本的には、「止まらない力が、動かない物体にぶつかったらどうなるか?」 というパラドックスのような状況にあります。私たちは意図的に JavaScript アプリ(あるいは SPA)として設計しており、これは 2012 年〜2013 年に「2022 年〜2023 年の未来がどうなるか」という最善の推測に基づいて行ったトレードオフです。もちろん偏りはありますが、「モバイル端末のブラウザパフォーマンスがデスクトップのそれと区別がつかなくなるだろう」という予測は、的中したと言えます。

むしろ、その予測を超えています。最新の Apple 製スマートフォンは、ラップトップやデスクトップよりも 速い からです。:astonished_face: これは… 予想外 でした!

:bullseye:

初回読み込み速度や全体的な速度の向上は引き続き進めていきますが、これまでの実績は称賛に値すると思います。例えば、2015 年に非常に大きな話題となったおかげで、Google は内部で V8、Chrome、Android を改善し、JavaScript における Qualcomm SoC のパフォーマンス不足に対処しました。

私たちの足かせとなっているのは… Qualcomm です。残念ながら、Qualcomm はこれまでパフォーマンス面であまり良い結果を残せていません。現在「最高」のパフォーマンスを誇る Android デバイスでも、おおよそ iPhone 7 レベルに過ぎません。古い Android デバイスが市場から姿を消すには時間がかかりますが、Snapdragon 855 と 865 はどちらも、おおよそ iPhone 7 レベルの decent な性能を持っていました:

Apple 製デバイスで、最も速い Android デバイスと同じくらい遅いものを見つけるには、さらに下にスクロールする必要があります。しかし、探せば iPhone X / iPhone 8 が Geekbench で約 910 点という最も近い一致です。残念ながら、865 は私が完全に理解していない理由により、Web 側のパフォーマンスがやや劣っており、Speedometer ではまだ iPhone 7 レベルの性能です:

様々な企業が様々な SoC を搭載した Android デバイスを発売し、それらが最も速く強力な SoC を作ろうと競い合っている世界だったらいいのにと思います。:crying_cat: 一方で、iPhone 7 の性能は Discourse にとって十分です。また、いずれは古い Android デバイスを含め、すべての Android デバイスが「少なくとも iPhone 7 と同じくらい速くなる」ことを願っています。また、今後の Snapdragon 875 にも期待しています。今後数ヶ月で詳細が明らかになるでしょう。:crossed_fingers:

Geekbench 5 の結果によると、Xiaomi Mi 11 は 5nm の Snapdragon 875 を搭載していることがわかります(Xiaomi の執行役員である Lu Weibing 氏によってほのめかされました)。今後の Xiaomi Mi 11 は、シングルコアベンチマークで 1,102 点、マルチコアテストで 4,113 点を記録しました。

これが本当なら、A12 レベルの性能となり、Web 側でも同様の結果が得られることを願っています!

とにかく、Discourse には JavaScript アプリとしてある という核心的なアーキテクチャ上の決定があり、私たちは予測可能な未来に向けてこの道に完全にコミットしています。

Deal_with_it_dog_gif

「いいね!」 23

統計を注視されている方へ、もう一つメモしておきたい日付があります。2020年12月のGoogleの最新コアアップデートに関連して、今後数週間で何が起こるのか興味深いところです。

https://searchengineland.com/googles-december-2020-core-update-was-big-even-bigger-than-may-2020-says-data-providers-344429

「いいね!」 1

最近発表されたApple Silicon搭載Macも忘れてはいけませんよ!:grinning:

気になったのですが、その報道はどこから来たのでしょうか?

A10チップはもう限界に来ています。

念のため、期待値は低めに設定しています。Appleはいつも先を行くからです。

それでもなお、Androidスマートフォンは未だに追いつこうと必死です。本当にばかげています。AppleはすでにA14チップを持っており、来年用のA15チップの開発にもおそらく取り組んでいるでしょう。

「いいね!」 2

ご共有ありがとうございます。記事からこの議論に関連するいくつかの項目を抜粋します。

被害を受けた場合の対処法。Google は過去に、コアアップデートにより悪影響を受けた場合に考慮すべき事項について助言を出しています。回復のために取るべき具体的なアクションは存在せず、実際にはランキングへの悪影響がページに問題があることを示すものではない可能性があります。ただし、Google は、コアアップデートの影響を受けたサイトが検討すべき 質問リスト を提供しています。また、Google はコアアップデートの間にもある程度の 回復が見られる と述べていますが、最も大きな変化が見られるのは、次のコアアップデートの直後です。

これも参考になります。

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

「いいね!」 7

私の見解では、SEO(検索エンジン結果を他のサイトと比較して最適化する作業)を論じる際、ユーザーのハードウェアについて言及することはほとんど無関係です。

なぜでしょうか?

実は非常にシンプルです。

一人のユーザーとその携帯端末での検索結果を考えてみましょう。

端末の速度やチップセットが何であれ、ネットワーク上の単一の端末が体験するパフォーマンス(性能)は、同程度の性能を持つすべてのウェブサイトにおいて概ね同じになります。ウェブサイト自体の速度が速ければ速く、遅ければ遅くなります。これは端末のチップセットなどに関係ありません。「潮が満ちればすべての船が浮き、引けばすべての船が沈む」のと同じです。SEO において、端末の性能は「ノイズ」であり、SEO で最適化されるのは「サーバー側のアプリケーション」です。

つまり、仮に宇宙で最も高速な携帯電話があったとしても、すべてのウェブサイトの速度はネットワークの速度とウェブサイトの設計次第で速くなったり遅くなったりします。SEO の焦点は、ウェブアプリケーションとその配信を最適化することにあり、ユーザー端末ではありません。あるウェブアプリが特定のチップセット上で「驚くほど素晴らしい」パフォーマンスを発揮するなら、同様の設計を持つ他のすべてのウェブサイトも同様です。SEO の対象はユーザー端末ではなく、サーバーに基づくウェブアプリケーション、コンテンツ、読み込み時間の最適化です。クライアント端末は理論上すべてのウェブサイトを訪れるため、SEO の信号対雑音比において「ノイズ」となります。

ウェブサイトの SEO の観点から言えば、同じクラス(性能特性)のすべてのユーザー端末を利用するユーザーにとって、ユーザーエクスペリエンスに基づく検索エンジン最適化はネットワーク上で同一です。あるウェブサイトが他のウェブサイトに対して SEO 上の優位性を得られるのは、ウェブサイト(およびそのネットワーク)のパフォーマンスによるものであり、ユーザー端末によるものではありません。

なぜでしょうか?

一般的に、ユーザー端末はすべてのウェブサイトにおいて同様に動作するからです。もしユーザーの端末がメモリやチップセットのせいで遅い場合、それはサイバースペース上のすべてのウェブサイトにおいて遅くなります。つまり、ユーザー端末が SEO に与える影響についての議論は、もはや意味をなさないのです。検索エンジン最適化はクライアントサイドの操作ではなく、サーバーサイドの操作です。

重要なのは、コンテンツ、プレゼンテーション、パフォーマンス、そして Google の AI がこれら要因をサイバースペース全体でどのように評価するかです。例えば、世界中のすべての人が量子コンピューティング搭載の携帯電話にアップグレードしたとしても、SEO は同じになります。なぜなら、すべてのユーザーが同じ「ユーザー端末のパフォーマンス曲線」を持つからです。最適化はプロバイダー(ウェブサイト側)で行われます。同様に、サイバースペース全体が遅いチップセット搭載の携帯電話に後退したとしても、検索エンジンのランキングはほぼ同じになります。なぜなら、必要な最適化はウェブコンテンツを提供するサーバー側で行われるからです。

もちろん、JavaScript 駆動の SPA である Discourse は、ロード後にモバイル端末が速ければより良く動作します。それは他のすべてのウェブサイトも同様です!一般的に、SEO においてはネットワークのパフォーマンスとサーバーのパフォーマンスが重要であり、ユーザー端末は重要ではありません。これは私の意見ではなく、科学的かつ工学的な事実です。JavaScript や EmberJS に対する私の意見や感情的な結びつきが、SEO の仕組みを変えることはありません。SEO に有効なのは、コンテンツとウェブアプリケーションのパフォーマンスです。

結論として、Google は高度な AI(主に人工ニューラルネットワーク)を使用して、ウェブコンテンツのランキングとインデックス付けを決定します。検索エンジン最適化は、Google の AI がサイトをどのようにランク付けし、サイトのパフォーマンス、そして「Google の AI へのアピール度」に基づいています。私たちが JavaScript や Ruby、Python をどれだけ愛し、提供するウェブアプリケーションの美しさや仕組みをどれだけ称賛しても、それは無関係です。除非 私たちのアプリケーションへの情熱が Google の AI にアピールし、Google の AI に適切に提示された独自のコンテンツを作成し、Google の AI がどのようにパフォーマンスを認識しているかが重要であり、私たちがどのようにパフォーマンスやコンテンツを認識しているかは重要ではありません。

私たちは自社のウェブサイトをランキング付けするのではありません。ランキング付けを行うのは Google の AI です。

Google は公に次のように述べています:

「コアアップデートの仕組みを考える一つの方法は、2015 年のトップ 100 映画のリストを作成したと想像することです。数年後の 2019 年にそのリストを更新すると、自然と変化します。かつて存在しなかった新しい素晴らしい映画が、候補として加わるようになります。また、いくつかの映画を再評価し、以前よりも高い位置に置くべきだと気づくかもしれません。リストは変化します。以前は上位にありながら順位を下げた映画が悪いわけではありません。単に、それらの前に来る価値のある映画が増えただけなのです」と Google は書いています。

同社は、コンテンツを評価する際に考慮すべき以下の質問リストを提供しました:

  • コンテンツは独自の情報、報道、調査、または分析を提供していますか?
  • コンテンツはトピックについて実質的かつ完全、あるいは包括的な説明を提供していますか?
  • コンテンツは、自明を超えた洞察に満ちた分析や興味深い情報を提供していますか?
  • コンテンツが他のソースを参照している場合、単にコピーしたり書き換えたりするのではなく、実質的な付加価値と独自性を提供していますか?
  • 見出しやページタイトルは、コンテンツを記述的で有益に要約していますか?
  • 見出しやページタイトルは、誇張や衝撃的な性質を避けていますか?
  • これはあなたがブックマークしたり、友人と共有したり、推薦したりしたいようなページですか?
  • 印刷された雑誌、百科事典、または本の中でこのコンテンツを目にする、または参照されると期待しますか?

これが SEO です。Google の中核事業は、機械がウェブサイトを評価し分類できるようにするアルゴリズムを作成することです。

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

「いいね!」 2

これは記録と矛盾しています。Google は Android デバイスから実際のページ読み込み時間を収集し、ページランキングに利用していることが分かっています。

「いいね!」 4

はい、しかしすべての Android デバイス(同じタイプの場合)は、すべてのウェブサイト(同じタイプの場合)に対して基本的に同じパフォーマンスを発揮します。つまり、webpacker や bundler を使用する JavaScript ベースのウェブサイトを最適化する場合、SEO の観点からは、同じく webpacker や bundler を使用する他の JavaScript SPA サイトすべてと競合することになります。

Google がこの情報を収集していないと言ったわけではありません。クライアントデバイスに焦点を当てるだけでは、SPA の SEO パフォーマンス問題が解決しないことを説明しようとしています。「潮が満ちればすべての船が浮かぶ」ように、圧縮された JavaScript を効率的に処理する高速で最適化された CPU は、同様のすべてのウェブサイトにおいて良好なパフォーマンスを発揮します。

つまり、SEO はサーバーサイド(上記で長時間にわたって詳細に記述した通り)にあり、クライアントサイドではありません。

これはよく知られている事実です。

ともあれ、ここではこの話題について議論したくありません。ありがとう。

Google は、現在および 2021 年に向けて、どの SEO シグナルを重要視しているかを明確に示しています。彼らはサイバースペース内の出来事や状況に基づいて、AI を絶えず再設計していきます。

「いいね!」 2

SEO の観点から言えば、確かに技術的に類似したサイトと競合することになります。

しかし、ビジネスの観点からは、技術に関係なく、自社の市場にある他のサイトと競合します。そのため、SEO の観点から「優れている」と見なされる技術への乗り換えを検討する人もいます。まさにそのような状況にある人々がいるのです。

「いいね!」 5