網(wǎng)站客戶端的演進發(fā)布者：本站     時間：2019-03-27 20:03:39

客戶端主要有兩種選擇:一種是基于瀏覽器HtML5頁面的，一種是Native模式的。到底是選擇HTML5還是Native， Native 如何解決快速迭代問題?
 
1.是Native還是HTML5
 
當前移動端主要還是以Native實現(xiàn)為主，從用戶體驗角度來考慮，Native的實現(xiàn)要比HTML5更流暢，同時Native還可以基于本地做很多在瀏覽器里不能做的優(yōu)化，如大數(shù)據(jù)的存儲、可以定制的通信協(xié)議、更方便地保持長連接以及更容易實現(xiàn)的實時消息推送。


 
當然HTML5也有無法比擬的優(yōu)勢，比如客戶端更輕量級、服務端發(fā)布更迅速、不需要用戶升級版本等。長期來看，移動端是否會像早期PC那樣從富客戶端轉向瀏覽器呢?筆者覺得未必，理由如下。
 
首先，相比HTMLS， Native實現(xiàn)性能優(yōu)勢更好。當前移動端都在追求極致體驗，App無疑會比HTMLS有更多的優(yōu)勢；其次，移動端屏幕較小，基于網(wǎng)頁的交互和App相比還有很多限制。最重要的是，不同的商家會主推帶有品牌標識的App還是會向統(tǒng)一-的瀏覽器靠攏?從目前的趨勢看，App會是手機端上爭奪的重點，所以筆者推測直接基于手機端的瀏覽器的應用不會成為主流的前端。
 
2. HTML5的頁面優(yōu)化
 
HTMLS頁面優(yōu)化一般可以從以下幾個地方人手。
 
第一，CSS內(nèi)聯(lián)異步加載。如果頁面中有內(nèi)容要依賴CSS的加載，很多時候就會出現(xiàn)白屏一這其實就是CSS阻塞了加載，CSS出不來就導致看不到首屏。CSS內(nèi)聯(lián)加載可以節(jié)省異步HTTP請求，CSS內(nèi)聯(lián)異步加載后可以大大緩解白屏問題。不過，就算內(nèi)聯(lián)以后也要觀察異步CSS文件的大小，并且異步之后要觀察domReady的時間變化。當然CSS內(nèi)聯(lián)也有可能會導致repaint和reflow的問題，并且由于異步內(nèi)容增大，服務端的性能開銷也會增加。
 
第二，其他的優(yōu)化。端上的優(yōu)化已經(jīng)有一整套的優(yōu)化方法列表了， 這里介紹一些我們在實踐中發(fā)現(xiàn)并驗證過的一些特別的優(yōu)化點，如assets 合并、整合頁面中inline的JSICSS到外部文件、將iframe改為JSONP調用、背景圖合并和將非首屏內(nèi)容加載改為異步等。
 
第三，bigpipe首屏加載。2012年的時候，F(xiàn)acebook有一個比較火的技術叫bigpipe，可以提升頁面的首屏加載效果，于是我們嘗試過采用類似的技術測試首屏的加載效果，
 
點擊鏈接http://www.webpagetest.org/video/compare.php?tests=140318 M5_ 7GV%2C140318 Z2 7CJ&thumbSize=200&ival=100&end full，可以通過webpagetest看到頁面的優(yōu)化效果。
 
3. Cookie壓縮
 
在無線場景下要額外注意Cookie，如果沒有留意，它可能會占用你一次無線請求下的大部分內(nèi)容，而且有可能并不會讓你察覺，所以有必要對Cookie進行壓縮測試。Cookie是在HTTP的頭部，通常的gzip和deflate都是針對HTTP body的壓縮但并不能壓縮Cookie，要想對Cookie做壓縮測試必須單獨處理，壓縮方式是將Cookie的多個K/V對看成普通的文本，進行文本壓縮。
 
4. URL短域名
 
URL短域名也很好理解，如果無線數(shù)據(jù)傳輸中有大量的域名，而域名又比較長，就會產(chǎn)生很多無謂的數(shù)據(jù)傳輸，最典型的應用像微博的hp://.cn，可以節(jié)省很多字節(jié)。但是像這種直接使用真實的t.cn的短域名是比較奢華的辦法，比較簡單的是使用約定的標簽替換，在解析時再替換回去。
 
5. CDN前置緩存
 
在有大量靜態(tài)數(shù)據(jù)請求的頁面中使用CDN前置緩存對網(wǎng)站的加速訪問非常有效。對比分析了杭州主站和CDN上的兩張圖片，一張是空圖片，一張是50KB大小的圖片。空圖片用于測試RTT， 50KB的圖片用于測試網(wǎng)速。
 
6.如何實現(xiàn)端的快速迭代
 
前面介紹了無線場景下端的優(yōu)化措施，那么當我們使用Native來實現(xiàn)時，遇到的一個問題是基于App的Native如何解決客戶端更新和服務端的快速迭代問題，一-般有兩種思路:一種是客戶端用同-一種技術開發(fā)，然后通過工具編譯技術把它編譯成不同平臺，上能夠執(zhí)行的代碼，如當前的React Native； 另一種思路是將客戶端中經(jīng)常需要更新的模塊做成動態(tài)推送的，用模板+數(shù)據(jù)的方式，在不同的客戶端平臺上實現(xiàn)一個小的解析引擎來實現(xiàn)快速個性化的定制。
 
那么再說回來，基于前面的這些推斷，網(wǎng)站建設多終端和服務端交互主要是以數(shù)據(jù)+模板的方式為主，那么服務端提供格式化的數(shù)據(jù)將成為必然選項。所以涉及的問題就是服務端既要提供格式化的數(shù)據(jù)( HTTP JOSN數(shù)據(jù))，又要支持傳統(tǒng)的PC的方式:基于JOSN數(shù)據(jù)渲染出HTML頁面。我們在后面會進一步介紹如何解決無線和傳統(tǒng)PC之間的這種差異。