Lighthouse のスコアを 100 に保つ、web パフォーマンス。

Web サイトのエクスペリエンスの質は、web サイトのビジネス目標と訪問者の満足度を達成する上で重要です。

Adobe Experience Manager（AEM）は、優れたエクスペリエンスと最適な web パフォーマンスを提供するように最適化されています。 （を使用） 実使用監視（RUM） 運用データの収集は、フィールドでの使用から継続的に情報を収集し、CRuX データがコードとデプロイメントの変更の影響を示すのを待つ必要なく、実際の使用パフォーマンスの測定を繰り返し行う方法を提供します。 RUM で収集されたフィールドデータは、ラボでシミュレートされた条件よりも実際のデバイスのネットワーク、ジオロケーション、処理能力がはるかに多様であるため、ラボの結果から逸脱することが一般的です。

この Google PageSpeed Insight サービス は、優れたラボ測定ツールであることが証明されています。 これは、web サイトのパフォーマンスとエクスペリエンスのスコアが徐々に低下するのを回避するために使用できます。

ボイラープレートを使用してプロジェクトを開始する場合、次の例を参照してください。 開発者向けチュートリアルで、モバイルとデスクトップの両方について、PageSpeed Insight で非常に安定した Lighthouse スコアが得られます。 100. lighthouse スコアのすべてのコンポーネントには、プロジェクトコードが消費するバッファーがあり、完全な境界内に残っています 100 lighthouse のスコア。

プルリクエストのテスト

Lighthouse のスコアが低くなると、スコアを向上させるのは難しいですが、スコアを維持するのは難しくありません 100 継続的にテストする場合。

プロジェクトでプルリクエスト（PR）を開くと、プロジェクトの説明に記載されたテスト URL が PageSpeed Insights サービスの実行に使用されます。 スコアが以下の場合、AEM GitHub ボットは自動的に PR に失敗します 100 結果のボラティリティを説明するために少しバッファを持つ。

結果は、デスクトップよりも達成が困難な傾向があるため、モバイル Lighthouse のスコアに対するものです。

Google PageSpeed Insights を選ぶ理由

多くのチームや個人が、Lighthouse のスコアを測定するために独自の設定を使用しています。 様々なチームが独自のテストハーネスを開発し、継続的な監視とパフォーマンスレポートの一環として設定された設定を持つ独自のテストツールを使用しています。

Web サイトのパフォーマンスは検索結果のランキングに影響し、crUX レポートの「Core Web Vitals」に反映されます。 Googleは、関連するデバイス情報（画面サイズなど）の平均的な組み合わせと、それらのデバイスのネットワークパフォーマンスに関する優れたハンドルを持っています。 しかし、最終的に、SEO は、web パフォーマンスの良い点と悪い点の最終的な決定者です。 特定の構成が移動のターゲットであるため、パフォーマンスのプラクティスを、現在の平均的なデバイスおよびネットワーク特性に合わせてグローバルに調整する必要があります。

そのため、Lighthouse のテストにプロジェクト固有の設定を使用する代わりに、Googleの最新バージョンで参照されているモバイルおよびデスクトップ戦略の一部として見られる、継続的に更新された設定を使用します PageSpeed Insights API.

Lighthouse のスコアを測定する他の方法から収集できると一部の開発者が感じている追加のインサイトがあるかもしれませんが、プロジェクト間で有意義で同等のパフォーマンスの会話を行うには、普遍的にパフォーマンスを測定する方法が必要です。 デフォルトの PageSpeed Insight サービスは、パフォーマンスの測定に関して、最も権威があり、最も広く受け入れられているラボテストです。

ただし、PageSpeed Insights から取得するレコメンデーションは、必ずしもより良い結果につながるとは限らず、特に Lighthouse のスコアに近づくほど結果は良くなることを覚えておくことが重要です 100.

組み込み RUM データ収集によって収集されたコア CWV （Web Vitals）は、結果の検証に重要な役割を果たします。 しかし、わずかな変更を加えると、結果のばらつきや十分なデータポイント（トラフィック）の不足が短時間で発生するため、ほとんどの場合、統計的に関連性の高い結果を得ることは現実的ではありません。

三相負荷（E-L-D）

Web ページ上のペイロードを 3 つのフェーズに分割すると、クリーンな lighthouse スコアを達成し、優れたカスタマーエクスペリエンスのベースラインを設定することが比較的簡単になります。

3 段階の読み込みアプローチでは、ページのペイロードと実行を 3 つの段階に分けます

フェーズ E：熱心

が含まれる 熱心な フェーズ、true に読み込む必要のあるすべて LCP が読み込まれて表示されます。 プロジェクトでは、通常、マークアップ、CSS スタイル、JavaScript ファイルで構成されます。

多くの場合、 LCP 要素は、ブロックに含まれています（多くの場合、自動ブロックによって作成されます）。 .js および .css また、読み込む必要があります。

