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

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


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