聽覺反應時間測試會測量你在聽到聲音提示（通常是嗶聲、音調或語音提示）後反應的速度，並回報該音訊訊號與你按下按鍵之間的差距（單位為毫秒）。聽覺的神經傳導路徑比視覺來得短且較不複雜，因此同一個人在聽覺測試上通常會比視覺測試產生較低（較快）的數值。然而，瀏覽器型的反應時間測試使用的是視覺訊號：一個變綠的色塊，並提示你按下。瀏覽器所回報的毫秒數，是從網頁 ready-state 回呼觸發的那一刻，到瀏覽器收到你的指標或鍵盤事件為止的時間間隔，而不是從某個聲音開始算。這項差異很重要，因為這個分數除了包含你本身的反應時間之外，還涵蓋了顯示器的更新頻率、合成器排程、瀏覽器的工作時序、作業系統的輸入處理，以及輸入裝置的傳輸延遲。本文將逐步說明「反應時間測試」工具的運作方式、毫秒數實際涵蓋哪些範圍，以及如何解讀它為你保留的最近、最佳與平均值。
聽覺反應時間測試實際測量的是什麼
聽覺反應時間測試的本質，是一個把感測輸入替換進去的碼錶問題。經過一段隨機的等待時間後，會播放一個聲音——最常見的是短音調、喀噠聲、嗶聲或一個說出的詞——測試會在那一瞬間啟動計時器。你按下按鍵、按鈕或觸控表面的動作會停止計時器，兩者之間的差異會以整數毫秒回報。
聽覺測試與視覺測試之間的差別，在於觸發你決策的感官路徑不同。聽覺所經過的處理階段比視覺少，這也是為什麼同一個人在聽覺反應時間上通常會比視覺反應時間稍低一些。然而，在身體之外，兩種測試同樣受限於以下兩個延遲：系統的輸出延遲，也就是程式要求變更後螢幕變化或喇叭發聲的速度；以及系統的輸入延遲，也就是你的手指移動後，鍵盤、滑鼠或觸控事件抵達程式的速度。
本文所介紹的「反應時間測試」工具是一個視覺測試，而非聽覺測試。它不會發出音調，也不會測量你的聽力。如果你是搜尋聽覺反應時間測試而來、並想使用這個瀏覽器工具，你應該預期它是一個綠色色塊的視覺測試，而不是嗶聲。若想了解這兩種概念在實務上的比較，音訊反應時間測試的準確度：視覺實況檢驗一文會更深入地說明視覺與聽覺之間的差距。
瀏覽器工具如何將視覺訊號轉換為毫秒
反應時間測試將計時工作保留在瀏覽器中，並將狀態保存在當前的分頁裡。每一次測試都遵循相同的四步驟流程，這也使得最終產生的數字具有足夠的可重現性，方便跨次比較。
- 網頁使用 Math.random 產生 1,500 到 4,000 毫秒之間的整數等待時間，因此每次測試的訊號出現前的間隔都會改變。
- 當該段等待時間結束時，網頁會將色塊切換為「準備」狀態，並在繪製該變化的同一個回呼中，以 performance.now 單調時鐘記錄當下的時間。
- 你的按鍵（指標、Enter 或 Space）會在瀏覽器的輸入事件上觸發第二次 performance.now 讀數。
- 顯示出來的結果是兩次讀數之間的非負差值，並四捨五入到最接近的整數毫秒。
由於等待時間是在 1,500–4,000 毫秒的範圍內隨機產生，訊號並不具有固定的節奏。你無法可靠地從先前的測試預測色塊何時會變綠。網頁也會把任何在 ready-state 回呼之前送達的按鍵視為「誤啟動」並予以拒絕，這就是為什麼當你搶先按下時，會出現「Too soon」（太快了）的訊息。針對黃金路徑的確定性測試治具會產生一個剛好 234 毫秒的案例，用以驗證計時的數學邏輯，而非僅僅相信程式碼本身是自洽的。
逐步執行測試
- 開啟反應時間測試頁面，並讓該分頁保持在前景，以免被瀏覽器降速。
- 選擇「Start test」（開始測試），並留意等待訊息。在這個階段請勿按下任何按鍵——等待時間是在 1,500 到 4,000 毫秒之間隨機產生，因此時機無法預測。
- 當色塊變綠並顯示「PRESS NOW」（立即按下）的瞬間，請按下色塊本身，或在色塊取得焦點時按下 Enter 或 Space。
- 讀取以毫秒顯示的最新結果。這只是你最近一次測試的結果。
- 在相同的裝置、瀏覽器、輸入方式、視窗位置與顯示模式下，重複相同的流程至少完成五次測試。
- 比較最近五次結果，其中最小值視為「最佳」，四捨五入後的算術平均值視為「平均」。
- 選擇「Reset all」（全部重設）以取消尚未完成的測試，或在想要一個全新的比較區間時清除所有結果。
解讀最近、最佳與平均值
這個工具只會在當前分頁中保留最近五次已完成的測試。一旦加入第六次已完成的測試，超出該範圍的較舊紀錄就會從可見視窗中淘汰，這就是為什麼摘要反映的是目前的測試階段，而非你的完整歷史紀錄。
| 欄位 | 計算方式 | 其意義為何 |
|---|---|---|
| 最新（Latest） | 最近一次已完成測試的結果 | 最近一次嘗試與其他次比較的結果 |
| 最佳（Best） | 五次保留測試中的最小值 | 可見視窗中最快的非負讀數 |
| 平均（Average） | 五次保留測試的算術平均值，四捨五入到最接近的毫秒 | 可見視窗的粗略集中趨勢 |
| Too soon（太快了） | 按鍵在 ready-state 回呼之前送達 | 誤啟動；本次結果未加入視窗 |
由於平均值是五次保留整數結果的算術平均值，因此可以手動計算以便快速驗算。如果你最近五次測試分別是 245、238、251、240 與 246 毫秒，總和為 245 + 238 + 251 + 240 + 246 = 1,220 毫秒，四捨五入後的平均值為 1,220 / 5 = 244 毫秒，網頁會顯示為 244。該視窗中的最佳值則為 238。
分數除了你本身的反應之外，還包含哪些部分
螢幕上顯示的數字並非純粹的人類反應時間。從網頁希望訊號出現的那一刻，到你手指實際移動為止，中間隔著好幾個層次，每一層都可能為最終讀數增加或減少若干毫秒。
- 顯示器更新與像素反應。「綠色」狀態會在瀏覽器回呼期間繪製，但實際的像素發光則會等到該面板硬體的下一次更新週期。
- 合成器排程。瀏覽器可能會依引擎與當前負載，把視覺變更批次處理、延後或與其他工作一併合成。
- 瀏覽器工作時序。JavaScript 事件迴圈決定 ready-state 回呼實際何時執行，而 performance.now 量測的就是那個瞬間。
- 作業系統的輸入處理。作業系統會透過自己的佇列分派指標與鍵盤事件，瀏覽器隨後才會接收到這些事件。
- 輸入裝置的傳輸。有線鍵盤、無線滑鼠、藍牙周邊裝置或觸控板，各自都會帶來不同的實體傳輸延遲。
- 事件分派。當事件抵達網頁後，監聽器會記錄第二次的 performance.now 讀數。
這就是為什麼該頁面將自己定位為瀏覽器時序工具，而非經過校準的硬體延遲量測計。JavaScript 無法觀測到手指實際移動、開關閉合、無線封包離開裝置、或顯示像素發出綠光的物理瞬間。這個工具也明確說明，它並非用來測試聽力、無法診斷神經系統疾病、無法評估駕駛能力，也無法認證競技表現。
會讓你的數字產生波動的條件
若希望你的數字具備可比性，請保持環境的穩定。有若干現實因素會讓不同測試之間的分數產生數十毫秒的差異。
| 條件 | 對分數的影響方向 | 原因 |
|---|---|---|
| 背景分頁 | 變慢（毫秒值升高） | 瀏覽器會對非作用中的分頁進行降速，導致計時器與輸入事件都受到延遲 |
| 省電模式 | 變慢（毫秒值升高） | CPU 與顯示器的頻率下降，延長了更新週期與排程時間 |
| 高 CPU 負載 | 變慢（毫秒值升高） | 事件迴圈與合成器必須與其他工作競爭資源 |
| 遠端桌面或串流工作階段 | 變慢（毫秒值升高） | 訊號與按鍵都需經過額外的網路節點傳輸 |
| 可變更新率或像素位移模式 | 不一定 | 顯示器的時序在測試過程中發生變化 |
| 輸入裝置的無線干擾或低電量 | 變慢或不一定 | 輪詢率或傳輸延遲產生波動 |
若要做有意義的比較，請在不同的嘗試中使用相同的裝置、瀏覽器、輸入方式、視窗位置與顯示模式，並讓分頁保持在前景。請完成數次測試，而非把單一離群值當成結論。如果你比較滑鼠與鍵盤，請在兩組之間重設，並在頁面之外標示條件，因為這個小工具刻意不儲存任何實驗註記。這個分數並不會套用年齡對照表、百分位排名、通過／不通過標籤、運動基準或醫療閾值，因此任何這類的解讀都需要經過控制的實驗流程，而非這個通用工具所能提供。
相關閱讀：為你的兼職 Algonquin 課程使用線上時鐘。