靜態化渲染和伺服器渲染二者都為你的APP頁面進行HTML渲染， 然而他們之間有個巨大的差異。。。
複製程式碼

也許你曾聽過靜態化渲染與伺服器渲染，你也知道他們二者都可以提高SEO，讓你的網站或者APP進行生成HTML頁面。當然你也可以使用 ReactDOMServer.renderToString()實現上述兩種目的。

這麼說，他們兩者看上去是一種東西？對吧？他們幾乎幾乎差不多一樣，接下來讓我解釋下。

熱切的靜態化渲染， 慵懶的伺服器渲染

靜態和伺服器渲染都參與到了對HTML的生成， 不同點在於靜態化渲染只在編譯的時候發生一次，然而伺服器渲染則是按需發生根據使用者的每一次請求。

靜態化渲染

當靜態化渲染的時候，你需要在每次使用者訪問前就生成好一個單一的HTML檔案。 接著你把這些生成好的檔案都存放在雲端服務中，比如亞馬遜的S3，或者執行中的Nginx伺服器。

靜態化渲染的優勢在於能夠對伺服器請求做到無腦的快速，因為在處理過程中不需要再去生成什麼檔案。 實際上, 由於你的網站的響應都是提前生成好的，那麼你就可以存放檔案在全世界任何角落的CDN。這樣可以讓你的網站打到一個不可思議的響應速度。但是這也是有代價的。

使用靜態化渲染時，你需要給每一個可能的請求提前生成響應。 對於那些對高質量內容的網站來說，這樣是沒問題的——靜態化渲染工具比如Navi可以在僅僅幾秒內生成上百個網頁。但是如果你需要搭建一些無法預測所以使用者請求的專案，比如一個搜尋引擎？或者你有一堆使用者生成內容，根據每一個請求來改變響應？這種情況的話，你需要的是伺服器渲染。

伺服器渲染

按React的說法，伺服器渲染指的是按照每一個請求生成HTML的過程。通常，你在伺服器上架設一些後端框架比如express或者Next.js，根據每個請求渲染你的React app， 就像更傳統的PHP和Rails框架網站一樣。

伺服器渲染總是慢於靜態內容的。然而，你還得為了讓速度更快些搗鼓一堆東西，當然這樣的延遲是否重要取決於你的商業需求。

當然， 伺服器渲染的速度短板，成就了他的靈活性，它允許你：

• 響應任何使用者發出的請求 —— 即使是你可能沒預想過的
• 從資料庫中抓取最新的內容，而不是過時的靜態檔案
• 對沒授權的使用者選擇性的隱藏內容

那麼我該選哪一個？

這個問題的 ~ 答案 ~ 當然是 ~~~ 看情況

如果靜態渲染可行的話（作者指對於你當前的需求），它是一個快速，低廉，簡單的解決方案。但是，如果你的網站需要達到以下這些需求，你則需要伺服器渲染：

• 如果你不能預測所有可能性的使用者請求
• 如果響應內容需要根據不同使用者進行改變
• 如果響應內容很快過時

請記住，如果需要為每個頁面提供特定的HTML用於SEO，這些需求將僅使伺服器渲染呈現成為必要的選擇。舉個例子，一個社交網路或者線上電商最好還是用伺服器渲染來搭建。

另一方面來說，如果SEO無關緊要的話，例如，一個存在於登入螢幕後面的應用程式 - 然後您的應用程式只需要一個HTML檔案。 在曾經，靜態渲染可能是最好的選擇。但是，最近靜態和伺服器渲染工具的改進大多縮小了簡單性差距。

渲染工具

幾年前當我開始用React來構建網站的時候，不管是靜態還是動態，都很難。我甚至寫了篇文章告訴你別這麼做,但是近年來，改變了很多。

有越來越多基於React的工具來靜態化渲染網站和APP，Gatsby就是個很受歡迎，高強度的選擇。對於一些更簡單的東西，你可以選擇Navi,一個跟Create-react-app一起使用的框架。

對於伺服器渲染，有兩種選擇（作者只提到這兩個），Next.js和Express,使用Next.js，您可以獲得一個開箱即用的完整框架和託管解決方案——同時你的整個專案也繫結到Next.js。如果Next.js對你來說不是好的選擇，你也可以試試比較傳統化的Express。

雞毛蒜皮的小事

最後，讓我解釋您正在閱讀的網站（這裡的網站指原文post的網站frontarm.com）如何運作。 Frontend Armory 是靜態渲染的,每次內容更改時，都會使用Navi重新構建站點，然後將其推送到S3。 然後，當您傳送請求時，它首先會檢查與CloudFront在地理位置上接近您的快取版本，然後再從S3請求它（如果失敗）。

關於原文作者

原文是由 Frontend Armory的編輯James K Nelson發表在Frontend Armory上面的。

譯者語

本篇文章，只是很基本的講解了一下靜態渲染和伺服器渲染的一些基本特點和區別，適合入門新人，對兩種渲染沒有基本概念的讀者。

由於近期對Frontend Armory這個網站的興趣，發現上面有些不錯的前端基本概念文章，所以想以此為長期學習的地方，通過翻譯來提升自己，也幫助他人。