如何實現Next.js混合渲染

本篇內容主要講解“如何實現Next.js混合渲染”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何實現Next.js混合渲染”吧!

寫在前面

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

• SSG(Static Site Generation/Static Generation)：靜態生成，在編譯時生成靜態 HTML

• SSR(Server-Side Rendering)：服務端渲染，用戶請求到來時動態生成 HTML

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

不僅如此，Next.js 還提供了混用支持，能夠將不同渲染模式結合使用，融合互補，例如：

• ISR(Incremental Static Regeneration)：增量靜態再生成，運行時定期重新生成靜態 HTML

• SSG 降級 SSR：未命中預先生成的靜態 HTML 時，立即進行 SSR

• SSR 帶靜態緩存：SSR 完成之后，將結果緩存起來，下次命中靜態緩存直接返回(相當于 SSG)

• SSG 結合 CSR：編譯時生成靜態部分(頁面外框)，CSR 填充動態部分(頁面內容)

• SSR 聯動 CSR：URL 直接訪問走更快的 SSR，SPA 跳轉過來走體驗更優的 CSR

這些細膩的混合渲染支持讓各種渲染模式得以充分發揮其優勢，也讓 Next.js 增色不少

SSG + SSR

SSG 相當于把 SSR  的渲染過程前移到了編譯時，從而優化掉這部分耗時，達到極佳的頁面加載性能。但也存在明顯的缺陷——只能用來渲染靜態內容，使得一個原本很厲害的方案很難有用武之地。那么，有沒有辦法擴大其適用場景?

有。關鍵在于如何理解“靜態”，靜態、動態實際上描述的是內容的變化頻率，幾乎(永遠)不會變，或者變化頻率很低的內容，我們稱之為靜態內容。所以只要想辦法應對內容變化，就有可能把  SSG 的適用場景從經常不變的“靜態內容”擴大到不經常變的“動態內容”

極限情況下，“不經常變”等價于“不是每一次都變”，也就是說，除了實時/個性化等每時每刻都動態變化的內容，其余場景都可以用  SSG，當然，前提是要保障內容能夠按需要的頻率更新生效。內容更新其實就是重新 SSG，所以只缺一個更新時機……

另一個不那么顯而易見的限制是靜態內容的數量，因為渲染工作要在編譯時全部完成，如果靜態數據有 100 萬條，就要編譯生成 100 萬份  HTML，編一次可能需要好幾天……編譯成本(無論時間/機器)會隨內容數量不斷增加，這是 SSG  渲染模式與生俱來的問題，看起來是無解的。除非，編譯時不生成全量頁面……

而面向用戶請求的 SSR 恰好能夠提供合適的更新時機，同時作為編譯的下游，SSR 有機會攔住漏網之魚。于是，SSG 與 SSR 一拍即合，SSG  只編譯生成小部分熱點頁面，其余的在運行時通過 SSR 生成。用戶請求到來時，根據內容是否需要更新來決定該走 SSR 重新生成還是沿用上次生成的產物：

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 擴大了適用場景(高頻變化的內容、編不完的海量內容)，SSR 獲得了性能優勢(靜態緩存)：

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

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

SSG + CSR

與 SSR 相比，SSG 成本更低，本地編譯生成靜態 HTML，托管到 Web 服務器或 CDN  即可享受到預渲染帶來的加載性能提升，沒有應用服務器的高額機器成本，也不用擔心 SSR 在線服務的可用性和運維工作

借助 SSR 擴大 SSG 的應用場景不得不考慮與之俱來的成本問題，那么，有沒有成本更低的辦法?

也有，但體驗上要有所妥協。既然 SSG 擅長渲染靜態內容，不妨對頁面內容進行動靜分離，將頁面上靜態的部分交由 SSG 編譯生成，其余動態部分仍通過 CSR  來填充：

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 結合 CSR，既縮短了頁面加載的白屏時間，又避免了 SSR 的額外成本。不過，美中不足的是加載體驗不如純  SSG，畢竟(用戶可能更關心的)動態內容需要在客戶端二次渲染才能呈現出來，不像 SSG  能夠一次性呈現完整內容。因此，這種方式帶來的更多是體驗提升，用戶感知上頁面載入變快了，算是一種漸進式渲染模式

P.S.關于 SSG 與 CSR 結合的更多信息，見Fetching data on the client side

SSR + CSR

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

hydrate不算，SSR 與 CSR 還有結合點么?

當然有。SSR 能夠有效縮短頁面加載過程中的白屏時間，同時提供頁面內容一次性完整呈現的暢快體驗，與之相比，CSR  渲染性能依賴客戶端環境、數據請求滯后等缺點變得無限大，大到掩蓋了 CSR 的高光優勢：

• 無刷新加載內容

• 可根據用戶行為預加載

這些優勢在首屏加載過程中確實體現不出來，所以單看頁面加載性能的話，SSR 完勝  CSR，二者之中任選一個即可，沒有結合的必要。然而，如果將視角提升到用戶操作的全流程，我們發現 CSR 與 SSR 能夠以非常融洽的方式完美結合：

• 首屏加載走 SSR：無論用戶直接通過 URL 訪問的是首頁還是二級、三級頁，SSR 都能讓頁面以最快的速度呈現出來

• 站內跳轉走 CSR：之后交互操作中的頁面跳轉，通過 CSR 無縫加載新內容，甚至能夠預測用戶行為提前加載目標頁的內容

到此，相信大家對“如何實現Next.js混合渲染”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！