新しい INP 指標が、JavaScript のフレームワークとライブラリを使用して構築したサイトのエクスペリエンスにどのように影響するかを把握できます。
Chrome の Chrome UX レポート レポートに、最近試験運用版の応答性に関する指標が新たに追加されました。この指標（現在は Interaction to Next Paint（INP））は、ページでのユーザー インタラクションに対する全体的な応答性を測定するものです。本日は、最新の JavaScript フレームワークを使用して作成されたウェブサイトが、この指標との関連でどのような位置づけにあるのかについてインサイトをお伝えしたいと思います。INP がフレームワークに関連する理由と、Aurora とフレームワークが応答性を最適化する仕組みについて説明します。
背景
Chrome では、Core Web Vitals（CWV）の一部として First Input Delay（FID）を使用して、ウェブサイトの読み込みの応答性を測定しています。FID は、最初のユーザー インタラクションから、インタラクションに接続されたイベント ハンドラをブラウザが処理できるようになるまでの待機時間を測定します。イベント ハンドラの処理、同じページ上での後続のインタラクションの処理、イベント コールバックの実行後に次のフレームを描画する時間は含まれません。ただし、ユーザーはページが読み込まれてから約 90% の時間を費やすため、ページのライフサイクル全体を通してユーザー エクスペリエンスにとって応答性が非常に重要です。
INP は、ウェブページがユーザー インタラクションに応答するまでに要する時間を測定し、ユーザーがインタラクションを開始してから次のフレームが画面に描画されるまでの時間を測定します。INP により、ページのライフサイクルで認識されるすべてのインタラクションのレイテンシを集計して測定できるようにしたいと考えています。Google は、INP によってウェブページの読み込み時間とランタイムの応答性をより正確に推定できると考えています。
FID で測定されるのは最初のインタラクションの入力遅延のみであるため、ウェブ デベロッパーは、CWV の改善プロセスの一環として、後続のインタラクションを積極的に最適化していない可能性があります。そのため、特にインタラクティビティが高いサイトでは、この指標で成果を上げるために懸命に取り組む必要があります。
フレームワークの役割
多くのウェブサイトは JavaScript に依存してインタラクティビティを提供しているため、INP スコアは主にメインスレッドで処理される JavaScript の量の影響を受けます。JavaScript フレームワークは、最新のフロントエンド ウェブ開発に不可欠な要素であり、ルーティング、イベント処理、JavaScript コードの区分けのための有用な抽象化をデベロッパーに提供します。したがって、それらを使用するウェブサイトの応答性とユーザー エクスペリエンスを最適化するうえで、中心的な役割を担っています。
フレームワークは、ウェブサイトの FID を早期に改善することで応答性を向上させるための措置を講じている可能性があります。ただし、利用可能な応答性指標データを分析し、特定されたギャップに対処する必要があります。一般的に、INP はパスレートが低い傾向があり、測定プロセスの違いにより、さらなるコード最適化が必要になります。次の表にその理由を示します。
Chrome の Aurora チームは、オープンソースのウェブ フレームワークを利用して、パフォーマンスや CWV の指標など、ユーザー エクスペリエンスのさまざまな側面を改善できるようデベロッパーを支援しています。INP の導入に伴い、Google はフレームワーク ベースのウェブサイトの CWV 指標の変化に備えたいと考えています。CrUX レポートの試験運用版の応答性指標に基づいてデータを収集しました。フレームワーク ベースのウェブサイトで INP 指標に簡単に移行できるように、分析情報とアクション アイテムを共有します。
応答性の指標データ（試験運用版）
INP が 200 ミリ秒以下は、優れた応答性を意味します。2023 年 6 月の CrUX レポートデータと CWV テクノロジー レポートでは、一般的な JavaScript フレームワークの応答性について次の情報が提供されています。
この表は、各フレームワークで応答性スコアが「良好」のオリジンの割合を示しています。数値は順調ですが、まだ改善の余地があることがわかります。
JavaScript が INP に与える影響
フィールドの INP 値は、ラボで観察された Total Blocking Time（TBT）とよく相関しています。これは、メインスレッドを長時間ブロックするスクリプトは、INP にとって不適切であることを示唆している可能性があります。インタラクションの後に JavaScript を大量に実行すると、メインスレッドが長時間ブロックされ、そのインタラクションに対するレスポンスが遅れる可能性があります。スクリプトがブロックされる一般的な原因は次のとおりです。
JavaScript が最適化されていない: 冗長なコードや不適切なコード分割、読み込み方法が原因で、JavaScript が肥大化し、メインスレッドが長時間ブロックされることがあります。コード分割、プログレッシブ読み込み、長いタスクの分割により、応答時間を大幅に短縮できます。
サードパーティのスクリプト: サードパーティのスクリプトは、インタラクションの処理に不要な場合があるため、メインスレッドをブロックして不要な遅延を引き起こす可能性があります。重要なスクリプトを優先することで、サードパーティ スクリプトの悪影響を軽減できます。
複数のイベント ハンドラ: すべてのインタラクションに複数のイベント ハンドラが関連付けられ、それぞれが異なるスクリプトを実行する場合、互いに干渉し合い、結果として長い遅延を引き起こす可能性があります。これらのタスクの一部は重要ではなく、ウェブ ワーカー上でスケジュールされる場合や、ブラウザがアイドル状態のときにスケジュールされる場合があります。
イベント処理のフレームワーク オーバーヘッド: フレームワークでイベント処理のための機能や構文が使用されている場合があります。たとえば、Vue は v-on を使用してイベント リスナーを要素にアタッチし、Angular はユーザー イベント ハンドラをラップします。これらの機能を実装するには、標準の JavaScript の上に追加のフレームワーク コードが必要です。
ハイドレーション: JavaScript フレームワークを使用している場合、ウェブページの初期 HTML をサーバーで生成することは珍しくありません。その場合、ウェブブラウザで操作できるように、イベント ハンドラとアプリケーションの状態を追加してこの HTML を補強する必要があります。このプロセスを水分補給と呼びます。JavaScript の読み込みにかかる時間やハイドレーションの完了にかかる時間によっては、読み込み時に負荷の大きいプロセスになることがあります。また、実際はそうではないにもかかわらず、インタラクティブに見えるページが表示される可能性もあります。ハイドレーションは、ページの読み込み中や（ユーザーの操作時などに）自動的に行われることが多く、タスクのスケジューリングにより INP や処理時間に影響を与える可能性があります。React などのライブラリでは、
useTransitionを活用することで、コンポーネントのレンダリングの一部を次のフレームに配置し、よりコストの高い副作用を将来のフレームに委ねることができます。したがって、クリックなどの緊急性の高い更新につながる移行中の更新は、INP に適したパターンになり得ます。プリフェッチ: 後続のナビゲーションに必要なリソースを積極的にプリフェッチすると、正しく行うことでパフォーマンスが向上する可能性があります。ただし、SPA ルートを同時にプリフェッチしてレンダリングすると、このような高コストのレンダリングはすべて単一のフレームで完了しようとするため、INP に悪影響を及ぼす可能性があります。これとは対照的に、ルートをプリフェッチせず、代わりに必要な処理（
fetch()など）を開始し、ペイントのブロックを解除します。フレームワークのプリフェッチに対するアプローチが最適な UX を実現しているかどうか、およびそれが INP にどのような影響を与えるか（存在する場合）を再検討することをおすすめします。
今後、優れた INP スコアを得るには、デベロッパーは、ページでのすべての操作の後に実行されるコードを確認し、チャンキング、リハイドレーション、読み込み戦略、ファーストパーティとサードパーティの両方のスクリプトについて、各 render() アップデートのサイズを最適化する必要があります。
Aurora とフレームワークは INP の問題にどのように対処していますか？
Aurora はベスト プラクティスを取り入れることでフレームワークと連携し、一般的な問題に対する組み込みソリューションを提供します。Google は Next.js、Nuxt.js、Gatsby、Angular と協力して、フレームワーク内に強力なデフォルトを設定してパフォーマンスを最適化するソリューションを開発してきました。この状況における Google の取り組みの要点を以下に示します。
React と Next.js: Next.js Script コンポーネントは、サードパーティ スクリプトの非効率的な読み込みに起因する問題に対処するのに役立ちます。Next.js では、共有コードのチャンクサイズを小さくするために、きめ細かいチャンクが導入されました。これにより、すべてのページでダウンロードされる未使用の共通コードの量を減らすことができます。また、Next.js と協力して、INP データを Analytics サービスの一部として利用できるようにする取り組みも行っています。
Angular: Aurora は Angular チームと提携し、サーバーサイド レンダリングとハイドレーションの改善に取り組んでいます。また、INP を改善するために、イベント処理と変更検出の改良についても検討する予定です。
Vue と Nuxt.js: Google は、主にスクリプトの読み込みとレンダリングに関して、コラボレーションの方法を検討しています。
フレームワークは INP の改善についてどのように考えていますか？
React と Next.js
startTransition と Suspense で実装される React.js のタイムスライシングを使用すると、選択型ハイドレーションまたはプログレッシブ ハイドレーションを選択できます。つまり、ハイドレーションは同期ブロックではありません。この処理は小さなスライスで行われ、いつでも割り込み可能です。
これにより INP が改善され、キー入力、遷移中のホバー効果、クリックにすばやく応答できるようになります。また、オートコンプリートなどの大規模な遷移であっても、React アプリの応答性を維持するのにも役立ちます。
Next.js は、ルートの遷移にデフォルトで startTransition を使用する新しいルーティング フレームワークを実装しています。これにより、Next.js サイト所有者は React タイムスライシングを導入し、ルート遷移の応答性を向上させることができます。
Angular
Angular チームは、INP にも役立ついくつかのアイデアを検討しています。
- ゾーンなし: 初期バンドルサイズを削減でき、アプリで何かをレンダリングする前に読み込む必要があるコードも削減できます。
- ハイドレーション: 操作のために起動する必要があるアプリの時間を制限するアイランド スタイルのハイドレーション。
- CD のオーバーヘッドを削減: たとえば、変更検出にかかる費用を抑え、アプリのチェックを減らす方法を見つけ、変更点に関するリアクティブ シグナルを活用します。
- より詳細なコード分割: 最初のバンドルを小さくします。
- 読み込みインジケーターのサポートの改善: たとえば、SSR の再レンダリング中、ルート ナビゲーション中、遅延読み込みオペレーションなどです。
- プロファイリング ツール: インタラクション コスト（特に特定のインタラクションの変更検出コスト）を把握するための優れた開発ツール。
こうした機能強化により、応答性やユーザー エクスペリエンスの低下につながるさまざまな問題に対処し、フレームワーク ベースのウェブサイトにおける CWV 指標と新しい INP 指標を向上させることができます。
まとめ
今後、INP スコアがウェブサイトの応答性とパフォーマンスを向上させるための優れたコンパスとなることが期待されます。既存の INP ガイドに基づいて、フレームワーク デベロッパー向けに実用的なヒントを 2023 年に提供する予定です。Google では、以下の方法によってこれを実現したいと考えています。
- フレームワークやウェブ デベロッパーが INP のフィールド データに簡単にアクセスするためのチャネルを作成する。
- フレームワークと連携して、デフォルトで INP を改善する機能を構築します。
INP の最適化に取り組むフレームワーク ユーザーの皆様からのフィードバックをお待ちしています。