【乾貨來了】讓手機站點像原生應用的四大途徑

【乾貨來了】讓手機站點像原生應用的四大途徑

 乾貨來了，在於提高用戶體驗，很是實用，作webapp的童鞋不要錯過~

本文由99根據Kyle Peatt的《A Beginner's Guide to Perceived Performance: 4 Ways to Make Your Mobile Site Feel Like a Native App》所譯

英文出處：http://www.mobify.com/blog/beginners-guide-to-perceived-performance/

中文譯文：http://www.w3cplus.com/performance/beginners-guide-to-perceived-performance.html

做者：Kyle Peatt

譯者：99 

這篇文章大約3000字。它涵蓋了移動網站「感知性能」的不少方面，以及加速你網站的切實可行的解決方案。TL;博士:這不是說你網站有多快，而是用戶認爲有多快。

——Kyle Peatt

在移動設備上構建設計良好的網站慢慢變得愈來愈容易。不論使用什麼方法(響應式設計、自適應等),若是你瞭解你所作的,建立一個美觀的網站不是問題。 但你的用戶可能仍然要求網站有原生app的體驗。完成這樣的體驗是一個挑戰。 大多數時候,當人們談論「app」或「原生」的感受,他們講的的不是一個網站的視覺體驗。他們所討論的，是用戶界面如何對他們的行爲進行反饋，以及這種反饋是怎樣呈現的。

原生應用很「快」。原生應用的動畫渲染的很平滑，按鈕及時響應用戶的點擊，當app加載數據時也不會有什麼問題。

讓你的網站像原生應用同樣，意味着你須要儘量的提升你網站響應及交互的速度

提升性能已是一個很熱門且頗有價值的話題了。直到最近，web端還在朝着笨重與緩慢發展。業內一直有個爭論：實現一個高性能的webapp是不可能的。

這也是facebook轉移到原生應用的緣由，至少在他們的開發資源下，沒法完成須要的速度與交互。

即便facebook這麼認爲，構建一個高性能的web網站也不是不可能的。但這不在咱們的掌控中。咱們只須要努力使這一切變爲現實。從技術上講，咱們有能力是咱們的網站變得更加快速，更加時髦，帶來更完美的體驗。

感知性能與實際性能

實際性能的提高很重要，但若是不讓用戶感知到提高效果，就不意味着這些提高能夠到達用戶。

今年早些時候,在西雅圖Luke Wroblewski 曾提到過他的mobile app-polar。 他解釋說,他的團隊在努力提升加載投票的速度。

polar是一款很簡潔的投票應用——99

同時,他們引入了一個小圖標,來向用戶表示投票正在加載。而以後，用戶感受投票加載很慢的反饋當即鋪天蓋地的涌來,儘管事實上。加載快得多。Polar迅速發佈了一個補丁來移除這個加載圖標,以後，投票的快速加載給用戶留下了深入的印象。

這是一個表達感知性能重要性的很好的例子。當人們「以爲」一個網站不快，那這個網站再快也沒用。加載圖標只是讓用戶注意這個事實：數據在加載，用戶只能等待，而不能抽離注意力。

做爲設計師和開發人員,咱們的目標不該該經過一些數字的增加，創建最快的網站,一樣應該創造最快的網站體驗。

所以最重要的是用戶如何感知你網站的速度。任何實際性能的提高只是一份錦上添花。我認爲,感知性能的提高，相比實際性能更重要。但這並不意味着你須要忽略實際性能的提高。

Ok，解釋足夠了，如何能夠立刻提高網站的感知性能？

下面的四個技巧，你能夠當即開始嘗試

給按鈕添加觸摸狀態

最簡單的提升站點感知性能的方法，是給網站增長」active」狀態。

你看,任什麼時候候一個訪問者點擊網站上的一個按鈕,她必須等待300毫秒才知道到底發生了啥。

瀏覽器設置了這個超時時間，以後能夠確保用戶不會進行一些其餘操做（雙擊）。所以等待1/3秒後，瀏覽器知曉了用戶的動做，並執行最初的點擊。當這個動做發生後，按鈕被一個灰色的東東覆蓋。

這是很糟糕的用戶體驗。Nielsen組織進行了一項研究，發現任何高於100ms的延遲都會讓用戶認爲他們在等待。他們可能只想進行一次跳轉。

然而不少的移動網站，包括我作的那些，沒有考慮這個感知問題。設計師一般的設計是觸摸時按鈕或者連接保持原樣。

爲了讓你的網站感受更快,你須要讓你的按鈕當即響應用戶的觸摸,給用戶一個明顯的視覺指示--有些事情正在發生。

