靜態化渲染和服務器渲染兩者都爲你的APP頁面進行HTML渲染, 然而他們之間有個巨大的差別。。。
複製代碼
也許你曾聽過靜態化渲染與服務器渲染,你也知道他們兩者均可以提升SEO,讓你的網站或者APP進行生成HTML頁面。固然你也可使用 ReactDOMServer.renderToString()實現上述兩種目的。html
這麼說,他們二者看上去是一種東西?對吧?他們幾乎幾乎差很少同樣,接下來讓我解釋下。前端
靜態和服務器渲染都參與到了對HTML的生成, 不一樣點在於靜態化渲染只在編譯的時候發生一次,然而服務器渲染則是按需發生根據用戶的每一次請求。react
當靜態化渲染的時候,你須要在每次用戶訪問前就生成好一個單一的HTML文件。 接着你把這些生成好的文件都存放在雲端服務中,好比亞馬遜的S3,或者運行中的Nginx服務器。數據庫
靜態化渲染的優點在於可以對服務器請求作到無腦的快速,由於在處理過程當中不須要再去生成什麼文件。 實際上, 因爲你的網站的響應都是提早生成好的,那麼你就能夠存放文件在全世界任何角落的CDN。這樣可讓你的網站打到一個難以想象的響應速度。可是這也是有代價的。express
使用靜態化渲染時,你須要給每個可能的請求提早生成響應。 對於那些對高質量內容的網站來講,這樣是沒問題的——靜態化渲染工具好比Navi能夠在僅僅幾秒內生成上百個網頁。可是若是你須要搭建一些沒法預測因此用戶請求的項目,好比一個搜索引擎?或者你有一堆用戶生成內容,根據每個請求來改變響應?這種狀況的話,你須要的是服務器渲染。後端
按React的說法,服務器渲染指的是按照每個請求生成HTML的過程。一般,你在服務器上架設一些後端框架好比express或者Next.js,根據每一個請求渲染你的React app, 就像更傳統的PHP和Rails框架網站同樣。緩存
服務器渲染老是慢於靜態內容的。然而,你還得爲了讓速度更快些搗鼓一堆東西,固然這樣的延遲是否重要取決於你的商業需求。服務器
固然, 服務器渲染的速度短板,成就了他的靈活性,它容許你:網絡
這個問題的 ~ 答案 ~ 固然是 ~~~ 看狀況app
若是靜態渲染可行的話(做者指對於你當前的需求),它是一個快速,低廉,簡單的解決方案。可是,若是你的網站須要達到如下這些需求,你則須要服務器渲染:
請記住,若是須要爲每一個頁面提供特定的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這個網站的興趣,發現上面有些不錯的前端基本概念文章,因此想以此爲長期學習的地方,經過翻譯來提高本身,也幫助他人。