讓移動網(wǎng)站看起來像本地應(yīng)用只需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字。它覆蓋了移動端網(wǎng)頁交互體驗(yàn)優(yōu)化的很多不同方面的實(shí)際解決方案，用來優(yōu)化你的網(wǎng)頁運(yùn)行速度。注意不是讓你的站點(diǎn)運(yùn)行的有多快，而是讓你的用戶感覺有多快。

 

當(dāng)下在移動端構(gòu)建一個優(yōu)秀的網(wǎng)站逐漸變得越來越簡單。無論是響應(yīng)式設(shè)計(jì)還是自適應(yīng)式，只要清楚你要做的樣式，精心制作一個好看的站點(diǎn)就不是什么問題。

也許你的用戶和我們一樣，想要一個像本地應(yīng)用體驗(yàn)的網(wǎng)站，所以構(gòu)建這樣的體驗(yàn)將會帶來很大的挑戰(zhàn)。

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

本地應(yīng)用相對于Web應(yīng)用要快得多，動畫效果渲染也更加平滑；當(dāng)點(diǎn)擊按鈕時(shí)，按鈕自身會立即響應(yīng)變化的樣式，不管操作是否加載成功，都不會報(bào)錯。

使你的站點(diǎn)看起來想本地應(yīng)用，意味著要盡一切可能的方法使你的站點(diǎn)快速的響應(yīng)。

當(dāng)今，性能優(yōu)化是一個非常熱門的話題。最近，網(wǎng)站開發(fā)已經(jīng)越來越重量級，網(wǎng)頁越重代表運(yùn)行得越慢，所以有人聲稱做一個高性能的網(wǎng)頁應(yīng)用程序幾乎是不可能的。

這就是為什么Facebook不得不轉(zhuǎn)向本地應(yīng)用的原因。因?yàn)閺哪壳八鶕碛械腤eb資源來看，并不能達(dá)到他們期望的運(yùn)行速度和交互體驗(yàn)。

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

體驗(yàn)性能 VS 實(shí)際性能

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

年初在西雅圖的一次An Event Apart會議中，Luke Wroblewski 講述了下關(guān)于他們的移動應(yīng)用Polar。他闡述到他和他的團(tuán)隊(duì)非常努力地優(yōu)化每次加載新的選票所需時(shí)間。

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

這個例子能很好的說明用戶對性能感知的重要性。你的網(wǎng)站是否真正運(yùn)行非常快并不重要。就像這個微調(diào)控件的例子，它只是吸引了用戶的注意力，但事實(shí)上仍然讓用戶感覺在等待響應(yīng)，而正確的做法是，我們應(yīng)該去分散用戶的注意力。

作為設(shè)計(jì)師和開發(fā)者，我們的目標(biāo)不僅僅是從學(xué)術(shù)理論上創(chuàng)造一個快速的站點(diǎn)，而更應(yīng)該從體驗(yàn)上去創(chuàng)造一個最快的站點(diǎn)。

用戶是如何感知你的站點(diǎn)的運(yùn)行速度才是最重要的，任何實(shí)際速度的提升不過是一個已經(jīng)精心裝飾好的蛋糕外帽。我認(rèn)為體驗(yàn)性能優(yōu)化比實(shí)際性能優(yōu)化更重要，但絕不代表不應(yīng)該去做實(shí)際性能優(yōu)化。

綜上所述，你該做些什么來優(yōu)化你站點(diǎn)的體驗(yàn)性能呢？

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

1. 給你的按鈕增加觸摸狀態(tài)

在移動設(shè)備上改善網(wǎng)站體驗(yàn)性能最容易的方法之一就是使用激活狀態(tài)。

眾所周知，用戶在任何時(shí)候點(diǎn)擊你網(wǎng)頁上的按鈕，在網(wǎng)頁響應(yīng)前他都必須等待約300毫秒。

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

這是一個糟糕的體驗(yàn)，Nielsen團(tuán)隊(duì)進(jìn)行了一項(xiàng)調(diào)查，結(jié)果顯示任何超過100毫秒的響應(yīng)都會讓用戶感到他們在等待——而用戶想要的僅僅是瀏覽你的網(wǎng)頁。

然而大多數(shù)的移動站點(diǎn)，包括我自己創(chuàng)建的，并沒有應(yīng)用這個體驗(yàn)設(shè)計(jì)，設(shè)計(jì)師們總是使用鏈接或者按鈕的默認(rèn)觸摸狀態(tài)。

要使你的站點(diǎn)感覺快，就要讓你的按鈕能夠及時(shí)響應(yīng)用戶的點(diǎn)擊事件，并且在狀態(tài)改變時(shí)給用戶一個可見的反饋。

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

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

