流式 HTML：那個沒人告訴你的前端性能黑科技
你辛苦做了個漂亮的前端應用，在本地測試飛快，但一上線就卡到懷疑人生。用戶點一下，毫無反應；等你的應用終于蘇醒，用戶早就跑了。
今天咱們就聊聊，為什么你的網站加載還是這么慢——并介紹一個神奇的技巧：流式 HTML（Streaming HTML）。
接下來，我們通過一個真實案例（使用 Node.js + React）深入探討問題所在，解釋傳統客戶端渲染（CSR）的弊端，并展示如何只需幾行代碼就大幅提升性能。
為什么你的前端頁面仍然慢到離譜？
現在大多數現代 Web 應用都基于 React、Vue 或 Angular 等前端框架。這些框架強大無比，打造復雜 UI 易如反掌——但問題是：默認采用客戶端渲染（Client-Side Rendering，簡稱 CSR。
CSR 意味著：
- 用戶訪問你的網站時，收到的并不是完整的 HTML。
- 而是一個空的
<div>和超大的 JavaScript 文件。 - JS 下載并執行完畢后，才開始調用 API、渲染頁面，用戶才能看到內容。
如果用戶的網絡慢一點、設備性能差一些，或者你的 API 服務器剛好今天“情緒不穩定”——
那整個過程會漫長無比，用戶感覺遲緩、卡頓，最終直接放棄。
要命的是：這不是用戶的錯，也不是 React 本身的問題，而是架構的問題。
問題本質：瀑布式加載的“死亡循環”
以常見的后臺管理頁面為例，CSR 下訪問該頁面的全過程：
- 瀏覽器請求 HTML 頁面；
- 服務端返回極簡的 HTML 外殼；
- 瀏覽器看到
<script>標簽，開始下載 JS； - JS 下載完畢，開始運行；
- JS 再次調用 API 獲取數據（比如用戶信息）；
- 數據返回后，JS 才開始渲染頁面。
每一步都依賴上一步的完成，就像瀑布一樣逐級等待。
圖片
傳統 CSR 加載示意圖（逐級阻塞）
想象一下，你的 JS 文件很大，比如 2MB，就算網絡不錯也要幾秒，再加上 API 調用的延遲——用戶可能要等上五秒才能看到頁面。
這在網頁性能領域，基本上意味著“死亡”。
圖片
一種常見的解決方案：服務端渲染（SSR）
一種廣為人知的解決方案就是 SSR。
SSR 的思路是服務器預先渲染完整的 HTML 頁面再發送給用戶：
- 用戶瞬間看到頁面內容；
- 瀏覽器再異步加載 JS，接管交互。
但 SSR 也不是萬能藥：對已有項目的改造成本極高，涉及到狀態管理、數據同步、hydration 問題。適合新項目，但舊項目遷移需謹慎。
真正優雅的解法：HTML 流式傳輸（Streaming）
相比 SSR，流式 HTML 更加巧妙：
- 用戶訪問頁面時，服務器立刻返回基本的 HTML 骨架和加載動畫；
- 瀏覽器迅速渲染初始頁面，感覺“響應很快”；
- 與此同時，服務器異步調用非關鍵 API；
- 數據一旦獲取完成，服務器再通過流式傳輸，將 HTML 逐步傳給瀏覽器；
- 瀏覽器同時開始并行下載 JS 文件；
- JS 加載完成時，頁面數據已經就位，直接進行渲染。
看圖更直觀：
圖片
HTML 流式傳輸示意圖（并行處理）
相當于你邊做飯邊洗衣服，而不是做完飯再去洗衣服。節約時間，提升體驗。
圖片
看代碼：Express 實現流式 HTML 傳輸實戰
用 Node.js Express 來演示：
const express = require('express');
const fs = require('fs');
const app = express();
const PORT = 3000;
// 靜態資源服務
app.use(express.static('public'));
// 模擬 API 調用獲取用戶數據
const fetchEmployees = async () => {
const res = await fetch('https://jsonplaceholder.typicode.com/users');
return res.json();
}
// 提前讀取 HTML 模板并拆分為兩段
const [HTML_START, HTML_END] = fs.readFileSync('./public/index.html', 'utf8').split('</body>');
app.get('/server', async (req, res) => {
res.write(HTML_START); // 立即返回 HTML 骨架給瀏覽器
try {
const employees = await fetchEmployees();
// 數據返回后再追加到流中
res.write(`
<script>
const serverEmployees = ${JSON.stringify(employees)};
console.log('Server data:', serverEmployees);
</script>
${HTML_END}
`);
} catch (err) {
console.error('API 錯誤：', err);
res.write(HTML_END);
}
res.end();
});
app.listen(PORT, () => console.log(`服務器啟動：http://localhost:${PORT}`));發生了什么？
- 瀏覽器立即得到 HTML 骨架；
- JS 文件和 HTML 并行加載；
- 服務器端獲取 API 數據后繼續返回 HTML；
- 瀏覽器無需再單獨調用 API，直接渲染頁面。
實踐價值與適用場景
- 更快的首屏渲染，用戶體驗極大提升；
- 無需大規模重構現有項目；
- 并行請求，降低頁面延遲；
- 相比 SSR，更輕量、更靈活。
- 并非所有數據都能提前服務端請求；
- 如果依賴客戶端輸入的數據，仍需 CSR。
適合以下情況：
- 頁面加載時有大量靜態或半靜態數據；
- 無法或不想完全遷移至 SSR；
- 使用的不是 Next.js 等 Meta-Framework（已自帶流式功能）。
性能優化額外小貼士：
- 靜態資源開啟緩存策略；
- 壓縮響應（Gzip/Brotli）；
- JS/CSS 文件最小化；
- 關鍵資源使用
<link rel="preload">； - 持續監測 TTFB（首字節響應時間）與 LCP（最大內容繪制時間）。
別忘了，性能不只是技術指標，更是業務指標！
最后，總結一下我們今天學到的：
? 傳統客戶端渲染延遲體驗嚴重 ? 服務端渲染體驗好，但成本高 ? HTML 流式傳輸兼顧兩者優勢，實操簡單
只要一個簡單的模式切換和一些基礎 Express 代碼，你就能實現更快的頁面加載，創造更好的用戶體驗。
快去試試吧，讓你的用戶重新愛上你的頁面！
