INPスコアが赤色になったとしても、3つのフェーズのうちどれが時間を浪費しているかが分かるまでは、パフォーマンスの問題とは言えません。多くのチームはこの手順を省略し、キャッシュプラグインを購入したり、スクリプトの実行を遅延させたりして、75パーセンタイルが動かないのをただ見ているだけです。このガイドは、私たちが代わりに採用している意思決定ツリーです。Chrome UXレポートの数値が不合格だった場合、その原因となっている特定のハンドラー、スクリプト、またはサードパーティタグを特定するための7つの分岐があり、各分岐には明確なしきい値が設定されています。このガイドは、コンバージョン数とLighthouseスコアの両方を管理するフロントエンドのリーダーやグロースチーム向けに書かれています。
そのギャップは現実のものだ。2025年のウェブ年鑑では、 モバイル発信元の77%は良好なINPを有していた デスクトップでは97%、 モバイル発信元の48%が、3つのコアウェブバイタルすべてに合格した。 (HTTPアーカイブモバイルでまだ問題となっているのは、主にインタラクションの遅延であり、そのほとんどは診断可能です。
INPが測定するもの、そして密かに無視するもの
次のペイントへのインタラクションは、ページ訪問ごとに 1 つのインタラクション遅延を報告します。 75パーセンタイル あなたの起源全体にわたって。良いことは 200ミリ秒以下、改善が必要は200ms以上500ms以下、不良は500ms以上(web.devその定義には、デバッグ方法を変える3つの要素があります。
- クリック、タップ、キーの押下のみがカウントされます。ホバー、ズーム、 スクロールは計測されませんそのため、スクロールがぎこちないとページが壊れているように感じても、INPは緑色のままです。
- インタラクションが多いページでは、INP 50回ごとに最も高い相互作用を1回無視するそのため、まれに発生する壊滅的なインタラクションは、エンゲージメントの高いページでは隠れてしまい、エンゲージメントの低いページでは表面化する可能性がある。
- すべてのインタラクションは 入力遅延 (ハンドラーが実行される前に) 処理時間 (ハンドラーが実行されています) プレゼンテーションの遅延 (ハンドラーの後、フレームペイントの前)。これら3つは、エンジニアリング上の問題としてはほとんど共通点がありません(web.dev).
最後の点が、この方法全体の要点です。「INP」をデバッグしているわけではありません。3つのフェーズのうちの1つをデバッグしているのであり、それぞれに異なる修正方法があります。
ブランチ0:コードに触れる前に、番号が実在することを確認してください。
PageSpeed Insightsを開き、ラボスコアではなくフィールドセクションを確認してください。ラボツールではINPを測定できません。INPは実際のユーザーが何かを押す必要があるためです。オリジンにフィールドデータがない場合、パフォーマンスの問題ではなくトラフィックの問題であり、以下の内容はまだ当てはまりません。次に、モバイルとデスクトップを別々に取得してください。2025年には世界的に20パーセントポイントの差がありました。モバイルが赤でデスクトップが緑の場合は、ラップトップでのテストを中止してください。
分岐1:動作が遅くなるのは負荷がかかっている時ですか、それとも負荷がかかった後ですか?
フィールドに計測機器を設置する web-vitals アトリビューション構築。以下の4行でデータが得られます。
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});
タリアセン・ウェストにおける修復作業について attribution.loadState まず。ほとんどの悪い相互作用が負荷状態を伴う場合 ローディング or ドムインタラクティブユーザーがスクリプトの評価中にタップした場合:これは配信の問題であり、ハンドラーではなくバンドルとタグマネージャで修正する必要があります。問題のあるインタラクションが完全に読み込まれたページ全体に広がっている場合は、ブランチ2に進んでください。
ブランチ2:どのサブパートが時間を管理していますか?
歳入録 inputDelay, processingDuration (NAIST) と presentationDelay すべてのサンプルについて。私たちの作業ルール:サブパートが相互作用を所有するのは、それが以下を説明する場合です。 総INPの50%以上50% をクリアできない場合は、まず入力遅延のケースとして扱ってください。他の 2 つのケースを悪化させる原因は、通常、メインスレッドの拡散的な混雑です。
| 主要な下位部分 | まず調査する | 典型的な原因 | 最初の修正 |
|---|---|---|---|
| 入力遅延 > 50% | longAnimationFrameEntries 呼び出し元タイプ | 読み込み中のスクリプト評価、タイマー、まだ実行中の以前のインタラクション | サードパーティースクリプトを延期または削除する。バンドルを分割する。定期的な作業をスレッド外に移動する。 |
| 処理時間 > 50% | longestScript (NAIST) と totalScriptDuration | コストのかかるイベントハンドラが1つあり、完全な再レンダリングをトリガーする状態更新が行われる。 | ハンドラー内で処理を一時停止し、次のペイント後に非視覚的な処理を移動します。 |
| プレゼンテーションの遅延 > 50% | totalStyleAndLayoutDuration | 大規模なDOM、レイアウトの乱れ、重い requestAnimationFrame | DOMサイズを縮小し、適用する content-visibilityバッチスタイルの読み書き |
| いずれのサブパートも50%を超えない | 上記のすべて | 一般的なメインスレッドの混雑 | 入力遅延として扱い、再測定してから再分岐する |
ブランチ3:スクリプトに名前を付ける
帰属情報構築では、各INPサンプルに加えて、ロングアニメーションフレームのエントリが含まれています。 attribution.longestScript このツールは、インタラクションの中で最も問題のあるスクリプトの呼び出し元、関数、およびソースファイルを提供します。 totalScriptDuration 5 ms を超えるすべての処理を集計します。ここで漠然とした「React が遅い」という問題がファイル パスに変わります。呼び出し元の種類を確認してください。 classic-script or module-script ロード時間評価のポイント、 user-callback or event-listener ロード後に実行される何か(オブザーバー、タイマー、アナリティクスリスナーなど)を指します(web.dev).
ブランチ4:それはあなたのものですか、それとも第三者のものですか?
スクリプトの帰属情報を発生元別に並べ替えてください。タグマネージャー、同意プラットフォーム、セッション記録ツール、チャットウィジェットは、クリックのたびにあなたのスクリプトよりも先に実行されるグローバルリスナーをインストールします。最悪のサンプルの4分の1以上にサードパーティの発生元が現れる場合は、技術的な対策よりも商業的な対策が重要です。タグのスコープを縮小するか、インタラクション時に読み込むか、サーバーサイドに移動してください。チャットウィジェットが結局費やす40ミリ秒を取り戻すためにハンドラーをリファクタリングしないでください。
分岐5:実験室で再現し、フレームを修正する
セレクターを attribution.interactionTargetご使用のフィールドデバイス構成に合わせてCPUスロットリングを調整したChrome DevToolsを開き、操作を記録します。 50ミリ秒長時間タスクの閾値(web.dev)、そしてそれをyieldによって分割します。
船 scheduler.yield() フォールバック付き。ChromeとEdgeは129から、Firefoxは142からサポートしていますが、 SafariはデスクトップでもiOSでも、MDN はベースラインではなく限定的な利用可能性を示します (DND, 使ってもいいですか) iOS シェアが大きいトルコや湾岸地域のユーザー向けには、 setTimeout フォールバックは必須です。
ブランチ6:実際に販売している市場を測定する
グローバルなCrUX平均値は、あなたに報酬を支払う市場を隠しています。CrUX BigQueryデータセットは国別のテーブルを公開しています。 chrome-ux-report.country_tr.YYYYMM トルコの場合、2文字の国コードであればどの国コードでも同じパターンで、デバイスのフォームファクターと有効な接続タイプを寸法として毎月更新されます(開発者向け Chrome) 公開されている CrUX API は国を公開していないため、このスライスは BigQuery 専用です。
販売先市場ごとに、オリジンを国別テーブルと照合してください。トルコ、ドイツ、湾岸諸国にサービスを提供する小売業者は、デバイス構成やネットワーク状況が異なるため、1つのコードベースから3つの異なるINP分布が見つかることがよくあります。オフィスがある市場ではなく、収益のある市場に合わせて調整してください。
ブランチ7:何かが動いたことを証明する
この修正は、展開ではなく実験として扱ってください。 トレンディオールトルコのマーケットプレイスでは、963 ms のモバイル INP を、React コンポーネント内の IntersectionObserver コールバックによって引き起こされた 700〜900 ms のタスクに追跡し、状態の更新を遅延させました。 scheduler.yield()6か月間で75パーセンタイルINPを約1,400msから約650msに短縮した。A/Bテストでは、 セッションあたり、商品一覧から商品詳細ページへのクリック率が1%向上 (web.dev). レッドバス 遅延読み込みインタラクションを 870~900 ms から 350~370 ms に短縮し、テキスト入力インタラクションを 72% 改善し、 全体の売上高が7%増加 (web.dev).
正確な数値に注目してください。1%であって40%ではありません。ここで、訂正すべき数値が出てきます。
8.4%という数字には注意が必要だ
この分野で最もよく引用される数字は、モバイル速度が0.1秒向上すると、小売コンバージョンが8.4%、旅行が10.1%向上するというものです。これは、Googleが委託した55のデロイトによる実際の調査、37のブランド、30万以上のセッションから得られたものです(web.devしかし、ページ読み込み時間やサーバー遅延などの負荷指標を測定しました。 INPではないデータは2019年末の30日間を対象としており、対照群がないため、これは観察された相関関係であり、因果関係ではありません。このデータは予算に関する議論のきっかけとして活用すべきであり、インタラクション遅延の改善による投資収益を予測するために使用すべきではありません。
【社内データ必要:Switasのp75 INP導入前後のデータと、顧客エンゲージメントにおけるコンバージョン率の差。公開されている事例研究を、自社データに基づく証拠に置き換えるため。】
この意思決定ツリーが破綻する箇所
- トラフィックの少ない発信元。 データが薄い場合、75パーセンタイルはノイズです。テンプレートごとに週あたり約1,000回のインタラクションを下回る場合は、ラボでプロファイリングを行い、CrUXでの成果を検証できないことを受け入れてください。
- SafariとFirefoxのユーザーは非表示になります。 CrUXはChrome専用です。収益のかなりの割合がiOS Safari経由で発生している場合、INPデータは測定対象として十分に把握できていないユーザー層を表しています。
- スクロールの不具合は対象外です。 INPはスクロールを無視するため、このツリーでは、操作感は悪いがテストでは正常に動作する無限スクロールリストの問題を見つけることはできません。
- これは設計上の負債ではなく、レイテンシーを検出するものです。 分かりにくいフィルターパネルでの180ミリ秒のインタラクションは、このツリーでは認識できないUX上の問題です。
FAQ
INPはFirst Input Delayと同じものですか?
いいえ。FIDは、最初のインタラクションのハンドラが実行されるまでまでの遅延のみを測定します。INPは、ハンドラの実行とその後の描画を含め、訪問全体における代表的なインタラクションの完全なレイテンシをカバーします。
なぜ私のLighthouseスコアは正常なのに、INPスコアは赤色なのでしょうか?
Lighthouseはラボツールであり、INP(アクセス数)を測定することはできません。実際のユーザーが何かを押すという動作は存在しないためです。Total Blocking Timeなどの指標は、相関性が低い場合があります。代わりに、PageSpeed Insightsの該当フィールドを参照してください。
CrUXに修正プログラムが反映されるまでどれくらい時間がかかりますか?
CrUXは28日間のローリングウィンドウに基づいてレポートを作成し、BigQueryテーブルは毎月公開されます。約4週間後に部分的なシグナルが表示され、2回の月次リリース後に完全なデータが得られるようになります。
フレームワークに手を加えずにINPを修正することはできますか?
多くの場合そうです。Trendyolの解決策は、React 16.9で1つのコールバック内でyieldを使用することであり、アップグレードは不要でした。サードパーティタグの遅延もフレームワークに依存しません。
同意バナーはINPに影響しますか?
原因は2つ考えられます。1つは、バナー自体のスクリプトが読み込み中にメインスレッドを競合すること、もう1つは、同意の決定が直後に大量のタグ読み込みを引き起こすことです。同意後の最初のインタラクションは個別に測定してください。
RUMベンダーは必要ですか、それともweb-vitalsライブラリだけで十分ですか?
アトリビューション構築とビーコンエンドポイントがあれば、このツリーを実行するのに十分です。ベンダーが購入するのは、顧客維持率、セグメンテーション、ダッシュボードであって、より優れたアトリビューションデータではありません。
INP(検索エンジン最適化)はSEO対策のために最適化すべきか、それともコンバージョン対策のために最適化すべきか?
コンバージョンを目標にしましょう。コアWebバイタルはランキング指標ですが、Trendyolの1%、redBusの7%といった実績は、インタラクションの質を高める効果であり、それだけでも取り組みの正当性を証明しています。
自分のリスティングページでこれを実行してください
トラフィックが最も多いテンプレートを選択し、アトリビューション構築を組み込み、ブランチ0から7までを順番に実行します。国別スライスと実験デザインを含めた独自のフィールドデータに対してツリーを実行したい場合は、 ウェブパフォーマンスチーム まさにこの取り組みを行う。
ソース
- 次のペイントへのインタラクション (INP) — web.dev
- 次の描画に合わせてインタラクションを最適化する — web.dev
- 現場での遅いインタラクションを見つける — web.dev
- 長時間のタスクを最適化する — web.dev
- パフォーマンス — Web Almanac 2025、HTTPアーカイブ
- TrendyolがINPを50%削減した方法 — web.dev
- redBusがINPを改善し、売上を7%増加させた方法 — web.dev
- ミリ秒が数百万を生み出す — web.dev / 55 / デロイト
- BigQuery 上の CrUX — Chrome for Developers
- スケジューラ: yield() — MDN
- スケジューラ API: yield — caniuse
- web-vitals JavaScriptライブラリ — GoogleChrome/web-vitals