這樣，你就可以使用CSS來給按鈕添加active狀態(tài)或者移除點(diǎn)擊高亮的狀態(tài)了:

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

如果你想要使頁面立即響應(yīng)，你可以做進(jìn)一步的改進(jìn)。

使用一個fasttap或者fastclick函數(shù)，可以完全消除點(diǎn)擊按鈕時(shí)300毫秒的延時(shí)，與active狀態(tài)搭配使用，可以讓你的站點(diǎn)擁有飛一般的速度。

關(guān)于更多fasttap的信息，可以參考谷歌的這篇文章 this article by Google 或者Github上的一個現(xiàn)成的實(shí)現(xiàn)this repo on Github。

2. 使用默認(rèn)滾動

你曾經(jīng)是否嘗試在自己的站點(diǎn)上創(chuàng)建一個可滾動的容器，或者被一個運(yùn)行起來非常慢，并且沒有任何響應(yīng)的滾動條困住？

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

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

然而，關(guān)于這個屬性還存在一個問題，那就是當(dāng)滾動到頁面最頂部的時(shí)候會禁止你的iphone顯示狀態(tài)欄。這個BUG已經(jīng)存在有段時(shí)間了，即使是最新版本iOS7上的移動版Safari都沒有解決這個問題。

解決這個問題的方法之一是：創(chuàng)建一個類來給容器添加 overflow-scrolling:touch屬性。然后只有當(dāng)容器處于可見狀態(tài) 時(shí)，使用JavaScript去應(yīng)用這個類，使其生效。

在Android 4上你不需要這個屬性，因?yàn)槊總€可滾動的容器都包含了原生滾動條。

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

3. 創(chuàng)建高性能動畫

在Web網(wǎng)站和本地應(yīng)用之間最顯著的差別是動畫的使用。

多年前，本地應(yīng)用在當(dāng)今設(shè)備中就能夠充分利用硬件圖形加速。而在Web端，開發(fā)者卻只能基于JavaScript來實(shí)現(xiàn)動畫，對于移動端功能比較弱的CPU來說，運(yùn)行起來會比較慢。

但是現(xiàn)在，隨著移動瀏覽器的支持，我們可以大量利用CSS3動畫來實(shí)現(xiàn)硬件加速。

這是一個英明的方法來添加那些我們喜歡的，本地應(yīng)用都已經(jīng)炫耀了多年的動畫特效。

如果還是覺得不夠快？要讓W(xué)eb動畫感覺像本地動畫，你必須確保你的動畫運(yùn)行起來不會慢或者足夠穩(wěn)定，這些都是相當(dāng)困難的。

Allen Pike of Steamclock Software(一家軟件公司) 2011年發(fā)表了一篇很贊的文章，大意為給用戶提供一個有趣的不影響性能的動畫，可以使用戶對這個應(yīng)用有一個非常好的印象。

有趣的是，這篇文章是關(guān)于本地應(yīng)用開發(fā)的，但我們可以參考這篇文章用來在網(wǎng)頁站點(diǎn)上創(chuàng)建類似本地應(yīng)用的動畫。

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

1.動畫的幀數(shù)至少要有60fps。這意味著每幀最起碼都要在16毫秒內(nèi)完成，這樣才能讓人感覺動畫是原生的或者是平滑的。所有iOS的內(nèi)置動畫都保持在60fps的運(yùn)行速度，這就是為什么在iPhone設(shè)備上滾動的感覺明顯比Android設(shè)備好的原因（雖然谷歌最近在這個領(lǐng)域取得了很大的改善）。你應(yīng)該確保所有跟用戶有直接交互的動畫都保持在這個速度才行。

2.所有事件的響應(yīng)都應(yīng)該保持在100毫秒以內(nèi)。如果超過這個心理門檻，用戶就會有慢的感覺，反之任何低于100毫秒的響應(yīng)對用戶來說都是一瞬間的體驗(yàn)。

3.如果一個動畫一定需要超過100毫秒，那也至少要保證在1000毫秒內(nèi)完成。Allen認(rèn)為任何需要在這么長時(shí)間的行為都需要給用戶一個反饋，比如一個進(jìn)度控件或者一個滾動條。

但是正如我們前面介紹的Polar的例子，轉(zhuǎn)移用戶注意力實(shí)際上是弊大于利的。稍后我們將介紹一個不同的方法來處理這個問題。

4.任何一個超過1秒的響應(yīng)都是不好的，并且需要謹(jǐn)慎。