有一個很讚的屬性用在網站上的按鈕或連接;它是:active僞類。咱們在桌面端一直使用這個僞類。

不幸的是,不管是iOS仍是android，當按鈕或者連接被點擊時都忽略了這個屬性,爲了激活這個狀態,你須要添加一個簡單的事件綁定到頁面的JavaScript中:

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

以後你能夠用css定義active狀態的樣式，以後去掉點擊時的高亮：

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

對按鈕設置這兩個屬性,用戶會當即感受到界面響應了用戶的操做，即便最終的響應速度是同樣的。你只是讓你的界面即時反饋了用戶的行動,而不會讓用戶傻等300 ms再看看到底幹了啥。

 沒有觸摸狀態（代碼）

 

有觸狀態（代碼）

不過若是你想當即響應用戶的操做，你可使用另外一種方案。

使用一個fasttap或fastclick這樣的JavaScript函數,能夠徹底去除點擊按鈕後300毫秒的延遲。配合active狀態，可讓網站快的亮瞎你的眼睛。

有關於fasttap更多的信息，能夠閱讀google搜索到的文章，這有一個現成的案例，你能夠從github上導出。

使用彈性滾動

你試過建立一個可滾動的容器，而後被默認的慢悠悠且不響應的滾動折磨的瘋掉麼？

如今能夠解放了，android3+與ios5+版本增長了一個新的屬性：overflow-scrolling這個屬性能夠激活平滑滾動，並且效果也不錯。

沒有滾動條(代碼)

有滾動條(代碼)

這個彈性滾動感受起來像原生應用，由於這個原本就是原生的滾動。你只須要向可滾動區域增長一行代碼。

-webkit-overflow-scrolling: touch;

不過這個屬性有個問題。這個屬性會使點擊iPhone頭部狀態欄讓網頁回到頂部的功能失效。這個bug已經存在了一段時間了，貌似也沒有在新的ios7版本中修復。

有一種方法能夠解決這個問題，爲容器建立一個class並應用屬性overflow-scrolling: touch。當且僅當容器顯示時，使用javascript添加class到容器上。

Android4上你不須要使用這個屬性。每一個可滾動的容器均包含彈性滾動。

在老版本的Android上你有兩種選擇。我比較喜歡的解決方案是利用Modernizr檢測彈性滾動，以後來控制佈局中容器的顯示。此外,有一些JavaScript庫你能夠試試，好比overthorw與iscroll。

建立高效的動畫

App與網站最明顯的差異之一就是動畫效果。

如今的設備上，應用程序已經可以充分利用硬件圖形加速。而在web端,開發商者使用基於javascript的動畫,在移動端的cpu上跑是很慢的。

但如今,隨着移動瀏覽器的不斷支持,你能夠在項目中使用基於硬件加速的CSS3動畫。

這樣，咱們就能夠添加一些視覺效果，這些效果已經被咱們喜歡的一些app應用了不少年了。

事實上也沒那麼快，若使動畫貼近原生體驗，你須要避免動畫的緩慢及抖動，而這都是很難處理的。Steamclock Software的Allen Pike寫過一篇很讚的文章，文章裏描述了動畫所帶給用戶的快樂，也講到低性能的動畫將對用戶在app上的體驗產生很大的影響

有趣的是,他寫的這篇是原生應用開發相關的。這使得這篇文章至關有用，咱們能夠跟隨下列任務來建立web上的動畫。

在文章中,他提出一個所謂的「時間軸感」:

• 動畫要跑在60fps下。這意味着每一幀須要花費16ms來跑完(1000ms/60=16)。這是要達到原生應用般平滑體驗的最基本要求。60 fps是全部的iOS的內置動畫運行的速度;這就是爲何滾動在iPhone上比Android設備上感受更好 (雖然谷歌已經取得了很大的進步)。你應該嘗試讓全部直接關係到用戶的交互動畫跑在這個速度上。
• 全部東西都要在100ms內渲染完畢。 這是個心理感受慢的界限。全部低於100ms的延遲都會讓用戶有瞬時響應的感受。
• 若是它絕對得超過100毫秒,1000毫秒內絕對應該回應。艾倫代表任何須要這麼長時間完成的操做，都應該給用戶一些反應代表正在發生。好比一個旋轉的圖標或一個進度條。可是,正如咱們以前研究過的那個投票app的例子,把用戶的注意力聚焦到那個小菊花上，實際上可能弊大於利。我將介紹一種不一樣的方法來處理這個問題。
• 全部超過兩秒的響應時間都是耍流氓。

好吧，你知道這些了，因此你估計要把鍵盤看成帽子而後去轉行了。啥時候咱們建立網站須要關心動畫的時間了？

