2023 年のコアページメトリクスに関する我々の推奨事項

元のアドレス: https://web.dev/top-cwv-2023

何年にもわたって、パフォーマンスを改善する方法について Web 開発者に多くのアドバイスを提供してきました。

これらの各推奨事項は、個別に多くの Web サイトのパフォーマンスを向上させる可能性がありますが、推奨事項の完全なセットは確かに圧倒的であり、実際には、1 人の個人または Web サイトがそれらすべてに従うことは不可能です。

Web パフォーマンスが日常業務でない限り、どの推奨事項が Web サイトに最もプラスの影響を与えるかは明確ではない可能性があります。たとえば、重要な CSS を実装すると読み込みのパフォーマンスが向上することを読んだことがあるかもしれませんし、画像を最適化することが重要であることも聞いたことがあるかもしれません。しかし、両方の時間がない場合、どちらを選択するかをどのように決定しますか?

Chrome チームでは、この 1 年間、この質問に答えようと努めてきました。ユーザーのパフォーマンスを向上させるために開発者に提供できる最も重要なアドバイスは何ですか?

この質問に適切に答えるには、特定の提案の技術的な利点だけでなく、開発者がそれらの提案を実際に採用できる可能性に影響を与える人的および組織的要因も考慮する必要があります。言い換えれば、理論的には大きな影響を与える可能性のある推奨事項がありますが、実際にはそれらを実装するための時間やリソースを持っているサイトはほとんどありません. 繰り返しになりますが、いくつかの推奨事項は重要ですが、ほとんどのサイトはすでにこれらの慣行に従っています。

パフォーマンスに関する推奨事項は、次の点に重点を置いています。

現実世界への影響を最大化するためのアドバイス
ほとんどのサイトに関連し、適用可能なアドバイス
ほとんどの開発者が実装できるアドバイス

過去 1 年間、私たちは多くの時間を費やしてパフォーマンス提案の完全なスイートを見直し、上記の 3 つの基準に照らして各提案を (定性的および定量的に) 評価してきました。

この投稿では、Core Web Vitalsごとにパフォーマンスを改善するための最重要の推奨事項について概説します。

一、Largest Contentful Paint（LCP）

推奨事項の最初のセットは、最大のコンテンツが表示可能領域 ( LCP ) 内に表示されるまでの時間です。これは、読み込みパフォーマンスの尺度です。

今日の Web 上の全サイトのうち、LCPが推奨しきい値に達しているのは約半分だけです。

1. HTML ソースから LCP リソースが見つかることを確認します。

HTTP アーカイブの2022 Web Almanacによると、モバイルページの72%に LCP 要素として画像が含まれています。つまり、ほとんどの Web サイトでは、LCP 向けに最適化するには、それらの画像がすばやく読み込まれるようにする必要があります。

多くの開発者にとって、画像の読み込みにかかる時間は問題の一部に過ぎず、もう 1 つの重要な部分は、画像の読み込みが開始されるまでの時間であることを理解していない可能性があります。

実際、LCP 要素が画像であるページの39%には、 HTML ドキュメントソースからは検出できないソース URL が含まれていました。

つまり、これらの URL は、<img src="...">やなど<link rel="preload" href="...">、ブラウザーはこれらの URL をすばやく見つけて、すぐに読み込みを開始できます。

画像の読み込みを開始する前に、CSS または JavaScript ファイルが完全にダウンロード、解析、および処理されるまでページが待機する必要がある場合は、おそらく手遅れです。

原則として、LCP 要素が画像の場合、画像の URL は常に HTML ソースから検索する必要があります。これを可能にするためのいくつかのトリックは次のとおりです。

画像は、src または srcset 属性を持つ<img>要素読み込まれます。
- data-src など、レンダリングに JavaScript が必要な非標準属性は使用しないでください。常に遅くなります。ページの9%は、data-src の背後に LCP イメージを隠していました。
クライアント側レンダリング (CSR) よりもサーバー側レンダリング (SSR) を優先します。
- SSR は、完全なページ要素 (画像を含む) が HTML ソースコードに存在することを意味するためです。CSR ソリューションでは、画像を見つける前に JavaScript を実行する必要があります。
画像を外部の CSS または JS ファイルから参照する必要がある場合でも、<link rel="preload">タグを。
- インラインスタイルによって参照される画像は、ブラウザーのプリロードスキャナーでは検出できないことに注意してください。そのため、たとえ HTML ソースで見つかったとしても、他のリソースをロードするときに検出されないようブロックされる可能性があるため、このようなます場合

