[[357486]]

本文轉(zhuǎn)載自微信公眾號(hào)「前端向后」，作者黯羽輕揚(yáng)。轉(zhuǎn)載本文請(qǐng)聯(lián)系前端向后公眾號(hào)。 

寫在前面

React 生態(tài)中，SSR 支持做得最好的可能是 Next.js，但 SSR 并不是Next.js的全部，只是其提供的預(yù)渲染支持之一：

• SSG(Static Site Generation/Static Generation)：靜態(tài)生成，在編譯時(shí)生成靜態(tài) HTML
• SSR(Server-Side Rendering)：服務(wù)端渲染，用戶請(qǐng)求到來(lái)時(shí)動(dòng)態(tài)生成 HTML

通過各種方式在 CSR 開始之前預(yù)先渲染出頁(yè)面內(nèi)容，從而加快首屏性能，同時(shí)滿足 SEO 的需要，這正是 Next.js 最核心的特性

不僅如此，Next.js 還提供了混用支持，能夠?qū)⒉煌秩灸Ｊ浇Y(jié)合使用，融合互補(bǔ)，例如：

• ISR(Incremental Static Regeneration)：增量靜態(tài)再生成，運(yùn)行時(shí)定期重新生成靜態(tài) HTML
• SSG 降級(jí) SSR：未命中預(yù)先生成的靜態(tài) HTML 時(shí)，立即進(jìn)行 SSR
• SSR 帶靜態(tài)緩存：SSR 完成之后，將結(jié)果緩存起來(lái)，下次命中靜態(tài)緩存直接返回(相當(dāng)于 SSG)
• SSG 結(jié)合 CSR：編譯時(shí)生成靜態(tài)部分(頁(yè)面外框)，CSR 填充動(dòng)態(tài)部分(頁(yè)面內(nèi)容)
• SSR 聯(lián)動(dòng) CSR：URL 直接訪問走更快的 SSR，SPA 跳轉(zhuǎn)過來(lái)走體驗(yàn)更優(yōu)的 CSR

這些細(xì)膩的混合渲染支持讓各種渲染模式得以充分發(fā)揮其優(yōu)勢(shì)，也讓 Next.js 增色不少

SSG + SSR

SSG 相當(dāng)于把 SSR 的渲染過程前移到了編譯時(shí)，從而優(yōu)化掉這部分耗時(shí)，達(dá)到極佳的頁(yè)面加載性能。但也存在明顯的缺陷——只能用來(lái)渲染靜態(tài)內(nèi)容，使得一個(gè)原本很厲害的方案很難有用武之地。那么，有沒有辦法擴(kuò)大其適用場(chǎng)景?

有。關(guān)鍵在于如何理解“靜態(tài)”，靜態(tài)、動(dòng)態(tài)實(shí)際上描述的是內(nèi)容的變化頻率，幾乎(永遠(yuǎn))不會(huì)變，或者變化頻率很低的內(nèi)容，我們稱之為靜態(tài)內(nèi)容。所以只要想辦法應(yīng)對(duì)內(nèi)容變化，就有可能把 SSG 的適用場(chǎng)景從經(jīng)常不變的“靜態(tài)內(nèi)容”擴(kuò)大到不經(jīng)常變的“動(dòng)態(tài)內(nèi)容”

極限情況下，“不經(jīng)常變”等價(jià)于“不是每一次都變”，也就是說(shuō)，除了實(shí)時(shí)/個(gè)性化等每時(shí)每刻都動(dòng)態(tài)變化的內(nèi)容，其余場(chǎng)景都可以用 SSG，當(dāng)然，前提是要保障內(nèi)容能夠按需要的頻率更新生效。內(nèi)容更新其實(shí)就是重新 SSG，所以只缺一個(gè)更新時(shí)機(jī)……

另一個(gè)不那么顯而易見的限制是靜態(tài)內(nèi)容的數(shù)量，因?yàn)殇秩竟ぷ饕诰幾g時(shí)全部完成，如果靜態(tài)數(shù)據(jù)有 100 萬(wàn)條，就要編譯生成 100 萬(wàn)份 HTML，編一次可能需要好幾天……編譯成本(無(wú)論時(shí)間/機(jī)器)會(huì)隨內(nèi)容數(shù)量不斷增加，這是 SSG 渲染模式與生俱來(lái)的問題，看起來(lái)是無(wú)解的。除非，編譯時(shí)不生成全量頁(yè)面……

而面向用戶請(qǐng)求的 SSR 恰好能夠提供合適的更新時(shí)機(jī)，同時(shí)作為編譯的下游，SSR 有機(jī)會(huì)攔住漏網(wǎng)之魚。于是，SSG 與 SSR 一拍即合，SSG 只編譯生成小部分熱點(diǎn)頁(yè)面，其余的在運(yùn)行時(shí)通過 SSR 生成。用戶請(qǐng)求到來(lái)時(shí)，根據(jù)內(nèi)容是否需要更新來(lái)決定該走 SSR 重新生成還是沿用上次生成的產(chǎn)物：

Instead, you may statically generate a small subset of pages and use fallback: true for the rest. When someone requests a page that’s not generated yet, the user will see the page with a loading indicator. Shortly after, getStaticProps finishes and the page will be rendered with the requested data. From now on, everyone who requests the same page will get the statically pre-rendered page.

