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