想知道你需要做什麼來最佳化你的網站效能嗎？
網上有很多頁面速度提示列表，但在本文中，我將解釋為什麼基於自動工具和高階頁面負載分析的方法通常是更有效的途徑。
最佳化您的網站效能
想讓你的網站載入得更快嗎？ 您將在網上找到無數列出網路效能技術的文章。
包括可以選擇一個快速託管提供商、最佳化您的影象、啟用瀏覽器快取、 縮小CSS和JavaScript、 使用內容交付網路、 啟用文字壓縮等等…
為什麼瀏覽技術列表不是加快網站速度的最佳方法
上面的提示都不是壞建議！ 但您如何知道哪些應用於您的網站，以及您需要關注哪些網路效能最佳化才能產生最大影響？
與其閱讀一長串頁面速度技巧，不如嘗試以下內容：
- 使用自動化工具來測試您的網站
- 檢查您網站上的不同資源何時載入
使用自動化工具來測試您的網站
與列出頁面速度提示的文章相比，Lighthouse 或 DebugBear 網站速度測試等自動化工具都具有巨大優勢：它們實際上會考慮有關您網站的資訊，並生成量身定製的推薦列表。
以下是 Lighthouse 生成的效能建議示例列表：
如果我們稍微滾動一下報告，我們可以看到 Lighthouse 還會告訴您您的網站已經透過的檢查， 其中許多是關於網站速度的文章中的常見建議。
今天， 很少看到一個網站不使用GZIP或Brotli壓縮文字響應。 預設情況下，現代開發工具都會進行最小化CSS和JavaScript程式碼。
文字壓縮功能有用嗎？
我覺得我檢視的99%的網站都使用HTTP文字壓縮。 但我想根據實際資料來核實事實 —— 也許我只處理更受歡迎的網站，或者其團隊有興趣提高網站效能的網站。
令人驚訝的是，網路年法表明，只有大約70%的網站正確使用文字壓縮！
這可以部分地解釋為，有一長條配置不良的低交通網站。 （難得那些通常都不是使用網站構建器或其他託管平臺嗎？）
但我認為主要原因是 Lighthouse 在決定您是否正確啟用了文字壓縮時非常嚴格。
例如，看看這個電子商務網站， 它正在發出數百個文字請求，透過使用文字壓縮來節省數兆位元組的資料傳輸。
但燈塔仍然不開心！ 顯然，有一個未壓縮的 Pinterest JavaScript 檔案，這意味著我們可以再節省1.9千位元組的資料傳輸。
Lighthouse 指出了這些小問題是件好事。 但對於大多數網站來說，最佳化其文字壓縮的使用並不是一個有用的效能提示。
檢查您網站上的不同資源何時載入
自動效能推薦是識別您網站上潛在最佳化的好方法。 然而，它們經常在各種方面受到限制：
- 並非每個最佳化都可以被檢測到
- 影響估計並不總是可靠的
頁面內容何時出現在您的網站上取決於不同資源（如程式碼或影象）在您的網站上載入的速度。 以下是顯示影象所需的一組典型步驟：
- 載入HTML文件
- 載入渲染阻止樣式表和指令碼
- 載入影象檔案本身
影象顯示的速度取決於每個步驟需要多長時間，以及它們是並行發生還是一個接一個地發生。 如果我們瞭解這些請求、它們之間的關係，以及它們在向用戶顯示的內容中發揮的作用，我們就可以最佳化這些資源的載入方式，以創造最佳的使用者體驗。
請求瀑布(Request waterfalls)提供此類資訊，我們可以看到不同的資源何時載入，以及這與訪問者的視覺進度有什麼關係。
這裡有很多值得看的東西，所以讓我們從檢視渲染阻止資源開始。 在頁面上顯示任何內容之前，這些檔案需要載入。
這些資源是如何相互關聯的？
- 當瀏覽器等待HTML程式碼載入時，沒有發生其他活動
- 一旦HTML程式碼開始載入，以下內容就可以並行進行：
- 下載完整的HTML文件
- 啟動樣式表和指令碼的請求
- 載入其他資源，如影象，如果它們在HTML程式碼中引用
- 載入渲染阻止資源後，瀏覽器可以啟動渲染過程
- 渲染後，內容對訪問者可見
我們可以在這個放大的瀑布視覺化中看到這一點。橙色條顯示了將已載入的資源轉換為可以顯示給使用者的視覺元素所需的CPU處理。 右側的藍線標誌著 First Contentful Paint 渲染里程碑。
最後，讓我們看看瀑布圖中的影象是如何載入的。 為了使分析更容易，DebugBear 報告了一個專注於頁面上最大影象的檢視。
在更快地看到加載影象時，您應該詢問它是在 HTML 程式碼載入後與其他資源並行載入，還是僅在另一個請求完成後載入。
在這種情況下，我們可以看到，主頁影象只有在CSS樣式表載入完成後才開始載入。 這些順序延遲會損害績效。 當我們檢視主頁影象時，網站的 Largest Contentful Paint 指標也受到影響。
一旦您確定了次優請求排序，您可以尋找改進它的方法，例如使用瀏覽器預載入功能直接在HTML中引用影象(browser preload feature)。
最佳化請求
避免長請求鏈是提高網站效能的重要早期步驟。 然而，一旦完成，您可能需要採取額外的措施來加快您確定為最重要的請求。
什麼決定了請求需要多長時間？
- 瀏覽器是否連線到新伺服器？
- 伺服器是否快速響應請求？
- 響應下載量有多大？
- 瀏覽器是否將該請求視為高優先順序？
最佳化這些方面的每一個意味著可以在更短的時間內載入您的資源。
這就是“頂級提示”列表中的許多標準建議的來源。 最佳化影象並應用文字壓縮將減少下載大小和持續時間。 使用更快的託管服務提供商可以縮短伺服器響應時間。
頻寬競爭：並非每個請求都需要快速
到目前為止，我們已經討論過更早地提出請求，並確保它們被優先考慮。 但那並不總是你想要的！
在之前的螢幕截圖中，您已經可以看到 Chrome 瀏覽器沒有對請求進行優先排序，導致長長的灰色條顯示的等待時間很長。 那是件好事！ 我們不希望這種低優先順序資源從重要的渲染阻止請求中奪走網路頻寬。
然而，這並不總是奏效的。 如果我們在瀑布中再往下看一點，我們可以看到瀏覽器正在載入一個大型指令碼和一個影象，這兩個對渲染主頁內容都不重要。
與此同時，瀏覽器正在嘗試載入主頁影象，這是最大內容畫（LCP）所必需的。 由於其他請求，這個12千位元組的檔案幾乎需要整整一秒鐘才能下載！
這就是為什麼有時你會想延遲載入一些資源，使用技術，例如 fetchpriority="low"，loading="lazy"，或者 async and defer script attributes.
找到高影響力的最佳化
您如何知道您網站上的哪些更改對您的網站速度最有用？
最可靠的檢查方式是嘗試更改並衡量對您網站的影響，最好使用真實使用者資料。 但那很慢，需要做很多工作。
燈塔審計附帶一個影響估計，告訴您如果您完全最佳化此審計，您的網站速度會加快多少。
同樣，DebugBear 測試結果將為您提供一個優先嘗試的建議列表。
要在不進行生產部署的情況下嘗試更改，您還可以使用本地覆蓋在 Chrome DevTools 中編輯網站程式碼，或使用 Cloudflare Workers 應用更改。
一些DebugBear檢查還支援整合實驗功能，讓您快速嘗試更改。
在整個網站上進行更改之前，先嚐試更改，讓您瞭解效能指標和使用者體驗將如何受到影響。
