GoogleがDiscourseサイトでのNext Paint（INP）への遅いインタラクションについて不満を述べる

一般
1

こんにちは。まず最初に、私はSEOを追いかけたり、Googleのサイトの見栄えや機能に関する要求 好みに合わせるために労力を費やすような人間ではないことをお伝えしておきます。しかし、Googleから私のサイトが、間もなくランキングに大きく影響するようになる新しい「Core Web Vital指標」を改善する必要があるというメールを受け取ったことは知っておく価値があります。

こちらは、私のサイトよりもINP（372ms対208ms）の点で若干悪いDiscourse Metaのレポートです。

Screenshot from 2023-07-10 07-13-48
Screenshot from 2023-07-10 07-13-481179×716 71.4 KB

Discourseは基本的にJavaScriptのウェブアプリなので、これらの指標を改善するのは簡単ではないと想像します。しかし、Googleは、Moto G Powerフォンをエミュレートしていると主張しているにもかかわらず、ウェブクローラーが見ているJavaScriptなしのバージョンに基づいてランキングを決定しているようです…

Screenshot from 2023-07-10 07-27-38
Screenshot from 2023-07-10 07-27-381511×770 124 KB

…そのため、私はGoogleのアルゴリズムやランキングが決定することについて、あまり信じていませんし、あまり気にもかけていません。しかし、開発者やサイト管理者が認識しておく価値のある注意喚起です。

「いいね！」 6
2

こんにちは @rahim123 さん。INPの改善は、Discourseのページナビゲーションアニメーションを、ページ全体の「スピナー」からスライダーに変更する動機の一つです。この変更は先週Metaにのみ展開されたため、Googleのウェブバイタル調査データにその変更が表示されるにはまだ少し早すぎます。

しかし、データには引き続き注意を払い、必要に応じてさらに調整を検討しますのでご安心ください。

「いいね！」 12
3

返信ありがとうございます。この件に対応していただいているとのこと、安心しました。

Google のライブ URL テスター https://pagespeed.web.dev を使用しましたが、それはすでにランキングに含まれているはずではありませんか？また、Google は JavaScript を使用しないバージョンを見ているため、スピナーとスライダーをどのように考慮しているのか分かりません。INP は、同じウェブサイト内で別のページに移動することに関連しているのではないでしょうか？その場合、単一の URL に対してその指標をどのように測定しているのか、よく理解できません。ページアーキテクチャと Google の最新の気まぐれに関するこれらの些細なことについては、専門家から程遠いので、私の無知をお許しください。

「いいね！」 1
4

はい、「PageSpeed Insights」と Google の検索クローラーは Discourse の基本的な HTML バージョンを取得します。そのため、残念ながらこれらのオンデマンド ツールはあまり役に立ちません。

検索ランキングでは、Google はデスクトップおよび Android の Chrome ユーザーから収集された実際のデータを使用します。彼らはそのデータを Overview of CrUX  |  Chrome UX Report  |  Chrome for Developers で公開しています。残念ながら、収集から公開までに 1 ～ 2 か月の遅延があるため、この新しいローディング スライダーの実際の影響を確認するにはしばらく待つ必要があります。

ご自身のサイト（または Meta）の Google データを確認するには、ここ にアクセスしてドメインを入力してください: https://developer.chrome.com/docs/crux/dashboard/。レポートを読み込んだら、左側に INP のタブがあります。私の記憶が正しければ、Google は検索ランキングのために「モバイル」データを重視しているため、デバイス フィルターを使用してそれを調べる必要があります。

Meta のモバイル データ:

SCR-20230710-mzkj
SCR-20230710-mzkj1742×1642 236 KB

目標は少なくとも 75% の「良好」を達成することです。これは、Google が検索ランキングに使用する P75 INP 値が 200ms 未満であることを意味します。

「いいね！」 9
5

すごい、そんなものがあるなんて知りませんでした。説明ありがとうございます！

「いいね！」 3
6

データポイントとして、サイトが稼働して以来、discourse-loading-slider テーマコンポーネントのみを使用しています。まだ「改善が必要」ゾーンにいます。

image
image1080×687 100 KB

特に、Googleから主に匿名アカウントでアクセスされるページが最もパフォーマンスが悪いようです。私のフォーラムに固有の可能性もありますが、共有する価値があると思いました。

「いいね！」 4
7

デイビッド、それは大きな改善のように思えますが、私は古いスピナーも気に入っています :wink: この改善を可能にした、アプローチにおけるハイレベルな技術的変更点を教えていただけますか？どこかに文書化されていますか？

8

INPの改善についてですか？

古いスピナーの場合、シーケンスは次のようになります。

  1. リンクをクリックします。
  2. EmberはすべてのDOMを解体し、古いルートのコンポーネントをクリーンアップします。
  3. スピナーが画面にレンダリングされます。
  4. ネットワークリクエストが解決されると、新しいルートがDOMにレンダリングされます。

