前段時(shí)間使用 React 與 Redux 重構(gòu)了我們360netlab 的 開放數(shù)據(jù)平臺?，F(xiàn)將其中一些技術(shù)實(shí)踐經(jīng)驗(yàn)總結(jié)如下：
Universal 渲染
Universal （“同構(gòu)”現(xiàn)在是公認(rèn)的不準(zhǔn)確的叫法）渲染是指在服務(wù)端與客戶端使用一套代碼進(jìn)行渲染的技術(shù)。它所帶來的優(yōu)勢如下：
- 與實(shí)現(xiàn)服務(wù)端渲染的傳統(tǒng)應(yīng)用相比，Universal 渲染中的客戶端渲染減少了網(wǎng)絡(luò)請求（主要是模板和靜態(tài)資源的請求），提高了頁面間切換的速度，可以看到頁面之間的切換都是瞬間完成的。
- 與實(shí)現(xiàn)客戶端渲染的傳統(tǒng) SPA（比如 Angular1.x 搭建的單頁面應(yīng)用）相比，Universal 渲染的服務(wù)端渲染提升了首屏加載速度，無須等待龐大的 Javascript 腳本加載完成后進(jìn)行渲染，因此也無須使用歡迎界面了。
- 與使用不同語言實(shí)現(xiàn)服務(wù)端渲染＋客戶端渲染的應(yīng)用（指的是后端語言為 Java、Python、PHP、前端語言為 JavaScript 的應(yīng)用）相比，由于 Universal 渲染使用同一套代碼（前后端均為 JavaScript），因此至少減少了一半的代碼量。
Universal 渲染非常復(fù)雜，需要權(quán)衡的東西很多。不過這都是值得的，真正讓網(wǎng)站達(dá)到了快如鬼魅的速度！順便引用一句話：
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)查，在一個(gè)頁面的加載過程中，僅僅200毫秒的差異就可以影響用戶的行為。
延遲渲染
很多人抱怨 React 并沒有大家說的那么快，其實(shí) React 只是便于優(yōu)化性能，在沒有經(jīng)驗(yàn)的新手手中，React確實(shí)可能會很慢。但如果你對 React 非常了解，那么快如鬼魅便不是虛言。React 性能優(yōu)化的方法很多，網(wǎng)上也有無數(shù)的文章對其進(jìn)行介紹（選擇 React 的另一好處：活躍的社區(qū)），常見的方法主要是，使用不可變數(shù)據(jù)，快速進(jìn)行變更檢查，以避免不必要的重新渲染。但我們還要介紹一種方法——延遲渲染。
延遲渲染類似于分頁或瀑布流，就是在一個(gè)有大量數(shù)據(jù)頁面中，先渲染一部分，等用戶滾動下去后，再進(jìn)行渲染。
延遲渲染除了可以提升性能之外，還可以過濾掉不需要在服務(wù)端渲染的代碼（服務(wù)端可沒有re-render），以減少 Universal 的難度。
延遲渲染的方法很多，實(shí)現(xiàn)的輪子也很多，不再贅述了。
減小重量
在 React 與 Redux 的項(xiàng)目中，不可避免要引入一些第三方的庫，因此最終打包的腳本重量很容易達(dá)到 500-800kb 以上（gzip 壓縮前）。盡管首屏渲染速度不會受此影響（因?yàn)槲覀儗?shí)現(xiàn)了 Universal 渲染中的服務(wù)端渲染，而瀏覽器又是自上而下解析的），但我們依然希望這個(gè)腳本的重量能夠更小?，F(xiàn)將一些可行的辦法列舉如下：
改變庫的調(diào)用方式
寫過NPM的包的同學(xué)很清楚，一個(gè)包通常會有一個(gè)入口文件，我們將所有的模塊都放在這個(gè)入口文件中，以便其他開發(fā)者調(diào)用。但是如果僅僅只用了一個(gè)包中很少一個(gè)模塊，那么從入口文件調(diào)用就會導(dǎo)致增加了很多多余的模塊。為此，我們應(yīng)該改變一些庫的調(diào)用方式，來避免這種情況，比如：
