react伺服器渲染時在渲染首頁之前請求首頁所需的資料導致短暫的白屏，可以怎樣處理更優雅？

1樓：

（雖然是一年前的問題，但還是很值得研究.）

現代ssr即首屏ssr+csr。題主想說的是怎麼提高首屏ssr這部分的速度以及如何設定和結束客戶端的Loading介面，那要先分析這個階段幹了什麼：

首先，ssr是在伺服器端進行，當接收到http請求時，從請求報文中得到訪問url，然後傳給StaticRouter:location渲染出vdom-tree，再利用ReactDOMSSR.renderToString將vdom-tree序列化為可傳輸資料，最後將資料作為http響應返回給客戶端。

你說的服務端需要請求資料再返回給客戶端，那可以讓StaticRouter先返回乙個/loading頁面，響應頭設定長連線，等到服務端資料請求完整後再響應一次返回最終頁面，響應頭關閉連線。

然後是關於首屏SSR的速度，這取決於你頁面的複雜程度，以及Effect額外計算的隔離。還有就是renderToString是乙個阻塞執行的過程，必須整個頁面全部序列化完畢才能響應，建議替換為renderToNodeStream，以流的形式返回資料。

2樓：陳偉嘉

把資料塞進index.html，這不就是jsp的做法麼？我覺得既然你選用了React，那相對官腔一點，優雅一點的做法肯定是通過請求拉取資料。

所有的白屏都可以用統一的載入進度條來解決，facebook前端設計團隊還有專門研究各種載入進度條，旨在搞出乙個最忽悠使用者心理的進度條，例如下面：

3樓：

1、暴力壓榨效能至肉眼看不了（上快取、加寬頻、加記憶體。。。）2、骨架屏

3、loading

4、流式渲染，也會存在部分白屏

5、bigpipe方案

之後想到其它方案再加

4樓：

分拆請求邏輯，只對響應較短的請求做ssr。長時間的請求只在client端做。一般來說，如果內網返回速度慢還不能調優（比如第三方介面），就沒有必要上isomorphic了。

對於不穩定的API，使用Promise.race做自動降級支援（ssr過慢則交由客戶端渲染）。

另外，如果條件允許，你可以自己做一層cache。

當然，所有前提都是以不能影響使用者首屏速度為準。

5樓：Wang Namelos

最大的問題就是node請求時間，如果非得服務端渲染，主要就得優化call webservice的時間了。

服務端渲染其實比較適合Node本身就是後端的，或者你全內網，響應很快的Web service。

如果你發現沒法優化，那就只能把那塊資料從後端渲染拿掉，比如Redux的話就讓server只給個預設的initialState，等bundle載入之後在前端再請求，其餘比較快的都後端渲染。

Placeholder啥的可以做，但是效果有限，很多動態的東西都不知道咋渲染。