關於 UA 嗅探、瀏覽器檢測和 Alex 的帖子
除非您在過去一周沒有註意，否則您可能已經閱讀過 Alex Russell 最近關於特徵檢測成本和一種可能的解決方案的論文 1 .亞歷克斯是我見過的最聰明的人之一，我一直很欽佩他願意在任何論壇上分享他的觀點，無論他的想法是否受歡迎或收到的響應質量如何。雖然我不能說我總是同意他的結論，但我可以說我尊重他得出結論的方式。這就是為什麼當他的觀點被歪曲到令人困惑的地步時，我會感到難過。
開始
在他關於這個主題的第一篇文章中，縮短審訊時間 1 ，亞歷克斯提出了幾個主張：
- 特徵檢測並不是跨瀏覽器解決方案的靈丹妙藥
- 某些特徵檢測技術會導致並不總是合理的性能損失
- 已知瀏覽器的可用功能集是已知的
對於這些說法，我沒有發現任何非常有爭議的地方，而且我相信它們都是正確的並且易於驗證。第二點其實是理解他立場的關鍵。
運行速度最快的代碼是執行最少操作的代碼。作為一名優秀的程序員，當然也希望提供最佳的用戶體驗，你的工作就是使用最少的操作來完成任何給定的問題。特徵檢測必然會引入額外的操作來確定合適的下一組操作。
雖然我從不反對特徵檢測，例如確定給定函數或屬性是否存在，但我公開反對那種冗長且複雜的特徵檢測技術 2 被一些庫和開發人員採用，尤其是在對多個功能進行前期評估時，例如 Modernizr 中的功能 3 .作為曾在多個大型、高流量網站上工作的人，出於性能原因，我一直強調要避免使用這種方法。
提案
Alex 提高特徵檢測性能的建議是確定並緩存已知瀏覽器的特徵測試結果。當實際結果已知時，這將允許庫跳過冗長且耗時的特徵檢測代碼。該方法需要一定程度的用戶代理檢測 4 提供正確的特徵檢測集。
現在，我過去一直（臭名昭著）說我不相信用戶代理檢測是壞的或邪惡的，或者它破壞了 Web 的精神或任何類似的事情——我只是簡單地說它是您應該普遍了解並了解何時何地適合使用的技術。我再說一遍：當你想識別正在使用的瀏覽器時，你會使用用戶代理檢測。而已。另一方面，當您想要確定某個功能是否可供使用時，會使用功能檢測。這是兩種不同的技術，有兩種截然不同的用例。
Alex 的提議是使用用戶代理檢測來加載在特定用戶代理中運行的特性測試的結果，同時為未知實體的瀏覽器保留常規特性檢測。讓我們面對現實吧，Internet Explorer 6 的功能集並沒有改變，所以如果你能準確地檢測到這個瀏覽器，那麼預加載它的功能集是有意義的。
我還會以與用戶代理嗅探相同的謹慎來擴充 Alex 的提議，即僅識別 以前的版本 瀏覽器（不是當前瀏覽器）。在下一個版本發布之前，您無法確定某個特定瀏覽器的功能集是否已凍結。恰當的例子：Internet Explorer 8 附帶了與最終 ECMAScript 5 規範不匹配的原生 JSON 實現。這後來在補丁中修復 5 .那時，Internet Explorer 8 是最新版本，因此只有緩存 Internet Explorer 7 或更早版本的結果才是合理的。
他沒說什麼
與亞歷克斯所說的幾乎一樣有趣的是他沒有說的話。主要是因為人們立即開始暗示他實際上在說他沒有說的話。這是我也處理過的網絡上令人難以置信的令人沮喪但令人難以置信的普遍現象。並不是說亞歷克斯需要任何人來拯救他，但我確實想概述一下他在帖子中從未說過的話：
- 他從未說過用戶代理檢測優於特徵檢測
- 他從未說過特徵檢測不好，不應該使用
- 他從未說過用戶代理檢測很棒，應該一直使用
- 他從未說過他的提議是唯一的解決方案
與有爭議的話題一樣，人們一直在整篇文章中鎖定一兩句話，而不是試圖吸收更大的觀點。
我的意見
上週，一位同事問我對亞歷克斯的提議有何看法。由於我只瀏覽了這兩個帖子，我決定回去仔細閱讀它們。首先，我認為 Alex 準確地概括了當前特徵檢測熱潮的問題，可以簡潔地概括為“所有特徵檢測，一直”，或者更簡潔，“特徵檢測，總是”。他正確地指出，特徵檢測熱潮沒有足夠關注與預先運行一堆特徵測試相關的性能開銷。
一般來說，我喜歡為舊的已知瀏覽器（例如 Internet Explorer 6 和 7）預先構建功能測試緩存的想法。我們絕對知道這些瀏覽器的問題，而且問題和瀏覽器都不會很快消失。我不太相信需要為其他類別的瀏覽器緩存信息，尤其是那些定期更新的瀏覽器。例如，我認為為 Chrome 做這樣的緩存會很浪費，它會以令人眼花繚亂的速度自動更新，以至於我無法告訴你我在這台計算機上運行的是哪個版本。
在這一點上，我更贊成 Alex 的提議，而不是反對。我確實相信緩存已知實體的特徵檢測結果是有價值的，但是，我相信應該對其進行緩存的 UA 數量很少。我將針對兩組瀏覽器：較舊的瀏覽器（IE6/IE7）和特定的移動瀏覽器。有趣的是，它們的共同點是運行代碼比在桌面上運行的現代瀏覽器慢。保留一個旨在針對性能最差的瀏覽器進行優化的小型靜態緩存對我來說是最有意義的，然後我只會根據需要進行額外的功能測試——在第一次嘗試使用該功能時運行測試，然後動態緩存。
我確信通過主要關注異常值可以找到緩存特徵數據的最佳點，尤其是那些使用速度較慢的 JavaScript 引擎 (IE6) 或導致 JavaScript 運行速度較慢的低功率設備（移動設備）。當然，與每一種理論一樣，這種方法必須在現實世界的場景中進行測試，才能確定確切的節省量。個人認為值得研究。
參考
- 縮短審訊時間，作者：Alex Russell
- JavaScript 功能測試
- 現代化
- 性能數不勝數和誤報，作者：Alex Russell
- Internet Explorer 8 中的原生 JSON 功能更新
