隨著網(wǎng)站建設技術(shù)的不斷發(fā)展，靜態(tài)渲染已經(jīng)不能滿足現(xiàn)在高要求的網(wǎng)站建站了，在本文中我們將突破靜態(tài)渲染的界限，并學習如何將其應用于個性化內(nèi)容，這種新模式被稱為“分段渲染”。


如果您認為靜態(tài)渲染僅限于對您網(wǎng)站的每個用戶都相同的通用公共內(nèi)容，那么您絕對應該閱讀這篇文章。分段渲染是 Jamstack 的一種新模式，可以讓您靜態(tài)渲染個性化內(nèi)容，無需任何類型的客戶端渲染或每個請求的服務器端渲染。有很多用例：個性化、國際化、主題化、多租戶、A/B 測試……今天的工作是以最佳性能實現(xiàn)此功能。讓我們看看如何做到這一點。提示：我們將介紹一種名為“分段渲染”的新模式。

使用現(xiàn)代 JavaScript 框架呈現(xiàn)網(wǎng)頁的多種方式，Repairing Magazine 用戶界面依賴于現(xiàn)代 JavaScript 庫 React。與其他類似的 UI 庫一樣，React 提供了兩種呈現(xiàn)內(nèi)容的方式：客戶端和服務器端?？蛻舳顺尸F(xiàn) (CSR) 發(fā)生在用戶的瀏覽器中。過去，我們會使用 jQuery 來做 CSR。服務器端渲染發(fā)生在您自己的服務器上，無論是在請求時 (SSR) 還是在構(gòu)建時（靜態(tài)或 SSG）。SSR 和 SSG 也存在于 JavaScript 生態(tài)系統(tǒng)之外。例如，想想 PHP 或 Jekyll。

這樣是有效的，但它是最好的方法嗎？您的服務器必須為每位讀者提供詼諧的笑話。如果有任何事情導致 JavaScript 代碼失敗，付費用戶將無法獲得樂趣，并且可能會生氣。如果用戶的網(wǎng)絡速度慢或計算機速度慢，他們會在下載笑話時看到一個丑陋的加載程序。請記住，大多數(shù)訪問者通過移動設備瀏覽！隨著 API 調(diào)用次數(shù)的增加，這個問題只會變得更糟。請記住，瀏覽器只能并行運行少量請求（通常每個服務器/代理 6 個）。服務器端渲染不受此限制，并且在從您自己的內(nèi)部服務獲取數(shù)據(jù)時會更快。


我們不再依賴客戶端 JavaScript。但是，為每個請求呈現(xiàn)文章并不節(jié)能。Time To First Byte (TTFB) 也增加了，因為我們必須等待服務器完成其工作才能開始看到一些內(nèi)容。我們用更丑陋的空白屏幕替換了丑陋的客戶端加載程序！現(xiàn)在我們甚至為此付出了代價！“stale-while-revalidate”緩存控制策略可以通過提供頁面的緩存版本直到它被更新來減少 TTFB 問題。但它不適用于個性化內(nèi)容，因為它只能緩存每個 URL 的一個頁面版本，而不考慮 cookie，并且無法處理提供付費內(nèi)容所需的安全檢查。


在這一點上，您遇到了我所說的“富客/差客戶”問題：您的高級用戶獲得了最差的性能，而不是獲得了最好的。根據(jù)設計，與靜態(tài)渲染相比，客戶端渲染和按請求服務器端渲染涉及最多的計算，靜態(tài)渲染在構(gòu)建時只發(fā)生一次。我認識的 99% 的網(wǎng)站都會選擇 CSR 或 SSR，并遭受富客/窮客問題的困擾。