スライダーを使用すると、ステップ2をスキップします。スライダーは、高コストな解体プロセスを待つことなく、すぐにレンダリングされます。

ここで明確にしておくべきですが、デフォルトを切り替える主な動機はUXの向上です。INPメトリックの改善も良いですが、変更の主な理由ではありません。

「いいね！」 5
9

最も重要なのは認識であり、コンテンツをあまり早く削除しないのは素晴らしいことです。素晴らしい仕事です！

「いいね！」 1
10

INPがサイトランキングに影響を与えるのは2024年3月からであることを覚えておくことが非常に重要です。そのため、今日私たちが取り組んでいる改善は、Googleに影響が出始める前に繰り返し行うことができます。

「いいね！」 7
11

私も古いものにはかなり愛着があります。古いスピナー用のテーマコンポーネント（またはユーザー設定）は可能でしょうか？

「いいね！」 3
12

元に戻すためのシステム全体の設定があります：「ページ読み込みインジケーター」

13

本当ですが、新しいものが気に入っている人もいますし、彼らの設定を変更したくありません。

また、私の記憶が正しければ、その切り替えはすぐに削除される予定です。

「いいね！」 2
14

最近追加されたと思っていたのですが？

15

本当ですが、これを見てください。

「いいね！」 4
16

ご自身のドメインデータ（例：meta.discourse.org）については、Google Search Console の「エクスペリエンス」→「Core Web Vitals」→「モバイル（レポートを開く）」の中に、常に最新のレポートがあります。「INPの問題：200ミリ秒以上（モバイル）」までスクロールしてください。

grafik
grafik1178×396 29.3 KB

17
編集: これは低確率/高影響のスケールに近いです。INPはp75のみを考慮します。

INPは、Matomoコアまたはプラグインによる投稿後の「クッキング」（=読み込み時のJSによる機能拡張）手順の影響を受ける可能性があります。これらの手順は、大きな「レンダリングブロック時間」を持つ「重い」JSタスクを実行します。

特にユーザーが別のスレッドに切り替えると、一度に10〜20件の投稿が「クッキング」されます。

ここでは、個々の投稿のタスクを個別のsetTimeouts()に分割すると常に良いでしょう。これにより、ブラウザは個々のタスク間でペイントを実行でき、プロセス全体が完了するのを待つ必要がなくなります。

例：次のようなものです。

var initializeSliderSlickItem = function (item) {
  /* 実際の初期化をここで行う */
  var $this = $(item);
  […];
};

$('.slider-slick').each(function () {
  var item = this;
  setTimeout(initializeSliderSlickItem, 0, item);
});
18

本当ですか？トピックから別のトピックに移動すると、次のペイントはページ上部のローダーになります。これはすぐに始まります。

「いいね！」 1
19
編集：これは低確率・高影響のスケールに近いです。INPはp75のみを考慮します。

…そしてその後、クッキングが始まります。ユーザーがDiscourseのクッキングタスク実行中に何かをクリックした場合、GoogleはINPを次のペイントまでの時間として測定します。次のペイントは、実行中のクッキングタスクの完了時に最も早く現れる可能性があります。

web.dev: INP: What is an interactionを参照してください。

Ng0j5yaGYZX9Bm3VQ70c
Ng0j5yaGYZX9Bm3VQ70c1030×273 59.3 KB

「インタラクションのライフサイクル。入力遅延はイベントハンドラが実行を開始するまで発生します。これは、メインスレッドでのロングタスク（例：「クッキング」）などの要因によって引き起こされる可能性があります。その後、インタラクションのイベントハンドラが実行され、次のフレームが表示される前に遅延が発生します。」

Googleは、ページ全体のライフサイクルを通じて複数のブロックイベントが発生する場合、最も長いペイントブロッキング時間をINPに考慮に入れます。ライフサイクルは次のようになります。

  1. URLスレッド「A」が開く
  2. スピナーが表示される
  3. スレッド「A」でクッキング投稿
  4. クリック1：ユーザーがスレッド「B」へのリンクをクリックする
  5. スピナーが表示される
  6. スレッド「B」の読み込み
  7. スレッド「B」でクッキング投稿
  8. クリック2：スレッド「B」がまだクッキング中の間に、ユーザーがスレッド「C」へのリンクをクリックする
  9. スレッド「B」で実行中のクッキングアクションが完了する（<-- クリック2のINPにカウントされる）
  10. スピナーが表示される
  11. スレッド「C」の読み込み
  12. スレッド「C」でクッキング投稿
  13. …

web.dev: INP: What is an interactionも参照してください。

vNosnKDYgBRnFmEvwm0c
vNosnKDYgBRnFmEvwm0c1279×287 96.2 KB

「INPは、ユーザーがページを離れるときに計算され、ページ全体のライフサイクルを通じてページの全体的な応答性を表す単一の値になります。」

20

p75のメトリックを使用しているため、あなたが描いたシナリオを誰も本当に心配する必要がないのは良いことです。これは明らかにDiscourseとの通常のやり取りを代表するものではありません。

「いいね！」 2