Inspired by stale-while-revalidate, background regeneration ensures traffic is served uninterruptedly, always from static storage, and the newly built page is pushed only after it’s done generating.

如此這般，SSG 擴(kuò)大了適用場(chǎng)景(高頻變化的內(nèi)容、編不完的海量?jī)?nèi)容)，SSR 獲得了性能優(yōu)勢(shì)(靜態(tài)緩存)：

This ensures that users always have a fast experience while preserving fast builds and the benefits of Static Generation.

P.S.關(guān)于 SSG 與 SSR 結(jié)合的更多信息，見When is fallback: true useful?、Incremental Static Regeneration

SSG + CSR

與 SSR 相比，SSG 成本更低，本地編譯生成靜態(tài) HTML，托管到 Web 服務(wù)器或 CDN 即可享受到預(yù)渲染帶來(lái)的加載性能提升，沒有應(yīng)用服務(wù)器的高額機(jī)器成本，也不用擔(dān)心 SSR 在線服務(wù)的可用性和運(yùn)維工作

借助 SSR 擴(kuò)大 SSG 的應(yīng)用場(chǎng)景不得不考慮與之俱來(lái)的成本問題，那么，有沒有成本更低的辦法?

也有，但體驗(yàn)上要有所妥協(xié)。既然 SSG 擅長(zhǎng)渲染靜態(tài)內(nèi)容，不妨對(duì)頁(yè)面內(nèi)容進(jìn)行動(dòng)靜分離，將頁(yè)面上靜態(tài)的部分交由 SSG 編譯生成，其余動(dòng)態(tài)部分仍通過 CSR 來(lái)填充：

First, immediately show the page without data. Parts of the page can be pre-rendered using Static Generation. You can show loading states for missing data.

Then, fetch the data on the client side and display it when ready.

SSG 結(jié)合 CSR，既縮短了頁(yè)面加載的白屏?xí)r間，又避免了 SSR 的額外成本。不過，美中不足的是加載體驗(yàn)不如純 SSG，畢竟(用戶可能更關(guān)心的)動(dòng)態(tài)內(nèi)容需要在客戶端二次渲染才能呈現(xiàn)出來(lái)，不像 SSG 能夠一次性呈現(xiàn)完整內(nèi)容。因此，這種方式帶來(lái)的更多是體驗(yàn)提升，用戶感知上頁(yè)面載入變快了，算是一種漸進(jìn)式渲染模式

P.S.關(guān)于 SSG 與 CSR 結(jié)合的更多信息，見Fetching data on the client side

SSR + CSR

SSG、SSR、CSR 三者兩兩結(jié)合，最耐人尋味的可能是這第三種——SSR 結(jié)合 CSR

hydrate不算，SSR 與 CSR 還有結(jié)合點(diǎn)么?

當(dāng)然有。SSR 能夠有效縮短頁(yè)面加載過程中的白屏?xí)r間，同時(shí)提供頁(yè)面內(nèi)容一次性完整呈現(xiàn)的暢快體驗(yàn)，與之相比，CSR 渲染性能依賴客戶端環(huán)境、數(shù)據(jù)請(qǐng)求滯后等缺點(diǎn)變得無(wú)限大，大到掩蓋了 CSR 的高光優(yōu)勢(shì)：

• 無(wú)刷新加載內(nèi)容
• 可根據(jù)用戶行為預(yù)加載

這些優(yōu)勢(shì)在首屏加載過程中確實(shí)體現(xiàn)不出來(lái)，所以單看頁(yè)面加載性能的話，SSR 完勝 CSR，二者之中任選一個(gè)即可，沒有結(jié)合的必要。然而，如果將視角提升到用戶操作的全流程，我們發(fā)現(xiàn) CSR 與 SSR 能夠以非常融洽的方式完美結(jié)合：

• 首屏加載走 SSR：無(wú)論用戶直接通過 URL 訪問的是首頁(yè)還是二級(jí)、三級(jí)頁(yè)，SSR 都能讓頁(yè)面以最快的速度呈現(xiàn)出來(lái)
• 站內(nèi)跳轉(zhuǎn)走 CSR：之后交互操作中的頁(yè)面跳轉(zhuǎn)，通過 CSR 無(wú)縫加載新內(nèi)容，甚至能夠預(yù)測(cè)用戶行為提前加載目標(biāo)頁(yè)的內(nèi)容

即，首屏加載工作交給更快的 SSR 來(lái)做，交互過程中讓 CSR 大展身手：

When you request this page directly, getServerSideProps runs at the request time, and this page will be pre-rendered with the returned props.

When you request this page on client-side page transitions through next/link or next/router, Next.js sends an API request to the server, which runs getServerSideProps. It’ll return JSON that contains the result of running getServerSideProps, and the JSON will be used to render the page. All this work will be handled automatically by Next.js, so you don’t need to do anything extra as long as you have getServerSideProps defined.

Next.js 不僅對(duì)這種結(jié)合方式提供了內(nèi)置支持，還能夠自動(dòng)預(yù)加載可視區(qū)域中的站內(nèi)鏈接：

prefetch – Prefetch the page in the background. Defaults to true. Any that is in the viewport (initially or through scroll) will be preloaded. Prefetch can be disabled by passing prefetch={false}.

P.S.關(guān)于 SSR 結(jié)合 CSR 的更多信息，見Only runs on server-side

原文鏈接：https://mp.weixin.qq.com/s/98wxchUHZHcIvfK2pT1DFQ