Firebase Performance 使用筆記

/

firebase上的功能愈來愈多

在進firebase看資料時,會看見firebase一直都有在更新,不論是UI、樣式,或是功能,這篇筆記的performance功能就是不小心點到,然後不小心看到的。

firebase的導覽列,通常品質數據分析這2個大類別,都是要有app才能使用,點進去會看見的是要有Android、IOS才行,有一天點了Performance,看見用JavaScript也行的icon,驚為天人,就打開文件看使用說明。

網頁app的icon,通常是指JavaScript
網頁app的icon,通常是指JavaScript

文件上的一個alert就是在說目前web performance還是beta狀態,之後會不斷更新:

The Firebase JavaScript SDK for Performance Monitoring is a beta release.

This product might be changed in backward-incompatible ways and is not subject to any SLA or deprecation policy.

雖然還在beta,但有看見新東西就會想玩一下,這幾天就埋了code來玩。

數據是12小時更新,在寫這篇時code才埋了2天,FID(first input delay)用的code也才剛埋,所以之後會再更新本篇內文部份。


建立firebase應用程式,取得firebase config

因為是firebase其中之一個功能,在埋code前要前有firebase的專案,開專案的方式可見官方說明:

Add Firebase to your JavaScript projcet

開完專案後,點選左側導覽列的Performance,接著點右側新增應用程式上面那個</>樣子的icon:

新增應用程式
新增應用程式

點擊後就會開啟一個輸入應用程式名稱的表單,填完後按註冊,就會看見頁面顯示出了firebaseConfig:

註冊完應用程式,出現的firebaseConfig
註冊完應用程式,出現的firebaseConfig

firebaseConfig先存下來,埋code時會用到。

如果來不及存就關掉視窗,之後也可以從專案設定中看到。

這是廣告,點擊一下可以幫本站多個一點點的廣告收入,謝謝


firebase performance埋code

firebase performance要埋的code,基本上步驟有以下3步:

  1. 埋碼:standalone SDK || standard SDK
  2. 埋碼:FID first input delay polyfill library
  3. 從network中確認有送資料給firebase performance

埋碼:standalone SDK || standard SDK

firebase performance基本的功能code有4種埋碼方式:

  1. standalone SDK:單純用firebase performance的功能時用
  2. standard SDK:除了performance的功能外,還有其它firebase的功能要用時用
  3. Hosting URLs:用firebase的主機時用
  4. module bundlers:用Browserify、webpack打包js檔時用

本篇筆記實驗的站是埋碼在GTM上,而且也只用performance的功能,因此選用的是第一種。

以下附上1、2的埋碼code。

standalone SDK

如果要用到custom traces功能,就要另外加上 window.perf = firebase.performance(); 這行。

standard SDK

埋碼 FID first input delay polyfill library

埋完firebase performance基本功能的code後,接著要埋first input delay的code。

first input delay,看google上的介紹,就是使用者進到頁面後,一直到做了第一個動作,這之間的時間。

第一個動作,看原始碼是以下:click、mousedown、keydown、touchstart、pointerdown。

這種計算概念覺得蠻好的,頁面繪製出第一個pixel,或是頁面載入完成,那些是系統時間。

這是廣告,點擊一下可以幫本站多個一點點的廣告收入,謝謝

但在速度這個項目,除了有系統時間,也有一個每個人的感覺時間。感覺快、感覺慢,那都是個人因素,firebase把使用者做了第一個動作的部份去當成數據,很偏向UX的一個設計。

FID的基本功能code如下:

埋完FID的基本code,之後還要觸發function才會執行,function是這樣:

perfMetrics.onFirstInputDelay(callback);

官方文件提供的範例是,callback裡面寫ga事件,不過因為我的站是埋gtag,所以callback改成gtag event tracking:

關於GA事件追縱的說明可看這篇:Google Analytics 事件追蹤設定

從network中確認有送資料給firebase performance

埋完上面2段程式碼後,接著就是要檢查有沒有成功。

開啟開發人員工具,windows按F12,mac點右鍵按檢查,開發人員的面板就會出來,接著選Network,會看見每個檔案的執行時間,再點選單的XHR濾出AJAX的部份,檔名會是log開頭的,點了檔案後,看一下Request URL是不是firebaselogging.googleapis.com開頭,如果是,再看Status Code是不是200,都是的話就代表資料發送成功。

