最近很多客戶咨詢我們是否可以提供響應(yīng)式網(wǎng)站建設(shè)服務(wù)，以及響應(yīng)式網(wǎng)站的優(yōu)缺點(diǎn)等等。這里蜀美想說(shuō)，蜀美可以為客戶提供響應(yīng)式網(wǎng)站建設(shè)服務(wù)，但前提是您需要知道每一種技術(shù)都有其特定的局限，以及其特有的優(yōu)勢(shì)，對(duì)于一些客戶認(rèn)為響應(yīng)式網(wǎng)站等于一切的客戶，蜀美特地分享了一篇關(guān)于響應(yīng)式的文章供大家閱覽。

你調(diào)整了瀏覽器，笑容攀上臉頰。你感到非常開(kāi)心，認(rèn)為自己實(shí)現(xiàn)了友好移動(dòng)的目標(biāo)。在正式討論前，讓我來(lái)預(yù)測(cè)下未來(lái)：你會(huì)失掉用戶和經(jīng)濟(jì)效益，如果你把響應(yīng)式網(wǎng)頁(yè)作為唯一目標(biāo)和唯一的解決辦法。好消息是，你可以行之有效。

在這篇文章中，我們會(huì)談到移動(dòng)互聯(lián)網(wǎng)和響應(yīng)式設(shè)計(jì)的關(guān)系，首先將介紹如何巧妙的運(yùn)用響應(yīng)式設(shè)計(jì)，為什么性能對(duì)移動(dòng)端非常重要，為什么響應(yīng)式設(shè)計(jì)不能最為你網(wǎng)站的目標(biāo)，最后技術(shù)的性能問(wèn)題幫助我們更好的理解這問(wèn)題。

自2000年開(kāi)始，設(shè)計(jì)者和開(kāi)發(fā)者就把移動(dòng)設(shè)備的問(wèn)題過(guò)于簡(jiǎn)單化，以至于現(xiàn)在仍然有人認(rèn)為響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)能解決一切問(wèn)題。

大家必須明白，凌駕于與任何目標(biāo)，移動(dòng)網(wǎng)絡(luò)體驗(yàn)必須和閃電一樣快。迅速、實(shí)用、兼容的體驗(yàn)對(duì)所有移動(dòng)設(shè)備都是挑戰(zhàn)。當(dāng)你使用響應(yīng)式設(shè)計(jì)時(shí)，這些挑戰(zhàn)都存在。從一開(kāi)始就重視性能會(huì)讓過(guò)程容易些。

響應(yīng)式設(shè)計(jì)是很棒，但不是萬(wàn)能鑰匙。如果你在移動(dòng)設(shè)備上一味堅(jiān)持，在轉(zhuǎn)換率后就可能隱藏著性能問(wèn)題。大約有11%的網(wǎng)站是響應(yīng)式，這個(gè)數(shù)字每月都在增長(zhǎng)，所以現(xiàn)在是談?wù)撨@個(gè)問(wèn)題的時(shí)機(jī)了。

據(jù)Guy Podjarny研究，72%的響應(yīng)式網(wǎng)站不分屏幕大小都提供相同的字節(jié)，盡管這會(huì)降低移動(dòng)網(wǎng)絡(luò)連接。不是所有用戶都有耐心等著網(wǎng)站加載。

對(duì)響應(yīng)式設(shè)計(jì)存在的問(wèn)題有了基本認(rèn)識(shí)，我們就能減低它帶來(lái)的損失。

移動(dòng)網(wǎng)站來(lái)自過(guò)去

我不是說(shuō)你不應(yīng)該采用響應(yīng)式設(shè)計(jì)或者去用m.*的子域名。事實(shí)上，現(xiàn)在社會(huì)分享無(wú)處不在，不分設(shè)備，分配給給文檔一個(gè)URL，這是聰明的做法。但這并不意味著一個(gè)單獨(dú)URL應(yīng)該提供相同的文檔或每一個(gè)設(shè)備都應(yīng)該下載相同的資源。

援引Ethan Marcotte的話，他創(chuàng)造了“響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)”這個(gè)術(shù)語(yǔ)。

最重要的是，響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)的初衷不是要取代移動(dòng)網(wǎng)頁(yè)?！狤than Marcotte

交互、移動(dòng)、快速

如果我們能使用一些其他的技術(shù)，就可以實(shí)現(xiàn)獲得響應(yīng)式設(shè)計(jì)好處的同時(shí)，不影響移動(dòng)設(shè)備的性能。響應(yīng)式設(shè)計(jì)從來(lái)不是意味著要解決“性能”，這也是為什么我們不能因此指責(zé)它的原因。然而，相信它能解決你所有問(wèn)題，這大錯(cuò)特錯(cuò)。

設(shè)計(jì)響應(yīng)式很重要，因?yàn)槲覀冃枰鉀Q跨桌面和移動(dòng)端視窗大小范圍的問(wèn)題。但是只考慮屏幕大小就低估了移動(dòng)設(shè)備。桌面和移動(dòng)端的界限正在變得模糊，基于不同的設(shè)備對(duì)我們而言仍然有多種可能性。但是我們還不能通過(guò)媒體查詢來(lái)決定響應(yīng)式設(shè)計(jì)的功能。一些評(píng)論家稱之為“可靠的響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)”，然而另一些人則認(rèn)為它是伴隨現(xiàn)代視覺(jué)的響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)。在沒(méi)有了解其基本語(yǔ)義的情況下，我們需要搞清楚這個(gè)問(wèn)題。

