互動體驗優化：4步讓移動網站看起來像本地應用

　　注：該文章大約3000字。它覆蓋了移動端網頁互動體驗優化的很多不同方面的實際解決方案，用來優化你的網頁執行速度。注意不是讓你的站點執行的有多快，而是讓你的使用者感覺有多快。

　　當下在移動端構建一個優秀的網站逐漸變得越來越簡單。無論是響應式設計還是自適應式，只要清楚你要做的樣式，精心製作一個好看的站點就不是什麼問題。

　　也許你的使用者和我們一樣，想要一個像本地應用體驗的網站，所以構建這樣的體驗將會帶來很大的挑戰。

　　大多數時候，當人們說一個應用就像一個原生程式或者像本地應用，他們並不是在討論這個網站的外觀。相反，他們討論的是當他們做出的一些操作之後的響應效果。

　　本地應用相對於Web應用要快得多，動畫效果渲染也更加平滑；當點選按鈕時，按鈕自身會立即響應變化的樣式，不管操作是否載入成功，都不會報錯。

　　使你的站點看起來想本地應用，意味著要盡一切可能的方法使你的站點快速的響應。

　　當今，效能優化是一個非常熱門的話題。最近，網站開發已經越來越重量級，網頁越重代表執行得越慢，所以有人聲稱做一個高效能的網頁應用程式幾乎是不可能的。

　　這就是為什麼Facebook不得不轉向本地應用的原因。因為從目前所擁有的Web資源來看，並不能達到他們期望的執行速度和互動體驗。

　　儘管Facebook也這麼認為，但是構建一個高效能的網站還是有可能的。雖然並不容易，但還是在我們可控制的範圍內。我們只是需要花更多的精力去將它實現而已。從技術上說，我們有能力使我們的網站執行地更快，看上去更現代化，以及擁有更完美的互動體驗。

　體驗效能 VS 實際效能

　　雖然提高實際效能很重要，但這並不意味著使用者最終能夠感覺到改善。

　　年初在西雅圖的一次An Event Apart會議中，Luke Wroblewski 講述了下關於他們的移動應用Polar。他闡述到他和他的團隊非常努力地優化每次載入新的選票所需時間。

　　於此同時，當傳送載入選票的非同步請求時，他們用了一個輕量的微調控制元件提示使用者。但是使用者反饋在載入新的選票時顯示微調控制元件讓他們感覺比以前慢了好多，儘管實際上它比以前更快。Polar迅速釋出了一個版本移除了這個微調控制元件，然後使用者馬上就覺得頁面載入快了好多。

　　這個例子能很好的說明使用者對效能感知的重要性。你的網站是否真正執行非常快並不重要。就像這個微調控制元件的例子，它只是吸引了使用者的注意力，但事實上仍然讓使用者感覺在等待響應，而正確的做法是，我們應該去分散使用者的注意力。

　　作為設計師和開發者，我們的目標不僅僅是從學術理論上創造一個快速的站點，而更應該從體驗上去創造一個最快的站點。

　　使用者是如何感知你的站點的執行速度才是最重要的，任何實際速度的提升不過是一個已經精心裝飾好的蛋糕外帽。我認為體驗效能優化比實際效能優化更重要，但絕不代表不應該去做實際效能優化。

　　綜上所述，你該做些什麼來優化你站點的體驗效能呢？

　這裡有四個技巧，你可以立即開始實施。

　　1. 給你的按鈕增加觸控狀態

　　在移動裝置上改善網站體驗效能最容易的方法之一就是使用啟用狀態。

　　眾所周知，使用者在任何時候點選你網頁上的按鈕，在網頁響應前他都必須等待約300毫秒。

　　瀏覽器會保持這個延時，這樣它才能確保使用者並不是想做其它動作（準確地說就是雙擊）。所以瀏覽器在這三分之一秒內檢測使用者是否有其它操作，如果沒有，則響應使用者上一次點選。當這個事件最終發生時，它會給出一個灰色的高亮展示給使用者。

　　這是一個糟糕的體驗，Nielsen團隊進行了一項調查，結果顯示任何超過100毫秒的響應都會讓使用者感到他們在等待——而使用者想要的僅僅是瀏覽你的網頁。

　　然而大多數的移動站點，包括我自己建立的，並沒有應用這個體驗設計，設計師們總是使用連結或者按鈕的預設觸控狀態。

　　要使你的站點感覺快，就要讓你的按鈕能夠及時響應使用者的點選事件，並且在狀態改變時給使用者一個可見的反饋。

　　有一個非常好用的CSS偽類叫做 active 狀態，它可以用來在網頁上顯示一個按鈕或者連結被點選了。我們也可以同時把它使用在PC端瀏覽器上。

　　不幸的是，無論是iOS還是Android上的連結或者按鈕被點選的時候都會忽略這個屬性。為了使用這個active狀態，你需要使用JavaScript給頁面新增一個簡單的事件:

document.addEventListener("touchstart", function(){}, true)

　　這樣，你就可以使用CSS來給按鈕新增active狀態或者移除點選高亮的狀態了:

