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


SEO全系列文章

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


SSR與CSR比較

  1. Server-Side Rendering
    • 傳統網頁渲染的方式,從Server產生HTML後,再傳送到Client。
    • 需要等待Server產生好HTML,Client才會收到畫面,因此可能會有等待過久的狀況。
  2. 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的解決方案

  1. 先寫在白紙上
    • 在開發SPA的時候,通常都會先有一張index.html的白紙,你可以直接把meta, JSON-LD…先寫在上面,因為只有root裡面的程式比較會影響到。
    • 缺點就是,SPA畢竟是單頁式的網站,所以直接寫在白紙上,會把所有的頁面都當作是同樣的頁面。
  2. 同構 Isomorphic(Universal)
    • 由於要達到SSR效果的目的是為了要讓Search engine讀懂網站的內容是什麼,並非真的要產生網站給Search engine使用,因此只要先寫好Client和Server共用的程式碼,並且在Server就把Client-side的程式碼跑過一遍,就可以達到目的了。
    • 講白一點就是只會render一半,再傳給Client進行完整render的動作,因此流暢度也有明顯的提升。雖然是半殘的SSR,但是為了方便,其實很多人還是會直接叫SSR,而不會叫同構,這是為了方便溝通而稱呼的。
    • 缺點就是開發技術含量很高,不止需要處理Client和Server的程式碼,還要了解Webpack的相依套件如何處理Server渲染的問題。
  3. 使用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,無論如何,還是盡可能避免掉分析的時間過多的狀況。

小結

如果你對如何達到同構 Isomorphic(Universal)的效果,請參考下一篇文章。