INPの改善とは？サーチコンソールで「改善が必要」と出たら、PageSpeed InsightsとChromeで遅い操作を探す

Search Consoleの「ウェブに関する主な指標」を開いたら、INPの行に「改善が必要」と出ていた。LCPやCLSなら画像や表示のずれの話だと見当がつくのに、INPは何の数字なのかがよく分からない。文章を読んでもらうだけのブログで、なぜ操作への反応が悪くなるのかも、ぴんとこないかもしれません。

この記事は、Search ConsoleでINPの問題が出た個人ブロガーに向けて書いています。読み終えたときには、INPが何を測っているのか、「改善が必要」がどの範囲なのか、自分のブログのどこが重いのかをどの画面で探せばいいのかが分かるはずです。Googleの開発者向けサイト web.dev の4ページ、Search Consoleのヘルプ、Google 検索セントラルの公式ブログと「ページ エクスペリエンス」の説明は、2026年10月10日に日本語版と英語版の原文で確かめました。web.dev の日本語版はAIによる翻訳と注記されているので、引用はどれも英語版と同じ意味かを見ています。

レポートそのものの読み方、たとえば表に出たURLが似たページのグループの代表にすぎないことは、ウェブに関する主な指標レポートの見方は？URLグループとデータなしに書きました。この記事は、INPの行に問題が出たあとの話だけを扱います。

結論:「改善が必要」は急ぐ段階ではない。直すなら遅い操作を1つ見つけるところから

web.dev とSearch Consoleのヘルプに書かれていることと、そこから私が決めている進め方をまとめると、次の4つです。

• INPは、クリック・タップ・キー入力から次の画面の描画までの時間。スクロールやマウスを重ねるだけの動きは測りません
• 「改善が必要」は、200ミリ秒を超え500ミリ秒以下。Search Consoleのヘルプは、「低速」より重要度が低いものとして扱っています
• まずPageSpeed Insightsで実際の訪問者の数字を見て、原因はChromeの[パフォーマンス]パネルで探す。前者で分かるのは、問題があるかどうかまでです
• 疑う順番は、外から読み込んでいるスクリプトと埋め込み。web.dev が原因の例に挙げているのは、サードパーティのスクリプト、大きなDOM、時間のかかるイベント処理です

INPとは:操作してから、次の画面が描かれるまでの時間

web.dev のInteraction to Next Paint（INP）は、INPをこう説明しています。

INP は、ユーザーによるページアクセスの全期間中に発生するすべてのクリック、タップ、キーボード操作のレイテンシをモニタリングすることで、ユーザー インタラクションに対するページの全体的な応答性を評価するための指標です。最終的な INP 値は、最大時間を要したことがモニタリングされたインタラクションであり、外れ値は無視されます。
— web.dev「Interaction to Next Paint（INP）」

英語版は "INP is a metric that assesses a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions ..." です。ページを開いてから離れるまでの操作のうち、いちばん反応が遅かったもの(極端な外れ値は除く)がそのページのINPになる、ということです。

測る操作は、マウスのクリック、タッチ画面のタップ、キーボードのキー入力の3つだけです。同じページによると、マウスを重ねる(ホバー)、拡大する、スクロールする、といった動きはINPでは観測されません。記事を上から下へ読むだけならINPは測られず、目次を開く、メニューを押す、埋め込んだ動画の再生ボタンを押す、といった操作が対象になります。

1回の操作にかかる時間は、3つに分けて考えられています。INPの最適化のガイドの言い方では「入力遅延」「処理時間」「プレゼンテーション遅延」です。押されてから処理が始まるまでの待ち、処理そのもの、処理が終わってから画面に描かれるまで、の3つだと私は読んでいます。このあとChromeで原因を探すときも、この3つのどこが長いかを見ます。

読むだけのページでも関係はあります。同じガイドは「ウェブサイトによっては、インタラクションがほとんどないか、まったくない場合があります。」と、文章と画像が中心のページを例に挙げたうえで、「いずれの場合も、INP が高いとユーザー エクスペリエンスが損なわれる可能性があります。」と書いています。操作が少ないページでも、その少ない操作で待たされれば同じことです。なお、以前の指標 FID からINPに置き換わった経緯はページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書きました。

しきい値:200ミリ秒以下が良好、500ミリ秒を超えると低い

web.dev は、INPの目安を3段階で書いています。

