在這篇文章中，我們會談到移動互聯網和響應式設計的關係，首先將介紹如何巧妙的運用響應式設計，爲什麼性能對移動端非常重要，爲什麼響應式設計不能作爲你網站的目標，最後技術的性能問題幫助我們更好的理解這問題。
自2000年開始，設計者和開發者就把移動設備的問題過於簡單化，以至於現在仍然有人認爲響應式網頁設計能解決一切問題。
大家必須明白，凌駕於任何目標，移動網絡體驗必須和閃電一樣快。迅速、實用、相容的體驗對所有移動設備都是挑戰。當你使用響應式設計時，這些挑戰都存在。從一開始就重視性能會讓過程容易些。
響應式設計是很棒，但不是萬能的鑰匙。如果你在移動設備上一味堅持，在轉換率後就可能隱藏着性能問題。大約有11%的網站是響應式，這個數字每月都在增長，所以現在是談論這個問題的時機了。
據Guy Podjarny研究，72%的響應式網站不分屏幕大小都提供相同的字節，儘管這會降低移動網絡連接。不是所有用戶都有耐心等着網站加載。
對響應式設計存在的問題有了基本認識，我們就能減低它帶來的損失。
移動網站來自過去
我不是說你不應該採用響應式設計或者去用m.*的子域名。事實上，現在社會分享無處不在，不分設備，分配給給文檔一個URL，這是聰明的做法。但這並不意味着一個單獨URL應該提供相同的文檔或每一個設備都應該下載相同的資源。
援引Ethan Marcotte的話，他創造了“響應式網頁設計”這個術語。
最重要的是，響應式網頁設計的初衷不是要取代移動網頁。——Ethan Marcotte
交互、移動、快速
如果我們能使用一些其他的技術，就可以實現獲得響應式設計好處的同時，不影響移動設備的性能。響應式設計從來不是意味着要解決“性能”，這也是爲什麼我們不能因此指責它的原因。然而，相信它能解決你所有問題，這大錯特錯。
設計響應式很重要，因爲我們需要解決跨桌面和移動端視窗大小範圍的問題。但是隻考慮屏幕大小就低估了移動設備。桌面和移動端的界限正在變得模糊，基於不同的設備對我們而言仍然有多種可能性。但是我們還不能透過媒體查詢來決定響應式設計的功能。一些評論家稱之爲“可靠的響應式網頁設計”，然而另一些人則認爲它是伴隨現代視覺的響應式網頁設計。在沒有了解其基本語義的情況下，我們需要搞清楚這個問題。
雖然沒有可應用於各類文檔的萬全之策，但是能夠運用一些技巧來改善現有響應式的`解決辦法，並且力求性能最大化。
實現每一個文檔對所有的設備都使用相同的URL和相同的內容，結構不必要相同。
當從零開始，遵循“移動先行”的方法。
在一個真實設備上測試當資源加載和顯示會發生什麼。不要依賴調整你的桌面瀏覽器。
使用優化工具測量和提高性能。
透過JavaScript傳輸響應圖片，雖然我們更期盼着瀏覽器供應商(例如srcset)能解決這個問題
當你需要當前設備具備加載條件時，只加載JavaScript，這會在onload事件之後發生。
對移動設備，內聯文檔的原始視圖，或者發送一屏顯示內容。
使用下面一種或幾種技術應用智能響應式的解決方案：條件加載、按組響應、服務器端層(如適應性方法)。
條件加載
不要總是在CSS中依賴media queries，因爲瀏覽器將會爲所有設備加載和解析所有選擇器和樣式 (後面詳細討論)。這就意味着手機爲了一個大屏要下載和解析CSS。因爲CSS塊的呈現，你要浪費一些時間等待聯接成功。
在設備上用JavaScript的matchMedia查詢來代替CSS media queries，你知道這些內容是不會變化的。例如，大家都知道iPhone不能動態的轉換成iPad的規格，所以我們只在正在需要CSS時才用。
可以用特徵檢測，例如 Modernizr，對UI和功能性做出更明智的決定而不是僅僅根據屏幕尺寸。
按組響應
在處理簡單文檔、爲臺式電腦和智能手機提供相同的HTML時，雖然爲我們可以讓所有屏幕依賴一個單一的HTML基礎和響應式設計，但這並不總是最好的解決方案。爲什麼呢?同樣是由於移動設備的性能。
即使我們在服務器端儲存相同的文檔，但是根據設備組別的不同給用戶不同的文檔。舉個例子，爲一個6英寸甚至更大的屏幕提供大的浮動選單，爲一個小屏幕提供漢堡選單。在每個組羣裏，使用響應時技術以適應不同的場景，例如肖像模式和風景模式的轉換，切換iPhone(320像素寬)、5英寸Android設備(360英寸)和平板(400像素)。
服務器端層
智能響應策略的最後一個選擇是服務器。
服務器端功能檢測和決策不是移動網絡的新鮮玩意。類似 WURFL 和Device Atlas的庫在市場上有好多年，響應式設計和服務器組件的混合也衆所周知。有時被稱爲是響應式設計和服務器端組件(RESS),有時又叫自適應設計，這提高了響應式設計的速度和可用性，同時每一個服務器端都保持一個代碼庫。
很遺憾的是。這些技術這幾年並沒有什麼突破性的發展。只能在博客和雜誌裏看到一些開發者對“RESS”、“響應式”、“自適應”做比較。原因就是：我們是前端專業人士。任何涉及到服務器的事情看起來都是不太愉快的問題。在一些情況下，前端設計師能把握好服務器的腳本，另一些情況是，服務器由遠程開發團隊管理，設計師不想每做一次小的UI改變就要和遠程團隊溝通處理。我能體會這種感覺。
這就是在大型項目中要花時間思考新架構層的原因，這樣前端工程師對服務器做決定時不會影響到後端架構。是一個極好的備選平臺，是介於當前企業後端基礎和前端之間的服務器端層。
在這個新的端層裏，前端的工程師可以根據有現實的決定權，這會使得在不觸及後端架構的情況下，讓所有設備上的體驗更爲快速、響應、可用。