LCP 画像に発見可能性の問題があるかどうかを理解するのに役立つように、Lighthouse はバージョン 10.0 (2023 年 1 月予定) で新しいインスペクターをリリースしています。

LCP リソースを HTML ソースから確実に発見できるようにすることで、測定可能な改善がもたらされ、リソースに優先順位を付ける機会がさらに開かれます。これが次の推奨事項です。

2. LCP リソースが最初にロードされていることを確認します

LCP リソースが HTML ソースから検出可能であることを確認することは、 LCP リソースの読み込みを早期に開始できるようにするための重要な最初のステップですが、もう 1 つの重要なステップは、リソースが最初に読み込まれ、重要度の低いリソースの後にキューに入れられないようにすることです。 .

たとえば、LCP イメージがの標準プロパティ<img>に、その前にスタックがある場合でも<script>、スクリプトのロードが完了した後にイメージをロードする必要があります。

これを修正する最も簡単な方法は<img>、 LCP イメージをロードするまたはに<link>新しいfetchpriority="high"属性を設定して、どのリソースの優先度が最も高いかに関するヒントをブラウザに与えることです。

これにより、これらのスクリプトが完了するのを待つのではなく、事前にロードするようブラウザに指示します。

Web Almanac によると、対象となるページの0.03%のみがこの新しい API を利用しています。つまり、Web 上のほとんどのサイトには、ほとんど作業をせずに LCP を改善する機会がたくさんあるということです。

fetchpriority 属性は現在 Chromium ベースのブラウザーでのみサポートされていますが、この API は漸進的な機能強化であり、他のブラウザーでは無視されるため、開発者は今すぐ使用することを強くお勧めします。

非 Chromium ブラウザーの場合、LCP リソースが他のリソースよりも優先されるようにする唯一の方法は、ドキュメントの前半でそれを参照することです。

前の例をもう一度使用すると、LCP リソースがこれらのスクリプトリソースよりも優先されるようにする場合は、これらのスクリプトの前に<link rel="preload" >タグをこれらのスクリプト<img>を以下の<body>に移動できます。

これは機能しますが、fetchpriority を使用するほど洗練されていないため、他のブラウザーがすぐにサポートを追加することを願っています。

LCP リソースの優先順位付けのもう 1 つの重要な側面は、loading="lazy"属性。

現在、ページの10%が実際に LCP イメージに設定されていますloading="lazy"。すべての画像に無差別に遅延読み込み動作を適用する画像最適化ソリューションには注意してください。

それらがその動作をオーバーライドする方法を提供する場合は、必ずそれを LCP イメージに使用してください。どの画像が LCP になるかわからない場合は、ヒューリスティックを使用して妥当な候補を選択してみてください。

重要でないリソースを延期することは、LCP リソースの相対的な優先順位を上げるもう 1 つの効果的な方法です。

たとえば、ユーザーインターフェイスをサポートしないスクリプト (分析スクリプトやソーシャルウィジェットなど) は、ロードイベントが発生するまで安全に延期できます。これにより、他の重要なリソース (LCP リソースなど) と競合しないことが保証されます。ネットワーク帯域幅用。

要約すると、LCP アセットが早期に読み込まれ、優先度が高いことを確認するには、次のベストプラクティスに従う必要があります。

LCP イメージのタグにfetchpriority="high"追加されます。<img>
- <link rel="preload">タグを介して LCP リソースがロードされても心配はいりません。まだ設定できるからですfetchpriority="high"。
LCP イメージの<img>タグloading="lazy"。
- これを行うと、画像の優先度が下がり、読み込みの開始が遅れます。
重要でないリソースを可能な限り遅らせます。
- 画像やiframe をドキュメントの末尾に移動してネイティブの遅延読み込みを使用するか、JavaScript を介して非同期に読み込みます。

3. CDN を使用してドキュメントとリソースを最適化する TTFB

最初の 2 つの推奨事項は、LCP リソースを早期に検出して優先順位を付け、すぐに読み込みを開始できるようにすることに重点を置いています。パズルの最後のピースは、最初のドキュメントの応答もできる限り迅速に届くようにすることです。

ブラウザーは、最初の HTML ドキュメント応答の最初のバイトを受信するまで、サブリソースを読み込むことができません。それが早ければ早いほど、他のすべての処理が早く開始されます。

この期間は Time To First Byte ( TTFB ) と呼ばれ、TTFB を短縮する最善の方法は次のとおりです。

地理的にできるだけユーザーに近い場所に配置してください。
このコンテンツはキャッシュされるため、最近リクエストされたコンテンツをすぐに再提供できます。