INP が 200 ミリ秒以下の場合、ページは応答性が高いことを意味します。
INP が 200 ミリ秒を超え、500 ミリ秒以下の場合、ページの応答性は改善が必要です。
INP が 500 ミリ秒を超えている場合は、ページの応答性が低いことを意味します。
— web.dev「Interaction to Next Paint（INP）」

英語版は "below or at 200 milliseconds"(200ミリ秒以下)、"above 200 milliseconds and below or at 500 milliseconds"(200ミリ秒を超え500ミリ秒以下)、"above 500 milliseconds"(500ミリ秒超)で、日本語版と同じ範囲です。判定には、実際の訪問のうち75パーセンタイル、つまり4回に3回の訪問がその値か、それより速い値を使い、モバイルとパソコンを分けて見るよう勧めています。

Search Consoleのヘルプの表も、INPは200ミリ秒以下が良好、500ミリ秒以下が改善が必要、500ミリ秒を超えると低速で、数字は同じです。ヘルプは、まず「低速」を直すよう勧め、「改善が必要」は改善の余地はあるが「低速」より重要度が下がる、と書いています。3つの指標を並べた表と、レポートの値の日本語訳で気をつけたい点はウェブに関する主な指標レポートの見方は？URLグループとデータなしにまとめました。

手順1:PageSpeed Insightsで、実際の訪問者のINPを見る

最初に見るのは、実際にブログを開いた人の数字です。web.dev のフィールドで遅いインタラクションを見つけるガイドは、手元で記録する仕組みが無い場合の始め方として、こう書いています。

まず、PageSpeed Insights にウェブサイトの URL を入力します。URL を入力すると、その URL のフィールド データ（利用可能な場合）が INP を含む複数の指標について表示されます。
— web.dev「現場でゆっくりとしたやり取りを見つける」

「フィールド データ」は、実際の訪問者のChromeから集めたデータ(CrUX)のことです。続けて、切り替えボタンでモバイルとパソコンのINPをそれぞれ見られる、とあります。Search Consoleで問題が出たのがモバイルかパソコンかを確かめてから、同じほうを見てください。上下の欄が何を測っているかはPageSpeed Insightsの見方は？上の実際のユーザーのデータが先、下の点数はLighthouseの試験で毎回変わるに書きました。

INPのページによると、サイトが CrUX の対象なら、このデータは少なくともサイト全体(オリジン)の単位で、場合によってはURL単位でも取れます(日本語版は英語版の "origin-level picture" を「オリジン レベルの画像」と訳していますが、ここでの picture は画像ではなく様子のことです)。記事1本の数字が出ず、サイト全体の数字だけが出ることもある、ということです。

そして、このデータには限界があります。

ただし、CrUX では問題があるかどうかはわかりますが、問題の原因はわかりません。
— web.dev「Interaction to Next Paint（INP）」

英語版は "while CrUX can tell you if there is a problem, it can't tell you what caused the problem." です。PageSpeed Insights は遅いことは教えてくれても、どの操作が遅いかまでは教えてくれません。

もう1つ気をつけたいのは、操作をしないテストの数字です。INPのページは、ラボのツールの中にはページの読み込みだけを見て操作をしないためINPを報告しないものがある、と書き、その場合について「このような場合、合計ブロック時間（TBT）は INP の妥当なプロキシ指標になる可能性がありますが、それ自体が INP の代わりになるわけではありません。」としています。読み込み中にメインスレッドがどれだけふさがっていたかの手がかりにはなっても、INPそのものではない、という扱いです。

手順2:Chromeの[パフォーマンス]パネルで、読み込み中に操作してみる

原因を探す道具として web.dev が勧めているのは、Chromeのデベロッパーツールです。ラボで遅い操作を手で診断するガイドには「[パフォーマンス] パネルを初めて開くと、リアルタイムの指標ビューが表示されます。」とあります。この画面を開いたままページを操作すると、操作の記録が並び、INPに当たる操作が強調され、開くと3つの部分ごとの内訳が見られます。

もっと細かく見たいときの手順は、ガイドでは次のとおりです(要約)。

1. 調べたい記事をChromeで開く
2. デベロッパーツールを開き、[パフォーマンス] パネルに移る
3. パネルの左上の [記録] ボタンを押して、記録を始める
4. 調べたい操作をする
5. もう一度 [記録] ボタンを押して、記録を止める

記録した操作にマウスを重ねると、3つの部分のどこに時間がかかったかが表示されます。ガイドには「インタラクションの縞模様の部分は、インタラクションの時間が 200 ミリ秒を超えた時間を表します。」ともあり、縞模様が出ている操作が、良好のしきい値を超えた操作です(英語版の画面名は Performance panel・Record button です)。