當(dāng)創(chuàng)建一個網(wǎng)站的時(shí)候，你還不得不考慮動畫運(yùn)行時(shí)間，知道這一切之后是否有種想轉(zhuǎn)行的沖動？

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

首先，有一個基于HTML5的一個CSS庫，叫做Effeckt.css。這個庫的目的是創(chuàng)建一個公用的動畫，它們的幀數(shù)都處于60fps。雖然這個庫還沒有完全完成，但是庫里的很多動畫都已經(jīng)可以很好的運(yùn)行了，我們強(qiáng)烈推薦使用這個庫來滿足你們的項(xiàng)目需求。

另外一個非常好用的庫就是Adobe公司的前端團(tuán)隊(duì)開發(fā)的Topcoat庫，這是一個以性能為中心的CSS組件庫，這個庫里全是能夠運(yùn)行得非常順暢的組件。因?yàn)閯赢嬓阅苁撬麄兊闹饕繕?biāo)，組件的每一部分，你都可以看到它究竟是如何執(zhí)行的。

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

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

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

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

當(dāng)然，那些重復(fù)且需要花費(fèi)長時(shí)間完成的動畫有可能讓人覺得厭煩，所以一定要確保有節(jié)制的使用這些技術(shù)，對于大多數(shù)的動畫而言這都是一個很好的建議。

4. 手勢利用

本地應(yīng)用優(yōu)于Web應(yīng)用的優(yōu)勢在于他們能夠利用手勢，對于使用觸摸屏幕的用戶來說，這樣能夠更加友好。

移動開發(fā)者已經(jīng)意識到手勢的魅力所在，并很快就使其得到了很好的利用。

看看類似Mailbox 或者Clear這樣的例子，這些應(yīng)用都使用了簡單的手勢，充分發(fā)揮了移動設(shè)備最大的優(yōu)勢——能夠直接觸摸屏幕的能力。

大多數(shù)網(wǎng)站都只會使用手勢點(diǎn)擊來觸發(fā)事件，設(shè)計(jì)師甚至不想去實(shí)現(xiàn)其它手勢，這樣給用戶像一個二等公民待遇的感覺。

我們開始考慮直接為這些設(shè)備開發(fā)特定的網(wǎng)站。如果用戶的設(shè)備支持手勢功能，那么為什么不利用他們呢？

當(dāng)然，移動操作系統(tǒng)都存在一個問題那就是：劫持在瀏覽器中的手勢，而去執(zhí)行系統(tǒng)自身的響應(yīng)。

對于本地應(yīng)用，比如Facebook 使用屏幕左右邊緣的滑動開拓導(dǎo)航。然而不幸的是，對于Web應(yīng)用來說，這種行為叫出界，Chrome會使用這個操作來切換選項(xiàng)卡，新版本的iOS7的Safari瀏覽器卻會使用它來歷史前進(jìn)和后退。

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

手勢1 一側(cè)到另一側(cè)的滑動

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

手勢2 拉取刷新

拉取刷新是讓用戶去獲取數(shù)據(jù)的另外一個手勢，有一大堆JavaScript庫可以很簡單的去實(shí)現(xiàn)這個手勢，有一個我以前用過的庫叫Hook.js。

手勢3 長按

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

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

手勢4 縮放功能

每個人都理解縮放，大多數(shù)人在網(wǎng)站上看到一個照片的時(shí)候都會去縮放來查看更多細(xì)節(jié)。

有時(shí)候?yàn)g覽器也會劫持這種手勢，即使這樣，也沒有那么糟糕。

無論是否需要鎖定整個窗口的放大或者縮小，有時(shí)你也并不希望用戶去縮放整個頁面。為了接管這些多點(diǎn)觸摸，你可以使用一個非常輕量庫叫Hammer.js，這個庫里有一堆手勢，你可以使用內(nèi)置的手勢，也可以創(chuàng)建你自己的。

這有一個很優(yōu)秀的圖片縮放示例網(wǎng)站 imgur.com mobile Website，它能夠檢測你的觸摸方法。

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

總結(jié)

但愿有那么一天，我們不需要再區(qū)分本地應(yīng)用還是Web應(yīng)用。雖然這一天還沒達(dá)到，但只要我們一直努力，使我們的網(wǎng)站讓用戶感受到是為他們量身打造，我相信那天一定會很快到來。

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

他們不關(guān)心你的網(wǎng)站發(fā)出了多少請求，也不在乎你的屏幕渲染得有多快。他們只關(guān)心網(wǎng)站帶給他們體驗(yàn)上的感覺。

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

如果你有更多提高體驗(yàn)性能的建議，請?jiān)谠u論中發(fā)表。

---