讓移動網站看起來像本地應用只需4個步驟

譯自：
A Beginner’s Guide to Perceived Performance: 4 Ways to Make Your Mobile Site Feel Like a Native App
原作者：Kyle leads
譯者：  TAT.sheran

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

 

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

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

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

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

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

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

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

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

體驗性能 VS 實際性能

雖然提高實際性能很重要，但這并不意味著用戶最終能夠感覺到改善。

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

于此同時，當發送加載選票的異步請求時，他們用了一個輕量的微調控件提示用戶。但是用戶反饋在加載新的選票時顯示微調控件讓他們感覺比以前慢了好多，盡管實際上它比以前更快。Polar迅速發布了一個版本移除了這個微調控件，然后用戶馬上就覺得頁面加載快了好多。

這個例子能很好的說明用戶對性能感知的重要性。你的網站是否真正運行非?？觳⒉恢匾＞拖襁@個微調控件的例子，它只是吸引了用戶的注意力，但事實上仍然讓用戶感覺在等待響應，而正確的做法是，我們應該去分散用戶的注意力。

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

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

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

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

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

在移動設備上改善網站體驗性能最容易的方法之一就是使用激活狀態。

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

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

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

然而大多數的移動站點，包括我自己創建的，并沒有應用這個體驗設計，設計師們總是使用鏈接或者按鈕的默認觸摸狀態。

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

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

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

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

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

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

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

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

2. 使用默認滾動

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

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

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

然而，關于這個屬性還存在一個問題，那就是當滾動到頁面最頂部的時候會禁止你的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應用。雖然這一天還沒達到，但只要我們一直努力，使我們的網站讓用戶感受到是為他們量身打造，我相信那天一定會很快到來。

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

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

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

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

---