どの操作を試すかについて、ガイドは、よく使われる流れに沿って操作すること、そしてメインスレッドがいちばん忙しくなりやすいページの読み込み中に操作することを挙げています。ブログなら、記事を開いた直後に、目次の開閉、メニューのボタン、埋め込んだ動画やSNSの投稿、記事内のボタンを押してみるのがそれに当たる、と私は考えています。手元のパソコンが速すぎて遅さが出ないときは、ガイドのとおり「物理デバイスがない場合は、Chrome DevTools で CPU スロットリング機能を有効にします。」で、処理の遅い端末に近い条件にして試します。

ブログで原因になりやすいもの:外から読み込むスクリプトと埋め込み

web.dev が挙げている原因の例

同じガイドは、INPが悪くなる原因をこう挙げています。

原因は多数考えられます。たとえば、メインスレッドで多くのタスクをスケジュールするサードパーティ スクリプト、DOM サイズが大きい、イベント コールバックに時間がかかっているなどです。
— web.dev「ラボでやり取りが遅い場合を手動で診断する」

英語版は "third-party scripts that schedule many tasks on the main thread, large DOM sizes, expensive event callbacks" です。ここでのサードパーティのスクリプトは、自分のサイトではなく、ほかの会社のサーバーから読み込んでいるスクリプトのことです。ガイドには、読者が押そうとした瞬間にサードパーティのスクリプトの処理が動いていた例の図もあり、「上の図では、ユーザーがページを操作しようとしたときにサードパーティ スクリプトからのタスクが実行されているため、入力遅延が長くなっています。」と説明されています。

読み込み中が特に危ないことは、最適化のガイドにも書かれています。「ページの読み込み中にインタラクションの入力遅延を延長する原因の 1 つに、スクリプトの評価があります。」。スクリプトはダウンロードしたあとも、中身を確かめて実行できる形にする作業が要り、それが重いとメインスレッドがふさがって、押しても反応が遅れます。

埋め込みの中の操作も、そのページのINPに入る

INPのページは、埋め込みについてもはっきり書いています。

インタラクションは、メイン ドキュメントまたはドキュメントに埋め込まれた iframe で発生します（埋め込み動画の再生ボタンをクリックするなど）。
— web.dev「Interaction to Next Paint（INP）」

読者には、どこからが埋め込みかは見えません。そのため、埋め込んだ動画の再生ボタンを押して反応が遅ければ、それも記事のINPとして数えられます。最適化のガイドによると、iframe にはそれぞれ独自のメインスレッドがありますが、INPはページ内の iframe も含めてページ単位で報告されます。動画の埋め込みを軽くする方法はブログにYouTubeを埋め込むとSEOに効く？貼る前に決めることと速度の影響に書きました。

広告やアクセス解析のタグは、私の読みではサードパーティのスクリプトに当たる

今回読んだ web.dev の4ページには、「広告」という語は出てきませんでした。ただ、ブログに貼る広告のコードや、SNSの埋め込み、アクセス解析のタグの多くは、ほかの会社のサーバーからスクリプトを読み込む作りです。私は、これらが web.dev の言う「サードパーティ スクリプト」に当たると読んでいます。Chromeで記録したときに、時間のかかっている処理がどのドメインから来たスクリプトかを見れば、自分のブログの部品か、外から来たものかの見当がつく、と私は考えています。

コードを書き換えられない書き手にできることは、使っていない埋め込みやタグを外すこと、そして外したら同じ手順で測り直すことだと私は考えています。広告は収益にかかわるので、外すかどうかは数字を見比べて決める話で、INPのためだけに一律に外すことは勧めません。

順位にどこまで効くかは、レポートの記事と同じ結論

INPが Core Web Vitals に入ったことは、Google 検索セントラルの2023年5月10日の公式ブログの末尾に、「2024 年 3 月 12 日更新: Interaction to Next Paint（INP）が FID に代わって Core Web Vital に組み込まれました。」と追記されています。同じ記事は、サイト所有者に Core Web Vitals の改善を強く勧める一方で、こうも書いています。

Search Console の Core Web Vitals レポートのデータやサードパーティの Core Web Vitals レポートの結果が良好な状態であっても、高いランキングが得られるとは限りません。
— Google 検索セントラル ブログ「INP を Core Web Vitals に導入」

