長期關注HubSpot One數字行銷的讀者一定知道在過去的幾年中行銷長多次講解了有關優化網頁加載速度和谷歌CWV指標的話題。事實上，多年來一些網站分析工具中都會提供一些指標來衡量網頁加載速度。像Google Analytics這樣的工具中就提供了這些指標。
注意，GA4還沒有引進這些指標。行銷長猜測谷歌認為這些指標的應用還有一定局限性，因此還沒有加入到新版本中。如果你熱愛添加這些老舊的指標，你可以查閱David Vallejo的部落格，他提供了詳盡的部署方法。國內也有人轉載了，行銷長就不重複勞動了。
那麼好奇的讀者有沒有想過一個問題，網頁載入的時候GA並沒有加載，那麼GA是如何知道網頁加載速度的呢？是不是GA標籤放在越前面，網頁加載速度就越快呢？
其實這些都要歸功於現代瀏覽器支持的Performance API。我們可以隨便拿個瀏覽器，打開DevTools裡的Console工具。然後輸入window.performance.timing回車，就可以得到各個關鍵時間點的時間戳。
你在上圖看到的166開頭的一長串數字就是以毫秒為單位的時間戳。始於1970年1月1日。比如你可以算一下上圖中1665653523203這個connectEnd的時間戳對應的日期時間，你可以在網站currentmillis.com直接計算。或者在Excel中用公式計算=[166….]/86400000+DATE(1970,1,1)+8/24
當我們理解了這一串數字背後的意義，我們就很容易去對它們進行排序並洞察一些時間指標了。你是否還記得行銷長之前提供了頁面加載的順序？
現在是不是就對上了？我們可以把這些時刻進行一定的運算並得到一些關鍵指標，具體地來說：
- Page Load Time: loadEventStart – navigationStart
- Page Download Time: responseEnd – responseStart
- DNS Time: domainLookupEnd – domainLookupStart
- Redirect Response Time: fetchStart – navigationStart
- Server Response Time: responseStart – requestStart
- TCP Connect Time: connectEnd – connectStart
- DOM Interactive Time: domInteractive – navigationStart
- Content Load Time: domContentLoadedEventStart – navigationStart
上面這八個指標就可以通過時間戳的計算得出。一些時候我們會發現計算出來的時長為0，比如TCP Connect Time為0，這說明載入該頁面時本身已經建立了TCP連接。再比如DNS Time為0，那就說明該域名的DNS查找已經被緩存，無需額外進行。
當我們理解到了這個層面，我們就可以更好地拆解載入頁面的各個指標的影響因素了。
比如Page Download Time是響應開始到結束之間的經過時間，這就純粹是下載時間，由帶寬傳輸速度決定。如果客戶端帶寬很低那麼你怎麼樣都無法優化。
又比如Server Response Time是請求開始到響應開始之間經過的時間，這會由伺服頁面需要計算的複雜度決定，那麼服務期的CPU和內存將會有直接影響。如果你選擇更多的服務器端渲染並以此優化SEO，那麼這個指標也會上升，因為你需要更多計算。
除了這些GA定義的指標，你也可以自己定義一些指標。比如新建一個DOM Load Time ：
- DOM Load Time: domContentLoadedEventStart – responseEnd
這個指標將揭示頁面在客戶端拼裝需要花費的時間，相對我們前面說的服務期渲染，這是客戶端渲染的指標。那麼這樣我們也可以了解到如果Page Load Time很長，到底問題在哪裡。
說到這裡，行銷長把2019年的坑給填了，可喜可賀。最後再說兩點：
- 如果你想要對GA4應用這些指標，推薦結合Google Looker Studio（原Google Data Studio）這樣處理毫秒級的指標間運算要方便許多。畢竟GA4裡能提供的自由度太低了。具體的做法參考《GA4+Data Studio才是正確打開方式？ 》
- 這些本篇介紹的指標都相當精確。但是呢，精確不代表能反映實際情況。這也是為什麼谷歌引進了Core Web Vitals來對用戶體驗進行更好的評估。如果你發現Core Web Vitals中的LCP和FID不太好（CLS和速度關聯不大），那麼可以利用這些指標來進行拆解深挖，定位具體問題出在哪兒，並採取相應措施。