この記事ではINPと、遅い操作を調べるためのINP Scanner Miltenの使い方を説明します。INPは2024年3月にCore Web VitalsのFIDを置き換えました。ラボテストが対象とするのは実行した操作であり、すべての訪問者の体験ではありません。
Interaction to Next Paint（INP）とは
INPは、訪問中のクリック、タップ、キー入力に対するページの応答性を評価します。操作の遅延には、入力の処理待ち、ハンドラーの実行、次の描画までの待ち時間が含まれます。FIDは最初の入力遅延のみを測定しましたが、INPは訪問全体の対象操作を考慮します。後続の非同期通信が完了するまでの全時間を測るものではありません。
INP の主な特徴:
- 集計方法： INPは平均値ではありません。通常は最も遅い操作を反映し、操作数が多い訪問では一部の外れ値を除外します。
- しきい値： 200ミリ秒以下は良好、200ミリ秒超から500ミリ秒以下は改善が必要、500ミリ秒超は不良です。実際の訪問は、モバイルとデスクトップを分けて75パーセンタイルで評価します。
- 対象操作： クリック、タップ、キー入力です。スクロールやホバー自体はINPの対象ではありません。
あなたにとって INP が重要なのはなぜですか?
1. ユーザーエクスペリエンス (UX)
表示の反応が遅いと、ボタンが動いていないように見え、繰り返し押されることがあります。具体的な操作と結果を測定してください。ページ読み込みに関する統計を、自分のサイトで測定したINPの直帰率への影響として扱うことはできません。
2. SEOと検索ランキング
INPは、Googleのランキングシステムで使われるCore Web Vitalsの一つです。良好な値が上位表示を保証するわけではなく、不良な値から一定の順位ペナルティを断定することもできません。内容の関連性や他の利用体験と併せて評価してください。
3. 競争上の優位性としてのスピード
すばやい表示の反応は、操作が受け付けられたことを伝えます。利用者にとって重要な課題を比較してください。同じ遅延でも、課題によって影響は異なります。
MiltenのINP Scannerを使う
INP Scannerは、制御されたブラウザー実行で応答性を調べるためのツールです。結果を一般化する前に、実行した操作とレポートの制約を確認してください。
1. テストした操作を確認する
代表的な手順を選び、実際に実行された操作を確認します。
- ボタンやリンクのクリック。
- 必要な入力欄でのキー入力。
- 要素に移動するためのスクロール。スクロール自体はINPの対象操作ではありません。
制御された実行は再現可能なシナリオであり、訪問者全員の端末での測定ではありません。ブラウザー、端末プロファイル、実際のテスト条件を記録してください。対象外の重要な手順は手動で補います。
2. 時間の内訳を読む
INPの測定にはEvent Timingのデータを使います。PerformanceObserverでは、対応しているeventエントリーを監視できます。この目的の汎用的なrenderエントリーはありません。web-vitalsなどのライブラリーが操作のグループ化とINPの計算を行います。
- 入力待ち、ハンドラー実行、描画待ちを区別します。
- メインスレッドの長いJavaScriptタスクを調べます。
- アニメーションの滑らかさは、関連する別の問題として確認します。
3. 指摘の原因を調べる
レポートに実際に含まれる証拠を使います。
- 記録された操作と対象要素を特定します。
- 遅い操作を調べます。600ミリ秒かかる「購入」ボタンは説明用の例であり、顧客サイトの測定値ではありません。
- ブラウザーのパフォーマンス記録で仮説を確認し、範囲を絞ったコード修正を試します。
自動テストの限界
- 現在の利用条件とレポートの項目を確認します。
- ブラウザーテストだけでは、訪問者の物理端末を検査したことにはなりません。
- 未実行の操作や不足データは未確認のまま扱い、取得できる場合は実際の訪問データで補います。
操作が遅くなる主な原因
1. 長いイベント ハンドラー
説明用の例です。関数とデータはアプリケーション側で定義する必要があります。
button.addEventListener('click', () => {
// Synchronous processing of 10,000 data rows
const result = heavyCalculation(data)
updateUI(result)
})
問題：同期処理のheavyCalculationがメインスレッドを占有し、次の描画を遅らせることがあります。 対策：処理を減らすか分割し、適した計算はWeb Workerへ移します。1回のsetTimeoutは同じ重い処理を後へ回すだけで、メインスレッドの外へ移すものではありません。
2. レンダリングをブロックする CSS/JS
例:
<link rel="stylesheet" href="large-styles.css" />
<script src="analytics.js" defer></script>
問題：描画を妨げるスタイルシートや重いスクリプト実行は、表示や入力を遅らせる場合があります。deferは実行時期を変えますが、処理の負荷は消しません。この例のCSSは画面に適用されます。media="print"だけでは画面用スタイルが適用されません。 対策の候補：
- 本当に重要なCSSのみをインライン化し、効果を測定します。
- 動的クラスと画面状態を確認してから未使用スタイルを削除します。PurgeCSSには適切な設定が必要です。
- 重要度の低いスクリプトを遅らせ、実行コストも減らします。
3. スローアニメーション
例:
@keyframes fade {
from {
opacity: 0;
transform: translateX(-100px);
}
to {
opacity: 1;
transform: translateX(0);
}
}
問題：opacityとtransformのアニメーションは効率的なことが多いものの、同時に多くの要素を動かすと、かくつく場合があります。 対策の候補：
- アニメーションを簡素化し、同時に動く要素を減らします。
- 必要な場合だけ、変更の直前に
will-change: transformを検討します。GPU利用を保証する設定ではなく、過剰な使用は資源を消費します。結果を測定してください。
4. レイアウトの再計算の繰り返し（layout thrashing）
例:
for (let i = 0; i < 100; i++) {
element.style.height = `${i}px`
console.log(element.offsetHeight) // Forces layout recalculation
}
問題：スタイルの書き込みとoffsetHeightなどの寸法の読み取りを交互に行うと、レイアウトの再計算が繰り返される場合があります。レイアウト計算と描画は別の処理です。 対策：
- 可能な限り、寸法の読み取りを先にまとめてから書き込みます。
- 適切な場合は
requestAnimationFrameで表示変更を予定します。ただし、同じ読み書きのループを中へ移すだけでは解決しません。
INPを向上させる方法: 5つの実践的なヒント
1. イベントハンドラーの最適化
- 長いタスクを分割し、
setTimeoutなど適切な仕組みで処理の間にブラウザーへ制御を返します。 queueMicrotaskは描画の機会を作りません。マイクロタスクの連鎖でページが止まり続ける場合があります。- ハンドラー内の即時処理を減らし、早く表示で応答します。
2. JavaScript バンドルのサイズを減らす
- 未使用のライブラリを削除します (Webpack Bundle Analyzer を使用するなど)。
- コード分割を適用してモジュールを動的にロードします。
3. デバウンスとスロットリングを使用する
課題に応じて、負荷の高い処理にdebounceやthrottleを使います。この例ではdebounceの定義またはインポートが必要です。入力欄そのものの反応は遅らせないでください。300ミリ秒は処理時期の例であり、INPの目標値ではありません。
const debouncedSearch = debounce((query) => {
fetchResults(query)
}, 300)
4. レンダリングの最適化
- 不要なDOMの複雑さを減らします。
- セレクターを原因と決めつけず、スタイルとレイアウトの処理時間を測定します。
- 画面外の領域には
content-visibility: autoを検討し、配置、フォーカス、アクセシビリティを確認します。
5. ローエンドデバイスでのテスト
可能なら代表的な低性能端末でも確認してください。開発者ツールではCPUを4倍遅くするなど、CPUや通信を制限した条件を試せます。これはラボ条件の例であり、サービスが固定の3G設定や物理端末を使用するという意味ではありません。
修正結果を確認する
公開後、同じ操作を同等の条件で繰り返します。時間だけでなく処理結果も確認してください。反応が速いカートにも、正しい商品が入る必要があります。
INP Scannerを提供するMiltenの結果も、次のように扱います。
- 確認した操作と不足している証拠を記録します。
- 同じ手順で修正前後を比較します。
- 実際の訪問は、その訪問データで評価します。良好なラボ結果が全利用者のINPを証明するわけではありません。
重要な遅い操作を一つ選び、原因の仮説を立て、限定した修正を試します。成功、失敗、未実行の確認を分けて記録してください。
詳しくはINPの測定ガイドとINPの最適化ガイドを参照してください。
