從伺服器要資料的那一刻：前端與伺服器的對話

Facebook LinkedIn Tweet

更新日期： 2025 年 4 月 2 日

本文為前端是什麼系列文：

建議閱讀本文前，先理解網際網路是什麼相關概念。若讀完本系列文，可前往閱讀後端是什麼。

當你打開一個網站、點擊一個按鈕或搜尋某個關鍵字時，畫面背後其實正在發生一連串「前端與伺服器的對話」。

這些對話看不見，但卻是讓網站能正常運作的關鍵。

這篇文章將帶你了解這個對話流程，也就是我們常說的「request / response」（請求與回應）。

我們會從基本概念出發，談談 CSR（Client-Side Rendering）與 SSR（Server-Side Rendering）是什麼、它們有什麼差別，並且實際動手做一個小小的資料請求範例，幫助你更深入理解。

瀏覽器與伺服器的互動流程：Request / Response

每當你打開一個網站、點擊一個連結或按下送出按鈕時，其實就是在觸發一段「前端（瀏覽器）和後端（伺服器）之間的溝通過程」。

這個溝通的基礎架構就是 Request（請求） 和 Response（回應）。

什麼是 Request？

Request 是由瀏覽器發出的「請求訊號」，告訴伺服器：「我需要某些資料或服務，請幫我準備。」

這個請求可能包含：

我要的網址（例如：https://example.com/products）
請求的方法（像是 GET 或 POST）
額外的資料（例如：表單輸入的內容、登入憑證）
標頭資訊（Headers，像是告訴伺服器我能讀什麼格式）

什麼是 Response？

Response 是伺服器對請求的回應。

伺服器在收到 Request 後，會根據你提出的需求準備對應的資料，例如 HTML 頁面、JSON 格式的資料、圖片、影音檔案等，然後回傳給瀏覽器。

當 Response 回來後，瀏覽器就能將這些資料顯示在畫面上，或做後續處理。

🍔 用生活例子來理解：像是點餐服務

你（瀏覽器）打電話給餐廳（伺服器），跟他說：「我要一份牛肉麵外帶。」👉 這就是 Request。
餐廳（伺服器）收到請求後，廚房開始準備你的餐點，然後請外送員把牛肉麵送到你家。👉 這就是 Response。

而整個流程的關鍵是：你清楚地表達需求，對方準備好東西，並且成功送回來給你。

常見的 HTTP Request 方法介紹：

在前端開發中，我們經常透過 HTTP 的四大主要方法來和伺服器互動，每一種方法都對應不同的操作。

方法	用途	舉例說明
GET	拿資料	我要「取得」某個產品清單、某篇文章內容，例如：顯示商品列表、顯示使用者資料。
POST	送資料	我要「送出」一筆資料給伺服器，例如：註冊帳號、送出表單、登入。
PUT / PATCH	更新資料	當我想要修改某個已存在的資料，例如：編輯個人資料、更新文章內容。（PUT 通常是「整筆改」，PATCH 是「部分改」）
DELETE	刪除資料	我要刪除某筆資料，例如：移除購物車的項目、刪除使用者帳號。

Request / Response 的基本流程圖

sequenceDiagram
    participant 瀏覽器
    participant 伺服器
    
    Note over 瀏覽器: 使用者操作瀏覽器
    瀏覽器->>伺服器: 發送 Request
    Note over 伺服器: 收到後處理請求
    伺服器->>瀏覽器: 回傳 Response
    Note over 瀏覽器: 收到資料並顯示在畫面上

這整個流程會在幾毫秒～幾秒之間發生完成，對使用者來說幾乎是即時的互動體驗。

🔍 小補充：Request / Response 的技術細節

這樣的溝通是透過 HTTP 或 HTTPS 協議 進行的，確保雙方知道怎麼「講同一種語言」。
當你在瀏覽器中按下 F12（開發者工具），再切到「Network（網路）」頁籤，就可以看到每一次 Request / Response 的詳細紀錄，包含請求的網址、方法、回傳的內容與狀態碼。

