確保電子商務站點的次秒載入時間是一項艱巨的工作。 在Layer0上，我們嘗試使它變得簡單得多，而Layer0將幫助您實現這一里程碑。 我們在這裏所做的是創建一個清單，您可以遵循這些清單，以確保您的生產站點速度極快，並且您花費的時間最少。
首先，讓我們來談談我們如何衡量速度：
衡量績效
**本例中我們使用了SpeedCurve (SC)，但您可以使用WebPageTest或任何其他產品
我們將重點放在測量的LCP指標上。 我們的目標是：
- 主頁<1.5s
- PLP至PDP導航：0.5s
還必須記住以下3個案例，因爲它會影響消費者在以下情況下的體驗 (a)由於有機搜尋流量，直接轉至公共圖書館/私人圖書館；及 (B)導航至購物車/結帳頁面時–從業務角度來看，這對我們的客戶至關重要：
- PLP作為登陸頁
- PDP作為登陸頁
- PWA ->原始/遺留(例如購物車/結帳)
讓我們從一些基本的檢查開始，這些檢查可以幫助我們獲得一些重大的速度提昇
- 確保使用了骨架，且布局穩定。
- 瀏覽器窗口中的‘Waiting for…’(或類似)消息(SC使用的WebPageTest中的已知問題)：檢查瀑布圖像，查看這是否是度量下降的唯一原因。
- 低解析度圖像轉換為高解析度圖像也可能導致SC中的度量降低–請檢查瀑布圖像，看看這是否是唯一的原因。
- 來自自定義組件的偽影(與基於最佳實踐構建的本地RSF組件相比)–導致組件過度重新渲染的樣式/元素。 再次檢查瀑布圖像，查看是否存在可見偽影(例如，低解析度圖像-> PLP->PDP過渡上的圖像傳送帶)
PLP至PDP導航
從PLP (搜尋結果或類別/品牌頁面)導航至PDP頁面是整個消費者旅程中最重要的導航元素。 對於每次購買，平均用戶導航到8.8個PDP頁面。 即使如此高頻率的頁面速度較慢，也會對使用者體驗造成重大不利影響。 以下是您可以遵循的一些事項，以確保獲得完美的PLP至PDP用戶體驗：
- 在摺疊頁面上方使用框架，並確保佈局穩定性
- 確保折疊內容與用戶設備顯示器的高度相符。
- 確保已正確配置高速暫存。 這意味著暫存通用頁面數據，而不是暫存用戶特定的數據點。 (有關更多詳細資訊，請查看我們的暫存指南)
- 使用預取(有關詳細信息，請參閱我們的預取指南)
- 在任意位置使用相同的縮略圖實例，以避免使用ForwardThumbnail組件時閃爍
- 在頁面道具中將盡可能多的資訊從PLP傳遞到PDP，以在PDP上顯示該資訊
主頁載入
主頁通常是用戶與網站的第一次互動。 確保旅程的良好開端，是為用戶提供滿意的結帳和下單流程的關鍵。 以下是您可以遵循的一些事項，以確保獲得出色的主頁體驗：
- 確保已正確配置高速暫存。 這意味著暫存通用頁面數據，而不暫存任何特定於用戶的數據點。
- 在折疊內容下麵緩慢載入
- 使用預連接標籤
- 優化圖像
- 延遲水合直到頁面載入完成
- 其他改進
PDP頁面載入
如果用戶對PDP頁面本身沒有很好的體驗，花費時間優化主頁和PLP到PDP導航將毫無價值。 確保用戶儘快獲得最重要的資訊，並延遲無法立即看到或無法操作的對象，這是優化PDP頁面載入的關鍵。 以下是優化PDP頁面時應牢記的一些事項：
- 暫存通用資產和數據(包括API響應)，以確保立即檢索數據並減少後端系統上的瓶頸。
- 在摺頁下方緩慢載入內容
- 使用優化的第一個圖像以縮短載入時間。
- 使用單獨的縮略圖和捏合縮放圖像，並且僅在請求時載入圖像。
PLP頁面載入
- 預載入PDP圖像以獲得折疊結果。
- 在摺頁下方緩慢載入內容
- 減少或避免決定PLP頁面變更的要求，例如背景色彩變更或其他視覺元素。
更多的指針
上述方法涵蓋了用戶在整個過程中交互的大部分內容。 但是，平臺的意義遠不止於可見的內容。 我們需要採取的下一步是確保平臺內部工作得到優化。 以下是一些要檢查以檢索性能的其他增益：
- TTL：使用Analyze=True NPM run build檢查包大小
- FCP：如果客戶選擇使用WebFont，LH分數可能會下降。
- 速度索引：在屏幕上顯示彈出窗口會降低頁面的速度索引
- 避免在模塊範圍(即客戶端)中執行長時間任務。
- 反應掛鉤很容易產生不必要的重新渲染。 雖然不太可能影響指標，但它們確實造成了網站遲緩的感覺。
- 使用PSI分數來了解代碼更改的影響，而不是本地機器LH分數和/或SpeedCurve結果。 在生產構建中使用4G模式以獲得真實的LH分數。
