新しい 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 により、ページのライフサイクルにおけるすべてのインタラクションの認識ラグに関する集計測定が可能になります。INP により、ウェブページの読み込みと実行時の応答性をより正確に推定できるようになります。
FID は最初のインタラクションの入力遅延のみを測定するため、ウェブ デベロッパーが CWV 改善プロセスの一環として、その後のインタラクションを事前に最適化していない可能性があります。そのため、特にインタラクティビティの高いサイトは、この指標で高い評価を得るために、より一層の努力が必要になります。
フレームワークの役割
多くのウェブサイトは JavaScript を使用してインタラクティビティを提供しているため、INP スコアは主にメインスレッドで処理される JavaScript の量によって影響を受けます。JavaScript フレームワークは、最新のフロントエンド ウェブ開発に欠かせない要素であり、デベロッパーに JavaScript コードのルーティング、イベント処理、分割に役立つ抽象化を提供します。そのため、メディアクォータは、それを使用するウェブサイトの応答性とユーザー エクスペリエンスを最適化する上で重要な役割を果たします。
フレームワークは、ウェブサイトの FID を改善することで、応答性を向上させる措置を以前に講じている可能性があります。ただし、利用可能な応答性指標データを分析し、特定されたギャップに対処する必要があります。一般的に、INP の合格率は低く、測定プロセスの違いにより、追加のコード最適化が必要になります。理由を次の表にまとめます。
Chrome の Aurora チームは、オープンソースのウェブ フレームワークと連携して、デベロッパーがパフォーマンスや CWV 指標など、ユーザー エクスペリエンスのさまざまな側面を改善できるよう支援しています。INP の導入により、フレームワーク ベースのウェブサイトの CWV 指標の変更に備えることができます。CrUX レポートの試験運用版の応答性の指標に基づいてデータを収集しました。フレームワーク ベースのウェブサイトで INP 指標への移行をスムーズに行うための分析情報と対策事項をお伝えします。
応答性の試験運用版指標データ
INP が 200 ミリ秒以下の場合、応答性は良好です。CrUX レポートのデータと 2023 年 6 月の CWV テクノロジー レポートでは、一般的な JavaScript フレームワークの応答性に関する次の情報を確認できます。
この表は、レスポンシブ スコアが高い各フレームワークのオリジンの割合を示しています。数字は有望ですが、改善の余地は十分にあります。
JavaScript は INP にどのような影響を与えますか？
現場の INP 値は、ラボで測定された Total Blocking Time（TBT）とよく相関しています。これは、メインスレッドを長時間ブロックするスクリプトは INP に悪影響を及ぼす可能性があることを意味します。操作後に JavaScript を大量に実行すると、メインスレッドが長時間ブロックされ、その操作に対するレスポンスが遅れる可能性があります。スクリプトがブロックされる一般的な原因は次のとおりです。
最適化されていない JavaScript: 冗長なコードや、コード分割と読み込みの戦略が不適切だと、JavaScript の肥大化が起き、メインスレッドが長時間ブロックされる可能性があります。コード分割、プログレッシブ ローディング、長いタスクの分割により、レスポンス時間を大幅に改善できます。
サードパーティ スクリプト: サードパーティ スクリプトは、インタラクションの処理に必要ない場合もありますが（広告スクリプトなど）、メインスレッドをブロックして不要な遅延を引き起こす可能性があります。重要なスクリプトを優先することで、サードパーティ スクリプトの悪影響を軽減できます。
複数のイベント ハンドラ: すべてのインタラクションに関連付けられた複数のイベント ハンドラが、それぞれ異なるスクリプトを実行している場合、相互に干渉し、長時間の遅延が発生する可能性があります。これらのタスクの一部は重要ではなく、ウェブワーカーでスケジュール設定したり、ブラウザがアイドル状態のときにスケジュール設定したりできます。
イベント処理のフレームワーク オーバーヘッド: フレームワークには、イベント処理用の追加機能や構文が含まれている場合があります。たとえば、Vue は v-on を使用してイベント リスナーを要素に接続しますが、Angular はユーザー イベント ハンドラをラップします。これらの機能を実装するには、Vanilla JavaScript の上に追加のフレームワーク コードが必要です。
ハイドレーション: JavaScript フレームワークを使用する場合、サーバーがページの初期 HTML を生成し、ウェブブラウザでインタラクティブにできるようにイベント ハンドラとアプリケーション ステータスを追加することがよくあります。このプロセスを「ハイドレーション」と呼びます。JavaScript の読み込み時間とハイドレーションの完了時間によっては、読み込み時に負荷の高いプロセスになる可能性があります。また、ページがインタラクティブに見えるのに、実際にはインタラクティブでないこともあります。多くの場合、ハイドレーションはページの読み込み時または遅延（ユーザー操作時など）に自動的に行われ、タスクのスケジューリングにより INP や処理時間に影響する可能性があります。React などのライブラリでは、
useTransitionを利用して、コンポーネントのレンダリングの一部を次のフレームに配置し、コストの高い副作用を将来のフレームに残すことができます。そのため、クリックなどのより緊急の更新につながる遷移での更新は、INP に適したパターンになる可能性があります。プリフェッチ: 後続のナビゲーションに必要なリソースを積極的にプリフェッチすると、適切に行うことでパフォーマンスを向上させることができます。ただし、SPA ルートを同期的にプリフェッチしてレンダリングすると、この高負荷なレンダリングがすべて 1 つのフレームで完了しようとするため、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 データをアナリティクス サービスの一部として利用できるようにしています。
Angular: Aurora は Angular チームと提携して、サーバーサイド レンダリングとハイドレーションの改善を検討しています。また、イベント処理と変更検出の改善を検討し、INP を改善する予定です。
Vue と Nuxt.js: 主にスクリプトの読み込みとレンダリングに関連して、コラボレーションの可能性を探っています。
フレームワークは INP の改善をどのように考えていますか？
React と Next.js
startTransition と Suspense で実装された React.js の時間スライスを使用すると、選択的または段階的な水分補給を有効にできます。つまり、ハイドレーションは同期ブロックではありません。小さなスライスごとに行われ、いつでも中断できます。
これにより、INP が改善され、キー入力、遷移中のホバー効果、クリックに迅速に対応できるようになります。また、自動入力などの大きな遷移でも React アプリのレスポンシブ性を維持できます。
Next.js には、ルート遷移にデフォルトで startTransition を使用する新しいルーティング フレームワークが実装されています。これにより、Next.js サイト所有者は React のタイムスライスを実装し、ルート遷移の応答性を改善できます。
Angular
Angular チームは、INP にも役立つ可能性のあるいくつかのアイデアを検討しています。
- ゾーンレス: 初期バンドルのサイズと、アプリがレンダリングする前に読み込む必要があるコードを削減します。
- ハイドレーション: インタラクションのために起動する必要のあるアプリの量を制限するアイランド スタイルのハイドレーション。
- CD のオーバーヘッドを削減する: たとえば、変更検出の費用を削減したり、アプリのチェックを減らす方法を見つけたり、変更に関するリアクティブ シグナルを活用したりします。
- よりきめ細かいコード分割: 初期バンドルを小さくします。
- 読み込みインジケーターのサポートの改善: SSR の再レンダリング中、ルート ナビゲーション中、遅延読み込みオペレーション中など。
- プロファイリング ツール: インタラクション コストを把握するための優れたデベロッパー ツール。特に、特定のインタラクションの変更検出コストについて把握できます。
これらの機能強化により、応答性とユーザー エクスペリエンスの低下を招くさまざまな問題に対処し、フレームワーク ベースのウェブサイトの CWV 指標と新しい INP 指標を改善できます。
まとめ
INP スコアは、今後、ウェブサイトの応答性とパフォーマンスを改善するための指針として役立つと期待されます。2023 年には、既存の INP ガイドを基に、フレームワーク デベロッパー向けに実用的なヒントを提供していきます。そのために、Google は以下の取り組みを行っています。
- フレームワークとウェブ デベロッパーが INP のフィールドデータに簡単にアクセスできるようにチャネルを作成する。
- フレームワークを使用して、デフォルトで INP を改善する機能を構築します。
フレームワークをご利用のお客様が INP の最適化を始める際には、ぜひフィードバックをお寄せください。