前段時間使用 React 與 Redux 重構(gòu)了我們360netlab 的 開放數(shù)據(jù)平臺。現(xiàn)將其中一些技術(shù)實踐經(jīng)驗總結(jié)如下：

Universal 渲染

Universal （“同構(gòu)”現(xiàn)在是公認的不準確的叫法）渲染是指在服務(wù)端與客戶端使用一套代碼進行渲染的技術(shù)。它所帶來的優(yōu)勢如下：

  1. 與實現(xiàn)服務(wù)端渲染的傳統(tǒng)應(yīng)用相比，Universal 渲染中的客戶端渲染減少了網(wǎng)絡(luò)請求（主要是模板和靜態(tài)資源的請求），提高了頁面間切換的速度，可以看到頁面之間的切換都是瞬間完成的。
  2. 與實現(xiàn)客戶端渲染的傳統(tǒng) SPA（比如 Angular1.x 搭建的單頁面應(yīng)用）相比，Universal 渲染的服務(wù)端渲染提升了首屏加載速度，無須等待龐大的 Javascript 腳本加載完成后進行渲染，因此也無須使用歡迎界面了。
  3. 與使用不同語言實現(xiàn)服務(wù)端渲染＋客戶端渲染的應(yīng)用（指的是后端語言為 Java、Python、PHP、前端語言為 JavaScript 的應(yīng)用）相比，由于 Universal 渲染使用同一套代碼（前后端均為 JavaScript），因此至少減少了一半的代碼量。

Universal 渲染非常復(fù)雜，需要權(quán)衡的東西很多。不過這都是值得的，真正讓網(wǎng)站達到了快如鬼魅的速度！順便引用一句話：

According to research at Google, the difference of just 200 milliseconds in page load performance has an impact on user behavior.

根據(jù) Google 的調(diào)查，在一個頁面的加載過程中，僅僅200毫秒的差異就可以影響用戶的行為。

延遲渲染

很多人抱怨 React 并沒有大家說的那么快，其實 React 只是便于優(yōu)化性能，在沒有經(jīng)驗的新手手中，React確實可能會很慢。但如果你對 React 非常了解，那么快如鬼魅便不是虛言。React 性能優(yōu)化的方法很多，網(wǎng)上也有無數(shù)的文章對其進行介紹（選擇 React 的另一好處：活躍的社區(qū)），常見的方法主要是，使用不可變數(shù)據(jù)，快速進行變更檢查，以避免不必要的重新渲染。但我們還要介紹一種方法——延遲渲染。

延遲渲染類似于分頁或瀑布流，就是在一個有大量數(shù)據(jù)頁面中，先渲染一部分，等用戶滾動下去后，再進行渲染。

延遲渲染除了可以提升性能之外，還可以過濾掉不需要在服務(wù)端渲染的代碼（服務(wù)端可沒有re-render），以減少 Universal 的難度。

延遲渲染的方法很多，實現(xiàn)的輪子也很多，不再贅述了。

減小重量

在 React 與 Redux 的項目中，不可避免要引入一些第三方的庫，因此最終打包的腳本重量很容易達到 500-800kb 以上（gzip 壓縮前）。盡管首屏渲染速度不會受此影響（因為我們實現(xiàn)了 Universal 渲染中的服務(wù)端渲染，而瀏覽器又是自上而下解析的），但我們依然希望這個腳本的重量能夠更小?，F(xiàn)將一些可行的辦法列舉如下：

改變庫的調(diào)用方式

寫過NPM的包的同學很清楚，一個包通常會有一個入口文件，我們將所有的模塊都放在這個入口文件中，以便其他開發(fā)者調(diào)用。但是如果僅僅只用了一個包中很少一個模塊，那么從入口文件調(diào)用就會導致增加了很多多余的模塊。為此，我們應(yīng)該改變一些庫的調(diào)用方式，來避免這種情況，比如：

我想了解如何學習

姓名：
手機：
留言：