INP: FID に代わる新しい重要な指標
2024 年 3 月 12 日、Google は Core Web Vitals: FID (First Input Delay) の移行を完了しました。 そして終了し、INP (Interaction to Next Paint) に入ります。パネルの静かな変化 ただし、Google Search Consoleは、何百万ものサイトのSEOランキングに実際の影響を与えます。私によると Chrome ユーザー エクスペリエンス レポート (CrUX) のデータ、 ウェブサイトの 43% は依然として失敗しています INP「良好」しきい値（200ms未満）、よりも大幅に高い数値 FID に失敗したサイトの 30% に。
FID は、最初の入力までの遅延、つまりユーザーが入力してからどのくらいの時間が経過したかのみを測定しました。 ブラウザがそのイベントの処理を開始したときに初めてクリックされました。 最初のインタラクションのみを測定し、維持されなかったため、この指標を打ち破るのは簡単でした。 次の塗装のアカウントです。 INP は根本的に異なります。 応答性 全体的に セッションの全期間中、最終スコアとして選択します インタラクションの最悪のパーセンタイル。
何を学ぶか
- INP と FID の違い、および実際の応答性を測定する理由
- INP 良好/改善が必要/不良しきい値 (200ms / 500ms)
- Chrome DevTools、web-vitals.js、PageSpeed Insights を使用して INP を測定する方法
- INP を爆発的に増加させる 5 つの最も一般的な JavaScript パターン
- CrUX フィールド データと Lighthouse 合成データを解釈する方法
- 遅いインタラクションを見つけて修正するためのデバッグ ワークフロー
INP の測定対象: 技術的定義
INP は、訪問中のページに対するユーザーのすべての操作 (クリック、タップ、および キーを押します。インタラクションごとに、入力からの時間を測定します。 ブラウザ時のユーザーの 次のフレームをペイントします それを反映する その入力に対する視覚的な反応。この間隔を次のように呼びます。 インタラクションの待ち時間 3 つの部分で構成されています。
- 入力遅延: ブラウザがイベントの処理を開始するまでの経過時間 (メインスレッドがビジー状態だった)
- 処理時間: JavaScriptイベントハンドラの実行時間
- プレゼンテーションの遅延: ブラウザが新しいフレームをレイアウト、ペイント、合成するのにかかる時間
INP は、 98パーセンタイル セッション内のすべてのインタラクションのうち（または最悪の場合） インタラクションが 50 未満の場合は値）。平均値でも典型的な値でもなく、ほぼ最悪です。 これにより、INP は FID よりもレイテンシのスパイクに対してはるかに敏感になります。
INP しきい値
| 評価 | INP値 | SEOへの影響 |
|---|---|---|
| 良い | < 200ms | ランキングにプラスに貢献 |
| 改善が必要 | 200ミリ秒～500ミリ秒 | 中立、改善の余地あり |
| 貧しい | > 500ミリ秒 | Googleランキングペナルティ |
FID と INP: 大きな違い
FID から INP への移行が重要な変更である理由を理解するには、次のシナリオを検討してください。 電子商取引ページがあります。最初のロード時に、ユーザーは「カートに追加」をクリックし、 イベントは 50 ミリ秒で処理されます (優れた FID)。次に、ページに移動し、製品をフィルターし、 カテゴリのドロップダウンが開きます。この 2 番目のインタラクションは重い計算であるため、800 ミリ秒かかります。 メインスレッドで実行されています。
Con FID: スコアは 50ms でした - 良い.
Con INP: スコアは 800ms - 貧しい.
INP は、最初のクリックだけでなく、セッション全体にわたる実際のユーザー エクスペリエンスを反映します。 これが、優れた FID を持っていた多くのサイトが現在では問題のある INP を抱えている理由です。
INPの測定方法
1. Chrome DevTools - パフォーマンス パネル
INP を診断する最も正確な方法は、Chrome DevTools のパフォーマンス パネルです。 次のように進めます。
- DevTools (F12) を開き、タブに移動します。 パフォーマンス
- 赤い丸をクリックして録音を開始します
- 測定したいインタラクション (クリック、入力など) を実行します。
- 録音を停止する
- 表示されたパネルで、セクション内の赤いバーを探します。 インタラクション
- インタラクションをクリックすると、入力遅延、処理時間、プレゼンテーション遅延などの内訳が表示されます。
2. Web Vitals JSライブラリ（フィールドデータ）
図書館 web-vitals Google の機能を使用すると、本番環境でのユーザーの実際の INP を測定できます。
これをプロジェクトに追加し、データを分析エンドポイントに送信します。
import { onINP } from 'web-vitals';
onINP((metric) => {
// metric.value: il valore INP in millisecondi
// metric.rating: 'good' | 'needs-improvement' | 'poor'
// metric.entries: le PerformanceEventTiming entries
console.log('INP:', metric.value, metric.rating);
// Invia a analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'INP',
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
});3. PageSpeed Insights と CrUX
PageSpeed Insights の「フィールド データ」セクションには、ドメインの実際の CrUX データが表示されます。 CrUX データは、同期が有効になっている Chrome ユーザーに基づいていることに注意してください。 したがって、これらは Lighthouse の合成結果ではなく、実際のデバイスでの実際のエクスペリエンスを反映しています。 ハードウェア制御上で実行されます。
実験室データとフィールドデータ
「ラボ」モードの Lighthouse と PageSpeed Insights はミッドレンジのモバイル デバイスをシミュレートします 遅い 4G 接続では。 CrUX データ (フィールド データ) は、サイトの実際のユーザーを反映しています。 2 つの測定値間に 30 ～ 50% の差異があるのは正常です。フィールドデータを指標として使用する 主に SEO の決定に使用され、ラボ データは技術的なデバッグに使用されます。
高いINPを引き起こす最も一般的なパターン
1. メインスレッド上の長いタスク
INP が高くなる主な原因は、 長いタスク: JavaScript タスク
それは50ミリ秒以上続きます。それぞれの長いタスクはブラウザのメイン スレッドをブロックし、ブラウザの応答を妨げます。
ユーザー入力に。それらを識別する最も簡単な方法は、DevTools のパフォーマンス パネルです。
またはAPI PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.warn('Long Task rilevato:', {
duration: entry.duration,
startTime: entry.startTime,
});
}
}
});
observer.observe({ type: 'longtask', buffered: true });2. ヘビー イベント ハンドラー
大量の計算を同期的に実行するクリック ハンドラーは、INP が高くなる原因となることがよくあります。 典型的なパターンは、次のようなハンドラーです。
- メモリ内の大きな配列をフィルタリングまたは変換する
- DOM を大量にレンダリング (数百の要素を追加)
- 複雑なレイアウトを計算するか、ブラウザのリフローを強制する
- 大きな JSON を解析します
3. 反応/角度変化検出が最適化されていない
React や Angular のようなフレームワークでは、単一のイベントが変更検出サイクルをトリガーできます。 これにより、コンポーネント ツリー全体が再計算されます。複雑なコンポーネントの場合、またはメモ化がない場合 適切な場合、これには 100 ～ 400 ミリ秒かかる場合があります。
Angular では、解決策は次のとおりです。 ChangeDetectionStrategy.OnPush および信号の使用
粒度の高い反応性。 Reactでは、 React.memo, useMemo e useCallback
それらは重要なツールです。
4. サードパーティのスクリプト
分析、チャット ウィジェット、広告スクリプト、その他のサードパーティ スクリプトは、多くの場合、メインスレッドで実行されます。 入力への応答をブロックする可能性があります。それらを識別するには、DevTools の [パフォーマンス] パネルで サードパーティのドメインから発生した長いタスクを探します。
5. SSR フレームワークにおけるハイドレーション
SSR (Next.js、Angular Universal、Nuxt) を使用したアプリケーションでは、水和フェーズは次のようになります。 高価な。ハイドレーション中に、フレームワークはレンダリングされた DOM にイベント ハンドラーを再アタッチします。 サーバー側。このフェーズがユーザーの操作と重なると、INP に影響が生じます。
INP デバッグ ワークフロー
高 NPI を診断および修正するための推奨ワークフローは次のとおりです。
- 問題のある相互作用を特定する パフォーマンスパネルの使用 開発者ツールによる。 「インタラクション」セクションでレイテンシーが 200 ミリ秒を超えるインタラクションを探します。
- 内訳を分析する: 3 つのコンポーネント (入力遅延、処理、 プレゼンテーション）が最大ですか？
- 入力遅延の場合: その時点ではメインスレッドで何か別のものが実行されていました クリックの。タイムラインでインタラクションに先行する長いタスクを探します。
-
場合と処理時間: イベント ハンドラーが遅すぎます。
アメリカ合衆国
scheduler.yield()それらを打ち破る（次の記事を参照）。 - プレゼンテーションが遅れた場合: フレームのレンダリングが遅い。 スラッシング レイアウト、高価な CSS アニメーション、過剰な合成レイヤーを探してください。
INP と SEO: 本当の影響
Google は、INP を含む Core Web Vitals がランキング要素であることを認めています。重量 正確には公表されていませんが、経験的証拠は、INP が「悪い」から「良い」に移行することを示しています。 競合ページのランキングを 2 ～ 5% 向上させることができます。トラフィックのあるサイトの場合 これは、目に見えるトラフィックの増加につながります。
最優先事項は、すべてのメイン ページ (ホームページ、カテゴリ ページ、 製品ページ）を「良好」評価（< 200ms）にします。静的コンテンツ ページにはめったに INP の問題。問題は、複雑な対話型インターフェイスを備えたページに焦点を当てています。
次のステップ
INP の問題を測定して特定する方法がわかったので、次のステップは、次のステップです。
それらを修正します。このシリーズの次の記事では、その使用方法について説明します。 scheduler.yield()
長いタスクを分割し、ある対話と別の対話の間のメインスレッドを解放します。
レンダリング側については、LCP 最適化の記事で、 プレゼンテーションが遅れ、最初の重要なフレームのペイントが加速されます。
結論
INP は Web パフォーマンス測定におけるパラダイムシフトを表しています: それだけでは十分ではありません ページの読み込みが速いことも重要です 答え 全体を通して素早く セッションの継続時間。 INP の良好しきい値を満たさないサイトの 43% にはチャンスがある ユーザーエクスペリエンスとSEOランキングの両方を向上させる具体的な方法。
出発点は常に測定です: インストール web-vitals.js あなたの中で
実際のユーザー データを収集し、Chrome DevTools を使用してインタラクションを診断します。
問題。具体的なデータがなければ、情報に基づいて最適化の決定を下すことができません。