旅遊移動端網站—慢！慢！慢！

一.前言

隨着智能手機和數據網絡的不斷普及，真正的「移動互聯網」的世界必然到來，不管是學生仍是工做者，不管是旅行規劃時仍是旅遊途中，使用智能手機進行搜索，應對途中的各類突發請款，這種趨勢依然不可避免。

據英國的市場研究公司 Euromonitor 計算代表，到2019年，價值 2.36 萬億美圓的旅遊和酒店業全球在線預訂中，將有四分之一會經過移動設備完成，而隨着世界驢友交流的不斷擴大，這個比率還會不斷提升。美國是使用手機預約最爲頻繁的國家，到 2016 年，預計使用手機預約量將達到 50% 。

這個看上去驚人的比例不難理解：旅遊，就其定義而言，就是一種移動體驗，現現在，研究行程，處理酒店、航班、火車和汽車的預訂，全部這一切均可以使用隨身攜帶的設備來完成。

可是，移動旅遊網站性能的又如何呢？

二.移動旅遊網站現狀

儘管整個旅遊業一直努力，想要知足遊客使用智能手機處理信息的慾望，但現實是，大部分移動旅遊網站的糟糕性能讓用戶痛苦萬分。

爲了感覺當下遊客的真實體驗，筆者使用時下最流行的智能手機，測試了 2015 年 11 月份性能排名前 100 的旅遊網站。（該排名是由信息科技公司 SimilarWeb 基於網站流量和用戶參與水平的數據融合後得出的）

筆者採用實際移動設備鏈接 AT&T 4G/LTE 網絡來測試網站的用戶體驗，分別使用蘋果 5 和 六、三星 Galaxy S5 和 S6 對每個被測網站進行了 3 次訪問。筆者記錄這三次測試的中間數據，並從如下幾個方面比較網站的性能：

• Load Time (Fully Loaded)加載時間（徹底加載）

• Time to First Byte（第一個字節出現的時間）

• Start Render（開始渲染時間）

• Requests (Fully Loaded)請求（徹底加載）

• Bytes In/Total Size in KB字節/總大小（KB）

• Content Breakdown by MIME Type根據MIME類型的內容細分

• Redirects重定向

測試中，筆者發現，在電子商務網站中常見問題，例如：頁面臃腫、複雜度加大、圖像大小及重定向太多，這些問題在移動旅遊網都有，並且都會拖慢頁面加載時間，增長延遲率。

三.測試的重要發現

與傳統的電商網站相比，移動旅遊網站一般具備更加龐大的表格，這就意味着網頁最初加載的元素是用於數據輸入的字段，而不是與旅行相關的各類圖片等圖片。

故而，這些移動旅遊網站的頁面構成很大程度上與傳統的移動零售網站是不一樣的。儘管如此，爲了應用的內部性能以及改善用戶體驗，各個旅遊網站的進步空間仍是很大的。

重要提示：本次測試的目的不在於對所測試的移動端設備進行性能評估，而是爲了揭示不一樣移動設備間的性能差別。網站全部者須要意識到，用戶中存在着這樣的體驗差別，從而根據各類不一樣的設備類型和鏈接方式對網站性能測試進行優先排序，而且使用相關工具進行性能分析監控也是十分必要的。

在排名前 100 的移動旅遊網站中：

• 四個設備的平均加載時間都超過預計的四秒的目標值：蘋果 6，加載時間中間值爲 6.7 秒；蘋果 5 爲 5.5 秒；三星 Galaxy S5 ，加載的時間中間值爲 5.7 秒，其中 S6 的加載時間中間值最短，爲 4.1 秒。

• 儘管被測試頁面平均只包含 62 個資源請求（例如，圖片、CSS 和 JavaScript 文件），然而，18% 的頁面都含有超過 100 次資源請求。每個請求都會增長延遲時間，這些加起來就拖慢了頁面加載時間。

• 圖片，做爲網站總體大小的一部分，健康的平均佔比約爲四分之一 （22.8%）。然而，在 10% 的被測網站中，其圖片含量都超過一半大小，最高達到 86%。

• 與理想的 1MB 總負載量相比，移動旅遊網站超過了該預期，平均負載爲 1.2MB。

通常來講，加載速度最慢的網站包含的 JavaScript 請求要比加載最快的網站多，JavaScript 的平均負載約爲 368K。

四.10個最慢的網站（匿名）