CSR 與 SSR 是什麼？

在現代網頁開發中，當我們在討論「一個網站的畫面是怎麼產生的？」時，會遇到兩種很重要的技術概念：

Client-Side Rendering（CSR，客戶端渲染） 與 Server-Side Rendering（SSR，伺服器端渲染）。

這兩者的主要差異在於——「誰」負責把資料變成畫面？

是使用者的瀏覽器（Client）處理？還是伺服器（Server）處理？

下面我們來分別說明。

Client-Side Rendering（CSR）：畫面在瀏覽器端生成

CSR 的意思是：資料從伺服器拿回來後，瀏覽器（前端）再用 JavaScript 把畫面畫出來。

這是目前非常流行的做法，尤其是在使用 React、Vue、Angular 等現代前端框架時幾乎都是走 CSR 的流程。

🛠 CSR 的詳細流程如下：

使用者在瀏覽器輸入網址、進入網站。
瀏覽器下載一個「非常簡單的 HTML 檔案」，這個檔案通常幾乎是空的，只是幫你把 JavaScript 載入進來。
接著瀏覽器會下載 JavaScript 檔案（通常包含整個網站的邏輯與畫面結構）。
JavaScript 開始執行，這時候才向伺服器發出資料請求（例如 API）。
當伺服器把資料回傳後，前端再用 JavaScript 把資料「渲染成畫面」。
使用者看到真正的內容，可能已經過了幾百毫秒甚至幾秒。

flowchart TD
    %% 初始加載流程
    Browser[瀏覽器] -->|1.請求頁面| Server[伺服器]
    Server -->|2.回傳HTML骨架和JS| Browser
    
    %% CSR主要流程
    Browser -->|3.載入JS| Bundle[JavaScript Bundle]
    Bundle -->|4.建立| ReactApp[React/Vue應用]
    ReactApp -->|5.管理| VirtualDOM[Virtual DOM]
    VirtualDOM -->|6.渲染| RealDOM[實際DOM]
    RealDOM -->|7.使用者看到| UI[使用者介面]
   
    
    %% 互動與狀態更新
    UI -->|8.互動| Event[事件觸發]
    Event -->|9.執行| Handler[事件處理函數]
    Handler -->|10.更新| State[應用狀態/Store]
    State -->|11.觸發重新渲染| VirtualDOM
    
    %% 重要概念標註
    ReactApp -.->|管理| Props[Props傳遞]
    ReactApp -.->|維護| StateManagement[狀態管理]
    VirtualDOM -.->|高效| DiffAlgorithm[差異比對演算法]
    
    classDef serverSide fill:#f9d,stroke:#333,stroke-width:1px
    classDef clientSide fill:#adf,stroke:#333,stroke-width:1px
    classDef component fill:#bfb,stroke:#333,stroke-width:1px
    classDef stateFlow fill:#ffa,stroke:#333,stroke-width:1px
    classDef concept fill:#eee,stroke:#999,stroke-width:1px,stroke-dasharray: 5 5
    
    class Server serverSide
    class Browser,Bundle,ReactApp,VirtualDOM,RealDOM,UI clientSide
    class AppComponent,HeaderComponent,MainContent,FooterComponent,ProductList,ProductCard1,ProductCard2 component
    class Event,Handler,State stateFlow
    class Props,StateManagement,DiffAlgorithm concept

🎬 生活比喻：

你訂了一份 IKEA 的家具組裝包裹，打開包裹時，裡面只有說明書、螺絲、木板，還有工具。

你必須依照說明書自己動手把整組家具組裝好，才能真正看到完整的成品。

這就是 CSR——自己在瀏覽器端把一切拼湊出來。

Server-Side Rendering（SSR）：畫面在伺服器端生成

SSR 則是相反的做法：在使用者請求網頁時，伺服器就已經把資料整理好並「生成完整 HTML 頁面」，直接送給瀏覽器。

