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

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

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

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

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

測試您的提取請求

結果發現，Lighthouse分數一旦降低就很難改善，但如果您持續測試，就很容易將分數保持在100。

開啟專案的提取請求(PR)時，系統會使用專案說明中的測試URL來執行PageSpeed Insights服務。 如果分數低於100，AEM GitHub機器人會自動讓您的PR失敗，並會留出一些緩衝區來說明結果的波動性。

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

為何選擇Google PageSpeed Insights？

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

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

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

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

不過，請務必記住，您從PageSpeed深入分析得到的建議不一定能帶來更好的結果，尤其是您越接近Lighthouse分數100。

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

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

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

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

階段E：熱心

發生任何事件之前，請務必注意，內文必須隱藏（具有display:none），以確保沒有影像開始下載，並避免初始CLS。

在​ eager ​階段中，第一個動作是「裝飾」DOM：載入順序很少調整，主要是將CSS類別新增至圖示、按鈕、區塊和區段，並建立自動區塊。 請參閱標示、區段、區塊和自動封鎖頁面，以取得有關所產生標示的詳細資訊。

然後就可以顯示內文，因為區段尚未載入且保持隱藏。

然後，完整的第一節 ​會以指定給此節的第一個影像"LCP候選項"的優先順序載入。 理論上，第一個區段擁有的區塊越少，LCP的載入速度就越快。

載入區段的LCP候選和全部區塊後，就可以顯示第一個區段，而且字型可以開始非同步載入。

這會結束​ eager ​階段。

LCP

一般而言，LCP是顯示在頁面頂端的「主圖」影像。 務必儘快在載入序列中載入並顯示此影像（請參閱​ Eager ​階段）。

必須載入顯示真LCP所需的所有專案。 在專案中，這通常包含標籤、CSS樣式和JavaScript檔案。

在許多情況下，LCP專案包含在區塊中，其中區塊.js和.css也必須載入。

在LCP顯示於100kb以下之前保留彙總裝載是很好的經驗法則，這通常會導致LCP事件比1560毫秒更快（在PSI中在100處獲得LCP分）。 特別是在行動裝置上，網路的頻寬往往受到限制，因此在LCP之前變更載入順序將影響最小或沒有影響。

強烈建議不要在LCP發生之前從第二個來源載入或連線到第二個來源，因為建立第二個連線（TLS、DNS等）會對LCP增加顯著的延遲。

在某些情況下，傳輸至使用者端的標籤中不包含實際的LCP元素。 當LCP元素有間接或查詢（例如呼叫的服務、載入的片段或需要在.json中進行的查詢）時，就會發生此情況。
在這些情況下，請務必在載入頁面時先猜測LCP候選專案（目前是頁面上的第一個影像），直到第一個區塊對DOM進行必要的變更為止。

在其他情況下，內容會包含2個主圖影像，一個用於案頭，一個用於行動裝置。 與上述相同，請務必確認正確的影像可視為LCP候選影像，且「主圖」區塊可能需要經過調整，以從DOM移除不必要的影像（移除行動裝置上的案頭影像，反之亦然），以免載入耗用頻寬的影像，或甚至更糟，先載入不必要的影像作為LCP候選影像。

最後，LCP可以是影像、視訊或長文字以外的內容……對於所有這些情況，都需要深入瞭解載入順序以及如何計算LCP候選者，才能進行正確的最佳化。

階段L：延遲

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

這包括載入下一個區段及其區塊(JavaScript和CSS)以及根據其loading="lazy"屬性和其他不會封鎖的JavaScript資料庫載入所有剩餘影像等內容。 延遲階段通常是您要建立之各種blocks中發生的所有事情，以符合專案需求。

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

階段D：延遲

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

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

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

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

頁首與頁尾

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

字型

由於網頁字型通常會對頻寬造成負擔，而且會透過https://fonts.adobe.com或https://fonts.google.com等字型服務從不同的來源載入，所以基本上無法在LCP之前載入字型，這就是為何會在之後載入字型的原因。

依預設，AEM樣板實作字型遞補技術，以在載入字型時避免CLS。 預先載入字型（透過早期提示、h2推送或標籤）將適得其反，並大幅影響效能。

額外優點：速度為綠色

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

效能問題的常見來源

長期下來，我們收集了會對效能產生負面影響的反模式集合，需要避免遵守本檔案的最佳實務。

早期提示/h2推播/預先連線是網路預算的一部分

直覺上，建議瀏覽器儘可能早地下載，甚至在標籤處理開始之前。 但請記住，最終目標是讓訪客儘快看到穩定頁面。 LCP計時是適合此用途的Proxy。

就經驗而言，若要透過PageSpeed Insight在行動裝置上取得LCP至100，網路限制的設定方式是只有一個主機具有不超過100kb的網路承載，因為設定主要是頻寬限制。 早期提示、h2推送和預先連線會透過下載LCP不需要的資源來消耗該頻寬，因此會對效能造成負面影響，必須移除。

路徑解析度的重新導向

如果訪客要求www.domain.com且被重新導向至www.domain.com/en然後又重新導向至www.domain.com/en/home,，他們每次重新導向都會受到罰款，亦即效能受到負面影響。 這大多顯示在透過RUM或CrUX測量的核心網頁動態中，因為實驗室結果中的PageSpeed Insights預設會從實驗室測試中排除重新導向額外負荷。

CDN使用者端指令碼插入

我們的標籤，以及我們的.aem.page和.aem.live來源已針對效能最佳化，我們對裝載的任何部分以及資源的載入序列都極為小心。

有些CDN廠商和設定會插入佔用頻寬和建立封鎖時間的指令碼，而這會在LCP之前對效能造成負面影響。 應停用這些指令碼，或在LCP之後以載入順序適當載入。

比較PageSpeed Insight報告的.aem.live來源與客戶CDN前面的對應網站（例如生產網站），將會顯示在AEM控制範圍以外的CDN所產生的負面影響。

CDN TTFB和通訊協定實作影響

根據CDN供應商，HTTP裝載的純傳送在通訊協定實作和效能特性上有所差異。 WAF等額外工具和AEM上游的其他網路基礎架構也可能對效能產生負面影響。
比較PageSpeed Insight報告的.aem.live來源與客戶CDN前面的對應網站（例如生產網站），將會顯示在AEM控制範圍以外的CDN所產生的負面影響。