UI 效能測試通常量的是什麼
初次載入：首次繪製時間、可互動時間、打包體積。這些對第一次造訪確實重要，現有工具也支援得很好，而且大多是每個工作階段只付出一次的成本。
使用者真正會注意到的是什麼
互動延遲
從點擊到畫面上出現反應之間的空檔。
不像載入，這在一個工作階段裡會發生數百次。
感知到的回應速度
介面究竟有沒有對這個操作做出回應。
在 100 毫秒內出現載入動畫，感覺上比沉默 400 毫秒來得快，即使它實際上比較慢。
資料一多就劣化
十筆資料時很順，兩千筆時根本不能用。
在乾淨的測試環境裡完全看不出來。
第三種最常一路溜進正式環境，因為測試環境的資料量很小，而客戶帳號不是。
真正重要、卻通常沒人量的那一項
拿同一段流程去跑一份接近真實規模的資料集。這不是負載測試，只是一個使用者，對上一個資料量與真實客戶相當的帳號。一份清單在十筆資料時 80 毫秒渲染完成、在兩千筆時要四秒，這就是缺陷，而在乾淨環境上做再多負載測試，都不會讓它現形。
為什麼在這裡正確性一樣要擺第一
一個因為請求默默失敗而瞬間渲染完成的介面，並不叫快。在量任何東西之前，先確認流程做到了它該做的事，再去量它花了多久。順序反過來，你得到的只是一組對著壞掉畫面信心滿滿的數字。
那個沒人維護的種子資料帳號
這個頁面建議的做法，大多都仰賴一個有真實資料量的環境，而團隊之所以沒有，理由值得直接談一談。
建一個不難，難的是讓它持續貼近真實，因為資料結構會變動、種子腳本會腐壞，兩季之後它產出的帳號已經不像任何東西了。到了那個時候，大家就不再信任它，回頭用十筆資料做測試。
能撐下來的版本，是從正式環境的樣貌生成，而不是來自一份寫死的腳本：取真實帳號各自擁有多少筆記錄的分佈，再照著第九十百分位數建一個測試帳號。它需要的是偶爾重新生成，而不是持續維護，而且因為來自客戶實際擁有的資料，它會一直誠實。
看回歸，而不是看絕對值
從各種基準借來的絕對目標，很少能套用到你身上。在同一個環境追蹤你自己的數字，並留意它的變動。有用的警訊是某段流程這週變慢了，而不是它超過了某人挑出來的一個數字。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果不想在本機安裝，儀表板一樣能涵蓋這些事，而完整的指令清單則放在 CLI 儲存庫。
如果管線屬於另一個團隊， GitHub App 是阻力最小的路徑：它就是一個 webhook，不會更動你儲存庫裡的任何東西，並且在你的建置回報新版本上線時觸發。如果你希望這個檢查直接顯示在儲存庫裡，一個 GitHub Actions 步驟也能做到。
TestSprite 會先驗證什麼
正確性，任何效能數字要有意義，都得先有它。一個因為請求默默失敗而瞬間渲染完成的介面，分數會漂亮得不得了，而這正是這裡要抓出來的失敗。
測試覆蓋由你的產品生成，每次變更都會對已部署的應用程式執行，也包含對一個具備真實資料量的種子帳號執行，而那正是會流進正式環境的效能劣化真正現形的地方。
計時與效能分析仍然交給專門的工具。你在這裡得到的，是確信被量測的那段流程確實能正常運作，以及當一份清單不再能隨資料量擴展時的早期訊號，因為改變的不只是時間，還有行為。
TestSprite 會量測 UI 效能嗎？
它驗證流程的行為是否正確，而那是前提。計時與效能分析是另一套工具。
我們該先追蹤哪個指標？
在一個接近真實規模的帳號上，量你最常被使用的三個操作的互動延遲。它比載入時間更貼近使用者的抱怨。
我們要怎麼取得真實的資料量？
把一個測試帳號灌到大型客戶的規模，然後留著它。只要它第一次抓到某份清單不再能隨資料量擴展，這份工夫就回本了。
感知效能值得特地去做嗎？
值得，而且成本很低。立刻讓使用者知道操作已被接收，對體驗的改變比真的省下幾毫秒還大。
效能該不該擋下一次發佈？
常用互動上的大幅退步，該擋。小幅波動就不必，否則你的時間都會花在調門檻上。