-Webkit-tap-highlight-color: rgba(0,0,0,0);

　　給你建立的按鈕新增了這些屬性和active狀態之後，使用者就可以立即感覺到頁面的反饋，即使實際上真實的反饋速度並沒有改變。你只是讓使用者針對自己的行為得到了一個及時的反饋，而不是讓他們等待300毫秒後才看到頁面響應。

　　Without Touch State(code) / With Touch State(code)

　　如果你想要使頁面立即響應，你可以做進一步的改進。

　　使用一個fasttap或者fastclick函式，可以完全消除點選按鈕時300毫秒的延時，與active狀態搭配使用，可以讓你的站點擁有飛一般的速度。

　　關於更多fasttap的資訊，可以參考谷歌的這篇文章 this article by Google 或者Github上的一個現成的實現this repo on Github。

　　2. 使用預設滾動

　　你曾經是否嘗試在自己的站點上建立一個可滾動的容器，或者被一個執行起來非常慢，並且沒有任何響應的滾動條困住？

　　幸運的是，Android 3+ 和iOS 5+ 都實現了一個新的名叫overflow-scroll的屬性，用來開啟原生的滾動條，它執行起來非常完美。

　　No Momentum Scrolling (code) / With Momentum Scrolling (code)

　　這個滾動條使用起來就像是使用本地程式的感覺，實際上它就是原生的，你需要做的只是給你的滾動容器新增這個屬性：

-Webkit-overflow-scrolling: touch;

　　然而，關於這個屬性還存在一個問題，那就是當滾動到頁面最頂部的時候會禁止你的iphone顯示狀態列。這個BUG已經存在有段時間了，即使是最新版本iOS7上的移動版Safari都沒有解決這個問題。

　　解決這個問題的方法之一是：建立一個類來給容器新增 overflow-scrolling:touch屬性。然後只有當容器處於可見狀態 時，使用JavaScript去應用這個類，使其生效。

　　在Android 4上你不需要這個屬性，因為每個可滾動的容器都包含了原生滾動條。

　　在比較老的Android版本下，你有兩個選擇方案。我最喜歡的一個方法是檢測容器是否支援滾動溢位屬性來判斷是否支援原生滾動。如果不支援，有幾個JavaScript庫可以用來代替，Filament Group’s Overthrow 和 iScroll 都是很不錯的實現方案。

　　3. 建立高效能動畫

　　在Web網站和本地應用之間最顯著的差別是動畫的使用。

　　多年前，本地應用在當今裝置中就能夠充分利用硬體圖形加速。而在Web端，開發者卻只能基於JavaScript來實現動畫，對於移動端功能比較弱的CPU來說，執行起來會比較慢。

　　但是現在，隨著移動瀏覽器的支援，我們可以大量利用CSS3動畫來實現硬體加速。

　　這是一個英明的方法來新增那些我們喜歡的，本地應用都已經炫耀了多年的動畫特效。

　　如果還是覺得不夠快？要讓Web動畫感覺像本地動畫，你必須確保你的動畫執行起來不會慢或者足夠穩定，這些都是相當困難的。

　　Allen Pike of Steamclock Software(一家軟體公司) 2011年發表了一篇很讚的文章，大意為給使用者提供一個有趣的不影響效能的動畫，可以使使用者對這個應用有一個非常好的印象。

　　有趣的是，這篇文章是關於本地應用開發的，但我們可以參考這篇文章用來在網頁站點上建立類似本地應用的動畫。

　　在這篇文章中，他描述了一個他所謂的“時間感知”：

　　1.動畫的幀數至少要有60fps。這意味著每幀最起碼都要在16毫秒內完成，這樣才能讓人感覺動畫是原生的或者是平滑的。所有iOS的內建動畫都保持在60fps的執行速度，這就是為什麼在iPhone裝置上滾動的感覺明顯比Android裝置好的原因（雖然谷歌最近在這個領域取得了很大的改善）。你應該確保所有跟使用者有直接互動的動畫都保持在這個速度才行。

　　2.所有事件的響應都應該保持在100毫秒以內。如果超過這個心理門檻，使用者就會有慢的感覺，反之任何低於100毫秒的響應對使用者來說都是一瞬間的體驗。

　　3.如果一個動畫一定需要超過100毫秒，那也至少要保證在1000毫秒內完成。Allen認為任何需要在這麼長時間的行為都需要給使用者一個反饋，比如一個進度控制元件或者一個滾動條。

　　但是正如我們前面介紹的Polar的例子，轉移使用者注意力實際上是弊大於利的。稍後我們將介紹一個不同的方法來處理這個問題。

　　4.任何一個超過1秒的響應都是不好的，並且需要謹慎。

　　當建立一個網站的時候，你還不得不考慮動畫執行時間，知道這一切之後是否有種想轉行的衝動？

　　不要擔心，有些很好的資源可以使這些東西變得容易得多。

