如何在響應式基礎上提高移動性能///響應式不是萬能的！教你提高響應式設計的移動性能（一）

如何在響應式基礎上提高移動性能

摘要：如何在響應式基礎上提高移動性能,從細節作起,結合網站,作好響應式頁面的設計優化工做.,隨着互聯網的高速發展,合肥網站建設小編今天爲你們介紹,爲解決移動性能的響應式頁面設計並非萬能的,而應該不斷的改進,從而更好的爲用戶服務.
隨着互聯網的高速發展，例如近段時間炒得火熱的谷歌申請的無人機技術，以及電商門戶網站阿里巴巴的上市等等，這都促進了互聯網突飛猛進的變化。

因此做爲網站seo人員不該固步自封，而應該努力的跟上時代的步伐，不只須要學習相關的seo知識，並且對於網站的製做相關過程也應該作相應的瞭解，以便更好的爲網站優化作準備。合肥網站建設小編今天爲你們介紹，爲解決移動性能的響應式頁面設計並非萬能的，而應該不斷的改進，從而更好的爲用戶服務。

智能手機的發展，促使了響應式頁面的出現，這對於前段時間話題360新推的Urlink，對網站建設的利與弊，有很大的衝擊。因此響應式頁面一直受到廣大網絡公司的歡迎和使用，一樣在設計響應式頁面的網站時，存在的問題以及挑戰一直存在。

目前對於市場中大部分11%的網站採起的是響應式網頁設計，據專業研究Guy Podjarny顯示，這其中有72%的響應式網站，在不一樣屏幕大小的移動性能設備中，都會提供相同的字節，這樣致使直接的結果是因不一樣屏幕移動設備，影響到用戶的加載速度。

咱們明白到響應式頁面存在的不足，並非說響應式頁面就不可取，這是一種錯誤的理解。咱們須要的是與移動性能設備相互促進影響的響應式頁面，從而更好的爲用戶服務，已達到更加的智能化。咱們能夠採起的相關措施，以下：

1，在相同的URL使用的文檔中，能夠採起相同的內容，對於網站設計的結構可不同。

2，響應式頁面的使用並非要取代移動頁面，因此要遵循移動先行的方案。

3，在決定使用響應式頁面的時，須要在相關的真是移動設備中進行測試，已記錄會發生的一些問題與不足，從而及時的採起解決方案。

4，對於不一樣瀏覽器所瀏覽到的頁面也會是不同的，因此對於設計好的響應式頁面須要使用優化工具，以便更好的進行測量，爲提升相關性能作準備。

5，在圖片設計中，須要經過JavaScript傳輸，以便在用戶瀏覽網站的時候，加載不會受到影響。

6，對於不一樣的移動設備，咱們須要考慮的是用戶在瀏覽時，須要作好相關的響應式解決方案，例如條件加載，在服務器端解決方案等等。

綜上所述，爲使網站在移動性能設備中更加快速的發展，須要網站建設設計以及優化人員共同的努力，從而更好的促進響應式頁面在用戶中更好的使用開來。這提升了響應式設計的速度和可用性，同時每個服務器端都保持一個代碼庫。
----------------------------

響應式不是萬能的！教你提高響應式設計的移動性能（一）


你調整了瀏覽器，笑容攀上臉頰。你感到很是開心，認爲本身實現了友好移動的目標。在正式討論前，讓我來預測下將來：你會失掉用戶和經濟效益，若是你把響應式網頁做爲惟一目標和惟一的解決辦法。

好消息是，你能夠改善它。

在這篇文章中，咱們會談到移動互聯網和響應式設計的關係，首先將介紹如何巧妙的運用響應式設計，爲何性能對移動端很是重要，爲何響應式設計不能做爲你網站的目標，最後技術的性能問題幫助咱們更好的理解這問題。

自2000年開始，設計者和開發者就把移動設備的問題過於簡單化，以致於如今仍然有人認爲響應式網頁設計能解決一切問題。

你們必須明白，凌駕於任何目標，移動網絡體驗必須和閃電同樣快。迅速、實用、兼容的體驗對全部移動設備都是挑戰。當你使用響應式設計時，這些挑戰都存在。從一開始就重視性能會讓過程容易些。

響應式設計是很棒，但不是萬能鑰匙。若是你在移動設備上一味堅持，在轉換率後就可能隱藏着性能問題。大約有11%的網站是響應式，這個數字每個月都在增加，因此如今是談論這個問題的時機了。

據Guy Podjarny研究，72%的響應式網站不分屏幕大小都提供相同的字節，儘管這會下降移動網絡鏈接。不是全部用戶都有耐心等着網站加載。

對響應式設計存在的問題有了基本認識，咱們就能減低它帶來的損失。
移動網站來自過去

