干貨來了，在於提升用戶體驗，非常實用，做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 的手機站。 你可以滑動兩下看看會發生什么。
只需要記住,如果你正在使用一個手勢,確保對於用戶而言，要么感覺自然，要么有意義。
結論
我希望有一天，我們不會需要區分本地和網絡。路漫漫其修遠兮，我們的工作是讓用戶覺得網站是圍繞他們設計的，這一天很快就會到來。
我認為，最近關注性能的趨勢固然很棒,但必須記住,我們的用戶不是機器。
他們不關心你的網站有多少請求，屏幕重繪有多快。但他們確實關心一些影響他們體驗的東西——他們的感知性能。
專注於確保你網站的外觀和行為像一個盡可能快的網站。如果用戶不注意的話是沒有資格稱作“最快的網站”的。
如果你對於改善感知性能有任何建議,請貼在評論里。
譯者手語：整個翻譯依照原文線路進行，並在翻譯過程略加了個人對技術的理解。如果翻譯有不對之處，還煩請同行朋友指點。謝謝！