如何讓你的移動端網站更快

性能測試

優化移動性能的第一步是進行性能測試。目前，業界存在大量免費和付費的資源能夠完成這一步。不過，我最喜歡的仍是谷歌 Chrome 內建的開發者工具和 WebPageTest。爲了簡單起見，本文中我就直接選用 Chrome 的開發者工具了。

你不是一個開發者？不要緊，這個開發者工具很容易就能夠上手：

1. 打開 Chrome （固然我已經假設你安裝了 Chrome 瀏覽器）
2. 點擊右上角相似漢堡的三條線按鈕，那是一個菜單鍵
3. 選擇更多工具，最後選擇開發者工具

若是你對開發者工具不太熟悉，或者只瞭解一點。若是你想再深刻的瞭解，能夠閱讀《DevTools Learning》。這篇文章收集了不少有關於開發者工具的學習資料。

如今你應該已經能夠看到網格型的屏幕已經大量有趣的信息。其中最重要的，就是頂部的下拉菜單，其中包含了許多不一樣的手機和平板模擬模式。太酷了。

接下來，選擇一個感興趣的設備，好比 iPhone 6。在瀏覽器的地址欄輸入站點地址，回車進入！你就能夠看到站點被渲染到了 iPhone 6 模擬器上。滾動到頁面底部能夠看到一系列的性能信息，好比頁面加載時間、頁面大小和總的請求數。點擊 Network 信息欄，能夠看到瀑布流形式的頁面加載動態，以下所示：

優化移動端圖片

根據這份 HTTP 統計，圖片大概佔據了頁面整體積的 60% 之多。只憑直覺來講，圖片通知了網頁。若是使用谷歌開發者工具檢查你的頁面，我相信也會得出相似的結果。當使用緩慢的移動網絡加載圖片時，大圖片就會嚴重影響頁面的響應速度。

雖然解決該問題可使用有損和無損圖片優化兩種技巧，可是對於移動端，咱們還有其餘的考慮：咱們是否應該在頁面加載之初就下載圖片？那種桌面端分辨率高達 1600px 精緻圖片，若是直接用在平板和手機上，即便平板和手機是高分率的，仍然顯得有些浪費。

如何解決？爲移動用戶加載更小體積的圖片。注意：這裏有正確和錯誤兩種優化方式。

提示：在本例中，請確保在頁面頭部使用了 viewport 元標籤。該標籤用於通知移動瀏覽器，當前頁面爲響應式頁面，避免被當成桌面站點縮放成移動屏幕的大小，那就太醜了。此外，若是該標籤不存在，那麼就會獲得不一樣的渲染結果。

<meta name="viewport" content="width=device-width, initial-scale=1.0" /> 

錯誤方式

響應式設計中大量使用了 CSS 媒體查詢，用來美化不一樣屏幕尺寸下的渲染結果，因此，最簡便的圖片切換方式就像以下代碼所實現的效果：

<!-- DON'T DO THIS --> <style> @media (min-width:376px) { .mobile_image { display: none; } .desktop_image { display: inline; } } @media (max-width:375px) { .mobile_image { display: inline; } .desktop_image { display: none; } } </style> <img src="mobile.png" class="mobile_image" /> <img src="desktop.png" class="desktop_image" /> 

這段代碼的功能就是，在頁面較寬時顯示一種尺寸的圖片，在頁面較窄時顯示另外一種尺寸的圖片。

看上去還不錯，可是卻有個致命的缺點：這兩個圖片都會被加載！爲了驗證這一結論，可使用谷歌開發者工具監視整個加載過程：

確實很糟糕。實際上，這比優化前更糟糕了！你浪費了大量的時間加載了一張可能永遠都不會用到的圖片！

正確方式

相反，當咱們使用 div 的 background-image 屬性的時候，就能夠實現想要的優化效果，上代碼：

<!-- DO THIS --> <style> @media (min-width:376px) { .myimage { background-image: url("desktop.png"); width: 700px; height: 550px; } } @media (max-width:375px) { .myimage { background-image: url("mobile.png"); width: 350px; height: 130px; } } </style> <div class="myimage"></div> 

在開發者工具中監視加載流程，以下所示：

從只能夠看出，只有相應尺寸的圖片被加載了…… 太棒了！固然，對此還有一點注意事項: 爲 div 使用 background-img，須要給給出肯定的尺寸和高度。若是面臨大量的圖片，或者這些圖片的尺寸常常改變，那麼這種方案就太繁瑣了。但若是隻是應用到大尺寸的主圖上，就能夠在下降複雜度的同時大幅提升響應性能。