檢查network中,有沒有發向firebase的POST
檢查network中,有沒有發向firebase的POST

以上三步都完成後,就是等待了,firebase上寫12小時內會產生報表,所以埋完code要做的就是等待。


firebase performance後台報表

當firebase收到數據並更新後,再從firebase的左側選單點Performance,就會看見畫面換成數據的樣子。

目前是放在自己經營的另外一個站上當測試,首先會看到的資料如截圖:

firebase performance後台首頁
firebase performance後台首頁

直接點網址的話,會出現各階段所耗的時間:

各階段所耗時間
各階段所耗時間

網路,會出現網站中,所有request所需的時間:

所有request所需時間
所有request所需時間

再點進各個網址,會看到2個指標:

網路 網址
網路 網址

點查看更多,會出現更詳細的資料:

網路 網址 查看更多
網路 網址 查看更多

覺得厲害的是,竟然還看得到Service worker的使用狀態,看得到多少裝置是受控/不受控/不支援的:

網路 網址 查看更多Service worker狀態
網路 網址 查看更多Service worker狀態

更多的使用紀錄待之後更新

前面開頭有寫到,這幾天也才剛使用,像custom traces的code也才埋沒多久,還沒看到報表,本篇之後有新的發現會再更新。


Summary
Firebase Performance使用筆記
Article Name
Firebase Performance使用筆記
Description
本篇大綱:建立firebase應用程式,取得firebase config、firebase performance埋code、埋碼standalone || standard、first input delay polyfill library、從network中確認有送資料給firebase、後台報表
Augustus
Let's Write
Let's Write
https://letswrite.tw/wp-content/uploads/2020/08/logo_512.jpg

隨選筆記文

Analytics Google

Google Analytics 事件追蹤設定

WordPress

WordPress:埋 Google AdSense 廣告

Front-End

File API 客製上傳檔案按鈕 / input file

Google Maps

Google Maps API 學習筆記 – 1:地圖、標記、客製樣式

PWA

PWA 學習筆記 – 2:Workbox CLI

Vue

用 VuePress 製作說明文件頁面 – 4:佈景主題、外掛

Front-End

Netlify + GitLab 建一個免費靜態網站

PWA

PWA學習筆記-1:cache、workbox基本使用

WordPress

WordPress SEO 有幫助的 2 個外掛

WordPress

Ubuntu 安裝 WordPress – 3:VM、資料庫權限、PHP、WordPress

訂閱
通知
guest
4 Comments
最舊
最新
Inline Feedbacks
看所有留言
taitan
taitan
5 月 之前

請問先進,Firebase Performance SDK埋設之後,老闆一直問說那API latency多少才正常?我有看了Dashborad上面的問題面版,大多是10%的存取超過2秒會被列成問題,請問這就是所謂的預設門檻嗎?Google有正式官方的說帖嗎?感謝!

titan
titan
回覆給  Augustus
5 月 之前

先進好,我們其實有埋好SDK了,也監看了一陣子了。只是老闆很愛咬文嚼字,一定要有個業界標準才甘願投入資源調效能~但Google文件確實少之又少。
做了一晚功課也自己回覆給自己,也希望先進指教糾正。
1.關於API latency與回應時間:API latency應該是server端那段的處理時間,而回應時間就是E2E整段從前端發送到收到回應的等待時間。

2.兩秒門檻值:業界常說回應時間最好都在1~2秒內,很久以前甚至也有所謂的Nielsen 8秒理論或後來的4秒理論。但Firebase 的預設值是2秒。證據在編輯門檻值的畫面中。

3.比例:之所以定10%,是因為大多數的SLA規範是希望90%百分位都能有好效能。故若有10%的要求回應時間超過2秒,就該算是問題。https://www.perfmatrix.com/90th-percentile-in-performance-testing/

4.統計區間:目前觀察Firebase Performance的報表,會有本月的近30天、近7天、1天的統計。最短為1天。若1天中有超過10%的要求回應時間超過2秒,就會被算是問題

圖片 12.png

Let's Write

前端工程師 Augustus 的學習筆記 — solving problems, in simple ways.