我不是說你不該該採用響應式設計或者去用m.*的子域名。事實上，如今社會分享無處不在，不分設備，分配給給文檔一個URL，這是聰明的作法。但這並不意味着一個單獨URL應該提供相同的文檔或每個設備都應該下載相同的資源。

援引Ethan Marcotte的話，他創造了「響應式網頁設計」這個術語。

最重要的是，響應式網頁設計的初衷不是要取代移動網頁。——Ethan Marcotte

交互、移動、快速

若是咱們能使用一些其餘的技術，就能夠實現得到響應式設計好處的同時，不影響移動設備的性能。響應式設計歷來不是意味着要解決「性能」，這也是爲何咱們不能所以指責它的緣由。然而，相信它能解決你全部問題，這大錯特錯。

設計響應式很重要，由於咱們須要解決跨桌面和移動端視窗大小範圍的問題。可是隻考慮屏幕大小就低估了移動設備。桌面和移動端的界限正在變得模糊，基於不一樣的設備對咱們而言仍然有多種可能性。可是咱們還不能經過媒體查詢來決定響應式設計的功能。一些評論家稱之爲「可靠的響應式網頁設計」，然而另外一些人則認爲它是伴隨現代視覺的響應式網頁設計。在沒有了解其基本語義的狀況下，咱們須要搞清楚這個問題。

雖然沒有可應用於各種文檔的萬全之策，可是可以運用一些技巧來改善現有響應式的解決辦法，而且力求性能最大化。

    實現每個文檔對全部的設備都使用相同的URL和相同的內容，結構沒必要要相同。
    當從零開始，遵循「移動先行」的方法。
    在一個真實設備上測試當資源加載和顯示會發生什麼。不要依賴調整你的桌面瀏覽器。
    使用優化工具測量和提升性能。
    經過JavaScript傳輸響應圖片，雖然咱們更期盼着瀏覽器供應商（例如srcset）能解決這個問題
    當你須要當前設備具有加載條件時，只加載JavaScript，這會在onload事件以後發生。
    對移動設備，內聯文檔的原始視圖，或者發送一屏顯示內容。
    使用下面一種或幾種技術應用智能響應式的解決方案：條件加載、按組響應、服務器端層（如適應性方法）。

條件加載

不要老是在CSS中依賴media queries，由於瀏覽器將會爲全部設備加載和解析全部選擇器和樣式 （後面詳細討論）。這就意味着手機爲了一個大屏要下載和解析CSS。由於CSS塊的呈現，你要浪費一些時間等待聯接成功。

在設備上用JavaScript的matchMedia查詢來代替CSS media queries，你知道這些內容是不會變化的。例如，你們都知道iPhone不能動態的轉換成iPad的規格，因此咱們只在正在須要CSS時才用。

能夠用特徵檢測，例如 Modernizr，對UI和功能性作出更明智的決定而不是僅僅根據屏幕尺寸。
按組響應

在處理簡單文檔、爲臺式電腦和智能手機提供相同的HTML時，雖然爲咱們可讓全部屏幕依賴一個單一的HTML基礎和響應式設計，但這並不老是最好的解決方案。爲何呢？一樣是因爲移動設備的性能。

即便咱們在服務器端儲存相同的文檔，可是根據設備組別的不一樣給用戶不一樣的文檔。舉個例子，爲一個6英寸甚至更大的屏幕提供大的浮動菜單，爲一個小屏幕提供漢堡菜單。在每一個組羣裏，使用響應時技術以適應不一樣的場景，例如肖像模式和風景模式的轉換，切換iPhone（320像素寬）、5英寸Android設備（360英寸）和平板（400像素）。
服務器端層

智能響應策略的最後一個選擇是服務器。

服務器端功能檢測和決策不是移動網絡的新鮮玩意。相似 WURFL 和Device Atlas的庫在市場上有好多年，響應式設計和服務器組件的混合也衆所周知。有時被稱爲是響應式設計和服務器端組件（RESS）,有時又叫自適應設計，這提升了響應式設計的速度和可用性，同時每個服務器端都保持一個代碼庫。

很遺憾的是。這些技術這幾年並無什麼突破性的發展。只能在博客和雜誌裏看到一些開發者對「RESS」、「響應式」、「自適應」作比較。緣由就是：咱們是前端專業人士。任何涉及到服務器的事情看起來都是不太愉快的問題。在一些狀況下，前端設計師能把握好服務器的腳本，另外一些狀況是，服務器由遠程開發團隊管理，設計師不想每作一次小的UI改變就要和遠程團隊溝通處理。我能體會這種感受。

這就是在大型項目中要花時間思考新架構層的緣由，這樣前端工程師對服務器作決定時不會影響到後端架構。Node.js是一個極好的備選平臺，是介於當前企業後端基礎和前端之間的服務器端層。

在這個新的端層裏，前端的工程師能夠根據有現實的決定權，這會使得在不觸及後端架構的狀況下，讓全部設備上的體驗更爲快速、響應、可用。