這種做法其實是比較「傳統」的方式，也常見於許多內容為主的網站或部落格。

🛠 SSR 的詳細流程如下：

使用者打開網站。
瀏覽器向伺服器發出 Request。
伺服器拿到請求後，在後端執行邏輯、抓資料、組成完整的 HTML。
把這個「已經包含畫面與資料」的 HTML 一次送給瀏覽器。
瀏覽器只需要接收並顯示這個 HTML，幾乎不需要額外的處理。
使用者能馬上看到完整的內容，速度快又利於 SEO。

flowchart TD
    %% 初始請求和伺服器端渲染
    Browser[瀏覽器] -->|1.請求頁面| Server[伺服器]
    
    %% 伺服器端處理
    Server -->|2.處理請求| Router[路由處理]
    Router -->|3.呼叫| Controller[控制器]
    Controller -->|4.獲取數據| Database[(資料庫/API)]
    Database -->|5.返回數據| Controller
    Controller -->|6.傳遞數據| TemplateEngine[模板引擎]
    TemplateEngine -->|7.渲染模板| Templates[(模板文件)]
    Templates -->|8.套用數據| TemplateEngine
    TemplateEngine -->|9.生成HTML| HTML[完整HTML]
    
    %% 回傳到客戶端
    HTML -->|10.添加少量JS| EnhancedHTML[增強型HTML]
    Server -->|11.回傳完整HTML| Browser
    
    %% 客戶端處理
    Browser -->|12.解析渲染| VisibleContent[用戶看到完整頁面]
    Browser -->|13.加載JS| EnhancementJS[增強JavaScript]
    EnhancementJS -->|14.添加交互功能| Interactive[增強用戶體驗]
    
    %% 後續請求
    Interactive -->|15.點擊鏈接| NewRequest[新頁面請求]
    NewRequest -->|16.提交表單或請求| Server
    
    %% 技術框架例子
    subgraph "傳統SSR技術"
        PHP["PHP + Laravel/Symfony"]
        Ruby["Ruby on Rails"]
        Python["Python + Django/Flask"]
        NodeJS["Node.js + Express + EJS"]
        Java["Java + Spring MVC + Thymeleaf"]
    end
    
    Server -.->|常用技術| PHP
    Server -.->|常用技術| Ruby
    Server -.->|常用技術| Python
    Server -.->|常用技術| NodeJS
    Server -.->|常用技術| Java
    
    classDef browser fill:#adf,stroke:#333,stroke-width:1px
    classDef server fill:#f9d,stroke:#333,stroke-width:1px
    classDef data fill:#ffd,stroke:#333,stroke-width:1px
    classDef process fill:#dfd,stroke:#333,stroke-width:1px
    classDef tech fill:#f5f5f5,stroke:#999,stroke-width:1px,stroke-dasharray: 5 5
    
    class Browser,VisibleContent,Interactive,NewRequest browser
    class Server,Router,Controller,TemplateEngine,HTML,EnhancedHTML server
    class Database,Templates data
    class EnhancementJS process
    class PHP,Ruby,Python,NodeJS,Java tech

🎬 生活比喻：

像去餐廳點好餐後，餐廳直接幫你把整套餐點端上桌，你不需要自己動手煮。

這就是 SSR——伺服器幫你準備好一切，只要享用就好。

CSR vs SSR 差異總整理：

項目	CSR（Client-Side Rendering）	SSR（Server-Side Rendering）
畫面生成地點	使用者的瀏覽器（前端）	伺服器端
初次載入速度	較慢（要先載入 JS、再請求資料再渲染）	較快（一次拿到已組好的畫面）
SEO 表現	較差（搜尋引擎可能看不到內容）	較好（搜尋引擎能抓到 HTML 內容）
後續互動體驗	非常流暢，支援動態互動	通常要加上前端 JS 才能有互動
技術挑戰	較依賴前端開發技能與架構設計	較依賴後端模板技術或 SSR 框架
適用情境	SPA、Web App、使用者互動多的系統	部落格、商品頁、內容導向且重視 SEO 的網站

