網頁效能，讓您的Lighthouse分數保持在100。

為了達到網站商業目標並提高網站訪客滿意度，了解網站體驗品質至關重要。

Adobe Experience Manager (AEM)已最佳化，可提供絕佳的體驗和最佳的網頁效能。 使用 Real Use Monitoring (RUM) — 實際使用監控(RUM) 作業資料收集、資訊會持續從欄位使用中收集，並提供重複使用實際效能測量的方法，無需等待CRuX資料顯示程式碼和部署變更的影響。 在RUM中收集的欄位資料通常與實驗室結果不同，因為實際裝置的網路、地理位置和處理能力遠比實驗室中的模擬條件更加多樣化。

此 Google PageSpeed Insight Service 被證明是出色的實驗室測量工具。 它可用來避免網站的效能和體驗分數緩慢降低。

如果您使用樣板來開始專案，如同在 開發人員教學課程，您將會在下列位置獲得非常穩定的行動版和案頭版PageSpeed Insight燈塔分數： 100. 在Lighthouse分數的每個元件上，有一些緩衝區可供專案程式碼使用，並且仍在完美範圍之內 100 燈塔分數。

測試您的提取請求

事實證明，在燈塔分數低的時候，很難提高其分數，但也不難將其保持在 100 如果您持續測試。

開啟專案的提取請求(PR)時，系統會使用專案說明中的測試URL來執行PageSpeed Insights服務。 如果分數低於，AEM GitHub機器人會自動讓您的PR失敗 100 略加緩衝，以解釋結果的不穩定性。

結果會針對行動Lighthouse分數，因為這些分數通常比桌上型電腦更難達成。

為何選擇Google PageSpeed Insights？

許多團隊和個人使用自己的設定來測量Lighthouse分數。 不同的團隊已開發自己的測試工具，並使用自己的測試工具搭配已設定的設定，作為持續監控和效能報告實務的一部分。

網站的效能會影響其在搜尋結果中的排名，這些排名會由crUX報表中的核心Web Vitals反映。 Google對於裝置資訊的相關平均組合（例如熒幕大小）以及這些裝置的網路效能有良好的控點。 但最終，SEO是決定網頁效能優劣的最終指標。 由於特定設定是移動目標，因此效能實務應與目前的全球平均裝置和網路特性保持一致。

因此，我們不是使用專案特定的設定進行Lighthouse測試，而是使用持續更新的設定，這被視為最新版Google中參考的行動和案頭策略的一部分 PageSpeed Insights API.

雖然有些開發人員覺得他們可以從其他測量Lighthouse分數的方法收集到額外的見解，以便能夠跨專案進行有意義且可供比較的效能對話，但需要有一種方法能普遍地測量效能。 在測量效能方面，預設的PageSpeed Insight Service是最具權威性、最廣為接受的實驗室測試。

不過，請務必記住，您從PageSpeed Insights取得的建議不一定會帶來更好的結果，尤其是您距離光源分數越近 100.

內建RUM資料收集所收集的核心Web Vitals (CWV)在驗證結果時扮演重要角色。 不過，對於細微的變更，結果的變異以及在短時間內缺乏足夠的資料點（流量），使得在大多數情況下取得統計上的相關結果變得不切實際。

三階段載入(E-L-D)

將網頁上的裝載分割成三個階段，相對而言是直接了當就能獲得乾淨的Lighthouse分數，並因此設定了絕佳客戶體驗的基線。

三階段載入方法會將頁面的裝載和執行分為三個階段

階段E：熱心

在 急切的 階段，為達到實際所需載入的一切 LCP 隨即載入。 在專案中，這通常包含標籤、CSS樣式和JavaScript檔案。

在許多情況下 LCP 元素包含在區塊中（通常由自動封鎖所建立），其中區塊 .js 和 .css 也必須載入。

區塊載入器會逐步解除隱藏區段，這表示必須為載入第一個區段的所有區塊 LCP 以顯示。 因此，在頁面頂端放入儘可能少的區段是可行的作法。

根據經驗法則，彙總裝載會保留在之前 LCP 會顯示在100kb以下，這通常會導致 LCP 事件速度比1560毫秒還快(LCP 在PSI中的評分為100)。 尤其是在行動裝置上，網路往往受到頻寬限制，因此變更之前的載入順序 LCP 影響最小或沒有影響。

從或連線到之前的第二個原點 LCP 強烈建議不要建立第二個連線（TLS、DNS等） 新增大幅延遲至 LCP.

階段L：延遲

在 延遲 階段，載入的承載部分不會影響總封鎖時間(TBT)和最終的第一次輸入延遲(FID)。

這包括載入區塊（JavaScript和CSS）以及根據其影像載入所有剩餘影像等 loading="lazy" 屬性和其他不會封鎖的JavaScript程式庫。 懶惰階段通常是發生在各種不同階段的一切 blocks 您即將建立以滿足專案需求。

在此階段中，仍建議您讓大量裝載來自相同來源且由第一方控制，以便視需要進行變更以避免對造成負面影響 TBT， TTI 和 FID.

階段D：延遲

在 已延遲 階段，載入對體驗沒有立即影響和/或不受專案控制且來自協力廠商的有效負載部分。 想想行銷工具、同意管理、擴充分析、聊天/互動模組等。 這些工具通常透過標籤管理解決方案進行部署。

請務必瞭解，為了將對於整體客戶體驗的影響降至最低，此階段的開始需要大幅延遲。 延遲階段應在LCP事件後至少三秒鐘，以便為其餘體驗時間留下足夠的時間，並讓其達成和解。

延遲階段通常會在中處理 delayed.js 會作為初始全面擷取指令碼，導致 TBT. 理想情況下， TBT 將問題從相關指令碼中移除，方法是在主要執行緒之外載入（在Web工作者中），或只是從程式碼中移除實際封鎖時間。 問題修正後，即可輕鬆將這些程式庫新增至延遲階段，並提早載入。

理想情況下，您的指令碼中不存在封鎖時間，這有時很難做到，因為常用的技術（如標籤管理員或建置工具）會建立大型的JavaScript檔案，在瀏覽器剖析這些檔案時封鎖這些檔案。 從效能的觀點來看，建議您移除這些技術，確定您的個別指令碼不會封鎖，並個別載入為個別的較小檔案。

頁首與頁尾

頁首及特別是頁尾不在的關鍵路徑指向 LCP，因此會在各自的區塊中非同步載入。 一般而言，不共用相同生命週期的資源（亦即會隨著編寫變更在不同時間更新）應儲存在不同的檔案中，以簡化來源與瀏覽器之間的快取鏈結，使其更有效率。 將這些資源分開，會增加快取命中率，並降低快取失效和快取管理的複雜性。

字型

因為網頁字型通常會對頻寬造成負擔，而且會透過如的字型服務從不同的來源載入 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.

額外優點：速度為綠色

建立快速、小而快速的網站不僅是為了提供轉換更好的卓越體驗，也是減少碳排放的好方法。