これら 2 つのことを達成する最善の方法は、CDNを使用することです。CDN は、世界中に広がるエッジサーバーにリソースを配布し、それらのリソースがネットワーク上を移動してユーザーに到達する距離を制限します。

CDN には、通常、サイトのニーズに基づいてカスタマイズおよび最適化できる、きめの細かいキャッシュコントロールもあります。

多くの開発者は CDN を使用して静的アセットをホストすることに慣れていますが、CDN は、動的に生成されたものであっても、HTML ドキュメントをキャッシュすることもできます。

Web Almanac によると、 HTML ドキュメントリクエストの29%のみが CDN によって処理されます。

CDN を構成するためのヒントを次に示します。

コンテンツがキャッシュされる時間を増やすことを検討してください。たとえば、コンテンツが常に最新であることが本当に重要ですか? それとも、数分で古くなっている可能性がありますか? .
コンテンツを無期限にキャッシュし、更新時にキャッシュをクリアすることも検討してください。
オリジンサーバーで現在実行されている動的ロジックを Edge Computingに移動できるかどうかを調べます。

一般に、コンテンツをエッジから直接提供できる場合 (オリジンサーバーへのアクセスを回避する場合) は常に、パフォーマンスが向上します。

オリジンサーバーに戻る必要がある場合でも、CDN は通常、それをより速く行うように最適化するため、どちらの方法でもメリットがあります。

二、累積レイアウトシフト（CLS）

次の一連の推奨事項は、Web ページの視覚的な安定性の尺度である累積レイアウトシフト時間 ( CLS ) です。

CLS は2020 年以降、ウェブ全体で大幅に改善されていますが、約 4 分の 1 のサイトがまだ推奨しきい値に達していません。

1. ページから読み込まれたコンテンツの明示的なサイズを設定する

通常、レイアウトシフトは、他のコンテンツの読み込みが完了した後に既存のコンテンツが移動するときに発生します。したがって、これを軽減する主な方法は、必要なスペースを可能な限り事前に予約することです。

サイズのない画像によるレイアウトのずれを修正する最も簡単な方法は、幅と高さのプロパティ (または同等の CSS プロパティ) を明示的に設定することです。

ただし、HTTP Archive によると、ページの72%には少なくとも 1 つのサイズ変更されていない画像があります。

サイズを明示的に指定しないと、ブラウザは最初にデフォルトの高さ 0px を設定し、画像が最終的に読み込まれてサイズが検出されたときに、顕著なレイアウトの変化を引き起こす可能性があります。

画像だけが CLS の要因ではないことを覚えておくことも重要です。レイアウトのシフトは、ページが最初にレンダリングされた後に読み込まれた他のコンテンツ (サードパーティの広告や埋め込みビデオなど) によって発生する可能性があります。

これには、縦横比プロパティが役立ちます。これは比較的新しい CSS 機能で、開発者が画像要素と非画像要素の縦横比を明示的に指定できるようにします。

これにより、動的な幅を (たとえば、画面サイズに基づいて) 設定し、ブラウザが適切な高さを自動的に計算できるようになります。これは、寸法のある画像の場合とほぼ同じです。

動的コンテンツは本質的に動的であるため、動的コンテンツの正確なサイズを知ることができない場合があります。ただし、正確なサイズがわからない場合でも、レイアウトシフトの深刻度を軽減するための措置を講じることはできます。

適切な最小の高さを設定することは、ほとんどの場合、ブラウザーが空の要素に対してデフォルトの高さ 0px を使用できるようにするよりも優れています。

min-height を使用すると、必要に応じてコンテナを最終的なコンテンツの高さまで拡張できるため、多くの場合簡単に修正できます。

2. ページが bfcache の条件を満たしていることを確認します

ブラウザは、バック/フォワードキャッシング (略してbfcache)と呼ばれるナビゲーションメカニズムを使用して、メモリスナップショットからブラウザの履歴の前後のページを即座に読み込みます。

bfcache は重要なブラウザーレベルのパフォーマンスの最適化であり、ページの読み込み中のレイアウトの変更を完全に排除します。多くの Web サイトでは、ほとんどの CLS が発生します。

それでも、bfcache の資格がない Web サイトが多数あり、多くのナビゲーションを取得する無料の Web パフォーマンスの最適化を逃しています。

メモリから復元したくない機密情報をページが読み込んでいる場合を除き、ページが適格であることを確認する必要があります。

Web サイトの所有者は、自分のページがbfcache の対象であることを確認し、そうでない理由に対処する必要があります。

