最佳化 Cookie 通知以提高效能和可用性。
本文說明 Cookie 通知如何影響效能、成效評估和使用者體驗。
效能
Cookie 通知可能會對網頁效能產生重大影響，原因在於這類通知通常會在網頁載入程序初期載入，而且會向所有使用者顯示，而且可能會影響廣告和其他網頁內容的載入情形。
Cookie 通知可能對 Web Vitals 指標造成以下影響：
最大內容繪製 (LCP)：大多數的 Cookie 同意聲明通知都很小，因此通常不包含網頁的 LCP 元素。但這種情況經常發生，尤其是在行動裝置上。在行動裝置上，Cookie 通知通常會佔據大部分的畫面。會發生這種情形，通常是因為 Cookie 通知含有大量文字 (文字區塊也可以是 LCP 元素)。
與下一個顯示內容的互動 (INP)：Cookie 通知通常會導致 INP 出現偏高的問題，因為這類通知通常會在接受時加入大量第三方指令碼。最常見的問題在於「接受」互動，因為系統會需要處理大量程序，才能一次新增所有第三方指令碼。請參閱下方的最佳做法一節，瞭解如何減少這類問題。
累計版面配置位移 (CLS)：Cookie 同意聲明通知是版面配置位移的常見來源。
一般來說，相較於自行建立的 Cookie 通知，第三方供應商的 Cookie 通知對效能的影響較大。這並不是 Cookie 通知特有的問題，只是第三方指令碼整體的性質。
最佳做法
本節的最佳做法著重於第三方 Cookie 通知。這些最佳做法中有些 (但非全部) 也適用於第一方 Cookie 通知。
瞭解 Cookie 通知對 INP 的影響
如前所述，「接受」按鈕經常是 INP 問題的特殊原因，原因在於該按鈕點選後需要處理大量資料。
Chrome 團隊已與多個同意聲明管理平台 (CMP) 合作，在點選「接受」後即可獲益，這樣瀏覽器就能在下次更新時快速確認接受條款。如需範例，請參閱 PubTech 個案研究。
如果您的 CMP 受到此影響，請嘗試與該 CMP 聯絡，看看對方是否能同樣避免嵌入 INP 的網站發生 INP 問題。如要瞭解如何產生策略，請參閱將長時間工作最佳化一文。
以非同步方式載入 Cookie 通知指令碼
Cookie 通知指令碼應以非同步方式載入。如要這麼做，請在指令碼標記中加入 async 屬性。
<script src="https://cookie-notice.com/script.js" async>
非非同步的指令碼會封鎖瀏覽器剖析器。這樣會延遲網頁載入和 LCP。詳情請參閱「有效率地載入第三方 JavaScript」。
直接載入 Cookie 通知指令碼
Cookie 通知指令碼應「直接」載入，方法是將指令碼標記放在主要文件的 HTML 中，而不是由代碼管理工具或其他指令碼載入。使用代碼管理工具或次要指令碼插入 Cookie 通知指令碼，會延遲 Cookie 通知指令碼的載入作業。指令碼會遮蓋來自瀏覽器的 Looker 剖析器指令碼，並防止指令碼在 JavaScript 執行之前載入。
及早與 Cookie 通知來源建立連結
從第三方位置載入 Cookie 通知指令碼的所有網站，都應使用 dns-prefetch 或 preconnect 資源提示，與代管 Cookie 通知資源的來源建立早期連線。詳情請參閱「及早建立網路連線，以改善感知的網頁速度」。
<link rel="preconnect" href="https://cdn.cookie-notice.com/">
視情況預先載入 Cookie 通知
有些網站可以使用 preload 資源提示載入 Cookie 通知指令碼，preload 資源提示會指示瀏覽器對指定資源提出提前要求。
<link rel="preload" href="https://www.cookie-notice.com/cookie-script.js">
如果用量限制在每頁擷取幾個重要資源，preload 將發揮最大效用。因此，預先載入 Cookie 通知指令碼的好處會隨情況而有所不同。
設定 Cookie 通知樣式時，請留意效能的取捨
如果自訂第三方 Cookie 通知的外觀和風格，可能會產生額外的效能成本。舉例來說，第三方 Cookie 通知不一定能重複使用網頁上其他位置使用的相同資源 (例如網路字型)。此外，第三方 Cookie 通知往往會在較長的要求鏈結末端載入樣式。為避免出現意外狀況，請特別留意 Cookie 通知的載入方式，並套用樣式和相關資源。
避免版面配置位移
以下是與 Cookie 通知相關的部分最常見的版面配置位移問題：
- 螢幕頂端 Cookie 通知：畫面頂端 Cookie 通知是版面配置位移的常見來源。如果在網頁轉譯完畢之後，已在 DOM 中插入 Cookie 通知，則會將 Cookie 通知置於網頁下方的網頁元素下方。藉由在 DOM 保留空間供同意聲明通知使用，即可避免這類版面配置位移。如果這不是可行的解決方案 (舉例來說，如果 Cookie 通知的尺寸因地理位置而異)，請考慮使用頁緣固定或互動視窗來顯示 Cookie 通知。由於這兩種替代方法都會在頁面其他部分將 Cookie 通知顯示為「重疊」，因此當 Cookie 通知載入時，應該不會導致內容轉移。
- 動畫：許多 Cookie 通知使用動畫，例如「滑入」Cookie 通知是一種常見的設計模式。視這些效果的實作方式而定，可能會造成版面配置位移。詳情請參閱「對版面配置位移進行偵錯」。
- 字型：延遲載入的字型會阻擋轉譯，或造成版面配置位移。連線速度緩慢時較容易看出這種現象。
進階載入最佳化
這些技術需要較多實作，但可以進一步最佳化 Cookie 通知指令碼的載入：
- 從自己的伺服器快取及提供第三方 Cookie 通知指令碼，可以改善這些資源的傳送速度。
- 使用服務工作站可讓您進一步控管第三方指令碼的擷取及快取作業，例如 Cookie 通知指令碼。
成效評估
Cookie 通知可能會影響成效評估。本節會討論其中幾項影響和緩解的技巧。
即時使用者監控 (RUM)
部分數據分析和 RUM 工具會使用 Cookie 收集成效資料。如果使用者拒絕使用 Cookie，這些工具就無法擷取效能資料。
網站應留意這種現象；瞭解 RUM 工具使用哪些機制收集其資料也是值得的。然而，對典型網站而言，由於資料偏移的方向和規模，這項差異可能並非引起警覺。使用 Cookie 不一定是成效評估的技術必要條件。web-vitals JavaScript 程式庫是不使用 Cookie 的程式庫範例。
視網站使用 Cookie 收集成效資料的方式 (即 Cookie 是否包含個人資訊) 和相關法規而定，使用 Cookie 評估成效時可能必須遵守與網站上某些用於其他用途的 Cookie (例如廣告 Cookie) 相同的法規要求。有些網站會在徵詢使用者同意時，選擇將效能 Cookie 當成獨立的 Cookie 類別。
綜合監控
如果沒有自訂設定，大部分的合成工具 (例如 Lighthouse 和 WebPageTest) 只會評估未回覆 Cookie 同意聲明通知的初次使用者體驗。不過，收集成效資料時，您也需要考慮快取狀態的變化版本 (例如初次造訪與重複造訪)，同時也需要考慮 Cookie 接受狀態的變化 (已接受、已拒絕或未回應)。
使用 WebPageTest 測試 Cookie 通知
以下各節將討論 WebPageTest 和 Lighthouse 設定，這些資訊有助於將 Cookie 通知納入成效評估工作流程。然而，Cookie 和 Cookie 通知只是許多在研究室環境中無法完全模擬的因素之一，因此，務必將「RUM 資料」設為效能基準測試的基石，而非合成工具。
使用指令碼
您可以使用指令碼，在收集追蹤記錄時，讓 WebPageTest「點擊」Cookie 同意橫幅。
前往「指令碼」分頁即可新增指令碼。下列指令碼會前往要測試的網址，然後按一下具有 id=cookieButton 的 DOM 元素。
combineSteps
navigate %URL%
clickAndWait id=cookieButton
使用這個指令碼時，請注意下列事項：
combineSteps會指示 WebPageTest 將後續指令碼步驟的結果「合併」為一組追蹤記錄和測量結果。在沒有combineSteps的情況下執行這個指令碼也相當實用，您可以透過個別的追蹤記錄，以更輕鬆的方式查看資源是在接受 Cookie 之前還是之後載入。%URL%是 WebPageTest 慣例，是指正在測試的網址。clickAndWait會指示 WebPageTest 點擊attribute=value指定的元素，並等待後續瀏覽器活動完成。格式為clickAndWait attribute=Value。
如果您的指令碼設定正確，WebPageTest 擷取的螢幕擷取畫面不應顯示 Cookie 通知 (已接受 Cookie 通知)。
如要進一步瞭解 WebPageTest 指令碼，請參閱 WebPageTest 說明文件。
設定 Cookie
如要使用 Cookie 集執行 WebPageTest，請前往「Advanced」分頁，然後將 Cookie 標頭新增至「Custom header」欄位：
變更測試位置
如要變更 WebPageTest 使用的測試位置，請按一下「Advanced Testing」分頁中的「Test Location」下拉式選單。
使用 Lighthouse 測試 Cookie 通知
在 Lighthouse 執行作業中設定 Cookie 可以做為將頁面進入特定狀態的機制，供 Lighthouse 進行測試。Lighthouse 的 Cookie 行為會因為結構定義 (開發人員工具、CLI 或 PageSpeed Insights) 略有不同。
DevTools
透過開發人員工具執行 Lighthouse 時，系統不會清除 Cookie。但系統預設會清除其他類型的儲存空間。您可以使用「Lighthouse」設定面板中的「Clear Storage」選項，來變更這項行為。
CLI
從 CLI 執行 Lighthouse 會使用新的 Chrome 執行個體，因此預設不會設定 Cookie。如要透過 CLI 使用特定 Cookie 集執行 Lighthouse，請使用以下指令：
lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"
如要進一步瞭解如何在 Lighthouse CLI 中設定自訂要求標頭，請參閱在驗證頁面執行 Lighthouse。
PageSpeed Insights
從 PageSpeed Insights 執行 Lighthouse 時，會使用新的 Chrome 執行個體，且不會設定任何 Cookie。您無法設定 PageSeed Insights，藉此設定特定 Cookie。
使用者體驗
不同 Cookie 同意聲明通知的使用者體驗 (UX) 主要取決於兩項決定：Cookie 通知在網頁上的位置，以及使用者自訂網站使用 Cookie 的程度。本節會說明這兩種決定的可能方法。
在考量 Cookie 通知的設計時，請考量以下幾點：
- 使用者體驗：使用者體驗是否良好？這項特定設計對現有的網頁元素和使用者流程有何影響？
- 商家：您網站的 Cookie 策略為何？您希望提出 Cookie 通知的目標是什麼？
- 法律：這是否符合法律要求？
- 工程：實作及維護的工作應達到多少工作量？改變的難易度為何？
刊登位置
Cookie 通知可顯示為標頭、內嵌元素或頁尾。也可以使用互動模式，或以插頁式廣告的形式顯示在網頁內容上方。
頁首、頁尾和內嵌 Cookie 通知
Cookie 通知通常放在標頭或頁尾。在這兩個選項中，通常建議放置頁尾，因為這樣不會造成乾擾、不會與橫幅廣告或通知競爭，而且通常不會造成 CLS。此外，也常常設置隱私權政策 和使用條款
雖然內嵌 Cookie 通知是可行選項，但可能難以整合至現有使用者介面，因此也很罕見。
互動視窗
強制回應是顯示在網頁內容頂端的 Cookie 同意聲明通知。 強制回應功能可能會因視窗大小而有很大的差異。
對於難以以不會造成版面配置位移的方式實作 Cookie 通知的網站而言，較小的部分畫面互動模式是不錯的替代方案。
另一方面，遮蓋大部分網頁內容的大型互動視窗也應謹慎使用。特別是，小型網站可能會發現使用者之所以跳出，而不是接受陌生網站的 Cookie 通知，因為其中含有遮蓋的內容。雖然上述概念不一定是同義詞，但如果您打算使用全螢幕 Cookie 同意聲明互動視窗，也應該瞭解 Cookie 牆的相關法規。
可設定性
Cookie 通知介面可讓使用者自行控管接受哪些 Cookie。
沒有設定
這類通知式 Cookie 橫幅不會向使用者提供停用 Cookie 的直接使用者體驗控制項，而是會加入網站的 Cookie 政策連結，提供使用者有關使用網路瀏覽器管理 Cookie 的資訊。這些通知通常包含「關閉」和「接受」按鈕。
部分設定
這些 Cookie 通知可讓使用者選擇拒絕 Cookie，但不支援更精細的控制選項。這種 Cookie 通知的做法比較少見。
完整設定
這些 Cookie 通知可為使用者提供更精細的控制項，以便設定使用者接受的 Cookie 使用方式。
使用者體驗：設定 Cookie 用量的控制項最常顯示，都是在使用者回應初始 Cookie 同意通知時啟動的獨立模組。不過，如果空間允許，部分網站會在初始 Cookie 同意聲明通知中以內嵌方式顯示這些控制項。
精細程度：最常見的 Cookie 設定方法，是讓使用者可依據 Cookie 的「類別」選擇採用 Cookie。常見的 Cookie 類別包括功能性、指定目標和社群媒體 Cookie。
然而，有些網站會更進一步，允許使用者依個別 Cookie 選擇加入。或者，如要為使用者提供更精細的控制選項，您也可以將「廣告」等 Cookie 類別細分為具體用途，例如允許使用者分別選擇瀏覽「基本廣告」和「個人化廣告」。
