幹貨來了，在于提升使用者體驗，非常實用，做webapp的童鞋不要錯過~
這篇文章大約3000字。它涵蓋了移動網站“感覺性能”的很多方面，以及加速你網站的切實可行的解決方案。tl;博士:這不是說你網站有多快，而是使用者認為有多快。 ——kyle peatt
在移動裝置上建構設計良好的網站慢慢變得越來越容易。不論使用什麼方法(響應式設計、自适應等),如果你了解你所做的,建立一個美觀的網站不是問題。 但你的使用者可能仍然要求網站有原生app的體驗。完成這樣的體驗是一個挑戰。 大多數時候,當人們談論“app”或“原生”的感覺,他們講的的不是一個網站的視覺體驗。他們所讨論的，是使用者界面如何對他們的行為進行回報，以及這種回報是怎樣呈現的。
原生應用很“快”。原生應用的動畫渲染的很平滑，按鈕及時響應使用者的點選，當app加載資料時也不會有什麼問題。
讓你的網站像原生應用一樣，意味着你需要盡可能的提高你網站響應及互動的速度
提高性能已經是一個很熱門且很有價值的話題了。直到最近，web端還在朝着笨重與緩慢發展。業内一直有個争論：實作一個高性能的webapp是不可能的。
即使facebook這麼認為，建構一個高性能的web網站也不是不可能的。但這不在我們的掌控中。我們隻需要努力使這一切變為現實。從技術上講，我們有能力是我們的網站變得更加快速，更加時髦，帶來更完美的體驗。
實際性能的提升很重要，但如果不讓使用者感覺到提升效果，就不意味着這些提升可以到達使用者。
polar是一款很簡潔的投票應用——99
同時,他們引入了一個小圖示,來向使用者表示投票正在加載。而之後，使用者感覺投票加載很慢的回報立即鋪天蓋地的湧來,盡管事實上。加載快得多。polar迅速釋出了一個更新檔來移除這個加載圖示,之後，投票的快速加載給使用者留下了深刻的印象。
這是一個表達感覺性能重要性的很好的例子。當人們“覺得”一個網站不快，那這個網站再快也沒用。加載圖示隻是讓使用者注意這個事實：資料在加載，使用者隻能等待，而不能抽離注意力。
作為設計師和開發人員,我們的目标不應該通過一些數字的增長，建立最快的網站,同樣應該創造最快的網站體驗。
是以最重要的是使用者如何感覺你網站的速度。任何實際性能的提升隻是一份錦上添花。我認為,感覺性能的提升，相比實際性能更重要。但這并不意味着你需要忽略實際性能的提升。
ok，解釋足夠了，如何可以馬上提升網站的感覺性能？
下面的四個技巧，你可以立即開始嘗試
最簡單的提高站點感覺性能的方法，是給網站增加”active”狀态。
你看,任何時候一個通路者點選網站上的一個按鈕,她必須等待300毫秒才知道到底發生了啥。
浏覽器設定了這個逾時時間，之後可以確定使用者不會進行一些其他操作（輕按兩下）。是以等待1/3秒後，浏覽器知曉了使用者的動作，并執行最初的點選。當這個動作發生後，按鈕被一個灰色的東東覆寫。
然而很多的移動網站，包括我做的那些，沒有考慮這個感覺問題。設計師通常的設計是觸摸時按鈕或者連結保持原樣。
為了讓你的網站感覺更快,你需要讓你的按鈕立即響應使用者的觸摸,給使用者一個明顯的視覺訓示--有些事情正在發生。
有一個很贊的屬性用在網站上的按鈕或連結;它是:active僞類。我們在桌面端一直使用這個僞類。
不幸的是,無論是ios還是android，當按鈕或者連結被點選時都忽略了這個屬性,為了激活這個狀态,你需要添加一個簡單的事件綁定到頁面的javascript中:
之後你可以用css定義active狀态的樣式，之後去掉點選時的高亮：
對按鈕設定這兩個屬性,使用者會立即感覺到界面響應了使用者的操作，即使最終的響應速度是一樣的。你隻是讓你的界面即時回報了使用者的行動,而不會讓使用者傻等300 ms再看看到底幹了啥。
不過如果你想立即響應使用者的操作，你可以使用另一種方案。
使用一個fasttap或fastclick這樣的javascript函數,可以完全去除點選按鈕後300毫秒的延遲。配合active狀态，可以讓網站快的亮瞎你的眼睛。
你試過建立一個可滾動的容器，然後被預設的慢悠悠且不響應的滾動折磨的瘋掉麼？
現在可以解放了，android3+與ios5+版本增加了一個新的屬性：<code>overflow-scrolling</code>這個屬性可以激活平滑滾動，而且效果也不錯。
這個彈性滾動感覺起來像原生應用，因為這個本來就是原生的滾動。你隻需要向可滾動區域增加一行代碼。
有一種方法可以解決這個問題，為容器建立一個class并應用屬性<code>overflow-scrolling: touch</code>。當且僅當容器顯示時，使用javascript添加class到容器上。
android4上你不需要使用這個屬性。每個可滾動的容器均包含彈性滾動。
app與網站最明顯的差别之一就是動畫效果。
現在的裝置上，應用程式已經能夠充分利用硬體圖形加速。而在web端,開發商者使用基于javascript的動畫,在移動端的cpu上跑是很慢的。
但現在,随着移動浏覽器的不斷支援,你可以在項目中使用基于硬體加速的css3動畫。
這樣，我們就可以添加一些視覺效果，這些效果已經被我們喜歡的一些app應用了很多年了。
有趣的是,他寫的這篇是原生應用開發相關的。這使得這篇文章相當有用，我們可以跟随下列任務來建立web上的動畫。
在文章中,他提出一個所謂的“時間軸感”:
所有東西都要在100ms内渲染完畢。 這是個心理感覺慢的界限。所有低于100ms的延遲都會讓使用者有瞬時響應的感覺。
如果它絕對得超過100毫秒,1000毫秒内絕對應該回應。艾倫表明任何需要這麼長時間完成的操作，都應該給使用者一些反應表明正在發生。比如一個旋轉的圖示或一個進度條。但是,正如我們之前研究過的那個投票app的例子,把使用者的注意力聚焦到那個小菊花上，實際上可能弊大于利。我将介紹一種不同的方法來處理這個問題。
所有超過兩秒的響應時間都是耍流氓。
好吧，你知道這些了，是以你估計要把鍵盤當作帽子然後去轉行了。啥時候我們建立網站需要關心動畫的時間了？
别擔心,有一些很贊的資源讓這些東西更容易實作!
以上兩個庫是齊頭并進的，而且topcoat也向effeckt.css貢獻代碼，這兩個庫跑的都很贊。
然後，我要讨論之前提到的，盡可能去掉加載提示的方案。
我傾向的方案是，當等待時間大于100ms，小于250ms時，使用加載圖示弊大于利，是以可以隐藏掉。
例如,如果你使用ajax請求内容,可以對内容的容器應用動畫,例如收縮起來再擴充進而适應新的内容。這樣的短動畫會分散使用者等待時的注意力,而不是讓使用者盯着一個不斷旋轉的小菊花--他們隻是等待一個短動畫完成，以至于甚至沒有意識到新内容沒出現。
當然, 需要很長時間才能完成的重複的動畫是非常令人讨厭的,是以我們要适當的使用這些動畫。對于大多數動畫而言都是這個道理。
app超過web端體驗的一點，是可以在觸控裝置上提供很自然的手勢。
然而大多數網站隻使用了觸摸對象。設計師對手勢唯恐避之不及,結果使用者感覺在web端受到了歧視一般。
我們需要考慮直接為裝置開發網站。如果一個使用者的裝置允許手勢操作,為什麼不使用它們?
當然,還有一個小問題:移動作業系統有個可惡的特性,移動浏覽器會劫持手勢作為己用。
好吧。這些手勢在我們的可控範圍之外。那麼你們應該使用什麼手勢呢？下面有四個例子。
即使存在邊緣問題,左右劃動仍然是一個很好用的手勢。你隻需要小心觸發時不要太靠近螢幕的邊緣。
這個手勢最好的應用是用于移動一組對象,比如幻燈片或清單标簽。
長按手勢可以用于拿起一個項目(如重新排序清單中的項)或顯示更多選項(如社會共享)。
每個人都懂雙指縮放。很多人當看到web端的圖檔後，都會嘗試縮放圖檔來看清細節。
這裡也存在浏覽器劫持使用者手勢的情況，不過不是很難辦。
隻需要記住,如果你正在使用一個手勢,確定對于使用者而言，要麼感覺自然，要麼有意義。
我希望有一天，我們不會需要區分本地和網絡。路漫漫其修遠兮，我們的工作是讓使用者覺得網站是圍繞他們設計的，這一天很快就會到來。
我認為，最近關注性能的趨勢固然很棒,但必須記住,我們的使用者不是機器。
他們不關心你的網站有多少請求，螢幕重繪有多快。但他們确實關心一些影響他們體驗的東西——他們的感覺性能。
專注于確定你網站的外觀和行為像一個盡可能快的網站。如果使用者不注意的話是沒有資格稱作“最快的網站”的。
如果你對于改善感覺性能有任何建議,請貼在評論裡。
譯者手語：整個翻譯依照原文線路進行，并在翻譯過程略加了個人對技術的了解。如果翻譯有不對之處，還煩請同行朋友指點。謝謝！
作者：白樹