wanfor?|?2015-03-03?|交互設(shè)計(jì),網(wǎng)頁重構(gòu),視覺設(shè)計(jì)
譯前言：2015年響應(yīng)式設(shè)計(jì)趨勢的延續(xù)，也將帶來更多的爭議和思考，此文所引論據(jù)較為客觀域蜗，點(diǎn)出了響應(yīng)式概念的初衷和近年來跨屏設(shè)計(jì)的狀況，并提供了解決思路和可參考的具體方法，原文下的評論也有諸多爭議盆赤，有興趣可以移步一覽。
作者：Maximiliano Firtman
你臉上掛著微笑心情愉悅地縮放著瀏覽器窗口時(shí)歉眷，認(rèn)為網(wǎng)站達(dá)成了移動(dòng)端友好體驗(yàn)的目標(biāo)牺六。在探討之前我要提前推論：如果你只是把響應(yīng)式網(wǎng)頁設(shè)計(jì)定為終極目標(biāo)并且是唯一的移動(dòng)端方案，是在流失用戶汗捡，也許還有金錢淑际。幸運(yùn)的是我們能夠修正這些錯(cuò)誤。
這篇文章的內(nèi)容將涉及移動(dòng)網(wǎng)頁與響應(yīng)式設(shè)計(jì)的關(guān)系扇住，始于如何提供靈巧的響應(yīng)式設(shè)計(jì)春缕，及移動(dòng)端的性能為何如此重要、響應(yīng)式設(shè)計(jì)何以不能視為網(wǎng)站的目標(biāo)艘蹋，并止于技術(shù)本身的性能爭議锄贼，以便輔助理解問題的真正所在。
2000年起女阀，設(shè)計(jì)師和開發(fā)者就已對移動(dòng)端存在的問題過分簡化宅荤，而現(xiàn)在有些人則認(rèn)為響應(yīng)式網(wǎng)頁設(shè)計(jì)是一切難題的銀彈[1]。我們需要正視的是浸策，達(dá)到移動(dòng)網(wǎng)頁的輕快體驗(yàn)應(yīng)蓋過其他任何目標(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)頁設(shè)計(jì)非常優(yōu)秀，但它不是銀彈。如果把它當(dāng)作移動(dòng)端的唯一法寶改化，那么也許會有性能問題將對轉(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ò)連接也是如此蜈亩。但并非所有的用戶都會耐心等待網(wǎng)站的加載。
實(shí)際上只需對問題有基本理解前翎，我們就可以讓損失降到到最低稚配。
移動(dòng)網(wǎng)站由來已久
我并不是說不該讓設(shè)計(jì)做到響應(yīng)式，或者建議應(yīng)該采用一個(gè)m.*的子域名港华。事實(shí)上道川，社交分享已無所不在，不區(qū)分設(shè)備讓每一個(gè)文件指向同一個(gè)URL是明智的立宜。但這并不意味著單一的URL應(yīng)該總是傳送同一文件冒萄，或者說是所有的設(shè)備應(yīng)該加載同一個(gè)資源。
引用創(chuàng)造“響應(yīng)式網(wǎng)頁設(shè)計(jì)”術(shù)語的Ethan Marcotte的一句話：
最重要的是橙数，響應(yīng)式網(wǎng)頁設(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)目所需評估其可行性≈痈纾”）
響應(yīng)迎献、移動(dòng)、快速
移動(dòng)端的性能保證與響應(yīng)式設(shè)計(jì)可以同時(shí)實(shí)現(xiàn)腻贰，只要用上一些其他技術(shù)吁恍。響應(yīng)式網(wǎng)頁設(shè)計(jì)從不意味著去制造性能問題，這也是我們無法歸罪于這項(xiàng)技術(shù)本身的原因银受，而許多人相信它能解決一切問題才是錯(cuò)誤的根源践盼。
讓設(shè)計(jì)響應(yīng)式化的重要性在于鸦采，我們需要處理從臺式機(jī)到手機(jī)的大區(qū)間viewport尺寸宾巍。但是只考慮屏幕尺寸低估了移動(dòng)設(shè)備，臺式機(jī)與手機(jī)的分界線正在變得模糊渔伯，不同類型的設(shè)備也趨于提供多樣化功能顶霞。顯然我們已無法再只依賴于使用媒體查詢這一功能。
有些評論者稱之為“負(fù)責(zé)任的響應(yīng)式網(wǎng)頁設(shè)計(jì)”，雖然其他人把它叫做現(xiàn)代化的響應(yīng)式網(wǎng)頁設(shè)計(jì)选浑。撇開兩種叫法語義上的差別蓝厌，我們確實(shí)需要理解并意識到問題所在。
不存在銀彈也沒有可以一勞永逸的方案古徒，我們能做的是使用組合技巧提升現(xiàn)有的響應(yīng)式方案并且力求性能的最優(yōu)化：
提供相同URL及內(nèi)容拓提，但針對不同設(shè)備結(jié)構(gòu)不同双抽；
在立項(xiàng)規(guī)劃階段便需遵循移動(dòng)優(yōu)先原則津函；
使用display: none時(shí)進(jìn)行真機(jī)測試驗(yàn)證資源加載丹锹，而非依賴于桌面瀏覽器模擬浦马；
在瀏覽器提供更好的解決方案（如srcset）之前睬棚，使用JavaScript分發(fā)響應(yīng)式圖片锰霜；
移動(dòng)端初始viewport的文件內(nèi)嵌蚓挤，或者優(yōu)先加載首屏內(nèi)容思犁。
提供更智能的響應(yīng)式方案如：按需加載萨驶、分組響應(yīng)式歉摧、服務(wù)器端的自適應(yīng)處理。
按需加載
CSS媒體查詢無法讓設(shè)備區(qū)分加載和解析腔呜，這意味著移動(dòng)端的手機(jī)會下載和解析為更大屏幕提供的CSS叁温。再者，蜂窩網(wǎng)絡(luò)下CSS的分區(qū)渲染浪費(fèi)的毫秒十分寶貴核畴，有必要避免全依賴于此券盅。
正如我們知道的，iPhone不會動(dòng)態(tài)轉(zhuǎn)換為iPad的尺寸膛檀，采用JavaScript 的matchMedia查詢方法替代CSS媒體查詢锰镀，則能夠保證不同設(shè)備顯示內(nèi)容的統(tǒng)一性并且只加載它們各自所需要的CSS。
使用特征檢測工具可以做到更好咖刃，如Modernizr可以構(gòu)建更智能的UI和功能定義泳炉，而不是只依賴于屏幕尺寸。
分組響應(yīng)式
基于單HTML頁面為所有屏幕進(jìn)行響應(yīng)式設(shè)計(jì)時(shí)嚎杨，為臺式電腦和智能手機(jī)傳送同樣的HTML結(jié)構(gòu)是糟糕的花鹅，原因再次回歸到移動(dòng)端的性能問題。
即使服務(wù)器端存儲同一個(gè)文件枫浙，基于設(shè)備分組也可以實(shí)現(xiàn)對終端的按需發(fā)送刨肃。舉例來說，為6英寸及更大尺寸的屏幕提供大的浮動(dòng)式菜單箩帚，而為小于6英寸的屏幕提供一個(gè)小的漢堡包菜單[2]真友。響應(yīng)式技術(shù)可以基于分組實(shí)現(xiàn)不同情境的適配，如橫豎屏模式的轉(zhuǎn)換紧帕、不同型號的iPhone（寬為320像素）盔然、各式5英寸的安卓設(shè)備（寬為360像素）及平板（寬為400像素及以上）桅打。
服務(wù)器端層面
更智能的響應(yīng)式解決方案的最后一個(gè)選項(xiàng)是服務(wù)器，對移動(dòng)網(wǎng)頁來說服務(wù)器端進(jìn)行特征檢測及定義并不新奇愈案，市面上早有諸如WURFL和Device Atlas之類的工具庫挺尾。
把響應(yīng)式設(shè)計(jì)與服務(wù)器端組件聯(lián)合同樣也有前例，已被知曉的有響應(yīng)式設(shè)計(jì)+服務(wù)器端組件(RESS)站绪，或被稱為自適應(yīng)設(shè)計(jì)遭铺，保障每個(gè)終端代碼簡約性的同時(shí)，提高了響應(yīng)式的速度與可用性體驗(yàn)恢准。
不幸的是掂僵，在過去幾年里這些技術(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)佑煤蠖瞬湛ǎ煌ㄟ^前端工程師就能夠?qū)Ψ?wù)器端架構(gòu)進(jìn)行操作的方式。Node.js[3]是一種卓越的作為前后端之間流通架構(gòu)的平臺队萤，這個(gè)架構(gòu)方式下轮锥，前端工程師可以基于內(nèi)部的流通性進(jìn)行調(diào)整而不需要涉及后端架構(gòu)，從而實(shí)現(xiàn)為所有設(shè)備提供輕快的響應(yīng)式和可用性體驗(yàn)要尔。
響應(yīng)式設(shè)計(jì)舍杜、性能和技術(shù)數(shù)據(jù)
對這篇文章你可能抱有一些置疑，接下來我們將對技術(shù)細(xì)節(jié)進(jìn)行重新審視以減輕你的疑慮赵辕。
響應(yīng)式設(shè)計(jì)通常會為所有設(shè)備傳送相同的HTML文件既绩，再采取媒體查詢的方式加載不同的CSS和image文件，這一點(diǎn)有的人可能不太同意还惠，但很多情況下都是如此實(shí)施的饲握。
你也可能會認(rèn)為如今移動(dòng)網(wǎng)絡(luò)速度的提升已足夠?qū)崿F(xiàn)良好的體驗(yàn)，畢竟4G非巢霞快救欧，設(shè)備也運(yùn)行得更為流暢，那么在下結(jié)論之前我們來看一些數(shù)據(jù)吧锣光。
蜂窩連接[4]
4G網(wǎng)絡(luò)還沒有廣泛覆蓋笆怠，而即便是全世界范圍內(nèi)都能夠使用4G網(wǎng)絡(luò)，可能也會有一些超出預(yù)期的狀況骑疆。只論US地區(qū)的4G用戶數(shù)量約為22%，而其中的40%并非隨時(shí)處于4G連接狀態(tài)替废，除外地區(qū)則只有不到3%的手機(jī)使用4G連接箍铭。
移動(dòng)網(wǎng)絡(luò)速度受限于帶寬，3G可以達(dá)到5Mbps椎镣，4G可以達(dá)到50Mbps诈火。但移動(dòng)網(wǎng)頁體驗(yàn)通常面臨的最重要的現(xiàn)狀是：消耗于接收大文件（如YouTube視頻）的帶寬越多，大批量小文件的并行下載越不順暢状答，并會伴有確定性的高發(fā)延遲冷守。延遲是設(shè)備對每個(gè)數(shù)據(jù)包的首字節(jié)發(fā)起請求接收的往返時(shí)間。
蜂窩網(wǎng)絡(luò)比其他連接方式延遲更多惊科。雖然US的家庭DSL連接延遲為20~45ms拍摇，3G網(wǎng)絡(luò)
卻可能達(dá)到150~450ms，4G網(wǎng)絡(luò)則為100~180ms馆截。這也就意味著蜂窩連接的延遲比家庭網(wǎng)絡(luò)要高出5~10倍充活。
尚有其他延遲方面的問題如無線電廣播引起的變動(dòng)：當(dāng)手機(jī)進(jìn)入休眠狀態(tài)后打開收音機(jī)頻率需要獲取更多數(shù)據(jù)而導(dǎo)致滯時(shí)；設(shè)備平均可用內(nèi)存越低也就意味著電池和CPU消耗越多蜡娶。
蜂窩網(wǎng)絡(luò)下的響應(yīng)式設(shè)計(jì)
一個(gè)實(shí)例：Keynote是一家提供性能解決方案的公司混卵，發(fā)布了2014超級碗頂尖廣告的網(wǎng)頁性能數(shù)據(jù)。這份報(bào)告里陳述：在wired或Wi-Fi連接下加載時(shí)間為1~10s區(qū)間窖张，而在蜂窩連接下加載時(shí)間為5~60s的區(qū)間幕随。實(shí)在難以想象超級碗上投放的廣告是需要加載整整一分鐘的網(wǎng)頁。
2014超級碗頂級廣告網(wǎng)頁性能（查看大圖）
同樣的報(bào)告顯示有43%的網(wǎng)站提供了移動(dòng)專屬版本宿接，平均體積為862KB赘淮；50%實(shí)行響應(yīng)式方案的平均體積在3211KB（超出將近四倍）；另外7%對移動(dòng)設(shè)備提供的則是桌面版睦霎，這基本可以認(rèn)為響應(yīng)式網(wǎng)站比移動(dòng)專屬網(wǎng)站的體積更大拥知。
當(dāng)然，響應(yīng)式網(wǎng)站可以有不一樣的表現(xiàn)碎赢，但不幸的是低剔，這份報(bào)告之外的響應(yīng)式網(wǎng)站的表現(xiàn)也基本與超級碗廣告相似。
基于云技術(shù)的瀏覽器
如果對移動(dòng)端網(wǎng)頁的性能仍存有疑慮肮塞，想想看基于云技術(shù)開發(fā)瀏覽器的廠商正為用戶做的——包括Opera Mini襟齿、基于亞洲的UC瀏覽器（根據(jù)statcounter的統(tǒng)計(jì)，其市場占有率為11%）枕赵，Amazon Fire的Silk瀏覽器和目前的 Google Chrome（通過選項(xiàng)設(shè)置）猜欺。
這些廠商在云端壓縮所有的網(wǎng)站和資源，隨后瀏覽器下載優(yōu)化過的版本到移動(dòng)端拷窜，而他們?nèi)绱俗龅睦碛墒钦J(rèn)識到了性能服務(wù)于用戶的意義开皿。
移動(dòng)端的網(wǎng)頁被低估
網(wǎng)絡(luò)社區(qū)通常會低估移動(dòng)瀏覽器的重要性涧黄，我曾聽到人們說現(xiàn)今的移動(dòng)端網(wǎng)頁只有iOS的Safari和Android的Chrome瀏覽器，對響應(yīng)式設(shè)計(jì)赋荆，我們只需顧及320像素寬的viewport笋妥。但實(shí)際情況比這復(fù)雜得多。
如今有不下于10個(gè)瀏覽器的市場占有率超過1%窄潭，就算只需考慮iOS和Android的默認(rèn)瀏覽器也并不容易春宣。大致情形來說，在移動(dòng)端瀏覽網(wǎng)頁的用戶中嫉你，iOS占50%月帝，Android占38%，Windows Phone占3%幽污，Opera Mini占5%（包括各類操作系統(tǒng)）嚷辅，剩余4%則為其他平臺。
而如今的Android平臺有64%的用戶使用自帶瀏覽器距误，這是一個(gè)與Google Chrome存在差異并且本身具有多個(gè)版本的瀏覽器潦蝇。此外，最新的三星Galaxy中有一些設(shè)備所提供的Android瀏覽器是自定義引擎的版本深寥。
根據(jù)viewport的尺寸攘乒，僅Android系統(tǒng)的智能手機(jī)，如今我們需要處理的像素寬度就包括320惋鹅、360则酝、400、540闰集。那么我要建議的是沽讹，不要低估移動(dòng)端的網(wǎng)頁，并去了解它那些獨(dú)一無二的特征武鲁。
1秒內(nèi)完成首屏內(nèi)容的加載
在移動(dòng)設(shè)備中爽雄，我們把在1秒或是更少時(shí)間完成首屏內(nèi)容（即不需滾動(dòng)直接顯示的內(nèi)容）渲染的網(wǎng)站視作是快的。我知道1秒鐘看起來十分快速——特別是考慮到至少有一半的情形是要在蜂窩網(wǎng)絡(luò)下來達(dá)到的——但這已被證實(shí)是可能的沐鼠。1秒響應(yīng)可保證用戶聚焦于內(nèi)容挚瘟，從而提升轉(zhuǎn)化率及減少流失。
達(dá)到1秒響應(yīng)時(shí)間饲梭，首屏內(nèi)容需要在傳輸控制協(xié)議（TCP）的單次往返時(shí)間中完成——不能忽略的是普遍的3G網(wǎng)絡(luò)幾乎存在半秒的延遲乘盖。由于TCP被稱為“慢啟動(dòng)”，首次響應(yīng)不能超過14KB以避免二次打包憔涉。這意味著首屏內(nèi)容的HTML和CSS至少必須符合14KB的單次HTTP響應(yīng)订框。如果我們做到這個(gè)，那么也就達(dá)成了1秒加載時(shí)間的感官體驗(yàn)兜叨。
這條規(guī)則并沒有被明確列出穿扳，且要視實(shí)際需要而有所調(diào)整衩侥。然而，由于移動(dòng)屏幕的首屏內(nèi)容顯示通常無法達(dá)到與桌面屏幕一致的效果矛物，使用響應(yīng)式設(shè)計(jì)達(dá)到1秒的目標(biāo)是非常艱難的茫死，但實(shí)現(xiàn)的難度是可以通過多種技術(shù)的結(jié)合降低的。
一個(gè)HTML服務(wù)所有平臺
一個(gè)典型的響應(yīng)式設(shè)計(jì)是對所有設(shè)備發(fā)送單一的HTML文件：電視泽谨、桌面璧榄、平板特漩、智能手機(jī)及其后的所有手機(jī)吧雹。這聽起來很贊，但我們生活的世界有蜂窩網(wǎng)絡(luò)和其他的各種問題涂身。移動(dòng)設(shè)備下你的響應(yīng)式HTML可能會正確渲染雄卷，但它不夠快，本來它應(yīng)該是可以更快的蛤售，這也在影響你的轉(zhuǎn)化率丁鹉。
一旦有display: none出現(xiàn)在CSS中悴能，你的站點(diǎn)就會開始變慢。一個(gè)從零開始為語義設(shè)計(jì)的站點(diǎn)冯凹，響應(yīng)式的超載會讓一切工作幾近化為無用；一個(gè)站點(diǎn)的HTML里包含的40個(gè)外部JavaScript里的絕大多數(shù)jQuery插件和功能庫都是為大屏服務(wù)的炒嘲，響應(yīng)式超載會讓一切崩潰宇姚。使用同一HTML浑劳，就等同于在所有設(shè)備加載同樣的外部資源。
這并不是說不能做單一的響應(yīng)式設(shè)計(jì)夭拌，只是站點(diǎn)不會自行進(jìn)行優(yōu)化魔熏。如果你已經(jīng)留心到了性能鸽扁，那么你的響應(yīng)式方案將會不同尋常。
我們來審視一番星巴克的站點(diǎn)滓窍，它的主頁是響應(yīng)式的并且在我們測算的三種viewport下（屏幕截圖見下）看起來都很贊巩那。但查看結(jié)構(gòu)之后此蜈，我們發(fā)現(xiàn)所有版本都加載33個(gè)外部JavaScript文件和6個(gè)CSS文件噪生。使用3G延遲網(wǎng)絡(luò)的移動(dòng)設(shè)備需要加載到39個(gè)外部文件只為顯示這樣一個(gè)頁面么跺嗽？
不同情境下的星巴克站點(diǎn) (查看大圖）
你可能會認(rèn)為桨嫁，“啊，干嘛怪技術(shù)應(yīng)該怪實(shí)現(xiàn)”楣导，這是對的畜挨。這篇文章并不是和響應(yīng)式網(wǎng)頁設(shè)計(jì)作對巴元，它駁斥的是瞄準(zhǔn)了響應(yīng)式卻實(shí)現(xiàn)得很糟糕，它駁斥的是以響應(yīng)式為目標(biāo)而不顧性能呕缭，正如星巴克一般禀忆。
若你的響應(yīng)式站點(diǎn)存在性能問題，那根源可能是出于你所定的目標(biāo)离熏。若為響應(yīng)式設(shè)計(jì)實(shí)施規(guī)劃，也必須為性能實(shí)施規(guī)劃滋戳。
資源加載
媒體查詢有多種應(yīng)用方式奸鸯，通常采用如下中的一種：
單獨(dú)CSS文件添加多樣的@media聲明可帽；
通過link標(biāo)簽的media屬性為頁面引入多樣的CSS文件。
第一種情形中蓄拣，只會產(chǎn)生一個(gè)CSS文件球恤，故所有設(shè)備都會加載全平臺的CSS，數(shù)百個(gè)無用的選擇器都會被瀏覽器轉(zhuǎn)譯和解析堪置。
你可能會認(rèn)為多樣的外部文件是更好的方式张惹，因?yàn)闉g覽器會基于斷點(diǎn)加載不同的資源诵叁，這是我們在各種博客钦椭、雜志彪腔、書和培訓(xùn)課程中得到的信息。
media="(min-width: 801px)">
media="(min-width: 401px) and (max-width: 800px)">
media="(max-width: 400px)">
好吧恭垦，你完全錯(cuò)了格嗅。所有的瀏覽器會不分環(huán)境地把所有的外部CSS一并加載屯掖。下面的屏幕截圖顯示iPhone下載了所有頭部引用的CSS文件， 包括與它無關(guān)的粪摘。
瀏覽器會不分環(huán)境地把所有的外部CSS一并加載 （查看大圖）
為何瀏覽器會下載所有的CSS文件徘意？現(xiàn)在假設(shè)有一個(gè)CSS文件是為豎屏提供的另一個(gè)則為橫屏提供轩褐。我們不希望瀏覽器在橫豎屏切換時(shí)飛快地切換CSS把介，為防止其間出現(xiàn)頁面裸奔（無CSS的裸HTML頁）竹宋，我們希望的是瀏覽器提前把所有文件都加載好蜈七。而這正是你基于屏幕尺寸定義媒體查詢會發(fā)生的一切莫矗。
那么可以調(diào)整移動(dòng)瀏覽器的尺寸么作谚？目前基本上不行，但廠商正在準(zhǔn)備推出可以像桌面瀏覽器一樣調(diào)整的移動(dòng)瀏覽器雀监，這也是瀏覽器會不顧媒體查詢的寬度匹配規(guī)則不分情境加載所有聲明的CSS的原因眨唬。
尚沒有任何移動(dòng)設(shè)備具有可伸縮的viewport（目前為止）匾竿，但某些情形下viewport會被重置：
某些瀏覽器的屏幕旋轉(zhuǎn)；
viewport聲明被動(dòng)態(tài)更改临庇；
onload添加了內(nèi)容導(dǎo)致偏移假夺；
支持外部鏡像斋攀；
某些三星的安卓機(jī)同時(shí)運(yùn)行多個(gè)app（多窗口模式下）蜻韭。
在上述變動(dòng)下瀏覽器會最優(yōu)化加載可能會需要的所有資源。而不遠(yuǎn)的將來瀏覽器對此會更智能闺魏，但此時(shí)我們尚有問題存留：我們傳送了比實(shí)際需要超出得多的資源析桥，從而讓用戶遭受無妄之災(zāi)。
真正的問題：以響應(yīng)式設(shè)計(jì)為目標(biāo)
正如Lyza Danger Gardner在“當(dāng)我們談?wù)摗憫?yīng)式’時(shí)我們在談?wù)撌裁础?/a>里所說的埋虹，設(shè)計(jì)師為“響應(yīng)式”下的定義并不一致娩怎，從而會導(dǎo)致溝通誤差截亦。
追本溯源來看，這個(gè)術(shù)語首次出現(xiàn)是在2010Ethan Marcotte的文章里袍啡，隨之而來是同名書籍境输。Ethan定義其為：以流體網(wǎng)格颖系、彈性圖片和媒體查詢?nèi)N技術(shù)為多區(qū)間的設(shè)備屏幕提供最佳顯示體驗(yàn)集晚。
這并沒有什么不對区匣，問題出現(xiàn)在我們只把它視之為站點(diǎn)效果亏钩，而沒有理解其背后更寬廣的更需要達(dá)成的目標(biāo)。
當(dāng)以響應(yīng)式設(shè)計(jì)效果為目標(biāo)蛤签，會變得容易迷失在觀念中震肮。你 真正試著去解決的問題是什么留拾？響應(yīng)式化有問題么？也許沒有沦偎。但你是否把“響應(yīng)式化”理解為“兼容移動(dòng)端”豪嚎？如果是這樣，那你也許犯了一些錯(cuò)誤舌涨。
一個(gè)站點(diǎn)的終極目標(biāo)應(yīng)該是“服務(wù)用戶”泼菌，從而實(shí)現(xiàn)更多形式的轉(zhuǎn)化啦租，不論是讓訪客傳播文字篷角、提供信息還是產(chǎn)生消費(fèi)。沒有高性能的站點(diǎn)就沒有滿意的用戶虐块。
性能在轉(zhuǎn)化上贺奠，尤其是移動(dòng)端方面的直接影響错忱，已被多次證實(shí)以清。如果這是你第一次聽聞，只要隨便翻閱一本Steve Souders關(guān)于網(wǎng)頁性能優(yōu)化的專業(yè)書就可一知詳細(xì)眉孩。
知曉目標(biāo)浪汪，決定用何種工具和技術(shù)以最佳方式實(shí)現(xiàn)凛虽。這就是你分析在哪里涩维、如何用響應(yīng)式方法時(shí)應(yīng)該做的袁波。你使用響應(yīng)式設(shè)計(jì)——卻沒有領(lǐng)會它篷牌。
響應(yīng)式與用戶
紐約時(shí)報(bào)在幾個(gè)月前以保持“符合你的預(yù)期”為目標(biāo)重新設(shè)計(jì)了網(wǎng)站枷颊，同時(shí)有上千家大型企業(yè)驕傲地推出了他們新的響應(yīng)式版的網(wǎng)站该面。
紐約時(shí)報(bào)以有別尋常的方式進(jìn)行響應(yīng)式設(shè)計(jì)隔缀，但有一些人對它并非基于相同HTML進(jìn)行適應(yīng)性布局而是采取專門的移動(dòng)站點(diǎn)抱以不滿，甚至有一篇文章冠以“新版的紐約時(shí)報(bào)WebApp缺失響應(yīng)式設(shè)計(jì)的核心”的標(biāo)題聲討界赔。
紐約時(shí)代雜志以有別尋常的方式進(jìn)行響應(yīng)式設(shè)計(jì) （查看大圖）
沒有人說過響應(yīng)式設(shè)計(jì)意味著使用同一HTML去適配所有屏幕尺寸淮悼，而這顯然已被當(dāng)作普遍定義袜腥。但這條規(guī)則并沒有在任何地方被明確規(guī)定钉汗，只是我們試圖簡化問題所造成的儡湾。
近幾個(gè)月內(nèi)徐钠，數(shù)家公司都在宣揚(yáng)著這樣的臺詞：“我們提供了一個(gè)新的響應(yīng)式版網(wǎng)站役首，讓移動(dòng)端轉(zhuǎn)化得到了100%的提升衡奥。”但轉(zhuǎn)化的提升確實(shí)是因?yàn)檎军c(diǎn)進(jìn)行了響應(yīng)式化么失息？還是用戶意識到了它是響應(yīng)式的而更愿意使用盹兢？
人們轉(zhuǎn)化更多僅是因?yàn)樵谝苿?dòng)設(shè)備上得到了更快更好的體驗(yàn)绎秒，而無關(guān)于采取了何種有別以往的方案（不論它是移動(dòng)端版本還是桌面版本的縮影）。以此說來剂娄，響應(yīng)性沒有任何優(yōu)于采用傳統(tǒng)移動(dòng)方案實(shí)現(xiàn)的特別之處阅懦，而相同設(shè)計(jì)下的獨(dú)立移動(dòng)站點(diǎn)若輔以其他技術(shù)形成更明智的方案徘铝，也能夠達(dá)到相同的轉(zhuǎn)化甚至更佳庭砍。
結(jié)論
“用戶才不鳥你的站點(diǎn)用上了什么響應(yīng)式” —— Brad Frost
Brad Frost相當(dāng)正確怠缸，用戶想要的是快速易用，他們并不老去調(diào)整瀏覽器窗口扳炬，也不需要理解“響應(yīng)式”的含義恨樟。
這是沉重的事實(shí)疚俱，也并非是所有網(wǎng)站都會面臨的狀況呆奕，但也好過總想著“我們做了響應(yīng)式兼容移動(dòng)端沒有后顧之憂了梁钾。”某些時(shí)候零酪，甚至不需要考慮情境地把響應(yīng)式設(shè)計(jì)稱之為“性能破壞者”也是有利的四苇，因?yàn)檫@將有助于讓人們關(guān)注到性能的重要性。
紐約時(shí)報(bào)是對的：以用戶為核心胎许，而非工具或技術(shù)辜窑，甚或是當(dāng)作設(shè)計(jì)師們的狂歡穆碎。
延伸閱讀
“遺失核心的響應(yīng)式設(shè)計(jì)”Brad Frost
“RESS: 響應(yīng)式設(shè)計(jì) + 服務(wù)器端組件,” Luke Wroblewski
“當(dāng)我們談?wù)摗憫?yīng)式’時(shí)我們在談?wù)撌裁?/a>” Lyza Danger Gardner, A List Apart
“再好的運(yùn)營也無法回避性能問題” Aaron Rudger, Keynote
“二度驗(yàn)證：實(shí)境下的響應(yīng)式設(shè)計(jì)性能” Guy Podjarny
“技術(shù)本無過錯(cuò)所禀，執(zhí)行決定成敗” Tim Kadlec
“稱之‘響應(yīng)式設(shè)計(jì)=性能破壞者’于性能有益” Tim Kadlec
詞匯譯注：
[1]沒有任何一項(xiàng)技術(shù)或方法可使軟件工程的生產(chǎn)力在十年內(nèi)提高十倍放钦。維基：沒有銀彈?
[2]漢堡包菜單操禀，以三道杠形式表示菜單入口颓屑。延伸閱讀：關(guān)于漢堡包圖標(biāo)的閑言碎語?
[3]Node，使用Chrome V8引擎快速構(gòu)建可伸縮應(yīng)用程式的平臺遍搞。Node.js 究竟是什么溪猿？?
[4]國內(nèi)外蜂窩網(wǎng)絡(luò)連接的狀況有所差異蒂培。百科參考：蜂窩網(wǎng)絡(luò)?
相關(guān)標(biāo)簽
