相關(guān)新聞
前言：2015年響應(yīng)式設(shè)計(jì)趨勢(shì)的延續(xù)，也將帶來(lái)更多的爭(zhēng)議和思考，此文所引論據(jù)較為客觀，點(diǎn)出了響應(yīng)式概念的初衷和近年來(lái)跨屏設(shè)計(jì)的狀況，并提供了解決思路和可參考的具體方法，原文下的評(píng)論也有諸多爭(zhēng)議，有興趣可以移步一覽。
你臉上掛著微笑心情愉悅地縮放著瀏覽器窗口時(shí)，認(rèn)為網(wǎng)站達(dá)成了移動(dòng)端友好體驗(yàn)的目標(biāo)。在探討之前我要提前推論：如果你只是把響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)定為終極目標(biāo)并且是唯一的移動(dòng)端方案，是在流失用戶，也許還有金錢。幸運(yùn)的是我們能夠修正這些錯(cuò)誤。
這篇文章的內(nèi)容將涉及移動(dòng)網(wǎng)頁(yè)與響應(yīng)式設(shè)計(jì)的關(guān)系，始于如何提供靈巧的響應(yīng)式設(shè)計(jì)，及移動(dòng)端的性能為何如此重要、響應(yīng)式設(shè)計(jì)何以不能視為網(wǎng)站的目標(biāo)，并止于技術(shù)本身的性能爭(zhēng)議，以便輔助理解問(wèn)題的真正所在。
2000年起，設(shè)計(jì)師和開發(fā)者就已對(duì)移動(dòng)端存在的問(wèn)題過(guò)分簡(jiǎn)化，而現(xiàn)在有些人則認(rèn)為響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)是一切難題的銀彈。我們需要正視的是，達(dá)到移動(dòng)網(wǎng)頁(yè)的輕快體驗(yàn)應(yīng)蓋過(guò)其他任何目標(biāo)。向所有移動(dòng)設(shè)備傳送一個(gè)快速可用并全兼容的體驗(yàn)是一個(gè)挑戰(zhàn)，在實(shí)施響應(yīng)式技術(shù)時(shí)也是如此。而在一開始便關(guān)注性能將協(xié)助我們更易達(dá)成目標(biāo)。
響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)非常優(yōu)秀，但它不是銀彈。如果把它當(dāng)作移動(dòng)端的唯一法寶，那么也許會(huì)有性能問(wèn)題將對(duì)轉(zhuǎn)化率造成阻礙。現(xiàn)約有11%的網(wǎng)站是響應(yīng)式的并且這個(gè)數(shù)字每個(gè)月都在上升，討論它的時(shí)機(jī)到了。
根據(jù)Guy Podjarny的調(diào)查，72%的響應(yīng)式網(wǎng)站統(tǒng)一傳送相同數(shù)量的字節(jié)，而不依據(jù)屏幕尺寸區(qū)分處理，甚至在使用速度較慢的移動(dòng)網(wǎng)絡(luò)連接也是如此。但并非所有的用戶都會(huì)耐心等待網(wǎng)站的加載。
實(shí)際上只需對(duì)問(wèn)題有基本理解，我們就可以讓損失降到到最低。
移動(dòng)網(wǎng)站由來(lái)已久
我并不是說(shuō)不該讓設(shè)計(jì)做到響應(yīng)式，或者建議應(yīng)該采用一個(gè)m.*的子域名。事實(shí)上，社交分享已無(wú)所不在，不區(qū)分設(shè)備讓每一個(gè)文件指向同一個(gè)URL是明智的。但這并不意味著單一的URL應(yīng)該總是傳送同一文件，或者說(shuō)是所有的設(shè)備應(yīng)該加載同一個(gè)資源。
引用創(chuàng)造“響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)”術(shù)語(yǔ)的Ethan Marcotte的一句話：
最重要的是，響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)不是特意為移動(dòng)網(wǎng)站提供的一個(gè)替代解決方案。
（譯補(bǔ)Ethan Marcotte原文：“我認(rèn)為響應(yīng)式設(shè)計(jì)是設(shè)計(jì)哲學(xué)的一部分，也是前端開發(fā)策略的一部分。而作為后者，應(yīng)依實(shí)際項(xiàng)目所需評(píng)估其可行性。”）
響應(yīng)、移動(dòng)、快速
移動(dòng)端的性能保證與響應(yīng)式設(shè)計(jì)可以同時(shí)實(shí)現(xiàn)，只要用上一些其他技術(shù)。響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)從不意味著去制造性能問(wèn)題，這也是我們無(wú)法歸罪于這項(xiàng)技術(shù)本身的原因，而許多人相信它能解決一切問(wèn)題才是錯(cuò)誤的根源。
讓設(shè)計(jì)響應(yīng)式化的重要性在于，我們需要處理從臺(tái)式機(jī)到手機(jī)的大區(qū)間viewport尺寸。但是只考慮屏幕尺寸低估了移動(dòng)設(shè)備，臺(tái)式機(jī)與手機(jī)的分界線正在變得模糊，不同類型的設(shè)備也趨于提供多樣化功能。顯然我們已無(wú)法再只依賴于使用媒體查詢這一功能。
有些評(píng)論者稱之為“負(fù)責(zé)任的響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)”，雖然其他人把它叫做現(xiàn)代化的響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)。撇開兩種叫法語(yǔ)義上的差別，我們確實(shí)需要理解并意識(shí)到問(wèn)題所在。
不存在銀彈也沒有可以一勞永逸的方案，我們能做的是使用組合技巧提升現(xiàn)有的響應(yīng)式方案并且力求性能的最優(yōu)化：
提供相同URL及內(nèi)容，但針對(duì)不同設(shè)備結(jié)構(gòu)不同；
在立項(xiàng)規(guī)劃階段便需遵循移動(dòng)優(yōu)先原則；
使用display: none時(shí)進(jìn)行真機(jī)測(cè)試驗(yàn)證資源加載，而非依賴于桌面瀏覽器模擬；
在瀏覽器提供更好的解決方案（如srcset）之前，使用JavaScript分發(fā)響應(yīng)式圖片；
移動(dòng)端初始viewport的文件內(nèi)嵌，或者優(yōu)先加載首屏內(nèi)容。
提供更智能的響應(yīng)式方案如：按需加載、分組響應(yīng)式、服務(wù)器端的自適應(yīng)處理。
按需加載
CSS媒體查詢無(wú)法讓設(shè)備區(qū)分加載和解析，這意味著移動(dòng)端的手機(jī)會(huì)下載和解析為更大屏幕提供的CSS。再者，蜂窩網(wǎng)絡(luò)下CSS的分區(qū)渲染浪費(fèi)的毫秒十分寶貴，有必要避免全依賴于此。
正如我們知道的，iPhone不會(huì)動(dòng)態(tài)轉(zhuǎn)換為iPad的尺寸，采用JavaScript 的matchMedia查詢方法替代CSS媒體查詢，則能夠保證不同設(shè)備顯示內(nèi)容的統(tǒng)一性并且只加載它們各自所需要的CSS。
使用特征檢測(cè)工具可以做到更好，如Modernizr可以構(gòu)建更智能的UI和功能定義，而不是只依賴于屏幕尺寸。
分組響應(yīng)式
基于單HTML頁(yè)面為所有屏幕進(jìn)行響應(yīng)式設(shè)計(jì)時(shí)，為臺(tái)式電腦和智能手機(jī)傳送同樣的HTML結(jié)構(gòu)是糟糕的，原因再次回歸到移動(dòng)端的性能問(wèn)題。
即使服務(wù)器端存儲(chǔ)同一個(gè)文件，基于設(shè)備分組也可以實(shí)現(xiàn)對(duì)終端的按需發(fā)送。舉例來(lái)說(shuō)，為6英寸及更大尺寸的屏幕提供大的浮動(dòng)式菜單，而為小于6英寸的屏幕提供一個(gè)小的漢堡包菜單。響應(yīng)式技術(shù)可以基于分組實(shí)現(xiàn)不同情境的適配，如橫豎屏模式的轉(zhuǎn)換、不同型號(hào)的iPhone（寬為320像素）、各式5英寸的安卓設(shè)備（寬為360像素）及平板（寬為400像素及以上）。
服務(wù)器端層面
更智能的響應(yīng)式解決方案的最后一個(gè)選項(xiàng)是服務(wù)器，對(duì)移動(dòng)網(wǎng)頁(yè)來(lái)說(shuō)服務(wù)器端進(jìn)行特征檢測(cè)及定義并不新奇，市面上早有諸如WURFL和Device Atlas之類的工具庫(kù)。
把響應(yīng)式設(shè)計(jì)與服務(wù)器端組件聯(lián)合同樣也有前例，已被知曉的有響應(yīng)式設(shè)計(jì)+服務(wù)器端組件(RESS)，或被稱為自適應(yīng)設(shè)計(jì)，保障每個(gè)終端代碼簡(jiǎn)約性的同時(shí)，提高了響應(yīng)式的速度與可用性體驗(yàn)。
不幸的是，在過(guò)去幾年里這些技術(shù)沒有在社區(qū)里獲得太多的推動(dòng)，只需看看有多少為開發(fā)者提供的博客或雜志將“RESS” 與“自適應(yīng)” 和“響應(yīng)式”相提并論便可一知。其一原因在于：我們是前端工程師，任何涉及后端的內(nèi)容都是個(gè)令人頭疼的難題。
一部分情況是前端設(shè)計(jì)人員可以控制的是服務(wù)器上的腳本；另一部分情況是有遠(yuǎn)程開發(fā)團(tuán)隊(duì)管理，設(shè)計(jì)師并不想在每次需要調(diào)整UI時(shí)都與他們打交道，這種情形下的心情我能夠理解。
這也是為何在大項(xiàng)目里頭應(yīng)該考慮新的架構(gòu)層：一種不需要?jiǎng)佑煤蠖耍煌ㄟ^(guò)前端工程師就能夠?qū)Ψ?wù)器端架構(gòu)進(jìn)行操作的方式。Node.js是一種卓越的作為前后端之間流通架構(gòu)的平臺(tái)，這個(gè)架構(gòu)方式下，前端工程師可以基于內(nèi)部的流通性進(jìn)行調(diào)整而不需要涉及后端架構(gòu)，從而實(shí)現(xiàn)為所有設(shè)備提供輕快的響應(yīng)式和可用性體驗(yàn)。
