国产又色又爽无遮挡免费,亚洲中文字幕乱码熟女在线,换脸国产av一区二区三区,99久久亚洲综合精品成人网

前言：2015年響應式設計趨勢的延續，也將帶來更多的爭議和思考，此文所引論據較為客觀，點出了響應式概念的初衷和近年來跨屏設計的狀況，并提供了解決思路和可參考的具體方法，原文下的評論也有諸多爭議，有興趣可以移步一覽。

你臉上掛著微笑心情愉悅地縮放著瀏覽器窗口時，認為網站達成了移動端友好體驗的目標。在探討之前我要提前推論：如果你只是把響應式網頁設計定為終極目標并且是唯一的移動端方案，是在流失用戶，也許還有金錢。幸運的是我們能夠修正這些錯誤。
這篇文章的內容將涉及移動網頁與響應式設計的關系，始于如何提供靈巧的響應式設計，及移動端的性能為何如此重要、響應式設計何以不能視為網站的目標，并止于技術本身的性能爭議，以便輔助理解問題的真正所在。
2000年起，設計師和開發者就已對移動端存在的問題過分簡化，而現在有些人則認為響應式網頁設計是一切難題的銀彈。我們需要正視的是，達到移動網頁的輕快體驗應蓋過其他任何目標。向所有移動設備傳送一個快速可用并全兼容的體驗是一個挑戰，在實施響應式技術時也是如此。而在一開始便關注性能將協助我們更易達成目標。
響應式網頁設計非常優秀，但它不是銀彈。如果把它當作移動端的唯一法寶，那么也許會有性能問題將對轉化率造成阻礙。現約有11%的網站是響應式的并且這個數字每個月都在上升，討論它的時機到了。
根據Guy Podjarny的調查，72%的響應式網站統一傳送相同數量的字節，而不依據屏幕尺寸區分處理，甚至在使用速度較慢的移動網絡連接也是如此。但并非所有的用戶都會耐心等待網站的加載。
實際上只需對問題有基本理解，我們就可以讓損失降到到最低。
移動網站由來已久
我并不是說不該讓設計做到響應式，或者建議應該采用一個m.*的子域名。事實上，社交分享已無所不在，不區分設備讓每一個文件指向同一個URL是明智的。但這并不意味著單一的URL應該總是傳送同一文件，或者說是所有的設備應該加載同一個資源。
引用創造“響應式網頁設計”術語的Ethan Marcotte的一句話：

                        最重要的是，響應式網頁設計不是特意為移動網站提供的一個替代解決方案。

（譯補Ethan Marcotte原文：“我認為響應式設計是設計哲學的一部分，也是前端開發策略的一部分。而作為后者，應依實際項目所需評估其可行性。”）

響應、移動、快速

移動端的性能保證與響應式設計可以同時實現，只要用上一些其他技術。響應式網頁設計從不意味著去制造性能問題，這也是我們無法歸罪于這項技術本身的原因，而許多人相信它能解決一切問題才是錯誤的根源。
讓設計響應式化的重要性在于，我們需要處理從臺式機到手機的大區間viewport尺寸。但是只考慮屏幕尺寸低估了移動設備，臺式機與手機的分界線正在變得模糊，不同類型的設備也趨于提供多樣化功能。顯然我們已無法再只依賴于使用媒體查詢這一功能。
有些評論者稱之為“負責任的響應式網頁設計”，雖然其他人把它叫做現代化的響應式網頁設計。撇開兩種叫法語義上的差別，我們確實需要理解并意識到問題所在。
不存在銀彈也沒有可以一勞永逸的方案，我們能做的是使用組合技巧提升現有的響應式方案并且力求性能的最優化：

                       提供相同URL及內容，但針對不同設備結構不同；
                       在立項規劃階段便需遵循移動優先原則；
                       使用display: none時進行真機測試驗證資源加載，而非依賴于桌面瀏覽器模擬；
                       在瀏覽器提供更好的解決方案（如srcset）之前，使用JavaScript分發響應式圖片；
                       移動端初始viewport的文件內嵌，或者優先加載首屏內容。
                       提供更智能的響應式方案如：按需加載、分組響應式、服務器端的自適應處理。

按需加載

CSS媒體查詢無法讓設備區分加載和解析，這意味著移動端的手機會下載和解析為更大屏幕提供的CSS。再者，蜂窩網絡下CSS的分區渲染浪費的毫秒十分寶貴，有必要避免全依賴于此。
正如我們知道的，iPhone不會動態轉換為iPad的尺寸，采用JavaScript 的matchMedia查詢方法替代CSS媒體查詢，則能夠保證不同設備顯示內容的統一性并且只加載它們各自所需要的CSS。
使用特征檢測工具可以做到更好，如Modernizr可以構建更智能的UI和功能定義，而不是只依賴于屏幕尺寸。

分組響應式

基于單HTML頁面為所有屏幕進行響應式設計時，為臺式電腦和智能手機傳送同樣的HTML結構是糟糕的，原因再次回歸到移動端的性能問題。
即使服務器端存儲同一個文件，基于設備分組也可以實現對終端的按需發送。舉例來說，為6英寸及更大尺寸的屏幕提供大的浮動式菜單，而為小于6英寸的屏幕提供一個小的漢堡包菜單。響應式技術可以基于分組實現不同情境的適配，如橫豎屏模式的轉換、不同型號的iPhone（寬為320像素）、各式5英寸的安卓設備（寬為360像素）及平板（寬為400像素及以上）。

服務器端層面

更智能的響應式解決方案的最后一個選項是服務器，對移動網頁來說服務器端進行特征檢測及定義并不新奇，市面上早有諸如WURFL和Device Atlas之類的工具庫。
把響應式設計與服務器端組件聯合同樣也有前例，已被知曉的有響應式設計+服務器端組件(RESS)，或被稱為自適應設計，保障每個終端代碼簡約性的同時，提高了響應式的速度與可用性體驗。
不幸的是，在過去幾年里這些技術沒有在社區里獲得太多的推動，只需看看有多少為開發者提供的博客或雜志將“RESS” 與“自適應” 和“響應式”相提并論便可一知。其一原因在于：我們是前端工程師，任何涉及后端的內容都是個令人頭疼的難題。
一部分情況是前端設計人員可以控制的是服務器上的腳本；另一部分情況是有遠程開發團隊管理，設計師并不想在每次需要調整UI時都與他們打交道，這種情形下的心情我能夠理解。
這也是為何在大項目里頭應該考慮新的架構層：一種不需要動用后端，只通過前端工程師就能夠對服務器端架構進行操作的方式。Node.js是一種卓越的作為前后端之間流通架構的平臺，這個架構方式下，前端工程師可以基于內部的流通性進行調整而不需要涉及后端架構，從而實現為所有設備提供輕快的響應式和可用性體驗。