雖然沒(méi)有可應(yīng)用于各類文檔的萬(wàn)全之策，但是能夠運(yùn)用一些技巧來(lái)改善現(xiàn)有響應(yīng)式的解決辦法，并且力求性能最大化。

· 實(shí)現(xiàn)每一個(gè)文檔對(duì)所有的設(shè)備都使用相同的URL和相同的內(nèi)容，結(jié)構(gòu)不必要相同。

· 當(dāng)從零開(kāi)始，遵循“移動(dòng)先行”的方法。

· 在一個(gè)真實(shí)設(shè)備上測(cè)試當(dāng)資源加載和顯示會(huì)發(fā)生什么。不要依賴調(diào)整你的桌面瀏覽器。

· 使用優(yōu)化工具測(cè)量和提高性能。

· 通過(guò)JavaScript傳輸響應(yīng)圖片，雖然我們更期盼著瀏覽器供應(yīng)商（例如srcset）能解決這個(gè)問(wèn)題

· 當(dāng)你需要當(dāng)前設(shè)備具備加載條件時(shí)，只加載JavaScript，這會(huì)在onload事件之后發(fā)生。

· 對(duì)移動(dòng)設(shè)備，內(nèi)聯(lián)文檔的原始視圖，或者發(fā)送一屏顯示內(nèi)容。

· 使用下面一種或幾種技術(shù)應(yīng)用智能響應(yīng)式的解決方案：條件加載、按組響應(yīng)、服務(wù)器端層（如適應(yīng)性方法）。

條件加載

不要總是在CSS中依賴media queries，因?yàn)闉g覽器將會(huì)為所有設(shè)備加載和解析所有選擇器和樣式 (后面詳細(xì)討論)。這就意味著手機(jī)為了一個(gè)大屏要下載和解析CSS。因?yàn)镃SS塊的呈現(xiàn)，你要浪費(fèi)一些時(shí)間等待聯(lián)接成功。

在設(shè)備上用JavaScript的matchMedia查詢來(lái)代替CSS media queries,你知道這些內(nèi)容是不會(huì)變化的。例如，大家都知道iphone不能動(dòng)態(tài)的轉(zhuǎn)換成iPad的規(guī)格，所以我們只在正在需要CSS時(shí)才用。

可以用特征檢測(cè)，例如 Modernizr，對(duì)UI和功能性做出更明智的決定而不是僅僅根據(jù)屏幕尺寸。

按組響應(yīng)

在處理簡(jiǎn)單文檔、為臺(tái)式電腦和智能手機(jī)提供相同的HTML時(shí)，雖然為我們可以讓所有屏幕依賴一個(gè)單一的HTML基礎(chǔ)和響應(yīng)式設(shè)計(jì)，但這并不總是最好的解決方案。為什么呢？同樣是由于移動(dòng)設(shè)備的性能。

即使我們?cè)诜?wù)器端儲(chǔ)存相同的文檔，但是根據(jù)設(shè)備組別的不同給用戶不同的文檔。舉個(gè)例子，為一個(gè)6英寸甚至更大的屏幕提供大的浮動(dòng)菜單，為一個(gè)小屏幕提供漢堡菜單。在每個(gè)組群里，使用響應(yīng)時(shí)技術(shù)以適應(yīng)不同的場(chǎng)景，例如肖像模式和風(fēng)景模式的轉(zhuǎn)換，切換iPhone（320像素寬）、5英寸Android設(shè)備（360英寸）和平板（400像素）。

服務(wù)器端層

智能響應(yīng)策略的最后一個(gè)選擇是服務(wù)器。服務(wù)器端功能檢測(cè)和決策不是移動(dòng)網(wǎng)絡(luò)的新鮮玩意。類似 WURFL 和Device Atlas的庫(kù)在市場(chǎng)上有好多年，響應(yīng)式設(shè)計(jì)和服務(wù)器組件的混合也眾所周知。有時(shí)被稱為是響應(yīng)式設(shè)計(jì)和服務(wù)器端組件（RESS）,有時(shí)又叫自適應(yīng)設(shè)計(jì)，這提高了響應(yīng)式設(shè)計(jì)的速度和可用性，同時(shí)每一個(gè)服務(wù)器端都保持一個(gè)代碼庫(kù)。很遺憾的是。這些技術(shù)這幾年并沒(méi)有什么突破性的發(fā)展。只能在博客和雜志里看到一些開(kāi)發(fā)者對(duì)“RESS”、“響應(yīng)式”、“自適應(yīng)”做比較。原因就是：我們是前端專業(yè)人士。任何涉及到服務(wù)器的事情看起來(lái)都是不太愉快的問(wèn)題。在一些情況下，前端設(shè)計(jì)師能把握好服務(wù)器的腳本，另一些情況是，服務(wù)器由遠(yuǎn)程開(kāi)發(fā)團(tuán)隊(duì)管理，設(shè)計(jì)師不想每做一次小的UI改變就要和遠(yuǎn)程團(tuán)隊(duì)溝通處理。我能體會(huì)這種感覺(jué)。

這就是在大型項(xiàng)目中要花時(shí)間思考新架構(gòu)層的原因，這樣前端工程師對(duì)服務(wù)器做決定時(shí)不會(huì)影響到后端架構(gòu)。Node.js是一個(gè)極好的備選平臺(tái)，是介于當(dāng)前企業(yè)后端基礎(chǔ)和前端之間的服務(wù)器端層。

在這個(gè)新的端層里，前端的工程師可以根據(jù)有現(xiàn)實(shí)的決定權(quán)，這會(huì)使得在不觸及后端架構(gòu)的情況下，讓所有設(shè)備上的體驗(yàn)更為快速、響應(yīng)、可用。