英語版は "Good stats within the Core Web Vitals report in Search Console or third-party Core Web Vitals reports don't guarantee good rankings." です。改善を勧める文のほうは、日本語版が「検索結果でのランキングを上げ」と訳しているのに対し、英語版は "for success with Search"(検索での成功のために)で、日本語版のほうが強く読めます。

Googleは、検索セントラルの「ページ エクスペリエンス」の説明で「Google のランキング システムでは Core Web Vitals が使用されます。」と書く一方で、上の公式ブログでは良い結果でも上位表示は保証されないと書いています。この記事も、その両方を書いたウェブに関する主な指標レポートの見方は？URLグループとデータなしの結論を越えません。公式の文言の読み比べはページエクスペリエンスは順位に効く？公式がランキングで使うと名指ししている要素はCore Web Vitalsだけにあります。

直したあと、Search Consoleで[トラッキングを開始]を押しても、解決したと判断されるまでには28日間のモニタリングがあります(途中でどれか1つのURLで問題が出れば、その時点で未解決と判断されます)。検証の仕組みも、上のレポートの記事に書きました。

よくある質問

PageSpeed InsightsにINPが出てきません

INPのページは、INPが報告されない理由として、読み込まれたあと一度もクリック・タップ・キー入力がなかった、スクロールやホバーだけで操作された、操作をしない検索クローラーなどのボットだった、の3つを挙げています。訪問者の少ないページでは、実際の訪問者のデータ自体が足りないこともあります。その場合は、手順2のChromeでの確かめ方が使えます。

文章を読むだけのブログでも、INPは悪くなりますか

なりえます。INPは操作の数ではなく、行われた操作のうち遅いものを見るので、目次やメニューを1回押しただけでも、そのときメインスレッドがふさがっていれば遅くなります。最適化のガイドも、操作がほとんどないページを例に挙げたうえで、INPが高いとユーザー エクスペリエンスが損なわれる可能性がある、と書いています。

画像を圧縮すれば、INPも良くなりますか

今回読んだ web.dev のページは、INPの原因として画像の重さを挙げていませんでした。画像の重さが効くのは、主にLCP(いちばん大きい要素が表示されるまでの時間)のほうです。LCPと画像の話はブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるにまとめました。

スクロールが重いのは、INPに入りますか

入りません。web.dev のINPのページは、ホバー・ズーム・スクロールはINPでは観測されない、と書いています。ただし、スクロールの途中でタップやクリックが混じる操作は、その部分が測られることがあるともしています。

まとめ

• INPは、クリック・タップ・キー入力から次の画面の描画までの時間。いちばん遅かった操作(外れ値を除く)がそのページの値になる。スクロールやホバーは測らない
• 200ミリ秒以下が良好、200ミリ秒を超え500ミリ秒以下が改善が必要、500ミリ秒を超えると低い。Search Consoleのヘルプの表も同じ数字で、「改善が必要」は「低速」より重要度が低い
• PageSpeed Insightsの実際の訪問者のデータで、問題があるかをモバイルとパソコンで確かめる。原因はそこでは分からない
• 原因はChromeの[パフォーマンス]パネルで、読み込み中に目次・メニュー・埋め込みを操作して探す。縞模様の操作が200ミリ秒を超えたもの
• web.dev が挙げる原因の例は、サードパーティのスクリプト、大きなDOM、時間のかかるイベント処理。iframe の埋め込みの中の操作もINPに入る
• 順位については、Googleは検索セントラルの説明で Core Web Vitals を使うと書く一方、良好でも高いランキングは保証されないとも書いている

INPに手を入れるのは、遅い操作が見つかってからで十分です。それまでの時間は、すでに検索結果に出ている記事のうち、どれの中身やタイトルを直すかを決めるほうに回せます。

ここからは、私が作っているツールの宣伝です。

どの記事の中身やタイトルを直すかを決めるところを、自動でやるツールを作りました。Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けます。並び順は、通常判定 → 参考判定 → 本文中心の監査の順。前2つの中は CTR機会差の多い順、30回未満は表示回数の多い順です。 判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ 判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。このツールは、表示速度もINPもCore Web Vitalsも測りません。診断カードが本文を読むときも、スクリプトや埋め込み(iframe)は取り除いて文字だけを読むので、INPが遅いかどうかは分かりません。INPの確かめ方は、この記事の手順でPageSpeed InsightsとChromeを使って手で行ってください。表示回数が0の行は読み込み時に除くので、検索結果に出ていない記事は候補に出てきません。並べ替えるだけで、順位やクリック数が上がることを約束するものではなく、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。