如果在閱讀上述文章後，您仍然無法歸咎造成點擊和工作階段次數落差的原因，問題可能出在速度延遲上。速度延遲所造成的點擊和工作階段次數不符問題，通常有下列幾項特徵：
- 無法將點擊和工作階段次數落差的源頭縮小到特定廣告活動、廣告群組或關鍵字。
- 在所有有效的 Google Ads 廣告活動中，「工作階段」的數量總是低於「點擊次數」。
- 按裝置 (如桌機、平板電腦、行動裝置) 劃分資料時，多個平台都出現點擊和工作階段次數不符的現象。
本文內容：
速度的重要性
「網路使用者通常不太有耐心」是廣受許多研究支持的論點，KissMetrics 的研究就提到一些發人深省的論述，包括「網頁反應延遲一秒，就可能錯失 7% 的轉換量」，以及「47% 的消費者期望網頁在兩秒以內載入完畢」。
也就是說，如果您的網站載入太慢，使用者很可能因此斷然離開並前往競爭對手的網站；要是競爭對手能夠迅速地提供相同的內容，誘因就更大了。
程式碼必須安插在適當位置
常有廣告客戶問我們：「Analytics (分析) 追蹤程式碼究竟該安插在 HTML 網頁原始碼的哪裡？」這點取決於您衡量使用者跳出狀況的精確程度。每次發生點擊後，如果系統需要數秒的時間才能記錄一次工作階段，這很可能導致系統來不及追蹤某些工作階段。我們通常建議讓追蹤程式碼緊靠在 </head> 結尾標記前面。
速度緩慢導致的後果
短暫點擊：這是指使用者點擊廣告後，Analytics (分析) 的追蹤程式碼請求還沒來得及啟動，使用者就點選上一頁按鈕或關閉瀏覽器。在這類情況下，Google Ads 會計入點擊，但 Analytics (分析) 卻沒有記錄到對應的工作階段。
一般來說，網站反應速度越慢、且出現在 Analytics (分析) 程式碼片段前的請求量越多，就越有可能發生短暫點擊，導致系統來不及記錄工作階段資料。
另外，發生短暫點擊就表示有使用者跳出網站；如果沒有追蹤跳出的工作階段，跳出率很可能會反常地偏低，無法反映實際狀況。
行動裝置和短暫點擊：行動裝置的網路傳輸速度 (3G 網路) 通常比大多數的電腦 (ADSL/Cable) 慢。指定在行動裝置上放送廣告時，反應快速的網站是避免短暫點擊出現的一大關鍵。
短暫點擊的暫時解決方式
這裡提供一個短暫點擊的暫時解決方式：儘可能在 HTML 原始碼中的高處安插 Analytics (分析) 追蹤程式碼片段，最理想的位置是所有 JavaScript 檔案的上方。
以上面這張螢幕擷取畫面為例，多個 JavaScript 檔案請求 (同步代碼) 處理完畢後，才輪到 Analytics (分析) 追蹤程式碼片段執行。稍後我們會討論最佳化的技巧，但您可以先將 Analytics (分析) 的追蹤程式碼片段移到其他 JavaScript 檔案的上方，暫時解決這個問題。由於 Analytics (分析) 採用非同步 JavaScript 代碼，因此不會拖慢網頁的載入速度，就算 Analytics (分析) 的伺服器延遲，也不會影響您網頁的載入時間，請放心。
您採行這個暫時解決方法後，應該有助於及時記錄因使用者過早離開網頁而漏記的工作階段 (因為 Analytics (分析) 程式碼片段能夠提早執行)，但從長遠來看，您仍然得改善龜速網站才能解決潛在問題，留住跳出的使用者。
如何判斷速度是否過慢
剛才提到，將 Analytics (分析) 追蹤程式碼放在 HTML 原始碼中較高的位置能暫時解決問題，但提升網站反應速度也很重要。
不過，究竟該怎麼判斷網站是否過慢呢？
測試 1：
在沒有快取的情況下 (您可以清空快取和 Cookie) 開啟新分頁，在瀏覽器的網址列中輸入您的實際連結網址，然後開啟 Chrome 開發人員工具並前往 [Network] 分頁。
接著請載入網站並查看請求清單，看起來應該像這樣：
找出 _utm.gif (舊版 Analytics (分析)) 或 collect (通用 Analytics (分析))，並查看右側的時間軸部分。以上圖為例，從送出第一個請求 (記錄點擊) 到 Analytics (分析) 的請求發生 (記錄工作階段) 為止，之間過了大約 8 秒的時間。
如果使用者在這 8 秒內點選上一頁按鈕，Google Ads 仍會計入一次點擊，但 Analytics (分析) 可能來不及為這個網站記錄一次工作階段。
別忘了 KissMetrics 是怎麼說的：「半數使用者期望網頁在兩秒內載入完畢」。 由此可知，這個網站仍有進步的空間。
測試 2：
Analytics (分析) 會自動擷取網頁載入時間的資料，並記錄到網站速度報表中。
您可以透過這份報表查看特定 Google Ads 實際連結網址，以便瞭解延遲狀況。以這個範例的示範網址來說，網站速度大約是 25 秒，實在是太慢了。
由此可知這個網頁跳出率偏高的原因。這個實際連結網址產生了許多短暫點擊 (意即跳出)，再加上實際記錄到的工作階段跳出率偏高，成效當然不理想。
理想的網頁載入速度大約是 3-4 秒。
您雖然可以透過網站速度報表得知網頁載入時間，但根據預設，系統只從 1% 的流量中取樣。如果您的網站每日訪客人數較少 (例如 10 萬以下)，建議您調高取樣百分比 (如流量的 5%)，以便取得更精細的網頁載入時間和其他「網站速度」指標資料。
在此提醒您，這麼做會建立一個額外請求，但通常不會對使用者體驗產生負面影響。
加快速度的方法
您現在還可以透過 Analytics (分析) 的網站速度報表，取得網站速度建議，只要輸入點擊量最高的實際連結網址，即可查看加快網頁速度的建議。
移除重新導向或更新實際連結網址
雖然重新導向能夠保留 Google Ads 自動標記參數，並將參數傳送至最終實際連結網址，但重新導向也會拖長點擊與 Analytics (分析) 記錄工作階段之間的時間。
有時候，網站擁有者在 Google Ads 點擊和最終實際連結網址間會設定多個重新導向。
建議您將 Google Ads 實際連結網址改為最終實際連結網址，這麼一來就不需要重新導向。
另外，客戶有時會使用點擊伺服器這類中介服務記錄 Google Ads 點擊 (第三方報表平台常用這類服務)。
我們瞭解您想透過多個平台多方記錄資料，但這類服務可能拖慢網站速度，導致使用者體驗不佳。如果您透過 Analytics (分析) 記錄的點擊和工作階段次數有問題，建議您移除這個點擊追蹤程式服務一段時間，看看點擊與工作階段兩者的數量比例有無改善，然後重新評估是否要繼續在第三方平台中追蹤點擊，或另找速度更快的服務供應商。
CSS 合併圖片
CSS 合併圖片可取代多個圖片請求。
上圖的網站送出了多個小型圖片圖示及檔案的圖片請求 (.png 檔案)。CSS 合併圖片的優點，說穿了就是將所有的圖片集結成一個請求 (一個大型圖片)，並利用 CSS 控制哪一部分的圖片應顯示在網站的哪個區域。這樣能夠將圖片請求數量減到最少，處理單一大型圖片請求的速度也比多個小型圖片請求更快。
使用內容傳遞聯播網
內容傳遞聯播網不但是加快網站速度的妙方，還能打造出規模更大更可靠的網站，箇中原理，在於將網站中頻繁存取的檔案和內容分散在全球各地的多個伺服器中。
網站代管服務的據點通常是一個固定的實體地點，例如加州。對於加州當地使用者來說，這是一項利多，因為他們可以快速地取得網站的內容，至於澳洲或歐洲等地的使用者，就得等待更長的時間才能從加州取得檔案。但只要藉助內容傳遞聯播網，使用者可改從所在實體地點附近的伺服器接收檔案。
此外，藉由將網站內容散佈到全球各地的多個伺服器，還能降低停電、服務中斷或其他基礎架構問題所造成的影響。
內容傳遞聯播網適合用來傳送通常是靜態或不常修改的內容 (如 JavaScript 檔案、CSS、HTML，以及圖片或影片內容)，它還會移除 JavaScript、CSS 和 HTML 檔案中多餘的行距，儘可能將這些檔案壓縮至最小。
Google 本身也提供內容傳遞聯播網服務，名為 Google PageSpeed。
壓縮 HTML、CSS 和 JS 檔案
如果不想使用剛才提到的內容傳遞聯播網服務，您可以改為選用各式各樣的模組、外掛程式及免費網站服務來移除多餘行距，並將多個檔案 (例如 CSS 檔案) 合併為單一請求，自動壓縮內容。
快取常用請求
有個常用的網路伺服器堆疊採用 Linux Apache MySQL PHP (LAMP)。
如上圖所示，將 HTML 生成的網頁傳送給使用者的過程實際上牽涉多個步驟，包括：
- 網路伺服器收到請求
- 網路伺服器接著經由 PHP 傳送請求，並由 PHP 判斷該存取哪個檔案/資料庫中的哪些資料列
- PHP 將傳送的內容封裝起來並建立相關的 HTML 網頁，然後傳送給使用者
快取的作用
在多數情況下，網頁內容並不會在使用者每次要求載入網頁時變動 (例如常見問題網頁)。因此，與其照著上圖的做法執行整套流程，系統可以建立網頁一次，並將其快取為 HTML 暫存檔；這樣一來，網路伺服器可以向大部分使用者直接送出靜態的 HTML 檔案，不必經由 PHP 重複同樣的網頁產生作業，也無需一而再、再而三地向資料庫送出查詢。網路伺服器擺脫不斷持續的多工處理流程後，自然能夠為所有人加快網站載入速度。
有許多免費的模組可以替您的網站執行這類工作。
雖然本文以 PHP 作為範例，但許多其他網路伺服器的運作方式大同小異，不難找到相似的模組來完成這類網頁快取工作。
考慮使用 Ajax 與外掛程式 (如 Infinite Scroll 或 Jquery 的 Lazy Load 等)
也許您曾經注意到，有些網站在使用者向下捲動網頁時才載入內容。YouTube 除了相關影片的縮圖外，也在留言部分採用這個做法：畫面上只顯示前幾則留言，使用者要求載入更多留言時，才會顯示更多內容。
適當地使用這項技術可縮小初始請求的網頁大小，以便使用者立刻與網頁互動。使用者想查看更多內容時，繼續向下捲動就能載入更多項目。
採用這個解決方法時，有幾個可用性及功能相關問題需要留意。如想瞭解相關詳情，請參閱 LazyLoad 和 InfiniteScroll 的說明文件。
Gzip 壓縮
舊版網路瀏覽器並不支援這個網頁壓縮方式 (HTML、CSS、JavaScript 等)，但新版瀏覽器 (包括行動裝置) 都適用。您通常只要按一下開關就能透過這項功能壓縮內容，非常便利。
如想進一步瞭解 Gzip，請觀賞這部影片。
升級為通用 Analytics (分析)
如果您尚未從傳統版 Analytics (分析) (ga.js) 升級為通用 Analytics (分析) (analytics.js)，建議您遷移至最新版的 Analytics (分析) 平台。這樣一來，您不但可以使用最新的產品功能，通用 Analytics (分析) 還能為您提升兩方面的效能：
- 模組式追蹤程式碼庫：analytics.js 擁有 Ecommerce 等多個外部模組，因此再也不會將這類模組加進所有的網站中 (ga.js 則會這麼做)。這樣可降低 analytics.js 的檔案大小，進而加快檔案傳輸速度。
- 減少對 Cookie 的依賴程度：通用 Analytics (分析) 現在會計算伺服器端 (而不是用戶端) 的廣告活動和工作階段資料，藉此減少每次檔案請求的 Cookie 資料傳輸量。它能夠提升的成效雖有限，但不容忽視。
速度更快的網站代管伺服器
龜速網站很可能導致您錯失商機，建議您考慮改用速度更快的網站代管伺服器。
其他訣竅和建議
本文篇幅有限，無法涵蓋所有可用的最佳化技術，但我們備妥了其他文件供您參考：如想瞭解更多訣竅和建議，請參閱這份說明文件。
最後要提醒您，就算您盡了全力提升自家網站的反應及傳輸速度，但不免會遇到使用者網路連線或行動網路過慢的問題；在偏遠的鄉村地區，以及電信基礎建設老舊或涵蓋範圍有限的開發中國家/地區，這個問題會更加明顯。
在這種情況下，建議您儘可能加快網站的反應速度，但就算是最面面俱到的網站，也可能因為使用者的網路連線過慢而碰上短暫點擊的問題。
