AO2 GUIDE 18 · 搜尋與量測
網站速度改善先確認真實使用情境與測試條件。從圖片、影片、外掛及 Core Web Vitals 找出優先問題，再驗證修改與實際體驗。
本篇以企業官網的閱讀、產品查詢與詢問任務為情境，說明如何理解常見效能指標、安排改善順序與上線驗收。文中的任務與配置為方法示例，並非對特定網站的檢測結果。
網站速度：先選重要任務，再選代表頁面
效能改善不必先測遍所有網址。可以從首頁、主要服務、核心產品、文章與聯絡入口各挑代表頁，並確認哪些任務最重要。例如客戶要找到規格文件、比較型號或成功提出詢問，這些任務會決定哪些問題應先處理。
同一個網站，不同模板可能有不同負擔。首頁有大影片，產品頁有圖庫，文章有長表格，表單則需要額外腳本。若只拿首頁的一個分數代表全站，就可能忽略最影響客戶判斷的頁面。請先記錄模板、裝置與需要完成的行為。
初步盤點也要保留必要功能。不要為了分數直接移除產品說明、文件入口或詢問功能，最後讓網站雖然載入較快，使用者卻無法完成工作。可先依 SEO 健檢指南 整理頁面與問題範圍。
分清楚載入、互動與版面穩定
Google 的 Core Web Vitals 包含 LCP、INP 與 CLS，分別觀察主要內容載入、互動回應與版面位移。它們有不同的測量目的，也需要不同的改善方式。企業團隊不必每個人都懂全部技術，但應能理解一個問題會影響哪種使用情境。
| 指標 | 主要觀察 | Google 文件的良好體驗參考 |
|---|---|---|
| LCP | 主要內容何時顯示 | 約 2.5 秒內 |
| INP | 互動後畫面回應是否及時 | 約 200 毫秒以內 |
| CLS | 內容是否突然移動 | 約 0.1 以下 |
這些參考值不是排名保證，也不是網站唯一的品質標準。若主要內容很快出現，但按鈕失效，仍然不能算完成驗收；反過來，也不應只因某次工具數字較差，就直接認定所有使用者都遇到同樣問題。
測試環境與真實使用資料，要分開解讀
固定條件的工具測試，有助於重現問題與比較修改；真實使用資料則反映實際裝置、網路與互動中的情況。兩者可能不同，並不一定代表其中一方錯誤。報告應寫清楚資料來源、日期、頁面與裝置條件。
如果某個網址沒有足夠的真實使用資料，就記錄限制，再用可重現的測試與實際任務協助判斷。不要把沒有資料解讀為完全沒有問題，也不要把單次模擬結果包裝成所有訪客的共同體驗。
比較修改前後時，盡量保留相同測試條件，也記錄同時發生的其他改動。網站剛更新內容、換了圖庫又新增追蹤工具，結果變化就不能只歸因於其中一項。清楚的變更紀錄，能讓後續回查更有意義。
第一屏的大圖與影片，先確認它的任務
企業首頁常希望用視覺建立第一印象，但主視覺也需要合理的檔案、尺寸與載入安排。先問這張圖或影片是否真的協助理解服務，是否需要立即播放，以及手機是否有適合的呈現方式。視覺價值與效能應一起設計。
若使用大幅影片，可以準備適合的靜態預覽與清楚的文字，避免重要說明只能等影片播放。也要檢查行動網路、播放器失敗與使用者偏好減少動態效果的情況。不是把所有動態都拿掉，而是讓資訊在不同條件下仍可理解。
圖片則核對實際顯示尺寸、壓縮與格式，避免很小的縮圖仍載入過大的素材。產品細節需要清楚，裝飾背景不一定需要同樣解析度。可接著看 圖片與品牌網站 SEO，讓畫質、用途與載入一起判斷。
版面會跳動，先檢查空間是否預留
圖片、影片、字型或第三方內容載入後，可能改變頁面空間。如果讀者正要點連結，內容卻突然往下移，就容易誤觸。這類問題應在實際閱讀中觀察，不能只看載入完成後的靜態截圖。
網站人員可以檢查圖片與播放器的比例、容器尺寸與必要的空間安排，也要觀察字型載入前後的標題斷行。長標題與多語版本尤其值得抽查，因為相同模板在不同文字長度下，可能有不同的位移與裁切。
如果頁面上有通知、嵌入元件或動態推薦，也應確認它們何時出現、會不會推動主要內容。改善不只是把某個數字降低，而是讓人能穩定閱讀與完成操作。每項修正都應有對應的使用情境。
互動不順，回到按鈕與功能的實際流程
有些頁面載入後很快，但打開選單、切換圖庫或操作篩選時明顯延遲。請把這些互動列成任務，記錄何時發生、需要等待什麼，以及是否有清楚的狀態回饋。避免只測第一次載入，漏掉客戶真正使用功能的時刻。
第三方工具也要盤點用途與必要性。多個聊天、追蹤、彈窗與嵌入程式，可能各自有業務目的，但應確認是否仍在使用、是否重複，以及出錯時會影響哪些功能。停用或調整之前，也要核對相依關係，避免為了解決一項問題造成另一項故障。
需要修改模板或外掛整合時，可由 WordPress 網站整合 一起規劃。交付應說明改動位置、測試任務與回復方式，不能只留下「已最佳化」這種無法回查的結論。
改善順序，先處理影響大又能確認的問題
可以依使用者影響、重要頁面、重現程度與實作成本排出順序。例如手機聯絡表單操作失效，通常比不影響閱讀的裝飾效果更急迫；某個核心產品模板普遍有問題，也可能比少數舊頁更值得先修。
不要一次開啟所有快取、合併或壓縮選項，再用一張較高分數的截圖結案。這些設定可能影響表單、動畫與其他腳本。應分項修改，保留原設定與結果，確認功能正常後再往下做，才比較容易發現相衝突的地方。
每項工作記錄問題、代表網址、改動內容、負責人與驗收方式。若某個建議需要大幅重做網站，先說明原因與預期改善的任務，再決定投入。工具提示是線索，仍需要結合實際架構與企業需求判斷。
上線驗收，把搜尋、閱讀與詢問一起走過
先用桌面與手機開啟代表頁面，檢查主要內容、圖庫、選單、下載與詢問入口。再走過成功與失敗情境，例如圖片尚未完成、表單輸入錯誤或第三方播放器無法使用時，使用者是否仍知道下一步。
若網站有正式的測試表單或驗收環境，可依企業安排確認提交與資料接收；不要為了測速度就反覆向業務送出無法辨認的真實詢問。測試紀錄應清楚標示用途，並由適合的人核對後續狀態。
量測可參考 GA4 實作指南，確認重要事件與成功狀態仍正常。上線後再回查效能與使用情況，避免一次部署完成後，就沒有任何人確認新內容是否再次增加負擔。
讓效能成為內容維護的一部分
圖片、影片與工具會持續增加，網站效能也需要跟著回查。可以為新素材訂必要檢查，例如用途、顯示尺寸、檔案大小、手機裁切與替代說明，讓編輯在上稿時就能發現明顯問題。
若核心模板或外掛更新，也應重走代表任務。固定保存幾個測試頁與驗收條件，比每次重新猜測要測哪裡更容易維護。這些紀錄可以連同內容與網站責任一起交接，讓後續改善有共同基礎。
當網站視覺與效能衝突時，先回到使用者任務：哪些資訊必須立即看到、哪些效果可以延後，以及失敗時需要什麼替代。這樣的判斷，通常比單純追求某個分數更能支持品牌與商業目標。
交付報告要能支持下一次維護
一份效能交付紀錄，可以同時列出代表頁面、原本問題、修改位置、測試條件與功能驗收結果。例如「產品圖庫切換延遲」應記錄是哪個模板、做了什麼調整，以及手機操作是否仍正常。只交一張較高分的截圖，下一位維護者很難知道哪些設定不能任意更動。
也要留下尚未處理的限制。若某項第三方功能仍影響載入，但企業目前需要保留，請說明原因與後續評估條件。這不是把問題合理化，而是讓團隊知道目前的取捨。當功能需求或素材改變時，就能依紀錄重新檢查，不必再次從頭猜測。
常見問題
工具分數很高，就代表網站體驗很好嗎？
不代表。分數只反映特定環境與檢查範圍，還需驗證手機閱讀、互動、表單與主要內容是否可用。先保存代表頁面與測量條件，再看實際使用資料和實驗室診斷各自提供的線索。改動後完成同一任務測試，確認沒有為分數移除必要功能或延後關鍵資訊。一次高分不能代表所有裝置與使用者，也不能直接當成搜尋排名或詢問成果。
首頁影片一定要移除嗎？
不一定。先確認影片是否提供必要品牌或產品理解，再檢查檔案、載入時機、預覽、播放方式和手機替代。可先用靜態封面提供清楚入口，再依需要載入影片；具體策略由實測與模板能力決定。比較調整前後的代表裝置和任務，確認重要內容更快可用且功能正常。如果影片只是裝飾並造成負擔，再評估移除，不按單一工具建議機械決定。
改善完成後，還需要定期檢查嗎？
需要，特別在新增圖片、追蹤工具、外掛或模板更新後。保留代表頁面、裝置與測試任務，記錄部署日期和變更；先定位是否由某項新素材或功能引起，再安排修正。實驗室測量可用於診斷，使用資料則反映另一個範圍，兩者分開解讀。避免反覆追逐小幅波動；只有新變更、明確失敗或未解問題時，再擴大檢查。
參考資料
本文為 AO2 獨立編寫的企業實作指南。工作情境與清單為方法示例；平台功能與技術規範請以所列官方文件為準。