Chrome にはすでにDevTools にbfcache テスターがあり、今年は、同様のテストを実行する新しい Lighthouse インスペクターと、この領域で測定するAPIを使用して、このツールを強化する予定です。

CLS セクションに bfcache を含めましたが、これまでで最大の改善が見られたため、bfcache は多くの場合、他のコア Web のバイタルも改善します。

これは、ページナビゲーションを大幅に改善するために使用できる多くのインスタントナビゲーションの 1 つです。

3. レイアウトを誘導する CSS アニメーションとトランジションプロパティを避ける

レイアウト変更のもう 1 つの一般的な原因は、要素のアニメーションです。たとえば、上部または下部からスライドインするバナーやその他の通知バナーは、CLS の要因となることがよくあります。

これらのバナーが他のコンテンツを邪魔にならないようにすると、これは問題になりますが、そうでない場合でも、それらをアニメーション化すると CLS に影響します。

HTTP アーカイブデータは、アニメーションをレイアウト遷移に決定的に関連付けることはできませんが、データは、レイアウトに影響を与える可能性のある CSS プロパティをアニメーション化するページは、ページ全体よりも「良い」CLS を持つ可能性が 15% 低いことを示しています。

一部の属性は、他の属性よりも CLS が悪いです。たとえば、余白や境界線の幅がアニメーション化されているページの CLS は、ページ全体が悪いと評価される割合のほぼ 2 倍の割合で「悪い」と評価されます。

レイアウトに影響を与える CSS プロパティを変換またはアニメーション化すると、レイアウトシフトが発生し、これらのレイアウトシフトがユーザーインタラクションから 500 ミリ秒以内に収まらない場合、CLS に影響するため、これはおそらく驚くべきことではありません。

一部の開発者は、要素が通常のドキュメントフローの外にある場合でも、これが当てはまることに驚くかもしれません。

上や左をアニメーション化するなどの絶対配置要素は、他のコンテンツをプッシュしていない場合でも、レイアウトをシフトさせます。

ただし、 top または left をアニメーション化する代わりにtransform:translateX()、transform:translateY()or をアニメーション化してもブラウザはページレイアウトを更新しないため、レイアウトの変更は発生しません。

ブラウザのコンポジタースレッドで更新できる CSS プロパティアニメーションを優先することは、長い間パフォーマンスのベストプラクティスでした。これは、作業を GPU にオフロードし、メインスレッドから切り離すためです。

一般的なパフォーマンスのベストプラクティスであるだけでなく、CLS の改善にも役立ちます。

原則として、ユーザーのクリックやキーストローク (ホバーは除く) に応答する場合を除き、ブラウザでページレイアウトを更新する必要がある CSS プロパティをアニメーション化または遷移させないでください。

また、トランジションとアニメーションには、可能な限り CSS transformプロパティを使用してください。

Lighthouse の[合成されていないアニメーションを回避] は、ページが潜在的に遅い CSS プロパティをアニメーション化する場合に警告します。

三、ファーストインプットディレイ（FID）

推奨事項の最後のセットは、ユーザーインタラクションに対するページの応答性の尺度であるFirst Input Delay ( FID ) に対応しています。これは、ユーザーが最初にページを操作してからブラウザがインタラクションに応答するまでの時間です。

現在、Web 上のほとんどのサイトは FID で高得点を獲得していますが、過去にFID 指標の欠点を文書化しており、ユーザーインタラクションに対するサイトの全体的な応答性を改善する機会がまだたくさんあると考えています。

私たちの新しい Interaction with Next Draw ( INP ) インジケーターは FID の後継となる可能性があり、以下の提案はすべて FID と INP に等しく適用されます。

FID よりも INP の方がサイトのパフォーマンスが悪いことを考えると、特にモバイルデバイスでは、FID が「良好」であるにもかかわらず、開発者はこれらの応答の提案を真剣に検討することをお勧めします。

1. 長時間のタスクを回避または中断する

タスクとは、ブラウザーが実行する個別の作業です。タスクには、レンダリング、レイアウト、解析、およびスクリプトのコンパイルと実行が含まれます。

タスクが長いタスク(つまり、50 ミリ秒以上) になると、メインスレッドがユーザー入力にすばやく応答できなくなります。

Web Almanac によると、開発者が長いタスクを回避または分割するためにできることはたくさんあります。

長いタスクを分割することは、この記事の他のいくつかの提案ほど労働効率的ではないかもしれませんが、ここで取り上げられていない他の手法よりも労働集約的ではありません.