提示：雖然使用這種方式能夠優化移動響應速度，但只是對於那些高分辨率的大圖。

是時候考慮拋棄 jQuery

什麼？你沒吃錯藥吧？jQuery 但是神通常的存在，你竟敢如此忽視它的存在？

jQuery 確實很是有用，它的初衷就是爲諸多沒有乖乖實現 W3C 標準的瀏覽器，提供統一的接口，避免書寫各類條件語句判斷當前環境。

可是，jQuery 的統一接口在移動設備上就顯得有些多餘了。移動端已經被相似 Safari 和 Chrome 的 webkit 內核瀏覽器統治了，因此無需再抽象出統一的接口。反而是它龐大的體積，即便是經過緩存調用，也應該考慮放棄它了。甚至是壓縮和合並後的 jQuery，也有 30KB 之巨。

固然，你也許還想使用相似 jQuery 的簡單接口，那麼我建議你使用 Zeptojs 來代替。雖然它不是徹底等同於 jQuery，可是壓縮後只有 5KB，纔是 jQuery 的六分之一。由於 Zeptojs 擁有不少和 jQuery 的接口，你一樣可使用較少的代碼編寫高質量的邏輯操做。對於大部分的基礎站點，Zepto 顯然更高效。

總結：壓縮第三方庫，同時使用 Zeptojs 做爲 jQuery 的可替換方案。

審查緩存配置

優秀的網頁開發者會盡可能減小頁面資源大小，從而較少頁面加載時間。更優秀的開發者甚至會盡可能減小第一次加載時的頁面資源大小。這其中發揮重大做用的就是瀏覽器混存。若是你的圖片、CSS 或者 JavaScript 資源不多改變，那麼就應該考慮緩存它們。緩存以後，你的用戶就只須要加載資源一次，下次再點擊時會直接使用緩存資源。

這裏有一篇 Mobify 上關於頁面緩存的入門文章：《Beginners Guide to Http Cache Headers》。此外，還有大量免費工具能夠測試緩存配置，好比很是酷炫的 REDbot、WooRank，以及咱們本身的 Zoompf。若是你使用了 Apache 或者 Nginx 服務器，建議開啓 mod_pagespeed 以精簡緩存配置。若是你使用了 WordPress，那麼建議使用 W3 Total Cache 這款優秀的插件。

提示：緩存資源是最有效的性能優化方案之一，對於移動端尤爲重要。審查你的緩存策略，並針對體積大、不頻繁變動的庫和圖片進行緩存吧。

喜歡動態圖？瀏覽器可不這麼認爲

動態圖最近有了復興的趨勢，但這沒法掩飾它年邁的姿態。回溯到三十年前，動態圖臃腫而又難如下載，特別是從影片裁剪的那種動態圖，真是不堪回首的歲月。很是建議使用 HTML5 的 video 標籤替代這些影片裁剪的動態圖。全部的現代瀏覽器都支持該標籤，而且它的大小隻有動態圖的十分之一甚至更少。

另外一個可選方案是使用 Imgur。當你在 Imgur 加載動態圖，它會將其轉換爲 GIFV。GIFV 本質上就是 HTML5 視頻，可是被高度優化了。Imgur 託管着你的視頻，並根據具體的瀏覽器兼容性提供 GIFV 或者 GIF。

提示：儘可能避免使用動態圖和複雜動效。使用 HTML5 vedio 和 GIFV 提供的現代視頻協議，有助於大幅提高性能並下降加載時間。

將來： HTTP/2

網絡傳輸終於緩慢的發展到了 HTTP/2。HTTP/1.1 已經 15 歲了，這真是個龍鍾老人，特別是體如今鏈接移動設備時的不可靠性和不穩定性。HTTP/2 已經被諸多瀏覽器和服務器所支持。雖然我不建議爲了 4 月 21 日的移動友好而激進地使用 HTTP/2，但在將來使用這一協議顯然值得列入你的路線圖中。更多相關信息請參考早前的文章。

提示：爲將來使用 HTTP/2 提早準備吧，這是它的時代！

總結

建立一個響應式、移動友好型的站點比修改樣式或標籤的細節會更加受到 Google 爬蟲的青睞。這些就是移動端須要考慮的細節，若是忽略了它們，顯然會嚴重拖累你的站點響應，甚至失去應有的用戶體驗。幸運的是咱們有諸多的免費工具能夠用來評估移動站點的響應性能。

如今，開始並深刻優化吧！