響應式設計還不夠，我們需要響應式性能

最近，我遇到了很多響應式網站，它們存在很多性能問題。 在他們中的大多數人身上，問題是如此明顯，以至於除了最新一代的智能手機之外，它們幾乎毫無用處。 考慮到響應性作為一個概念旨在覆蓋更廣泛的受眾這一事實，這似乎適得其反。

這個問題的最大貢獻者是仍然流行的桌面優先設計範式。 從移動優先的角度思考似乎可以解決問題，但僅憑這一點並不能保證令人滿意的性能。 我們似乎都過於依賴或多或少的優雅退化。 我們依靠 shims 和 polyfill 來啟用缺失的功能。 我們依靠庫來實現快速開發，並在瀏覽器兼容性成為問題時提供支持。

“為什麼要擔心？” 你可能會問。 “我們的大多數訪客都擁有運行最新操作系統版本的高性能智能手機。 他們可以處理我們的網站。 分析告訴我們。”

對於稻草人的論點，我很抱歉，但我認為值得大聲說，可以使用您網站的人將是您的大多數用戶。 如果您在分析中沒有看到 Android 2.3，這是否意味著沒有使用這些設備的用戶？ 或者這是否意味著您的網站無法為這些用戶提供任何東西？ 考慮到那一代的許多設備仍在貨架上，即使在今天也被全新購買。 您不應該將其完全視為過去的技術而忽略。

因此，我想談談Web開發的理想案例和實際目標。 以及讓我們更接近這些目標的實踐和範式。

磚頭設計範式

年度手機銷量的很大一部分仍由功能手機佔據。 更大一部分的人口不是每年都購買手機，但他們仍然擁有一些支持網絡的設備。 再加上仍在使用的上一代智能手機，再加上 Kindle 和其他半功能網絡設備（WAP 設備、電視、烤麵包機、T 恤和積木）。 將它們全部加起來，您可能會達到驚人的總和。

考慮此受眾的用例。 他們不會在設備上閱讀長篇文章、瀏覽和研究。 但他們可能會經歷嘗試在數字鍵盤上輸入 URL 並使用方向鍵導航頁面以獲取電話號碼或即時仔細檢查地址的恐懼。

那麼對於我們來說，實現一個僅向低於特定功能和性能閾值的設備提供該信息的次移動優先佈局有多難？

優雅的改進

將優雅降級作為最低限度的最佳實踐，我們創建了一個包羅萬象的原則，（在某種程度上）阻礙了超越它的思考。 一旦優雅的降級到位，我們可以肯定地說我們的工作已經完成，並且做得很好。 越來越多的時候，我們甚至不必考慮它，因為它已經被正在使用的各種框架和庫所涵蓋。 最後，在某些情況下，polyfills 和 shims 完全消除了功能退化的需要。

隨著這個功能變得越來越容易獲得，考慮它（更不用說超越它）的需求變得越來越遙遠。

從這篇文章的角度來看，它可以這樣分解：

不優雅的降級：如果一個特性不是很容易獲得的，那麼實現就會失敗，以至於它變得不可用或以極其不切實際的方式可用。

優雅降級：如果一個特性不是現成的，它會以某種方式失敗，但仍然可以實現可接受的可用性。

不優雅的改進：如果該功能不是現成的可用，它由 polyfill 或 shim 模擬。

到了，問題解決了。

好吧，除非您考慮那些相同的低端設備的性能。

由於缺乏弟弟妹妹的處理能力和數據能力，他們被要求承擔更大的負載。 將 polyfills 作為解決方案會產生一種錯覺，即所有現代功能現在都可以在所有設備上使用，並且可以毫無顧慮地使用。

所以你實現了modernizr和polyfill一切以防萬一。 最不稱職的設備最終會加載最多的數據，並執行最多的處理。 從而確保“最佳”最終用戶體驗。

優雅改進的想法將扭轉這一概念，從最低的功能要求開始並加載升級，直到基於設備功能的性能-可用性平衡達到最佳狀態。 因此，數據流量和處理要求將轉移到最適合處理它們的設備上。

當然，目前這個概念非常複雜：大多數框架和庫都不支持它，幾乎沒有討論過，對此類實踐的引用很少，相距甚遠，並且僅限於微功能。 但在某些時候，所有概念和功能都是如此。

它可以，但它必須嗎？

Web 開發的另一個最佳實踐是在激活之前檢查設備上的功能是否可用。

但是，考慮到您可以在舊的 Android 手機上安裝最新版本的 Google Chrome，它會聲稱它可以運行 CSS 動畫、WebGL、背景視差效果和許多其他功能。 但它真的，真的，不能。 以至於瀏覽器會崩潰，整個設備將變得無響應，以至於必須重新啟動才能重新獲得控制權。