JavaScript でできるだけ少ない作業を行うよう常に努力する必要がありますが、長いタスクを小さなタスクに分割してメインスレッドを支援し、レンダリングの更新やその他のユーザー操作をより迅速に行うことができます。

もう 1 つのオプションは、 isInputPendingとScheduler APIの使用を検討することです。

isInputPending は、ユーザー入力が保留中かどうかを示すブール値を返す関数です。true が返された場合、JavaScript の実行が中断され、ブラウザがそれらのユーザー入力を処理できるようになります。

スケジューラ API は、実行中の作業がユーザーに表示されるかバックグラウンドで行われるかを考慮した優先度システムに従って作業をスケジュールできる、より高度なアプローチです。

長いタスクを分割することで、対話や結果として生じるレンダリングの更新の処理など、ユーザーに表示される重要な作業をブラウザーが処理する機会が増えます。

2. 不要な JavaScript を避ける

間違いなく、今日の Web サイトはかつてないほど多くの JavaScript を送信しており、その傾向はすぐには変わらないようです。

あまりにも多くの JavaScript を送信すると、メインスレッドの注意を引くためにタスクが競合する環境が作成されます。これは、特に重要な起動期間中に、Web サイトの応答性に確実に影響します。

ただし、これは解決できない問題ではありません。いくつかのオプションがあります：

Chrome DevTools のカバレッジツールを使用して、ウェブサイトアセット内の未使用のコードを見つけます。
- 起動時に必要なリソースのサイズを削減することで、Web サイトがコードの解析とコンパイルに費やす時間を短縮し、最初のユーザーエクスペリエンスをよりスムーズにすることができます。
コード分割を使用して、これらのコードを個別のパッケージに移動します。
- カバレッジツールで見つかった未使用のコードは、起動時に実行されなかったために「未使用」とマークされることがありますが、将来の機能にはまだ必要です。
タグマネージャーを使用している場合は、定期的にタグをチェックして、タグが最適化されているか、まだ使用されているかを確認してください。
- 未使用のコードを含む古いタブをクリーンアップして、タブマネージャーの JavaScript をより小さく効率的にすることができます。

3. 大規模なレンダリングの更新を避ける

Web サイトの応答性に影響を与える可能性があるのは JavaScript だけではありません。

レンダリング自体がコストのかかる作業になる可能性があります。多数のレンダリングの更新が発生すると、サイトがユーザー入力に応答する機能が妨げられる可能性があります。

レンダリングジョブの最適化は簡単なプロセスではなく、通常は達成したい内容によって異なります。

それでも、レンダリングの更新が適切であり、長時間実行されるタスクに波及しないようにするためにできることがいくつかあります。

非視覚的な作業にrequestAnimationFrame()を使用しないでください。
- requestAnimationFrame() 呼び出しは、イベントループのレンダリングフェーズで処理されます。このステップで行われる作業が多すぎると、レンダリングの更新が遅れる可能性があります。
DOM サイズを小さく保ちます。
- DOM サイズは、レイアウト作業の強度と相関します。レンダラーが非常に大きな DOM のレイアウトを更新する必要がある場合、そのレイアウトを再計算するために必要な作業は大幅に増加します。
CSS コンテインメントを使用します。
- CSS コンテインメントは、CSS の content プロパティに依存しています。これは、contain プロパティによって設定されたコンテナに対してレイアウトがどのように機能するかをブラウザーに指示します。これには、レイアウトスコープの分離と DOM の特定のルートへのレンダリングも含まれます。
  これは必ずしも簡単なプロセスではありませんが、複雑なレイアウトを含む領域を分離することで、不要なレイアウトおよびレンダリング作業を回避できます。

結論は

ページのパフォーマンスを改善することは、特にウェブ全体に考慮すべきガイドラインがたくさんあることを考えると、大変な作業のように思えるかもしれません. ただし、これらの推奨事項に注意を払うことで、焦点と目的を持って問題に取り組み、できればサイトのコア Web 活力に変化をもたらすことができます。

ここに挙げた推奨事項は決して網羅的なものではありませんが、現在のウェブの状態を注意深く分析した結果、2023 年に主要なウェブ指標でサイトのパフォーマンスを改善するための最も効果的な方法であると確信しています。

さらに最適化のヒントが必要な場合は、以下のリストをご覧ください。

LCP の最適化
 CLS の
 最適化 FID の
 最適化 INP の最適化

—————————— 【本文終わり】 ——————————

最後に: 慣習は構成よりも優れている - ソフトウェア開発におけるシンプルさの原則

—————————— 【終了】 ——————————