Simular
近幾年，網站技術日新月異，從傳統的 HTML/CSS 升級到有 Angular/React/Vue 等等前端大型框架，複雜度也越來越高。其中，夏木樂經常被客戶詢問的其中一個問題是：「能不能把網站做成前後端分離？」
由於這個問題並不是單一層面的，完全要依照真實的需求與預算去規劃，所以我們在這邊介紹一下網站的前後端輸出模式，以及講解一下各種不同模式的優缺點。有需要製作網站的朋友，不如趁機檢視自己的需求適合哪一種模式。
網站的前端與後端
首先要講解，什麼是前端與後端？很多人會把這個與前台後台搞混。
前台與後台
「前台」「後台」指的是網站的對外頁面與管理介面，對外給訪客看的稱為「前台」，管理員修改編輯網站的地方稱為「後台」或「管理介面」。
前端與後端
而「前端」與「後端」則是不同的概念，前端指的是瀏覽器上看到的網站程式與畫面，包含HTML/CSS/JS 等，是主要與訪客互動的 UI 介面。而後端指的是伺服器上運作的程式語言與資料庫，可能是 PHP / Ruby / Python / MySQL / PostgreSQL 等。
一個網站要能正常運作，必須是由前端與後端協同運作的。前端是使用者看到的 UI 介面，可以進行操作與互動。而當使用者進行註冊、登入、編輯、儲存等等行為時，會將指令發送到後端，由伺服器運算與處理，這樣就能將內容寫入到資料庫。
網站的輸出模式
而前面提到的 CSR / SSR ，指的就是前端與後端的交互模式。
SSR，又稱為 Server-Side Rendering
SSR 就是指【伺服器輸出畫面】。前面提到，前端的重要性，就是由 HTML/CSS 構成的 UI 介面，可以讓使用者操作與互動。傳統上，大多數網站是由伺服器將 HTML 組合起來，發送到瀏覽器端。所以常見的網站在點擊時，會有明顯的跳頁、切換的感受。這就是因為每次點擊頁面時，伺服器會重新輸出完整的 HTML 頁面，所以頁面會有跳轉的感覺。
CSR，又稱為 Client-Side Rendering
CSR 則是指【客戶端輸出畫面】，這裡的客戶端是指瀏覽器的意思。
也就是說進入網站時，只會收到一次 HTML，之後點擊所有頁面，不會產生跳轉，都是由瀏覽器將這些資料繪製成新的頁面。由於只有一份 HTML 且沒有跳轉的感受，這種網站又稱為 SPA (Single Page Application) 單頁應用程式。也有些人稱之為「前後端分離技術」，近年則有新名詞稱為 JAMStack。
SSR 的特性與優缺點
開發協做簡單，工程師訓練較困難
前面提到 SSR 的特性就是由伺服器輸出每頁的 HTML，所以後端程式同時要處理資料庫存取、網站商業邏輯與前端 HTML / CSS / JS 等等的交互工作，然後再一口氣推送到瀏覽器端。實務上前後端很難分開開發，必須要同時開發，因此一位工程師需要同時了解前端與後端的基本知識，訓練較為困難。
體驗不佳，但 SEO 優良
在體驗上，因為特性是跳轉頁面時會比較有切換的感覺，操作時會有一種中斷感，是一種體驗上的缺點。雖然如此，但是其優點是是 SEO 成效非常好，甚至在高度競爭的 SEO 場合，可能是最推薦的作法。由於每頁都會把完整的 HTML 包含網站內文輸出給使用者，搜尋引擎在爬取時，可以直接得知每一頁有什麼文字內容，進而增進索引效率。而在過去，大多數的搜尋引擎是不支援 JS 的，因此 SSR 變成 SEO 的唯一管道（雖然近年來有些改變，但不影響這個優勢，稍後會詳細說明）。
首次進入網站快
SSR 首次進入網站的速是比較快的，因為 SSR 只會把該頁面需要的內容傳輸給瀏覽器。
而 CSR 是由瀏覽器繪製頁面，這意味者大多數的程式邏輯都放在 HTML/JS 這一邊，首次進入頁面時，要載入比較大包的程式文件，才能開始繪製網站。
故相較之下，SSR 首次進入網站的速度反而較快，這同樣也是增進 SEO 的一個要點。
更適合企業官網或內容網站
由於以上因素，我們可以看到大多數的新聞資訊或雜誌部落格網站，幾乎都是 SSR。企業形象官網，也大多數會選擇 SSR 來增進 SEO。如果您是要做企業網站，或是分秒必爭的行銷網頁，SSR 可能是較好的選擇。
CSR 的特性與優缺點
開發協作較麻煩，工程師訓練較容易
CSR 的網站開發模式較為麻煩，成本也稍高。工程師必須先製作後端程式，編寫成 API，然後再編寫前端的程式，接著前端程式要透過 API 向伺服器呼叫資料，取得 JSON 格式的資料內容，再繪製成前端網站畫面。一般來說，相同功能下，成本會是 SSR 的 1.5倍 - 2 倍，同時也必須區分成前端工程師與後端工程師兩個職位協同運作，會需要密切溝通才能把網站做好。當然優點是，前端與後端的工程師，可以專心學會一門技術就好，訓練較簡單。
操作較流暢
在使用者體驗方面，CSR 的優點是，跳轉頁面的感受比較流暢，你會覺得像是在操作一個軟體，而不是網頁。因此 CSR 在國外大多數用於後台介面、操作介面、應用軟體或 SaaS 軟體服務等等之類，由於需要使用者大量的操作，流暢的介面比較不會讓人感到不耐煩。
首次載入慢、SEO 不佳
而 CSR 的缺點其實也很明顯，首先是首次載入網站較慢，你會看到一個明顯的讀取進度或 讀取畫面 LOGO，跑完之後網站才會顯現出來，這在分秒必爭的 SEO 上是一個明顯的缺點。另外是每頁的 HTML 不含內文等重要資訊，都要後續等待載入，所以搜尋引擎無法得知內文，難以索引。雖然近年來 Google 已經改善了 JS 的讀取機制，可以等待 CSR 繪製頁面，但成效肯定不如 SSR 來得高。且除了 Google 之外，市面上更多其他搜尋引擎如 Yahoo, Bing, 百度等等，不見得每一個引擎的 JS 繪製效果都一樣好，排名差異會很大。最後是，當我們用 Facebook 與 Twitter 分享時，無法根據頁面輸出描述與封面圖，造成使用者分享的困難。
CSR 搭配 SSR
既然 CSR 在 SEO 上有難以改善的缺點，那有沒有辦法補齊這個部分呢，也是有的。近年來，CSR 的相關主流框架，開始支援 SSR 繪製頁面。也就是說，一開始進入網站時，先由伺服器輸出 SSR 的 HTML 頁面，讓搜尋引擎較容易索引，使用者也能更快看到網站。接著 JS 框架引擎會把這個輸出的 HTML 套用到動態程式上面，讓他變成可以動態切換的頁面。這個行為稱為水合（Hydration）。
一次解決所有問題，但成本最高
這算是大型企業或大型網站在使用者體驗與SEO上的終極解決方案，一次可以解決上面提到的雙重問題。但最大的缺點就是，成本非常高，因為所有頁面都要特別提供一個 SSR 的輸出版本。後端除了 API 以外，也必須實作 Server 進程，作為動態吐出 HTML 的 SSR 端點。
外包團隊難找
一般企業做形象網站的話，可能也找不到廠商提供這類服務，因為這種模式的網站，無法用市面上常見的共享型伺服器承載，變成要自己聘請一整個工程團隊才能實作，成本上不是非常划算。簡單來說，這種作法較為適合那種經營一個網站為主體產品，並且整間公司就是靠該網站營利的網路軟體公司或 SaaS 公司較為適合。
常見的誤解
接下來，我們提供一些市面上常見的對 CSR 與 SSR 的誤解，讓企業可以稍微了解實務上如何應用這兩種開發模式。
SSR 的工程師一定要是全端
因為 SSR 不會區分前後端工程師，很多人以為 SSR 就必須是全能型的工程師才能做。但其實SSR 也是可以簡易區分前後端的，例如後端工程師寫資料庫存取的部分，前端工程師進行套版。中間採用模版語法做橋接，這樣就不用特別去學兩種不同的技術（但實務上，通常還是建議雙方要對另一端有一定程度的認識）
做 CSR 就可以同時提供 API 給別人用
由於 CSR 必須先在後端開發 API，很多企業以為這樣就能順便提供 API 給第三方團隊進行應用。實務上雖然做的到，我們強烈不建議這種作法，因為資安非常差。內部使用的 API 通常不會有嚴格的權限控管，但提供給外部用的 API ，最好要有 API Key，必要時可以撤除 API Key 與 AccessToken。而內部用的 API 如果跟外部用的一樣嚴格，又會造成團隊開發成本升高或網站效能降低。因此建議還是要切分成兩個 Entrypoint。
CSR 是未來的趨勢，SSR 將被淘汰
實際上並不會這樣，因為前面提到了搜尋引擎的基本運作原理，無論如何 SSR 依然有他的優勢存在。未來可能會有更多 CSR 的應用軟體，但是內容、新聞、雜誌型網站，或者企業官網，大多還是用 SSR 在商業上會有更好的成效。
Google 未來可以完美的索引 CSR
這個期望已經等了十年了。許多推廣 CSR 的文章最後都會說:「Google 正在強化對 AJAX 的索引能力，未來一定能取代 SSR」，很可惜，這個未來還沒到來。
雖然 Google 確實也越來越能良好的索引 CSR 網站，但實務上目前的成效依然沒有 SSR 來得好。如果您沒有競爭對手，也許還是可以靠內容取勝。但如果您在激烈競爭的 SEO 市場，與對手在一兩名排名上搏鬥時，SSR 網站可能就會輕易的贏得排名。
另外是，首次載入較慢的問題，在 PageSpeed 跑分上面也較難贏得高分 （要注意體感快不見得跑分會高，還是要看 FCP 等等指標）。
網站公司就只會 SSR
非也，夏木樂也專精於 CSR / SPA 網站開發，同時可以研發基於 Vue 的單頁應用。
的確很多網站公司不接 CSR 的網站案件，除了技術選型的差別以外，主要還是 CSR 的成本費用比 SSR 高很多，一般企業不見得願意單純為了 CSR 提升預算。且多數的企業都還是有 SEO 考量，在經過夏木樂分析之後，最後都會接受採用 SSR 製作。
CSR 與 SSR 只能選一個做
並不是，很多網站可能是混合式的。在需要 SEO 的頁面採用 SSR 輸出，在需流暢操作的頁面採用 SPA 設計。具還是看我們對一個網站的期望，還有要解決的問題。有些工程師容易陷入非黑即白的技術切分，但實際上，就連 Github / Google / Facebook 都有很多 SSR 的介面，還是要依照實際需求規劃才有意義。
結論：企業應該選擇適合自己的技術
無論是 SSR 還是 CSR，他們都是經歷 10 多年存活下來的技術，一定有其適合的應用範圍。企業選擇網站建置服務時，不要陷入「某某技術是未來趨勢， 某某技術將被淘汰」的線性思維，而是要從商業、集客的角度出發。
如果是形象官網，使用 SSR 肯定能帶來更好的SEO 排名與集客效果。如果是做應用程式，CSR 肯定能帶來流暢的操作體驗。如果您正經歷 CSR 與 SSR 難以抉擇的狀態，歡迎聯繫夏木樂，我們會提供您專業的技術選擇建議。