觀察這些最慢的網站，能夠發現它們一般（雖然並不是所有）含有較多的請求，佔用資源較多。

另外一個拖慢訪問的關鍵因素：第三方JavaScript和跟蹤器/分析工具！

業界試圖獲取更多的客戶數據，來進行各類市場營銷活動，這也是能夠理解的。可是，數據跟蹤器（例如 GA、百度統計）加劇了網站的負荷，增長了讀取任務的數據量，拖慢了網速。

下面，來看看某個最慢網站的瀑布流圖：

以黃色突出的條目，表示的是「警告」。它們與廣告網絡和分析工具備關，每每包含了不受歡迎的重定向，而 JavaScript 元素的總和（包含 110 個請求）佔了整個移動網頁的 60.2%。

圖片來源: WebPagetest.org

五.真實用戶體驗監控工具

就像咱們以前說過的，包括移動互聯網行業在內的全部網站對用戶體驗的關注愈來愈多，傳統的撥測已經不能知足各個公司的需求，而一款好的工具就更加劇要了，像上面的兩個圖（瀑布流圖以及各個請求佔用比例），都是經過這類工具獲得的。

除了那兩類表格以外，對於訪問者的手機系統的類型以及網絡制式的統計也很重要，這樣才能更加有針對性的進行優化動做。


如今 APM 監控領域能作到上面說的資源耗時瀑布流圖、各個資源佔用比例、以及訪客系統分類統計的工具還很少，作的比較好的有：OneAPM Browser Insight、AppDynamics、Ruxit、New Relic

這幾款工具均採用的是頁面插碼的方法，並且還支持本地化部署，也就不用擔憂 JS 的下載時間給頁面帶來的緩慢問題了。

六.結論和建議

總結

對於移動旅遊萬展或者酒店網站的全部者來講，須要權衡下第三方跟蹤器(GA、百度統計、CNZZ 等)形成的性能衝擊及其帶來的好處，是否值得消耗部分用戶訪問時間。

整個旅遊業界的網站跳出率約爲 41%，包括全部的網站、臺式 PC 端和移動設備端，任何有利於爲用戶提供良好體驗的方法都應進行利用與嘗試。

筆者建議：

一、整合 JavaScript 和 CSS

將 JavaScript 代碼和 CSS 樣式整合到統一的文件，並在多個頁面間進行共享無疑是最多見的方法。這種技術簡化了代碼維護，改進了客戶端的緩存效率。在 JavaScript 文件中，確保一樣的腳本不會在一個頁面上屢次下載（現狀況是，當大型團隊或者多個團隊共同參與頁面開發時，重複腳本下載的機率尤爲高）。

二、壓縮代碼

壓縮，一般適用於腳本和樣式表，它消除了沒必要要的字符，如空格，換行符和評論。正確壓縮的資源無需任何特殊處理就能在客戶端運行，與此同時文件大小平均減小 20% 左右。HTML 頁面中的腳本和樣式塊也能夠壓縮，許多優質的代碼庫均可以進行壓縮，常伴隨把多個文件合併成一個的服務，這就進一步減小了請求數量。

三、延遲加載和執行非必需的腳本

在頁面徹底渲染以前，許多腳本代碼庫是沒必要要的。所以，能夠放心地將下載和解析這些腳本延遲到 onload 事件以後，而不妨礙頁面重要可見內容的初始渲染。

延遲加載的腳本能夠是你本身的，或者更重要的，是來自第三方的腳本。廣告、社交媒體工具、或分析工具支持的劣質腳本會妨礙一個頁面的渲染，有時甚至使加載時間延長寶貴的數秒。

聽從這些建議和一些最佳實踐有助於提升網站用戶的參與水平。記住，對於用戶來講，即便是相貌平平的輸入字段頁面也可能反應太慢。

你也不想他們問：「頁面加載出來了嗎？」

注：
本文參考原文連接，
http://www.webperformancetoday.com/2015/12/16/were-not-there-yet-images-scripts-and-redirects-are-slowing-down-the-top-mobile-travel-sites/
（做者：KENT ALSTAD）

由 OneAPM 產品運營翻譯整理。

Browser Insight 是一個基於真實用戶的 Web 前端性能監控統計平臺，可以幫你們定位網站性能瓶頸，網站加速效果可視化；支持瀏覽器、微信、App 瀏覽 HTML 和 HTML5 頁面。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客