如何加強網站的SEO - SSR與CSR篇

這篇文章將會進一步的講述上次所提到的SSR與CSR，並且進一步的分析如何讓CSR也能達到如SSR的效果。

SEO全系列文章

📌 如何加強網站的SEO - 基礎篇
📌 如何加強網站的SEO - 進階篇
📌 如何加強網站的SEO - SSR與CSR篇
📌 如何加強網站的SEO - 同構篇
📌 如何加強網站的SEO - 框架篇
📌 如何加強網站的SEO - 資安篇

SSR與CSR比較

Server-Side Rendering
- 傳統網頁渲染的方式，從Server產生HTML後，再傳送到Client。
- 需要等待Server產生好HTML，Client才會收到畫面，因此可能會有等待過久的狀況。
Client-Side Rendering
- Modern web的網頁開發框架主要是以CSR為主，通常是SPA的網頁開發框架。
- 程式傳送到Client才產生HTML，所以一開始Client收到的HTML，幾乎是一張白紙，只有進入點（root）。
- SPA藉由先傳送程式碼到Client，來增加Client瀏覽網站的流暢度，在某些情境可以加速載入。

CSR的疑問

你可能看完上面的比較，會覺得CSR看起來似乎優點比SSR還多，那為什麼很多開發者會想解決試圖讓CSR變得像SSR呢？
最主要的原因，又回到的Search engine的議題，由於CSR是先傳送一張白紙給Client
因此也表示Search engine一開始拿到的HTML也是一張白紙，這樣對Search engine來說，他根本無法辨識網站的種類，甚至是內容。
沒錯，儘管你的meta tags和JSON-LD做得多好，那麼都只是做白工而已。

CSR的解決方案

先寫在白紙上
- 在開發SPA的時候，通常都會先有一張index.html的白紙，你可以直接把meta, JSON-LD…先寫在上面，因為只有root裡面的程式比較會影響到。
- 缺點就是，SPA畢竟是單頁式的網站，所以直接寫在白紙上，會把所有的頁面都當作是同樣的頁面。
同構 Isomorphic（Universal）
- 由於要達到SSR效果的目的是為了要讓Search engine讀懂網站的內容是什麼，並非真的要產生網站給Search engine使用，因此只要先寫好Client和Server共用的程式碼，並且在Server就把Client-side的程式碼跑過一遍，就可以達到目的了。
- 講白一點就是只會render一半，再傳給Client進行完整render的動作，因此流暢度也有明顯的提升。雖然是半殘的SSR，但是為了方便，其實很多人還是會直接叫SSR，而不會叫同構，這是為了方便溝通而稱呼的。
- 缺點就是開發技術含量很高，不止需要處理Client和Server的程式碼，還要了解Webpack的相依套件如何處理Server渲染的問題。
使用SPA框架的框架（Next, Nuxt）
- 相信有在開發React, Vue…的人，應該多少會聽過Next和Nuxt這類的框架，這種框架可以在Server端產生好指定路徑的完整HTML。
- 這類的框架主要並非解決SSR的問題，但是他們的出現，讓很多追求網站開發效率的人來說，有很明顯的提升，例如：分類與路徑的分明。
- 雖然優點很多，但是並非所有的專案開發，都會以這個框架為優先選擇，例如行銷頁並不需要做到SSR的效果，主要是以SMO曝光而非SEO，明明靜態網頁可以辦到的事情，為什麼需要以動態網頁的形式來呈現網站內容呢？綜合以上成本考量，因此SPA有時候還是首選，並不需要使用到框架（沒錯，以公司的角度來看，還是要考量到成本效益）

Search engine的解決方案

儘管現在Search engine在分析SPA是這麼的不友善，但是像是Google，宣稱會逐漸針對SPA的SEO進行分析優化，未來也許有一天不必再擔心搜尋曝光一定需要做到類似SSR的效果，但是目前還是建議能先從Server產生HTML為主。因為CSR對Search engine來說，你可以想像是，他們用自己Server的效能和時間去產生HTML，所以分析的時間一定會大於SSR，無論如何，還是盡可能避免掉分析的時間過多的狀況。