logo

EP2 - CSR, SSR, SSG, RSC這些到底是什麼？

hey 大家好 我是Eric 歡迎收聽前端輕鬆聊

這是一個講講前端知識和我在北美工作經驗分享的頻道

如果你覺得這有幫助到你 請幫我五星留言 follow twitter 推廣給其他也在努力的朋友們

今天想聊聊CSR和SSR

現在的你可能覺得這是什麼鬼

CSR是Client side rendering and SSR是 Server side rendering

上一集講到render渲染就是把你的app跑完產生出HTML DOM的過程

那如果你現在是用webpack，create react app，vite然後沒有特別設定的話

你應該是用client side rendering意思就是網站的畫面其實是在使用者的電腦手機產生的

你如果用瀏覽器的開發者工具來看你HTML原始碼是什麼你應該會看到在body tag裡面幾乎沒有東西除了可能一個div

你的比如React app他會開始跑起來決定這個route這個path要跑什麼頁面什麼component最後放在那個div上面

這一系列流程都是在瀏覽器上面執行的

CSR有幾點好處：

  • Project setup很簡單 網路上很多project的模板甚至webpack或Vite都有模板
    git clone git fork基本上你就可以開始開發了
  • deployment也簡單 你也不用一個server 你幾乎只要把這些寫好的html css js某個資料夾裡或是AWS S3 bucket裡面 設定好所有request都繞到你的root html檔 剩下的你的js框架就會處理好了
  • 而且因為你沒有server所以維護上應該相對便宜
  • 現在還有PWA progressive web app 可以做離線的就像手機的app一樣 有需求的話你的SPA也可以這麼做

壞處是：

  • 在沒有cache的情況下 你的網頁可能會挺慢的畢竟browser要下載CSS JS parse完之後才能開始跑然後再給妳當前網頁的畫面
  • SEO其實效果會不太好 搜尋引擎有各自的爬蟲去爬網站資料 大部分資料都得從head tag裡面抓而且除了google的以外其他的其實都不會跑你的JS 換句話說 除了google其他的爬到你的網站其他的會覺得這網站是空的沒資料

如果你的app是當作內部工具 dashboard 比較功能導向不需要SEO的話 那可能client side rendering就夠了

Pre-rendering

之後有了一個叫做prerendering的方案而且很多SaaS服務做這個的

幫你偵測現在的request進來是不是web crawler這可以從useragent甚至哪個IP查然後先在server幫你的app做render返回給web crawler

好處是這樣你不用特別花時間把你的CSR改成SSR

個人覺得壞處是因為你把web crawler和真的user分開了

你不一定會馬上發現SEO可能壞了或是pre-rendering的服務壞了

而且SEO資料更新通常也要等個幾天才會知道

你也可以特別為了這個加進你的testing plan 但個人覺得挺麻煩的而且SEO也不好測試

Server-side rendering

很大的區別是會在server上面先把app render好再把幾乎完整的HTML DOM傳回來給使用者

CSS JS也會傳回來然後經過一個步驟叫做hydration

你的react vue app會在client的瀏覽器load起來，component會找到那些DOM然後把state和event掛上去，這個跑完之後就跟client side rendering的SPA沒什麼兩樣了

好處是：

  • 因為是SSR，任何使用者和爬蟲都能看得懂也能準確抓到head tag裡面的資料。以後把你的網站放在facebook上就不會一片空白沒人點讚。by the way記得follow我的Twitter幫我點讚，如果你沒有Twitter那我幫你辦一個
  • 可以利用後端的cache來幫你的網站優化效能，假設你的app比較重讀取的話比如可能是blog或是電商這種資料不一定會一直變的，那你可以考慮幫你的網站在server上比如用redis cache甚至是用CDN cache。

壞處是：

  • 開發要更加小心因為你寫的code有可能會在server上面跑而一不小心你可能就會把使用者資料流出去了所以通常都會希望是stateless server也就是server不知道request進來的是誰。
  • 除了資料外流這種security reason，還得小心可能會server memory leak之類的因為畢竟你的code會在server上面跑了而如果server掛了然後又沒有cache那等於大家都掛了，不過通常會跟devops的人合作把monitoring和自救的方法setup好比如開兩個instance然後掛了自動重啟之類的。
  • 那同樣的因為接下來你多了一個環境就是server，開發過程可能會稍微繁瑣一點得確定這個component要不要在server跑和server有沒有這個API，最直接的就是server不會有window或document因為這是browser的API，如果沒有做特殊處理是會直接crash的而當你公司每秒十萬上下的時候是很恐怖的。

現在其實每個框架都有自己的SSR方案而且還可以說現在SSR挺盛行的，Angular Universal, Nuxt, Next, Remix, SvelteKit.

Static Site Generator

SSR另一種模式或是更極端的就是在build的時候直接生成一堆HTML，這感覺就像最當初學前端時候開了一堆HTML做不同頁面互相link。

這好處和CSR很像就不需要傳統上的server只要一個S3 bucket就行了當因為這些都是完整編譯好的HTML所以SEO不是問題。

Blog很常用這形式來build因為不會一直更新

React Server Components

最近在React世界裡面大家都在關注個東西叫react server component, RSC

React在2020年時候介紹server components，是一種只會在server上面跑的component，server跑完就會把HTML傳回client

去年開始在Nextjs上面開始做測試然後今年13.4版本中正式成為stable API所以大家可以開始在production上使用

他跟SSR很像但不同的點是

  • SSR會把那些的component的JS bundle傳回來做hydration但server component不會
  • 整體語法會更貼近JS。今天你要在component裡面fetch data 你直接把那個component掛個async你就可以直接await你的promise了
  • 有些限制比如各種hooks不能用 context state effect之類的這種reactive功能的

效能上來講理論上應該是會更快因為看到的畫面速度可能是一樣的但time to interactive會比較快因為不用等JavaScript跑完也不用做平常的hydration

目前Nextjs有非常好的RSC支持也有很好的migration plan而且很多人也開始在試

那跟任何技術一樣 不是新的出來就一定要用 only use it when it makes sense

如果你覺得這項技術可以幫你的project帶來好的影響 可以幫助你解決某個問題 而且也了解使用這個技術的風險 讓你當然可以用

junior 和 senior差別就是senior以上要去想為何要用這個library 為何要用這個技術 用了那你們project要怎麼改之類的

這以後再開一集講好了

如果你覺得這有幫助到你 請幫我五星留言 follow twitter 推廣給其他也在努力的朋友們

如果你喜歡這內容的話幫我在 Twitter 和 Threads 上面分享給其他正在前端這條路上努力的朋友們，也別忘了訂閱我們電子報收到第一手消息喔 🚀