最佳化 Cookie 通知的效能和可用性。
本文將說明 Cookie 通知對效能、效能評估和使用者體驗的影響。
效能
Cookie 通知可能會對網頁效能產生重大影響，原因在於這類通知通常是在網頁載入程序的早期載入、向所有使用者顯示，而且可能影響廣告和其他網頁內容的載入情形。
以下是 Cookie 通知對網站體驗指標指標的影響：
最大內容繪製 (LCP)：大多數的 Cookie 同意聲明通知都很小，因此通常不包含網頁的 LCP 元素。然而，這可能發生於行動裝置，尤其是行動裝置。在行動裝置上，Cookie 通知通常會佔據大部分畫面。通常是當 Cookie 通知包含大量文字區塊 (文字區塊也可以是 LCP 元素)。
首次輸入延遲時間 (FID)：一般來說，Cookie 同意聲明解決方案本身對 FID 的影響最小，只須執行少量 JavaScript 就能取得 Cookie 同意聲明。不過，這些 Cookie 啟用的技術 (亦即廣告和追蹤指令碼) 可能會對網頁互動產生重大影響。將這些指令碼延後到接受 Cookie 為止，可以做為減少首次輸入延遲時間 (FID) 的技術。
累計版面配置位移 (CLS)：Cookie 同意聲明通知是版面配置位移的常見來源。
一般來說，相較於您自行建構的 Cookie 通知，第三方供應商的 Cookie 通知可能更能提升成效。這不是 Cookie 通知特有的問題，而是第三方指令碼的性質。
最佳做法
本節的最佳做法著重於第三方 Cookie 通知。這些最佳做法中，有部分 (但非全部) 也適用於第一方 Cookie 通知。
以非同步方式載入 Cookie 通知指令碼
Cookie 通知指令碼必須以非同步方式載入。方法是在指令碼標記中加入 async 屬性。
<script src="https://cookie-notice.com/script.js" async>
非非同步的指令碼會封鎖瀏覽器剖析器。這會延遲網頁載入和 LCP詳情請參閱有效率地載入第三方 JavaScript 一文。
直接載入 Cookie 通知指令碼
請將指令碼標記放在主要文件的 HTML 中，以便「直接」載入 Cookie 通知指令碼，而不是由代碼管理工具或其他指令碼載入。使用代碼管理工具或次要指令碼插入 Cookie 通知指令碼，就會延遲載入 Cookie 通知指令碼：這麼做會從瀏覽器的 Look 圖表剖析指令碼，防止指令碼在 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 通知是版面配置位移的常見來源。如果在周圍網頁轉譯後，將 Cookie 通知插入 DOM，系統會將其下方的網頁元素下移往下移。只要在 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 類別。
綜合監控
如果沒有自訂設定，大多數合成工具 (例如 Lighthouse 和 WebPageTest) 只會評估未回應 Cookie 同意聲明通知的初次使用者體驗。不過，在收集效能資料時，不僅需要考量快取狀態的變化 (例如初始造訪和重複造訪)，還須考量 Cookie 接受狀態的變化，包括接受、拒絕或未回應。
以下各節將說明 WebPageTest 和 Lighthouse 設定，有助於將 Cookie 通知納入效能評估工作流程。然而，Cookie 和 Cookie 通知只是在研究室環境中難以完美模擬的眾多因素之一。因此，請務必將 RUM 資料做為效能基準的基石，而非使用合成工具。
使用 WebPageTest 測試 Cookie 通知
影片腳本
您可以使用指令碼讓 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。如要使用特定 Cookie 集透過 CLI 執行 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 通知的可能設計時，請思考以下幾點：
- UX：是否提供良好的使用者體驗？這項特殊設計對現有網頁元素和使用者流程 有何影響？
- 業務：您網站的 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 類別細分為特定用途，例如允許使用者另外選擇採用「基本廣告」和「個人化廣告」。