別擔憂,有一些很讚的資源讓這些東西更容易實現!

第一個是HTML5 Boilerplate中的Effeckt.css。 他們的目標是實現一些跑在60fps下的常見的轉換和動畫。雖然這個庫並沒徹底完成，裏面不少的效果已經跑得很好了。我極力推薦你在項目中使用這個庫。

另外一個很好的庫是 Topcoat,Adobe網絡團隊編寫的代碼,這是一個創建在性能考慮下的CSS組件庫。這個庫裏塞了滿滿的優秀的組件,運行平穩。由於性能是他們的主要目標,每個組件都已經被跟蹤性能,這樣你就能夠清楚地看到組件的性能。

以上兩個庫是齊頭並進的，並且topcoat也向effeckt.css貢獻代碼，這兩個庫跑的都很贊。

而後，我要討論以前提到的，儘量去掉加載提示的方案。

我傾向的方案是，當等待時間大於100ms，小於250ms時，使用加載圖標弊大於利，所以能夠隱藏掉。

例如,若是你使用Ajax請求內容,能夠對內容的容器應用動畫,例如收縮起來再擴展從而適應新的內容。這樣的短動畫會分散用戶等待時的注意力,而不是讓用戶盯着一個不斷旋轉的小菊花--他們只是等待一個短動畫完成，以致於甚至沒有意識到新內容沒出現。

固然, 須要很長時間才能完成的重複的動畫是很是使人討厭的,因此咱們要適當的使用這些動畫。對於大多數動畫而言都是這個道理。

提供天然的手勢體驗

App超過web端體驗的一點，是能夠在觸控設備上提供很天然的手勢。

Mailbox與Clear能夠做爲手勢應用很好的例子。這些app使用簡單的手勢來利用了移動設備最大的特點—能夠直接觸摸屏幕上的物體。

然而大多數網站只使用了觸摸對象。設計師對手勢惟恐避之不及,結果用戶感受在web端受到了歧視通常。

咱們須要考慮直接爲設備開發網站。若是一個用戶的設備容許手勢操做,爲何不使用它們?

固然,還有一個小問題:移動操做系統有個可惡的特性,移動瀏覽器會劫持手勢做爲己用。

例如, 像Facebook同樣的應用程序經過觸摸屏幕的左邊和右邊來打開導航。然而,在瀏覽器段,這種交互是不可用的。對於Chrome，這種操做用來切換選項卡。iOS 7新版本的移動Safari使用這種操做前進,與後退。

好吧。這些手勢在咱們的可控範圍以外。那麼大家應該使用什麼手勢呢？下面有四個例子。

手勢1:左右划動

即便存在邊緣問題,左右划動仍然是一個很好用的手勢。你只須要當心觸發時不要太靠近屏幕的邊緣。

這個手勢最好的應用是用於移動一組對象,好比幻燈片或列表標籤。

手勢2:下拉刷新

下拉刷新也是用戶接觸到的手勢。這裏有一些很讚的js庫能夠很容易的實現這個特性，我使用hook.js來實現。

手勢3:長按

有一個頗有用的屬性: -webkit-touch-callout: none。這將禁用移動Safari瀏覽器中默認的長按效果。在android禁用這個效果則須要費點勁。

長按手勢能夠用於拿起一個項目(如從新排序列表中的項)或顯示更多選項(如社會共享)。

手勢4:雙指縮放

每一個人都懂雙指縮放。不少人當看到web端的圖片後，都會嘗試縮放圖片來看清細節。

這裏也存在瀏覽器劫持用戶手勢的狀況，不過不是很難辦。

當你鎖定或不鎖定viewport的時候，你有時不但願用戶在雙指縮放時縮放整個頁面。爲了代替這個多指手勢，你可使用這個小而精的harmmer.js庫。這個庫擁有一系列的手勢能夠爲你使用，你也能夠創建本身的手勢。

一個很好的雙指縮放例子是imgur.com 的手機站。 你能夠滑動兩下看看會發生什麼。

只須要記住,若是你正在使用一個手勢,確保對於用戶而言，要麼感受天然，要麼有意義。

結論

我但願有一天，咱們不會須要區分本地和網絡。路漫漫其修遠兮，咱們的工做是讓用戶以爲網站是圍繞他們設計的，這一天很快就會到來。

我認爲，最近關注性能的趨勢當然很棒,但必須記住,咱們的用戶不是機器。

他們不關心你的網站有多少請求，屏幕重繪有多快。但他們確實關心一些影響他們體驗的東西——他們的感知性能。

專一於確保你網站的外觀和行爲像一個儘量快的網站。若是用戶不注意的話是沒有資格稱做「最快的網站」的。