聽覺反應時間測試會測量你在聽到聲音提示（通常是嗶聲、音調或語音提示）後反應的速度，並以毫秒為單位回報該音訊訊號與你按下按鍵之間的時間差。聽覺神經傳導路徑比視覺路徑更短且更不複雜，因此同一個人在聽覺測試中得到的數字通常會比在視覺測試中更低（更快）。然而，基於瀏覽器的反應時間測試使用的是視覺訊號：一個會變成綠色並提示你按下的彩色面板。瀏覽器所回報的毫秒數，是從頁面的 ready-state 回呼觸發的那一刻，到瀏覽器收到你的指標或鍵盤事件的這段時間間隔，而不是從聲音開始算起。這個差異很重要，因為這個分數除了包含你自己的反應時間外，還涵蓋了顯示器更新、合成器排程、瀏覽器工作排程、作業系統的輸入處理，以及輸入裝置的傳輸延遲。本文將逐步說明反應時間測試工具的運作方式、這些毫秒數實際上涵蓋了哪些範圍，以及如何解讀它為你保存的最新值、最佳值與平均值。
聽覺反應時間測試實際上測量的是什麼
聽覺反應時間測試本質上就是一個計時器問題，只是把輸入換成了感官刺激。經過一段隨機等待時間後，會播放一個聲音——最常見的是短音、喀噠聲、嗶聲或一個說出的詞——測試在那一瞬間啟動計時器。你按下按鍵、按鈕或觸控表面的動作會停止計時器，兩者之間的差異以整數毫秒數回報。
聽覺測試與視覺測試之間的差異，在於觸發你決策的感官傳導路徑。聽覺經過的處理階段比視覺少，這也是為什麼同一個人在聽覺測試中的反應時間通常會比視覺測試稍低一些。然而在身體之外，兩種測試都同樣受到兩個延遲的限制：系統的輸出延遲，也就是程式要求後螢幕變化或喇叭發聲的速度；以及系統的輸入延遲，也就是你的手指移動後，鍵盤、滑鼠或觸控事件抵達程式的速度。
本文所介紹的反應時間測試工具是一個視覺測試，而非聽覺測試。它不會發出音調，也不會測量你的聽力。如果你是搜尋聽覺反應時間測試而來，並想使用這個瀏覽器工具，你應預期會看到綠色面板的視覺測試，而不是嗶聲。如需了解這兩種概念在實務上的比較，聽覺反應時間測試的準確度：視覺現實檢驗一文會更深入地說明視覺與聽覺之間的差距。
瀏覽器工具如何將視覺訊號轉換為毫秒數
反應時間測試將計時工作保留在瀏覽器中，並將狀態保存在當前的分頁裡。每次測試都遵循相同的四步流程，這也使得最終產生的數字足以在不同嘗試間進行比較。
- 頁面使用 Math.random 產生一個介於 1,500 與 4,000 毫秒之間的整數等待時間，因此每次測試的訊號出現間隔都不同。
- 當等待時間結束時，頁面將面板切換為就緒狀態，並在同一個繪製該變化的回呼中使用 performance.now 單調時鐘記錄當下時刻。
- 你的按鍵——指標、Enter 或空白鍵——會在瀏覽器的輸入事件上觸發第二次 performance.now 讀取。
- 顯示的結果為兩次讀取之間的非負差值，四捨五入到最接近的整數毫秒。
由於等待時間在 1,500–4,000 毫秒的範圍內隨機產生，因此訊號並無固定節奏。你無法可靠地根據前幾次測試來預測面板何時會變綠。頁面也會將任何在 ready-state 回呼之前抵達的按鍵視為誤啟動而予以拒絕，這就是為什麼當你太早按下時會出現「Too soon」訊息。一個針對黃金路徑的確定性測試固定裝置會產生正好 234 毫秒的案例，藉此驗證計時運算，而非僅僅相信程式碼本身的一致性。
逐步執行測試
- 開啟反應時間測試頁面，並將該分頁保持在前景，避免瀏覽器對其進行節流。
- 選擇「Start test」並留意等待訊息。在此階段請勿按下任何按鍵——等待時間在 1,500 與 4,000 毫秒之間隨機產生，因此無法預測確切時刻。
- 在面板變綠並顯示「PRESS NOW」的瞬間，按下面板本身，或在面板已聚焦時按下 Enter 或空白鍵。
- 讀取以毫秒為單位顯示的最新結果。這僅代表你最近一次的測試結果。
- 在相同的裝置、瀏覽器、輸入方式、視窗位置與顯示模式下，重複相同的步驟至少完成五次測試。
- 比較最後五次結果，其中最小值為「最佳」，四捨五入後的算術平均數為「平均」。
- 選擇「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 負載 | 變慢（毫秒數增加） | 事件迴圈與合成器須與其他工作競爭資源 |
| 遠端桌面或串流工作階段 | 變慢（毫秒數增加） | 訊號與按鍵皆須經過額外的網路節點傳遞 |
| 可變更新率或像素位移模式 | 不固定 | 顯示器時序在測試過程中發生變化 |
| 無線干擾或輸入裝置低電量 | 變慢或不固定 | 輪詢率或傳輸延遲產生波動 |
為了進行有意義的比較，請在不同的嘗試間使用相同的裝置、瀏覽器、輸入方式、視窗位置與顯示模式，並將分頁保持在前景。多完成幾次測試，而非僅憑單一離群值下定論。如果你比較滑鼠與鍵盤，請在兩組之間重置，並在頁面之外標註條件，因為此小工具刻意不會儲存任何實驗紀錄。該分數並不套用年齡對照表、百分位排名、通過／不通過標籤、運動成績基準或醫學閾值，因此上述任何詮釋都需要受控的實驗流程，而非此通用工具。