那該選哪一種？

想法 / 需求	建議選擇
「我想做像 Gmail、Facebook 那樣的 Web App」	CSR
「我的網站主要是文章、商品頁，需要被 Google 搜尋到」	SSR
「我希望網站初次載入就很快看到內容」	SSR
「我的網頁資料是從外部 API 拿來的，更新頻繁」	CSR
「我使用的是 Next.js / Nuxt」	它們可以混合 SSR + CSR，視需求調整

CSR 對 SEO 的影響是什麼？

為什麼 CSR 會影響 SEO？從搜尋引擎的角度來看

很多剛開始接觸前端開發的同學，會好奇：「CSR（Client-Side Rendering）不是能做出很動態的網站嗎？為什麼會對 SEO 不友善？」

這要從 搜尋引擎（像 Google）是怎麼看你網站的內容 說起。

🔍 搜尋引擎是怎麼抓你網站的內容？

搜尋引擎會透過一種叫做 爬蟲（crawler） 的程式，自動去瀏覽網頁、讀取 HTML 裡的文字內容、連結、標題等等，然後建立搜尋結果的索引（index）。

這些爬蟲最擅長的就是直接讀「HTML 原始碼」。

但問題來了：CSR 的 HTML 一開始是空的。

🧱 CSR 的問題：HTML 裡幾乎沒內容

回顧一下 CSR 的流程，我們知道：

當使用者第一次打開網頁時，伺服器回傳的 HTML 幾乎是空的（只包含一個 <div id="app"></div>）
實際內容（文章、圖片、產品）是等 JavaScript 執行完、資料抓回來後 才動態加到頁面上

✅ 人類看網頁的流程：

等一下畫面就跑出來了 → 看得懂內容 → 沒問題

❌ 搜尋引擎的流程：

拿到的是空的 HTML → 看不到真正內容 → 無法收錄或理解這個頁面

這就會造成 SEO（搜尋引擎最佳化）效果變差 的情況。

⚠️ 會出現什麼具體後果？

你的網頁可能根本不會被 Google 納入搜尋結果
即使收錄了，搜尋結果上也會看不到正確的標題或描述
頁面內容無法被爬蟲理解 → 沒辦法依據關鍵字正確排序
對依賴自然搜尋流量的網站（例如電商、媒體、部落格）來說是大災難

那該怎麼辦？

如果你開發的頁面「非常重視 SEO」，例如：

產品介紹頁（需要被搜尋到）
部落格文章頁（要靠自然流量）
媒體內容頁（如新聞、報導）

那麼你可以考慮這兩種替代方案：

✅ 1. SSR（Server-Side Rendering）

使用伺服器端渲染，讓伺服器直接回傳一份已經包含完整資料的 HTML 頁面，讓爬蟲一進來就能看到內容。

這樣可以確保搜尋引擎能正確抓到你要的內容。

現代框架中：

React → 可以使用 Next.js
Vue → 可以使用 Nuxt

✅ 2. 靜態預渲染（Static Site Generation）

如果你的頁面內容不是經常變動，可以在「建置階段」就把畫面生好，像是「事先烤好的餅乾」，直接放在伺服器上等使用者來吃。

這種方法叫做 預渲染（Pre-rendering） 或 靜態生成（Static Generation），效果就跟 SSR 類似，但執行時效能更好、也更穩定。

也是 Next.js、Nuxt 等框架的功能之一
常與 JAMstack 架構搭配（像是 Markdown 網站、靜態部落格）

小結：CSR ≠ SEO 友善，但不是不能處理

項目	CSR（Client-Side Rendering）	SSR / 靜態生成
首次載入 HTML 是否包含資料？	❌ 幾乎沒有	✅ 有完整內容
搜尋引擎能否讀取頁面資料？	⚠️ 不一定能讀到	✅ 可以
適合哪類網站？	互動性高的系統、內部頁面	重視搜尋流量的公開頁面