　　首先，有一個基於HTML5的一個CSS庫，叫做Effeckt.css。這個庫的目的是建立一個公用的動畫，它們的楨數都處於60fps。雖然這個庫還沒有完全完成，但是庫裡的很多動畫都已經可以很好的執行了，我們強烈推薦使用這個庫來滿足你們的專案需求。

　　另外一個非常好用的庫就是Adobe公司的前端團隊開發的Topcoat庫，這是一個以效能為中心的CSS元件庫，這個庫裡全是能夠執行得非常順暢的元件。因為動畫效能是他們的主要目標，元件的每一部分，你都可以看到它究竟是如何執行的。

　　Topcoat和Effeckt.css可以結合一起使用，Topcoat可以直接使用Effeckt.css的功能，並且可以很完美的融合在一起。

　　接下來，我們來討論前面提到的儘可能避免spinners問題的方法。

　　我的首選方法是避免spinners的等待時間不會超過100毫秒，但對於小於250毫秒的等待我會(使用spinner實際上是弊大於利的)用一個動畫來隱藏它。

　　例如，你正在非同步拉取一段內容的時候，嘗試使用動畫讓容器縮上去，再縮回來以適應新的內容。這樣一個簡短的動畫可以分散使用者注意力，而不是盯著一個spinner，他們只需等待一個很短的動畫完成。甚至他們都不知道是否有新的內容。

　　當然，那些重複且需要花費長時間完成的動畫有可能讓人覺得厭煩，所以一定要確保有節制的使用這些技術，對於大多數的動畫而言這都是一個很好的建議。

　　4. 手勢利用

　　本地應用優於Web應用的優勢在於他們能夠利用手勢，對於使用觸控螢幕的使用者來說，這樣能夠更加友好。

　　移動開發者已經意識到手勢的魅力所在，並很快就使其得到了很好的利用。

　　看看類似Mailbox 或者Clear這樣的例子，這些應用都使用了簡單的手勢，充分發揮了移動裝置最大的優勢——能夠直接觸控螢幕的能力。

　　大多數網站都只會使用手勢點選來觸發事件，設計師甚至不想去實現其它手勢，這樣給使用者像一個二等公民待遇的感覺。

　　我們開始考慮直接為這些裝置開發特定的網站。如果使用者的裝置支援手勢功能，那麼為什麼不利用他們呢？

　　當然，移動作業系統都存在一個問題那就是：劫持在瀏覽器中的手勢，而去執行系統自身的響應。

　　對於本地應用，比如Facebook 使用螢幕左右邊緣的滑動開拓導航。然而不幸的是，對於Web應用來說，這種行為叫出界，Chrome會使用這個操作來切換選項卡，新版本的iOS7的Safari瀏覽器卻會使用它來歷史前進和後退。

　　好把，這些手勢還是有相當多的限制的，究竟哪些可供我們使用呢？這裡有4個：

　　手勢1 一側到另一側的滑動

　　即使即將出界，一側到另外一側的滑動也是一個相當不錯的手勢，只是需要注意的是不要太靠近螢幕的邊緣了。

　　手勢2 拉取重新整理

　　拉取重新整理是讓使用者去獲取資料的另外一個手勢，有一大堆JavaScript庫可以很簡單的去實現這個手勢，有一個我以前用過的庫叫Hook.js。

　　手勢3 長按

　　有一個很有用的屬性叫做 –Webkit-touch-callout: none; 它將關閉移動端Safari預設的長按事件，但是你想要在Android上關閉它還需要額外的工作。

　　長按手勢主要用於拖動一個元素（比如重排一個列表的順序）或者展示更多操作給使用者（例如，社交分享）。

　　手勢4 縮放功能

　　每個人都理解縮放，大多數人在網站上看到一個照片的時候都會去縮放來檢視更多細節。

　　有時候瀏覽器也會劫持這種手勢，即使這樣，也沒有那麼糟糕。

　　無論是否需要鎖定整個視窗的放大或者縮小，有時你也並不希望使用者去縮放整個頁面。為了接管這些多點觸控，你可以使用一個非常輕量庫叫Hammer.js，這個庫裡有一堆手勢，你可以使用內建的手勢，也可以建立你自己的。

　　這有一個很優秀的圖片縮放示例網站 imgur.com mobile Website，它能夠檢測你的觸控方法。

　　但是要注意的是，如果你使用了一個手勢，請確保它是一個讓使用者感覺自然或有意義的行為。

　總結

　　但願有那麼一天，我們不需要再區分本地應用還是Web應用。雖然這一天還沒達到，但只要我們一直努力，使我們的網站讓使用者感受到是為他們量身打造，我相信那天一定會很快到來。

　　我覺得專注效能優化雖然是件好事，但我們也必須記住，我們的使用者不是機器。

　　他們不關心你的網站發出了多少請求，也不在乎你的螢幕渲染得有多快。他們只關心網站帶給他們體驗上的感覺。

　　重要的是如何讓你的網站看起來或者感覺上是最快的。那些使用者無法感知的高速網站是毫無意義的。

　　如果你有更多提高體驗效能的建議，請在評論中發表。

　　原文出處： Kyle leads