從按下 Enter 到畫面出現，不到一秒鐘，背後卻跑了十幾道工序。
先講結論
這個問題面試必考，但它的價值遠不只是面試。理解這整條流程，會讓你在做效能優化和除錯網路問題時有完全不同的視野。簡單版答案：URL 解析 → DNS 查詢 → TCP 連線 → TLS 握手 → HTTP 請求 → 伺服器處理 → 回傳回應 → 瀏覽器渲染。接下來一步步拆。
DNS 解析：把名字翻譯成地址
你輸入 www.example.com，但網路世界只認 IP 位址。DNS 的工作就是把域名翻譯成 93.184.216.34 這樣的數字。
查詢順序是這樣的：瀏覽器快取 → 作業系統快取 → 路由器快取 → ISP DNS → 最後才是一路從根域名伺服器往下查。大部分情況下，快取就能搞定，所以你感覺不到延遲。
但如果是第一次訪問一個冷門網站？那個多出來的幾十毫秒你可能就有感覺了。這也是為什麼 <link rel="dns-prefetch"> 這種優化有意義。
TCP 三次握手：先確認彼此都在
找到 IP 之後，瀏覽器要跟伺服器建立 TCP 連線。三次握手的過程很像打電話：
- 客戶端：「喂？聽得到嗎？」（SYN）
- 伺服器：「聽到了，你聽得到我嗎？」（SYN-ACK）
- 客戶端：「聽到了！」（ACK）
連線建立完成。如果是 HTTPS（現在幾乎都是），後面還要再跑一輪 TLS 握手——交換加密方式、驗證憑證、產生對稱金鑰。每多一個 round trip 就多一點延遲，這就是為什麼 HTTP/2 的多路複用和連線重用很重要。
HTTP 請求與回應
連線建好之後，瀏覽器送出 HTTP 請求：
GET /index.html HTTP/1.1
Host: www.example.com
Accept: text/html
Accept-Encoding: gzip, deflate, br伺服器收到後做路由處理、跑業務邏輯、可能查一下資料庫，然後回傳：
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600
<!DOCTYPE html>
<html>...到這裡為止都是「網路層」的事。接下來，資料到了瀏覽器手上，輪到它把一堆文字跟程式碼變成你看到的畫面了。
瀏覽器渲染：文字變畫面
這段叫做關鍵渲染路徑（Critical Rendering Path）：
- 解析 HTML → 建立 DOM Tree
- 解析 CSS → 建立 CSSOM
- DOM + CSSOM 合併成 Render Tree
- Layout：算出每個元素的位置跟大小
- Paint：把像素畫到螢幕上
- Composite：合成多個圖層
這裡有個關鍵：遇到 <script> 標籤會暫停 HTML 解析去執行 JS。所以 <script> 放在 <body> 底部、或者加上 defer/async 是有道理的——不是迷信，是因為 JS 真的會擋住渲染。
<!-- 阻塞渲染 -->
<script src="app.js"></script>
<!-- 非同步載入，DOM 解析完才執行（推薦） -->
<script defer src="app.js"></script>
<!-- 非同步載入，載入完立即執行 -->
<script async src="analytics.js"></script>那效能優化怎麼做？
每個階段都有對應的優化手段：DNS 階段用 dns-prefetch，連線階段用 preconnect，請求階段減少 HTTP 請求數量或用 HTTP/2，回應階段開 Gzip 壓縮跟 CDN，渲染階段 CSS 放頭部、JS 放底部或加 defer。
但說真的，不用一次全做。先用 Chrome DevTools 的 Network 面板看看瓶頸在哪，針對性地優化，效果會好很多。
下次面試被問到這題，你不只能回答流程，還能聊聊每一步的優化策略——面試官會很開心。