這個問題最近開始在很大程度上影響 Android 應用程序（從用戶的角度來看）。 從這個意義上說，最明顯的退化之一影響了 Google Talk/Hangouts 應用程序升級，由於舊設備上的性能問題，他們的服務從可用的最輕量級的聊天應用程序變成了幾乎無法使用的應用程序。 （再次強調這一點：這裡的“舊”意味著您仍然可以在幾乎任何商店購買現成的、全新的）。 同樣的問題影響了 YouTube 應用程序和 Twitter 應用程序（根據我的經驗），顯然還有許多其他應用程序。

因此，在計劃階段的某個時間點花點時間評估高性能核心功能相對於尖端化妝的價值。 或者至少讓您的上一代應用/服務/內容以某種形式提供給舊用戶。 說到這個……

讓用戶選擇退出前沿

您是否曾發現自己試圖通過舊設備或連接不佳的設備使用 Gmail？ “加載基本 HTML”鏈接肯定會派上用場。

為什麼您的尖端、響應式、動畫、面向觸摸的在線店面沒有該功能？

想一想：您要求它具有響應性，以便您可以接觸到更多潛在客戶。 你讓它最前沿，留下最好的第一印象。 結果，更少的潛在客戶甚至可以獲取有關您和您的服務的基本信息。 如果優雅的改進對您來說成本太高，那麼如果“WOW”版本對他們的設備來說太多了，您為什麼不至少為您的訪問者提供訪問純文本版本內容的選項。

你真的需要整個圖書館嗎？

最後，我希望看到的最後一個超出標準的最佳實踐是“使用它或失去它”。 跟踪實際使用的庫和模塊並僅包含它們有時很乏味，但將整個工具集保存在每個頁面上只是草率。

最近，我開始跟踪我在包含庫後實際使用了多少功能。 而我最常使用的工具是 jQuery。 我經常發現我只使用了一個或兩個功能（例如 $.extend 或 $.ready），或者更糟糕的是，我只使用它來按類或 ID 獲取元素。 有時我會這樣，有時我會返回代碼以刪除或解耦依賴項。

如果您可以根據結果自動分析最終使用了哪些庫以及使用了多少庫並減輕了體重，那不是很好嗎？

許多庫和應用程序提供了在開始使用之前自定義加載的選項。 但我一直有這種感覺，在我們的庫中標準化自動化的“使用它或失去它”構建架構應該不會太遠。

我對“包羅萬象”的方法過敏。 但是將它與這樣的功能結合使用可能會將方法轉變為類似於原型板的方法：一種過於靈活的開發工具，不僅在語法上，而且在實際功能本身上都被縮小了。

需要的是該庫的僅開發版本，該版本將通過對相關功能的單元測試，啟用對使用的功能的跟踪並輸出最小的依賴或至少使用規模（例如詢問我是否包含 8% 的 jQuery其功能或 80%）。 然後可以使用依賴項輸出來挑選、聚合和最小化生產的輸出。

但我能做些什麼呢？

首先，解決問題。 想一想，與您的同行討論，並嘗試在現實世界的場景中發現問題。

試試看。 把你藏在某個抽屜裡的上一代手機挖出來。 嘗試在您自己的網站上使用它，並檢查內容是否甚至可以遠程使用。 去國外拜訪一些落後時代的親戚，並嘗試成為他們的技術佈道者。 看看他們在技術採用方面的滯後是否實際上是由可訪問性問題促成的。

如果您是委託網站的買家，請確保在此問題上要求（至少）低級別的支持。 請記住：目標不是為低級設備創建所有功能的完整端口。 所要求的只是這些用戶獲取您的聯繫信息，而不是他們的設備崩潰。

為此留出實際資源：該問題的最簡單解決方案不應超過一兩天和一些前瞻性思考。 請記住首先製作網站的最基本原因（更不用說製作響應式網站了）。

如果您是開發庫、框架、捆綁軟件或任何其他可嵌入軟件的軟件包開發人員：您就是能夠在這裡發揮最大作用的人。 如果您可以促進或將這些概念整合到您的平台中，您將影響 Web 開發的整個領域。 如果您確實將它納入您的包裝設計，請告訴我，我會為您傳福音。

最後，**如果您是開發人員或設計師**，不要只停留在最佳實踐。 總是試著在那個地平線上看一點點。 為了您的客戶和用戶的利益，您需要努力推動這些尚未有人要求的概念，這些概念不受支持且未記錄在案。

最終，如果您想听有人持續數小時並發現自己在薩格勒布附近，請告訴我。 我們可以去喝杯咖啡。