ブロックローダーは、セクションの非表示を徐々に解除します。つまり、最初のセクションのすべてのブロックを LCP が表示されます。 このため、ページの上部に必要なだけ含む小さなセクションを作成すると効果的な場合があります。

の前に集計ペイロードを保持するのは、経験則として適切です LCP が 100 kb 未満で表示される。通常、この場合、 LCP イベントが 1560 ms より高速（LCP 100 でのスコアリング（PSI））。 特にモバイルでは、ネットワークの帯域幅が制限される傾向があるため、読み込みシーケンスを変更する必要があります LCP 影響は最小限か、ありません。

前の 2 番目の接触チャネルからの読み込みまたは前の 2 番目の接触チャネルへの接続 LCP が 2 つ目の接続（TLS、DNS など）を確立している場合は、を使用しないことを強くお勧めします。 大幅な遅延を LCP.

フェーズ L：遅延

が含まれる 怠惰 フェーズでは、ペイロードのうち、合計ブロッキング時間（TBT）に設定し、最終的に最初の入力遅延（FID）に設定します。

これには、ブロック（JavaScript と CSS）の読み込みや、ブロックに従った残りのすべての画像の読み込みが含まれます loading="lazy" ブロックしない属性およびその他の JavaScript ライブラリ。 怠惰な段階は、通常、様々な中で起こるすべてのものです blocks プロジェクトのニーズをカバーするためにを作成します。

このフェーズでも、ペイロードの大部分が同じ接触チャネルから取得され、ファーストパーティによって制御されるので、への悪影響を避けるために必要に応じて変更を加えることができます TBT, TTI および FID.

フェーズ D：遅延

が含まれる 遅延 フェーズでは、エクスペリエンスにすぐに影響を与えない部分や、プロジェクトによって制御されておらずサードパーティから提供されている部分がペイロードに読み込まれます。 マーケティングツール、同意管理、拡張分析、チャット/インタラクションモジュールなどを考えてみましょう。 多くの場合、タグ管理ソリューションを通じてデプロイされます。

顧客体験全体への影響を最小限に抑えるには、このフェーズの開始を大幅に遅らせる必要があることを理解することが重要です。 遅延フェーズは、残りのエクスペリエンスが解決されるまでに十分な時間を残すために、LCP イベントの少なくとも 3 秒後にする必要があります。

遅延相は通常、以下の部位で処理される： delayed.js これは、を引き起こすスクリプトの最初のキャッチオールとして機能します TBT. 理想的には、 TBT 問題は、メインスレッド外（web ワーカー内）で読み込むか、コードから実際のブロック時間を削除するだけで、問題のスクリプトから削除されます。 問題が修正されると、これらのライブラリを遅延フェーズに容易に追加し、より早く読み込むことができます。

スクリプトにブロック時間がないことを理想としています。これは、タグマネージャーやビルドツールなどの一般的に使用されるテクノロジーでは、ブラウザーが解析しているためにブロックしている大きな JavaScript ファイルを作成するのが難しい場合があります。 パフォーマンスの観点からは、これらのテクニックを削除し、個々のスクリプトがブロックしていないことを確認して、別々の小さなファイルとして個別に読み込むことをお勧めします。

ヘッダーとフッター

ヘッダー、特にページのフッターは、へのクリティカルパスにありません LCP。これが、各ブロックに非同期で読み込まれる理由です。 一般に、同じライフサイクルを共有しないリソース（オーサリングの変更によって異なる時間に更新される）は、接触チャネルとブラウザの間のキャッシュチェーンをより簡単かつ効果的にするために、別のドキュメントに保管する必要があります。 これらのリソースを別々に保持すると、キャッシュヒット率が増加し、キャッシュの無効化とキャッシュ管理の複雑さが軽減されます。

フォント

Web フォントは帯域幅に負担がかかり、のようなフォントサービスを介して別のオリジンから読み込まれることがよくあります。 https://fonts.adobe.com または https://fonts.google.comを使用する場合、の前にフォントを読み込むのはほとんど不可能です LCP。そのため、通常はに追加されます lazy-styles.css およびが次の期間の後に読み込まれる LCP が表示されます。

LCP ブロック

場合によっては、実際の LCP 要素は、クライアントに送信されるマークアップには含まれません。 これは、インディレクションまたはルックアップがある場合（例えば、と呼ばれるサービス、読み込まれるフラグメント、で実行する必要があるルックアップなど）に発生します .json）に設定します。 LCP 要素。
このような状況では、ページの読み込みは、を推測して待機することが重要です。 LCP 最初のブロックが DOM に対して必要な変更を行うまでの候補（現在はページの最初の画像）。
ブロックする前に待機するブロックを特定するには LCP 読み込む、を含むブロックを追加する LCP 要素を LCP_BLOCKS 配列複写 scripts.js.

ボーナス：スピードは緑

高速で小規模かつ迅速にレンダリングする web サイトの構築は、コンバージョン率の高い優れたエクスペリエンスを提供するための優れたアイデアというだけでなく、炭素排出量を削減するための優れた方法でもあります。