INPとは？PageSpeed Insightsに出ない理由と、FIDとの違い
「PageSpeed InsightsでINPを探したが、どこにも見当たらない」と戸惑っていませんか？
INPは他の指標と違い、実際に誰かがページを操作しないと測れません。数値が出ないことには理由があります。
この記事では、INPが参考値に出ない理由、FIDから何が変わったのか、3つの区間の見方、WordPressで原因になりやすい箇所までを解説します。
数値が出ないときに何を見ればよいかが分かります。
INPとは、操作してから画面が変わるまでの時間
INPは Interaction to Next Paint の略です。利用者が操作してから、その反応が画面に現れるまでの時間を測ります。
ボタンを押したのに何も起きない。もう一度押してしまう。その体感を数値にしたものです。押した瞬間ではなく、見た目が変わるまでを1回分として数えます。
クリック・タップ・キー入力が対象
対象になる操作は3種類です。マウスのクリック、画面のタップ、キーボードの入力。この3つだけです。
1回の操作で、複数の処理が動くことがあります。ボタンを押すと、押した瞬間の処理、離した瞬間の処理、クリックとしての処理が順に走る。別々には数えず、INPはこれらをまとめて1回の操作として扱います。それぞれが50ミリ秒かかれば、合計で150ミリ秒です。
個々の処理が軽くても、重なれば基準を超えます。1つずつ見るのではなく、操作単位で見る必要があります。
身近な例では、質問をタップして回答が開くよくある質問の欄、画像を拡大する操作、絞り込みの条件を切り替える操作などが該当します。押した直後に画面が変わるものは、すべて対象と考えて構いません。
スクロールとホバーは含まれない
指を滑らせるスクロールや、マウスを乗せただけのホバーは対象外です。これらは連続的な動作で、始まりと終わりを区切れないためです。
ただし例外があります。キーボードのスペースキーやページダウンでスクロールした場合は、キー入力として計上されます。同じスクロールでも、操作の種類で扱いが変わります。
スクロールが引っかかる、という現象を感じている場合、それはINPの問題ではありません。別の原因を探すことになります。
200ms以内が良好、500ms超は改善が必要
基準は200ミリ秒以内が良好、500ミリ秒を超えると改善が必要です。その間は「改善の余地あり」となります。
判定は、直近28日間に実際にページを開いた利用者のうち、75%がその値に収まっているかで決まります。4人に1人が基準を超えていれば、不合格の扱いです。
INPはCore Web Vitalsの3指標の中で、最も基準を満たしにくい指標とされています。JavaScriptを多く読み込むサイトほど不利になります。
INPが参考値に出てこないのは正常
PageSpeed Insightsを開いて、INPが見当たらない。これは設定の誤りでも、測定の失敗でもありません。仕組み上、出ないのが正常です。
実際の操作がないと測れない
LCPやCLSは、ページを開くだけで測れます。読み込みの過程で起きることだからです。
一方のINPは、誰かがクリックしなければ発生しません。測定ツールがページを開いただけでは、測る対象そのものが存在しません。
そのため、INPは実際の利用者から集めたデータにしか現れません。この種のデータは、Chromeを使っている利用者から集められ、28日間分がまとめて集計されます。
参考値で代わりに見るのはTBT
参考値の欄には、代わりにTBTという指標が出ています。合計ブロック時間と表示されることもあります。
これは、読み込みの最中にブラウザが他の作業で手一杯だった時間の合計です。手一杯の時間が長いほど、操作しても反応が返りにくい。INPと直接の関係はありませんが、傾向としては連動します。
実測値のINPが出ていない段階では、このTBTを目安にします。TBTが長いなら、INPも悪い可能性が高いと考えて差し支えありません。
実測値がない場合の対処
アクセスの少ないサイトでは、実測値そのものが表示されないことがあります。集計に必要な件数が集まらないためです。
この場合、2つの方法があります。ひとつは、ドメイン全体のデータを見ること。ページ単位で足りなくても、サイト全体なら集まっていることがあります。
もうひとつは、自分で操作しながら測ることです。手順は次のようになります。
Chromeでページを開き、キーボードのF12で開発者ツールを出します。パフォーマンスのタブを選び、記録の開始を押してから、遅いと感じるボタンを実際に押します。数秒待って記録を停止すると、その操作が項目として並びます。
項目を選ぶと、待ち時間、処理、画面反映の3つに分けた内訳が表示されます。これは実際の利用者の値ではありませんが、遅い箇所の特定には使えます。CPUの速度を落とす設定を併用すると、性能の低い端末での状態に近づきます。
INPはFIDから何が変わったのか
INPは2024年3月に、FIDという指標を置き換えました。変わったのは、測る回数と、測る終点の2つです。
最初の1回から、すべての操作へ
FIDが見ていたのは、そのページで最初に行われた操作だけでした。2回目以降は対象外です。
これでは、読み込み直後さえ乗り切れば良い数値が出てしまいます。実際には、記事を読み進めた先で押したボタンが重い、という状況のほうが多い。そこで、INPはページを閉じるまでのすべての操作を対象にしました。
待ち時間だけから、画面が変わるまでへ
FIDが測っていたのは、操作してから処理が始まるまでの待ち時間だけでした。処理そのものにどれだけかかったかは見ていません。
反応が始まりさえすれば良い数値が出る。しかし利用者にとって重要なのは、画面が実際に変わることです。この点を踏まえ、INPは画面に変化が現れるまでを測ります。
この2点の変更で、基準を満たす難易度が上がりました。FIDでは良好だったサイトが、INPでは不合格になる例は珍しくありません。
50回を超えると最悪の1回は除外される
INPは「最も遅い1回」と説明されることが多いのですが、正確ではありません。
操作が50回以下のページでは、確かに最も遅い1回が採用されます。しかし50回を超えると、50回につき1回、最も遅いものが除外されます。100回の操作があれば、上位2件が除かれます。
操作の多いページでは、たまたま起きた1回の引っかかりで数値が決まってしまう。それを避けるための仕組みです。とはいえ、記事を読むだけのページで50回を超えることはまずありません。通常の記事ページでは、最も遅い1回がそのまま数値になります。
INPを3つの区間に分けて考える
INPも、LCPと同じように区間に分けられます。3つの区間のどこが長いかで、直す場所が変わります。
反応が始まるまでの待ち時間
操作した瞬間、ブラウザが別の作業をしていると、その作業が終わるまで反応できません。この待ち時間が1つ目の区間です。
読み込み直後に長くなりがちです。広告の読み込み、解析タグの初期化、スライダーの起動などが重なる時間帯だからです。この区間が長いなら、原因は押したボタンではなく、裏で動いている別の処理です。
処理そのものにかかる時間
2つ目は、その操作に対応する処理を実行している時間です。押されたボタンに紐づいたJavaScriptが動いている時間と考えて構いません。
ここが長い場合、処理そのものが重いということになります。一度に多くの要素を書き換えている、複雑な計算をしている、といった状態です。
対処は、処理を分けることです。押した直後に見た目だけ先に変え、重い処理はその後に回す。利用者は反応が返ったと感じるため、体感が変わります。
画面に反映されるまでの時間
3つ目は、処理が終わってから、画面に変化が現れるまでです。ブラウザが画面を描き直す時間です。
変更した箇所が多いほど、また構造が複雑なほど長くなります。処理は一瞬で終わっているのに反応が遅い、という場合はここを疑います。
WordPressでINPの原因になりやすい箇所
WordPressの場合、INPの原因はほぼ1つに集約されます。結論から書くと、原因はプラグインが読み込むJavaScriptです。
プラグインが積み上げるJavaScript
プラグインは、それぞれが独立してJavaScriptを読み込みます。10個入れれば10個分が積み上がります。
問題は、必要のないページでも読み込まれることです。お問い合わせフォームのプラグインが、フォームのない記事ページでもファイルを読み込んでいる。そうした状態がよくあります。読み込む量が増えるほど、ブラウザが手一杯になる時間も延びます。
まず、使っていないプラグインを停止します。次に、特定のページでしか使わないものを、そのページだけで読み込む設定にできないかを確認します。
どのプラグインが重いかは、開発者ツールのネットワークのタブで確認できます。読み込まれているファイルの一覧が出るので、プラグイン名を含むJavaScriptのファイルを探します。記事ページなのにフォームや予約機能のファイルが並んでいれば、そこが削れる余地です。
スライダーとポップアップ
目に見える形で重いのが、この2つです。
スライダーは、表示のために継続的な処理が必要です。画像を切り替え続けているあいだ、ブラウザは他の作業に手を回しにくくなります。ポップアップも、表示のタイミングを判定するために常に監視を続けています。
どちらも、それがなければ成立しないページでなければ、外す価値があります。スライダーで見せている情報は、並べて置いたほうが読まれることが多い。
プラグインを入れないという選択
当サイトはプラグインを1つも使っていません。必要な機能はテーマの中に書いています。
そのため、読み込むJavaScriptは自分で書いた1ファイルだけです。INPが問題になる余地が、構造上ほとんどありません。
すべてのサイトでこの構成が取れるとは考えていません。更新する人が複数いる、機能が頻繁に増えるといった条件では、プラグインのほうが現実的です。ただ、企業サイトのように内容が安定しているなら、選択肢として検討する価値はあります。
それでも改善しない場合
プラグインを整理しても数値が動かない場合、テーマ側のJavaScriptを疑います。スクロールに応じた演出、無限スクロール、常時動いているアニメーションが該当します。
これらは見た目の印象を良くしますが、操作への反応と引き換えになっていることがあります。演出を一時的に外して測り直せば、影響の大きさが分かります。
まとめ
INPが参考値に出ないのは、仕組み上そうなっているためです。この指標だけは、実際に誰かが操作しないと測れません。数値が見当たらないことを、設定の誤りだと考える必要はありません。
実測値が出ていない段階では、TBTを目安にします。出ている場合は、3つの区間のどこが長いかを見てから手を付けます。
そしてWordPressでは、原因のほとんどがプラグインのJavaScriptです。まず使っていないプラグインを停止し、スライダーとポップアップが本当に必要かを見直すところから始まります。
