1. 伺服器渲染是必須的
目前有個比較錯誤的分立觀點：“伺服器渲染與單頁面應用的對立。”如果我們真的想最大程度地提升使用者體驗和效能，把這兩者區別對待、互為排斥都不是好的解決方法。
首先，當進行頁面傳送時，網際網路連線本身有個理論速度限制。地理位置上兩點間的傳輸速度受到地域、頻寬、路由等因素影響；減少兩點之間往返的通訊次數顯得尤為關鍵。一個足夠靈活的系統應當能夠均衡好瀏覽器端和伺服器端的程式碼渲染工作，減少網站和網路應用之間的差別。
2. 即時響應使用者輸入
當使用者訪問某個網站時，每個互動動作都應該儘量做到少延遲、快響應。
在HTML中文件的連線是透過超鏈或<a>標籤完成的。當點選這些連結時，瀏覽器會傳送一個請求，這個請求被接收和響應前的用時是無法確定的。相反，JavaScript能夠針對使用者輸入做出即時的響應。例如谷歌或百度，現在我們在其首頁進行輸入時，不用點選搜尋或確定，瀏覽器會自動進入搜尋結果頁面；還有就是智慧提醒，邊輸入邊提醒的功能也是非常人性化的。
只要在Google搜尋欄敲任何一個鍵，都會直接跳入搜尋結果頁面
3. 響應資料/狀態變更
現在無論是採用傳統的頁面重新整理還是AJAX互動來對靜態頁面執行更新都顯得稍稍落伍了。目前更好的做法是自行更新(self-updating)。
如果有款應用同時開啟了多個標籤/頁面，如果使用者進行了登出操作，所有已開啟的標籤都應該能同時失效。要想做到類似的自行更新，狀態協調(state reconciliation)是需要多加考慮的。在只是更新少量資料的參合，我們往往很容易忽略了長時間連線中斷後該如何讓程式作出正確響應。比方說休眠電腦數天後再開啟，我們的程式該如何對這個狀態(如機器狀態標識碼)進行處理呢？如果我們想在初始頁面傳送資料，在客戶端指令碼裝載前必須確保資料是可訪問的。一旦發生連線中斷，指令碼建立的初始連線必須能夠進行會話恢復。
每個頁面都指向了同一個會話和登入狀態
4.控制與伺服器的資料交換
在全球資訊網中，客戶端和伺服器端的資料交換一般限於已下幾種形式：
- 點選連線，GET獲取了新的頁面，然後渲染這個頁面；
- 通過POST或GET提交表單，然後渲染新頁面；
- 非同步裝入一個影像或物件，然後渲染它。
現在網路上有豐富的APIs(如XMLHttpRequest,EventSource)不但能幫助我們很好地控制資料流向，同時能幫助增強使用者體驗，如表單的填寫、傳送。
如前述的狀態協調，如果程式檢測到連線中斷後，把資料暫存起來將能幫助日後的會話恢復。服務工作器(Serviceworker)的引入在這時就變得非常重要了。它能夠讓JavaScript Web應用在後臺執行。即使程式沒有開啟，我們仍然能夠在後臺同步使用者資料。
5.增強歷史記錄處理
一般來說，頁面狀態的過渡依賴於URL的變更；這給我們帶來了增強歷史記錄管控的機會。
當瀏覽歷史頁面時，評論的摺疊狀態應該得到保留
例如，我們通過手機應用檢視商品時，發現了心儀物品，一般情況下如果這時候進行購物車操作都會中止當前介面的訪問；購物完畢後點選返回，如果先前已經翻看了很多頁並滾動到某個位置，如果這時能根據歷史記錄準確地返回之前的位置，使用者會對此非常讚賞的。再譬如，我們填寫了某個表單，如果傳送失敗，點選返回後能自動幫助使用者把已經填好的資料進行恢復，這也是能極大增強使用者體驗的。
6. 推進程式碼變更
如果程式的程式碼發生變更，採用什麼方法來使客戶端對此做出正確響應是很重要的。
一個好的程式碼更新推送機制是如果發現有新的版本，能夠及時提醒客戶端對此進行選擇處理。又或者是在HTTP請求的頭部資訊中附加版本號資訊，讓伺服器針對版本號作出正確處理。
更好的一個處理方法是進行熱程式碼過載(hot code reloading)。它的意思是不需要對整個頁面進行重新整理，而只是對變更關聯部分或模組進行線上更新。這需要對全域性影響進行全面評估，防止部分模組更新後出現其它異常。
7. 預先感知
一個豐富的JavaScript應用能夠有效識別使用者輸入並做出預感反饋。
典型的例子是當滑鼠懸停在某個連結時，伺服器已經開始著手準備資料，這將極大地減少渲染新頁面用時。還有就是能針對滑鼠動作做出互動反饋，如移動，碰撞，移出/入等。
這是一個用jQuery實現的感知滑鼠動作的例子
寫在最後：
Web仍然是當前資訊傳播的最重要媒介之一。當我們不斷為頁面新增動態互動的同時，我們必須確保新技術能很好地做好承上啟下的角色。JavaScript是開拓新局面的當頭先鋒，隨著其使用得更為廣泛更為深入，使用者體驗也會邁進新的臺階。
原文連結：Rauchg
相關閱讀
評論(1)