網站速度的是 SEO 優化的重點！Google 老早就強調網站速度的重要性，更是難得的公開宣布將速度納入排名要素當中，但想要把網站速度做好並不容易，有非常多的優化方向與細節，這篇文章我將以 SEO 的目標，告訴你有哪些 SEO 速度優化項目值得投資！
哪些因素會影響網站速度？
網站速度是一種使用者體感的問題，當用戶與你的網站互動時，需要從瀏覽器請求網站，經過伺服器回應、網站下載資源、畫面解析這幾個關鍵步驟，這當中的每個環節都可能影響到用戶感受的速度：
- 伺服器回應時間：當有人向伺服器請求檔案時，能多快的準備好並提供用戶，取決於伺服器的等級與架設的地理位置，想要做好 SEO 速度優化，一個離目標用戶接近且品質不錯的伺服器是必不可少的喔！
- 下載資源時間：從伺服器提供資料給用戶時，也會需要一段時間，這取決於網站資源檔案的大小、與用戶網路速度。如果問題出在用戶的網路速度，那就不是我們能解決的，也不會影響到 SEO 表現。（Google 對於用戶體驗速度的統計，是依據整體平均值，單一用戶網路特別爛不會影響到網站評分）
- 前端渲染時間：當用戶的裝置拿到必要檔案後，還需要經過程式的編譯來呈現出畫面，而這個過程所需要的速度，主要是看程式碼寫的好不好來決定，如果程式的寫法有非常畫面大小調整、額外插入資訊、不好的讀取順序等等，都可能會造成速度變慢。
看懂 Google PageSpeed Insights 速度檢測工具
想要客觀的了解網站速度表現，最簡單的方法就是透過工具檢測，我們最推薦使用 Google PageSpeed Insights 工具，原因是這個工具本身就是 Google 提供的，內涵了其對 SEO 網站速度應該要有的改善有哪些方面，要知道我們優化速度最終目標就是取得更好的 SEO 表現，而不是單純的想要專研網頁技術，所以，直接改善裁判給的建議，當然會是最有效的方式。
網站體驗三大核心指標
Google 並不是直接拿速度的檢測項目給予 SEO 分數，而是透過真實觀察使用者的感受來評分，換句話說，使用者的體感才是 SEO 速度優化的重心，而這當中有三個最重要的項目，被稱為網站體驗核心指標（Core Web Vitals）：
最大內容繪製（Largest Contentful Paint, LCP）
紀錄用戶在開啟網站後顯示最大內容元素所需時間，這可以很好地反應出用戶需要花多少時間可以看到網站的重點。當網站載入畫面時，在視覺上最大的元素要多久才能就定位，就是最大內容繪製（Largest Contentful Paint, LCP）。以下圖為例，最大的元素即為左側的手提包圖片，而 LCP 即表示該圖片被瀏覽器呈現出來的時間。Google 建議 LCP 應該控制在 2.5 秒以內，才能達到最佳的讀取速度。
首次輸入延遲（First Input Delay, FID）
首次輸入延遲（First Input Delay, FID）是指用戶與網頁任意元件互動後，需要多少時間才會回饋給用戶，例如：當用戶想要瀏覽下一篇文章，在點擊網頁上的連結後，網站需要花多少時間來處理這個請求，就是 FID，Google 建議 FID 最佳時間為 100 毫秒（0.1秒）以內。值得注意的是，只有分離式的點擊行為會被視為「首次互動」，而滑鼠捲動、畫面放大縮小等連續行為不會計入 FID 中。
FID 之所以被納入重點，是因為這與用戶的回饋感受息息相關，點擊按鈕沒反應、點擊連結沒跳轉、點擊放大不理你⋯⋯這些情況都會極大程度的影響用戶體驗，而如果太慢反應，很可能也會造成用戶覺得功能壞掉的狀況，所以改善 FID 並不單純是速度議題，還有轉換、UX等重點。
累計版面配置轉移（Cumulative Layout Shift, CLS）
現在的許多網站都採用 RWD 響應式排版的技術，這能讓手機用戶更好的瀏覽網站內容，但也會遇到一個新的問題，就是會增加用戶選染資料到視覺就定位的時間，你應該也會常常看到網站在讀取過程當中，各個元件跑來跑去還定位的畫面吧，那就是因為各部件得排版還沒讀取完，這時候雖然看得到內容，但很可能一下子又跑來跑去，讓人很不舒服。
而衡量這種問題的指標就是 CLS，也就是反映網站在載入時的視覺穩定性。Google 將此指標的得分規範在 0.1 以內，因此若在 PageSpeed Insights 上測得的得分高於 0.1 ，即會被視為不及格。如果有這些問題，要先檢查有沒有發生大圖縮小、小圖放大、插入元件等程式寫法。
效能問題列表
Google 基於各種能夠改善網站速度的項目，提供網站現在遇到的問題列表：
| 項目 | 指標分類 | 解決人員 | 項目重要度 |
|---|---|---|---|
| 避免鏈結關鍵要求 | FCP, LCP | 一般操作人員 | 低 |
| User Timing 標記和測量結果 | 前端工程師 | 低 | |
| 降低要求數量並減少傳輸大小 | 前端工程師 | 中 | |
| 最大內容繪製元素 | LCP | 前端工程師 | 中 |
| 缺少包含 width 或 initial-scale 的 標記找不到任何 `` 標記 | TBT | 前端工程師 | 高 |
| 避免長時間在主要執行緒上執行的工作 | TBT | 前端工程師 | 中 |
| 排除禁止轉譯的資源 | FCP, LCP | 前端工程師 | 高 |
| 使用合適的圖片大小 | 一般操作人員 | 高 | |
| 延後載入畫面外圖片 | 前端工程師 | 高 | |
| 壓縮 CSS | FCP, LCP | 前端工程師 | 中 |
| 壓縮 JavaScript | FCP, LCP | 前端工程師 | 中 |
| 減少無用的 CSS | FCP, LCP | 前端工程師 | 中 |
| 圖片編碼有效率 （壓縮圖片） | 一般操作人員 | 高 | |
| 提供 next-gen 格式的圖片 | 後端工程師 | 高 | |
| 啟用文字壓縮 | FCP, LCP | 伺服器管理者 | 中 |
| 預先連上必要來源 | FCP, LCP | 前端工程師 | 低 |
| 初始伺服器回應時間很短 | FCP, LCP | 伺服器管理者 | 高 |
| 避免進行多次頁面重新導向 | FCP, LCP | 前端工程師 | 高 |
| 預先載入重要要求 | FCP, LCP | 前端工程師 | 中 |
| 使用影片格式的動畫內容 | LCP | 一般操作人員 | 中 |
| 請移除 JavaScript 套件中重複的模組 | TBT | 前端工程師 | 低 |
| 避免將舊版 JavaScript 提供給新型瀏覽器 | TBT | 前端工程師 | 中 |
| 預先載入最大內容繪製圖片 | LCP | 前端工程師 | 中 |
| 避免耗用大量網路資源 | LCP | 前端工程師 | 中 |
| 使用有效的快取政策處理靜態資產 | 伺服器管理者 | 高 | |
| 避免 DOM 過大 | TBT | 後端工程師 | 高 |
| JavaScript 執行時間 | TBT | 前端工程師 | 中 |
| 將主要執行緒的工作降到最低 | TBT | 前、後端工程師 | 高 |
| 載入網站字型時沒有任何文字消失 | FCP, LCP | 前端工程師 | 低 |
| 盡量減少第三方程式碼的使用量 | TBT | 前、後端工程師 | 高 |
| 使用門面元件延遲載入第三方資源 | TBT | 前、後端工程師 | 中 |
| 未延遲載入最大內容繪製圖片 | LCP | 前端工程師 | 低 |
| 避免大量版面配置轉移 | CLS | 前端工程師 | 高 |
| 使用被動事件監聽器來提升捲動效能 | 前端工程師 | 低 | |
| 避免使用 document.write() | 前端工程師 | 中 | |
| 避免使用非合成的動畫 | CLS | 前端工程師 | 中 |
| 圖片元素具有明確的 width 和 height | CLS | 前端工程師 | 中 |
（以上項目的解決人員與重要度排序是依據 Procrustes 的執行經驗所得，是一個廣泛的平均認知，不一定完全適用於你的品牌。）
Google PageSpeed Insights 提供了詳盡的網站效能診斷，且針對每個診斷項目都有簡單的說明和建議的解決方式。以下則是我們挑選出，最值得做的項目，方便你做一個改善目標：
- 缺少包含 width 或 initial-scale 的 <meta name=”viewport”> 標記找不到任何 `<meta name=”viewport”>` 標記
<meta name=”viewport”>不僅會根據行動裝置螢幕大小將應用程式最佳化，還能避免使用者輸入內容出現 300 毫秒的延遲。 - 排除禁止轉譯的資源
當 Google PageSpeed Insights 的報告出現「排除禁止轉譯的資源」時，表示網站內有過多的 JavaScript 和 CSS 程式檔案，因而干擾了首次畫面的顯示。此時，我們就需要延遲 JavaScript 和 CSS 程式檔案的顯示時間、壓縮或刪除不必要的 JavaScript 和 CSS 程式檔案。 - 使用合適的圖片大小
圖檔是網站中最常見的資源之一，使用合適的圖片大小可以降低文件的檔案大小，並縮短下載時間。 - 延後載入畫面外圖片
建議在所有重要資源載入完成之前，延遲載入畫面外圖片和隱藏項目，以縮短互動的準備時間。 - 圖片編碼有效率（壓縮圖片）
經過最佳化的圖片載入速度較快，且能節省使用者的行動數據用量。 - 提供 next-gen 格式的圖片
優化圖檔除了上面提供的方法之外，還有 Google 現今提倡的新世代圖片格式（next-gen），包含 WebP 和 AVIF 等圖片格式，不僅能提供更好的圖片品質，同時也能縮小圖檔大小，進而提高網頁的速度，但要注意的是，並不是所有的瀏覽器都支援這些格式的圖片，因此在使用前務必先考慮瀏覽器的兼容性。 - 初始伺服器回應時間很短
請確保伺服器能快速回應主要文件，因為這會影響到所有其他要求的回應時間。 - 避免進行多次頁面重新導向
重新導向會延遲網頁載入時間，因此我們應避免或降低網站進行此動作。 - 使用有效的快取（cache）政策處理靜態資產
用戶每次造訪一個網站，Google 就要去該網站重新爬取網頁內容、程式碼、圖片等所有的網頁資訊，非常耗時，但若能利用瀏覽器的快取功能，便可以減少下載時間、提升網站加載速度。 - 避免 DOM 過大
大型 DOM 會增加記憶體用量、延長樣式運算的時間，並產生費工的版面配置重排。簡言之，瀏覽器通常需要讀取完網頁所有元素，才能了解該網頁應如何運作，所以網頁元素愈多，瀏覽器就需要愈多時間讀取，進而阻塞了網頁操作的反應時間。 - 將主要執行緒的工作降到最低
建議你縮短剖析、編譯及執行 JavaScript 所耗費的時間，提供較小的 JavaScript 酬載可能會有幫助。 - 盡量減少第三方程式碼的使用量
第三方程式碼可能會嚴重影響載入效能。請盡量減少不必要的第三方供應商，並在網頁的主要內容載入完畢後，再載入第三方程式碼。 - 避免大量版面配置轉移
這些 DOM 元素對於網頁的「累計版面配置位移」(CLS) 影響最大。
看到自己的網站分數後，你應該很想要立刻開始優化網站，以達到更高分的速度表現，但我想勸你稍等一下，因為很多速度改善會涉及到程式碼的優化，這不一定是你可以解決的問題，此外，當你的條件不同時，也可能需要用更多角度來思考：
- 是否有技術人員協助：若我們不具備相關技術背景，能夠選擇的方向就只有「外娉」或者「自己做能做的項目」。但我得說優化速度的程式碼調整，往往都會被獅子大開口，很難用低成本達成，如果公司當前不具備充足的資金可以投入，我會建議放棄一些優化目標，先做那些非技術人員也可以做的部分就好。
- 是否使用架站系統：若我們是使用像是 WordPress 這樣的架站系統自行架站，那麼進行網站速度優化就會比較容易，因為這些架站系統通常都有優化網站速度相關的插件或工具。當然，我們也需要懂得如何使用和配置這些插件或工具，才能使其發揮最大的效果。值得注意的是，若安裝了過多外掛，可能會產生反效果，因為那不但無法有效提升網站速度，反而會因為資料量過於龐大而降低網站速度。
Wordpress 的 SEO 速度優化建議
我們自己就是長期開發並使用 WordPress 的業者，也看過非常多不熟悉 Wordpress 導致的速度災難，因此，如果你正在使用 Wordpress 作為網站後台，以下是我們可以給你的經驗指引：
慎選輕量化、原生功能的主題
Wordpress 的建置通常會從挑選主題開始，普洛客使用的主題是 Astra，但我們並沒有要特別推薦哪一個主題，我們對於選主題的建議是：盡量選使用 Wordpress 原生功能的主題，減少使用額外編輯、額外後台環境功能的東西，例如：Elementor 的主題就是額外多了一個 Elementor 編輯器，這種多建置編輯器的做法，雖然看似會讓排版功能變強大，但其實是犧牲效能帶來的，往往會對網站速度帶來毀滅性的影響，非常不建議。
外掛挑選功能單一的就好
普洛客使用過的外掛可能超過百種，在這裡我們給你一個非常清晰的建議：「不要用複合功能的外掛」，外掛功能越複雜，代表佔用資源越多，也代表網站會跑得越慢，所以，使用外掛最重要的就是先釐清你希望外掛做哪些事，挑選只做這些事情的外掛就好，不要想著安裝功能強大、複雜、什麼都管的外掛，那種外掛往往會把網站拖垮。此外，同性質的外掛安裝一個就好，這樣可以減少衝突發生的可能性，並且安裝的外掛越少越好。
好的伺服器不貴，不要省過頭了
如果網站是商用的，我們強烈建議選用業界比較頂尖的伺服器，因為這些伺服器不只能提升速度，還能順便幫你解決不少問題，例如：備份、快取、CDN 等等。普洛客使用 Kinsta 作為伺服器，但我們並沒有推薦一定要選用這個伺服器，只是強烈建議不要在伺服器上太省，此外，也盡量避免用台灣的伺服器，並不是因為我們不愛國，而是台灣的伺服器 CP 值真的太低了，同樣規格的伺服器買台灣的至少要花 4~5 倍價格，技術能力、客服水準還更差。
