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

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

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

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

開発者チュートリアルにあるように Boilerplate でプロジェクトを開始すると、100 でモバイルとデスクトップの両方について PageSpeed Insight で非常に安定した Lighthouse スコアが得られます。 lighthouse スコアのすべてのコンポーネントには、プロジェクトコードが使用するバッファーがあり、引き続き完全な 100 lighthouse スコアの境界内にあります。

プルリクエストのテスト

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

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

結果は、デスクトップよりも達成が困難な傾向があるため、モバイル 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：熱心

何かが起こる前に、画像がダウンロードを開始しないようにし、最初の CLS ールを避けるために、本体を（display:none で）非表示にする必要があることに注意することが重要です。

eager フェーズでは、最初のアクションは DOM ードを「飾る」ことです。読み込みシーケンスではいくつかの調整を行い、主にアイコン、ボタン、ブロック、セクションに CSS クラスを追加し、自動ブロックを作成します。 結果として得られるマークアップについて詳しくは、 マークアップ、セクション、ブロック、自動ブロックページを参照してください。

セクションがまだ読み込まれておらず、非表示のままであることを考慮して、本文を既に表示できます。

次に、このセクションの最初の画像である「LCP 候補 に優先して 最初のセクション全体」が読み込まれます。 理論的には、最初のセクションのブロック数が少ないほど、より高速に LCP を読み込むことができます。

LCP 候補とセクションのすべてのブロックが読み込まれると、最初のセクションが表示され、フォントの読み込みが非同期で開始されます。

これで eager 段階は終了です。

LCP

一般に、LCP はページの上部に表示される「ヒーロー」画像です。 この画像が読み込まれ、読み込みシーケンスでできるだけ早く表示されることを確認することが重要です（Eager フェーズを参照）。

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

多くの場合、LCP 要素はブロックに含まれており、ブロック .js および .css も読み込む必要があります。

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

2 つ目の接続（TLS、DNS など）の確立によって LCP ークフローに大きな遅延が生じるため、LCP ークフローが発生する前に 2 つ目のオリジンから読み込んだり、接続したりすることは強くお勧めしません。

クライアントに送信されるマークアップに、実際の LCP 要素が含まれていない場合があります。 これは、LCP 要素の間接参照またはルックアップがある場合（例えば、呼び出されたサービス、読み込まれたフラグメント、.json で実行する必要があるルックアップなど）に発生します。
このような状況では、ページの読み込みは、最初のブロックが DOM に必要な変更を加えるまで、LCP 候補（現在はページ上の最初の画像）を推測して待つことが重要です。

コンテンツに 2 つのヒーロー画像が含まれる場合は、デスクトップ用とモバイル用の 2 つがあります。 上記と同様に、正しい画像を LCP の候補と見なし、不要な画像を DOM から削除（モバイルデバイス上でデスクトップ画像を削除またはその逆）して帯域幅を消費する画像を読み込まないか、さらに悪い場合は、最初に不要な画像を LCP の候補として読み込むように「ヒーロー」ブロックを調整する必要がある可能性があります。

最後に、画像、ビデオ、長いテキスト以外の LCP を指定することもできます。これらのケースすべてについて、読み込みシーケンスと LCP 候補の計算方法を深く理解して、正しい最適化を行う必要があります。

フェーズ L：遅延

遅延 フェーズでは、合計ブロッキング時間（TBT）および最終的な最初の入力遅延（FID）に影響を与えないペイロードの部分が読み込まれます。

これには、次のセクションとそのブロック（JavaScriptと CSS）の読み込みや、loading="lazy" 属性に従って残りのすべての画像と、ブロックされていない他のJavaScript ライブラリの読み込みなどが含まれます。 怠惰フェーズは、通常、プロジェクトのニーズをカバーするために作成しようとしている様々なフェー blocks で発生するすべてです。

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

フェーズ D：遅延

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

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

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

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

ヘッダーとフッター

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

フォント

Web フォントは帯域幅に負担がかかり、https://fonts.adobe.com や https://fonts.google.com などのフォントサービスを介して別のオリジンから読み込まれることが多いので、LCP ージの前にフォントを読み込むのはほとんど不可能です。これが、直後に読み込まれる理由です。

デフォルトでは、AEM Boilerplate は、フォントの読み込み時に CLS れを避けるために font fallback テクニックを実装しています。 フォントを（アーリーヒント、h2-push またはマークアップを使用して）プリロードすると、逆効果になり、パフォーマンスに大きな影響を与えます。

ボーナス：スピードは緑

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

パフォーマンスに関する問題の一般的な原因

時間の経過と共に、パフォーマンスに悪影響を与えるアンチパターンのコレクションを収集しました。このドキュメントのベストプラクティスに準拠するには、回避する必要があります。

アーリーヒント/h2-push/pre-connect は、ネットワーク予算の一部です

本能的に、マークアップ処理が開始される前であっても、ブラウザーにできるだけ早く、できるだけダウンロードするように指示することは理にかなっています。 ただし、最終的な目標は、できるだけ早く訪問者に表示する安定したページを用意することです。 LCP のタイミングはそれの良いプロキシです。

経験則として、PageSpeed Insight を使用してモバイルで 100 を実行する LCP ールを取得するには、ネットワークの制約を設定します。その方法では、設定がほぼ帯域幅の制約を受けるため、100 KB を超えないネットワークペイロードを持つホストを 1 つだけ存在させることができます。 初期ヒント、h2-push および事前接続は、LCP ークフローに必要なく、パフォーマンスに悪影響を与えるリソースをダウンロードして削除することで、その帯域幅を消費します。

パス解決のためのリダイレクト

訪問者が www.domain.com をリクエストして www.domain.com/en にリダイレクトされ、その後リダイレクトのたびにペナルティを受け www.domain.com/en/home, 場合、パフォーマンスが悪影響を受けます。 これは、ラボの結果として RUM または CrUX を介して測定されるコア Web Vitals で主に見られます。デフォルトでは、PageSpeed Insights で、ラボテストからのリダイレクトオーバーヘッドが除外されています。

CDN クライアントスクリプトの挿入

このマークアップだけでなく、.aem.page と .aem.live の起源もパフォーマンスのために最適化されており、ペイロードのどの部分にも非常に注意し、リソースの読み込みシーケンスにも非常に注意しています。

一部の CDN ベンダーおよび設定では、帯域幅を消費するスクリプトが挿入されてブロック時間が発生してから、パフォーマンスに悪影響 LCP 与える場合があります。 これらのスクリプトは、無効にするか、LCP 後の読み込みシーケンスで適切に読み込む必要があります。

PageSpeed インサイトレポートの .aem.live ージオリジンと、顧客の CDN の前にある対応するサイト（例：実稼動サイト）の比較では、AEMの制御外で CDN によって生じる悪影響が示されます。

CDN TTFB とプロトコル実装の影響

CDN ベンダーによって、HTTP ペイロードの純粋な配信に対するプロトコル実装とパフォーマンス特性に違いがあります。 WAFやAEMのアップストリームにあるその他のネットワークインフラストラクチャなどの追加のツールも、パフォーマンスに悪影響を与える可能性があります。
PageSpeed インサイトレポートの .aem.live ージオリジンと、顧客の CDN の前にある対応するサイト（例：実稼動サイト）の比較では、AEMの制御外で CDN によって生じる悪影響が示されます。