CSR 能讓網站看起來更動態、互動性更高，但它天生不太適合拿來處理 SEO 關鍵頁面。

要打造既漂亮又搜尋友善的網站，理解這個限制非常重要。

好消息是，現在很多前端框架都已經支援「混合渲染」策略，讓你在同一個專案中可以選擇哪一頁用 CSR、哪一頁用 SSR 或預渲染，彈性十足！

只要策略正確，就不用擔心 SEO 掉漆啦 😄

結語

前端與伺服器的互動，是現代網頁開發中非常基礎、卻又重要的核心概念。

無論你是初學者，或是剛接觸前後端分離的架構，理解「request / response」的流程、CSR 與 SSR 的差異，會幫助你更有信心地開發動態網站。

記得，網頁不是魔法，而是程式之間有條不紊的對話。

掌握這場對話，你就能掌握畫面背後的世界！

從伺服器要資料的那一刻：前端與伺服器的對話

瀏覽器與伺服器的互動流程：Request / Response

什麼是 Request？

什麼是 Response？

常見的 HTTP Request 方法介紹：

Request / Response 的基本流程圖

🔍 小補充：Request / Response 的技術細節

CSR 與 SSR 是什麼？

Client-Side Rendering（CSR）：畫面在瀏覽器端生成

🛠 CSR 的詳細流程如下：

🎬 生活比喻：

Server-Side Rendering（SSR）：畫面在伺服器端生成

🛠 SSR 的詳細流程如下：

🎬 生活比喻：

CSR vs SSR 差異總整理：

那該選哪一種？

CSR 對 SEO 的影響是什麼？

為什麼 CSR 會影響 SEO？從搜尋引擎的角度來看

🔍 搜尋引擎是怎麼抓你網站的內容？

🧱 CSR 的問題：HTML 裡幾乎沒內容

✅ 人類看網頁的流程：

❌ 搜尋引擎的流程：

⚠️ 會出現什麼具體後果？

那該怎麼辦？

✅ 1. SSR（Server-Side Rendering）

✅ 2. 靜態預渲染（Static Site Generation）

小結：CSR ≠ SEO 友善，但不是不能處理

結語

伺服器是什麼？新手入門指南

新手指南：什麼是第三方金流？

SQL CHECK 約束：確保數據有效性的關鍵機制

跨來源資源共享（CORS）完整指南：打破瀏覽器的安全邊界

GraphQL 如何根據 Query 動態生成 SQL？

新手指南：什麼是 Red Hat？完整介紹與應用解析

關於本站

瀏覽器與伺服器的互動流程：Request / Response

什麼是 Request？

什麼是 Response？

常見的 HTTP Request 方法介紹：

Request / Response 的基本流程圖

🔍 小補充：Request / Response 的技術細節

CSR 與 SSR 是什麼？

Client-Side Rendering（CSR）：畫面在瀏覽器端生成

🛠 CSR 的詳細流程如下：

🎬 生活比喻：

Server-Side Rendering（SSR）：畫面在伺服器端生成

🛠 SSR 的詳細流程如下：

🎬 生活比喻：

CSR vs SSR 差異總整理：

那該選哪一種？

CSR 對 SEO 的影響是什麼？

為什麼 CSR 會影響 SEO？從搜尋引擎的角度來看

🔍 搜尋引擎是怎麼抓你網站的內容？

🧱 CSR 的問題：HTML 裡幾乎沒內容

✅ 人類看網頁的流程：

❌ 搜尋引擎的流程：

⚠️ 會出現什麼具體後果？

那該怎麼辦？

✅ 1. SSR（Server-Side Rendering）

✅ 2. 靜態預渲染（Static Site Generation）

小結：CSR ≠ SEO 友善，但不是不能處理

結語

Similar Posts

關於本站